アプリエンジニアからクラウド専用のインフラエンジニアになってみて

アプリエンジニアから
クラウド専用の
インフラエンジニアになってみて
NRIネットコム株式会社
佐藤瞬
2015/07/24 DevLove関西

誰？
佐藤瞬
NRIネットコム株式会社
福島県会津若松市出身
Amazon Web Services  
パターン別構築・運用ガイド 
書きました

Amazon Web Services
パターン別構築・運用ガイド
AWS本の中で
もっとも分厚い本です

NRIネットコム
Webシステムの企画・設計・開発・運用
Webディレクター／デザイナーも多数在籍
NRIグループとして国内複数ヶ所にデータセンター
もちろん、AWSはじめクラウドにも力を入れています
Web周りのビジネスを専門としている会社

本日のテーマ
クラウド時代のエンジニアの役割 
∼AWSを使い続けて気づいたこと∼

まずは私の経歴から
1. 基幹システムの運用
POSを担当。レジ作ってました。
2. 証券系Webシステムの開発
ガチガチのウォーターフォール
3. AWS上でシステムの構築・運用
ECサイト、業務システム、キャンペーンサイトなど
それなりにアプリやった後
インフラエンジニアにクラスチェンジしました

というわけで、
＊アプリ・インフラ両方を経験している
＊現在はAWSをがっつり触っている
という立場から、今日のテーマについて話していこうと 
思います。

Agenda
アプリエンジニアがAWSを触りはじめて感じたこと
Infrastructures as codeへの取り組み
これからのアプリエンジニアとインフラエンジニアに
ついて思うこと

一番はじめに感じたのは
情報量の多さ

簡単に情報が手に入る
公式ドキュメント 
http://aws.amazon.com/jp/documentation/
Developers.io 
http://dev.classmethod.jp/
ググればSlideShareやQiitaにもたくさん
フレームワークやライブラリについて調べるより遥かに楽

AWSサポート
技術的な疑問や課題に答えてくれる
ビジネスサポート以上であればチャットができる 
→障害時に助かります
日本人が対応してくれるので余計な心配をせず
コミュニケーションできる
調べてよくわからなくても、サポートに聞けばいい

主にネットワーク周り
VPC / Route Table / Internet Gateway / Security Group
VPC∼Security Groupなどのネットワーク周りまで
AWSを使う前にイメージできてなかった
EC2とかRDSは１クリックで立ち上がるもんだと思っ
ていた（ゆとり） 
→思いの外、設定項目が多い

プログラマブルに構築できる
APIですべて操作できる（はず）
SDKが充実 
→ 言語がよりどりみどり。好きなものを選べる 
AWS自体が巨大なフレームワークのような感覚
Java Python (boto) PHP .NET Ruby Node.jsJavaScript

ネットワーク∼仮想マシンまでコード化できる
AWSがプログラマブルに構築できる
Chef/AnsibleなどでOS∼ミドルウェアはコード化できる
ネットワーク∼デプロイまでコード化できる
デプロイもコード化できる

Infrastructure as codeへの取り組み

Infrastructure as codeへの取り組み
コード化の取り組みについて
実際にコード化してみて感じたこと

コード化の種類
AWS構築のコード化
OS∼ミドルウェア構築のコード化
デプロイのコード化
運用のコード化

CloudFormation
AWSのリソースをJSON形式のtemplateで定義
templateに従って自動構築してくれるサービス
AWSリソースのほとんどに対応 
→ 対応してないものもたまにある

CloudFormationの問題
JSONがつらい。
数百行のJSONファイルができあがるので闇が深い
JSONはプログラムで使う分にはいいが、 
人間が使うものではない 
（※個人の感想です）

kumogata
CloudFormationのテンプレートをRubyで書ける
Rubyで書ける意味
コメントが記述できる
同じ処理はループで書ける
ファイルを分割できる 
（require、load、includeを使う）

kumogata
詳しくはGithubのリポジトリを 
https://github.com/winebarrel/kumogata
Web+DB Press 2015年2 月号 
http://gihyo.jp/magazine/wdpress/archive/2015/vol85
Codenize.tools
kumogata以外にもAWSのコード化に便利なツールが 
ってます 
http://codenize.tools/

Chef
クライアントが必要
機能が多く、便利な反面複雑
他のメンバーへの教育が大変
Ansible
手軽さと簡単さは素晴らしくいいが、Playbook
がYAMLなのはつらい
Pythonよく知らない
→ どっちもしっくりこなかった

Itamae
ChefとAnsibleのいいとこ取りしたようなもの
Rubyで書ける（ChefのようなDSL）
クライアント不要（SSH経由で実行可）
覚えることが少ない。すごくシンプル 
→ レシピを実行する以外の機能が特にない
コア部分はSpecinfra

Itamaeのサンプル
以下が参考になります
itamaeのテストコード 
https://github.com/itamae-kitchen/itamae/tree/master/spec/integration/recipes
itamae plugin 
Githubで「itamae plugin」で検索 
→ ChefのCommunity Cookbookのようなことをgemでやってる

デプロイのコード化
AWS SDK + fabric（Pythonのツールの方）
AWSを操作する必要がある部分はSDKでスクリプトを作成
デプロイ前のAMIの取得、EIPの付け替えなど
アプリを置いたり、アプリ起動までの準備などはfabricで
fabricを使ってる理由はシンプルだから

運用のコード化
バックアップ・監視／通知・障害対応など
hubot × Slack（一例）
障害時にAWSコンソールにログインして確認するのは面倒
AWSのAPIをhubotで叩いて情報を取得
主にEC2インスタンスのステータス確認に活躍してます
セキュリティの観点からあまり深いことはやらせていない

といった感じでコード化をすすめてきました

Infrastructure as codeを実践してみて
インフラのコードを書くこと自体は簡単
問題はどのようにインフラを設計するか
結局、インフラの知識が最も重要
コードを書けることよりも、
インフラの知識がどれだけあるかが重要

Infrastructure as codeを実践してみて
プログラマブル ≠ アプリエンジニアの仕事
インフラがプログラマブルに書けるといっても、 
いきなりアプリエンジニアがやるのは難しい
正しくインフラの知識と経験を持った人間が行うべき
コード自体がDSLやYAMLなので形式が決まっており、
コードを書いた経験はあまり重要ではない 
→ もちろん工夫して書けるに越したことはないですが

これからのアプリエンジニアと
インフラエンジニアについて

API Gateway
• APIの作成・管理サービス
• 実質LambdaにEndpointを持たせることができる
• 完全にサーバーレスでサービスが構築可能になる

フロントエンド・モバイルから 
AWS使い放題！！！
超楽しそう！！！
IoT とか夢が膨らむね(^^)

という感じでワクワクでしたが

インフラエンジニアの立場で考えると

構築・運用するインフラがない

API Gatewayのインパクト
今までもAWSのマネージドサービスを使って、なるべく
サーバレスで構築するのが基本だった
それでも中心にはEC2上のアプリケーションがあった 
（BeanstalkもEC2上にアプリがあることは同じ）
しかし、API GatewayによってEC2なしでサービスを構築
することが簡単になった
サーバレスという方向性は前々からあったが、一気に加速した

今後のシステム構築
① まずは、サーバレスで構築する方向で進める 
（フロントエンド / モバイル＋ API Gateway / Lambda）
② 厳しければ、EC2上にアプリケーションを作る

②ではインフラエンジニアにも仕事がある。 
→ ①がダメなときにしか仕事がない？

②ではインフラエンジニアにも仕事がある。 
→ ①がダメなときにしか仕事がない？
→ ①もやろう

インフラエンジニアの仕事
API Gateway自体、アプリかインフラかで分別はできない
特にインフラエンジニアがやっても問題ない
仕事がくるのを待ってるだけではお荷物 
※割れ窓理論 
「建物の窓が壊れているのを放置すると、誰も注意を払っていな
いという象徴になり、やがて他の窓もまもなく全て壊される」
https://ja.wikipedia.org/wiki/割れ窓理論
待ってるだけのインフラエンジニア = 割れm(ry

では、アプリエンジニアは？

アプリエンジニアの仕事
当然、アプリエンジニアも①をやる
そもそもインフラエンジニアだけでは、ビジネスロジック
を完成させるのは難しい
インフラエンジニアをアプリエンジニアがサポートしつつ
完成させていく必要がある

あれ？
結局、インフラエンジニアお荷物では？

アプリとインフラの関係
インフラエンジニアも共に行うことで、
EC2上にアプリケーションを構築する必要になった場合、
• なにが問題だったのか
• どうやったら解決するのか
• アプリケーションにはどのような要件が必要なのか
といった現状を把握しているので、すぐに動き出せる。
また、AWSの知識もアプリエンジニアに共有できる。

アプリとインフラの関係
ただし、
実際にはまだまだEC2が必要
ユーザー認証
RDSとの接続
クローズドなネットワーク

最近の私
でも、素振りはしときましょう
フロントエンドの勉強はじめました
AngularJS、SemanticUI
やっぱりAPI Gatewayと相性がいい 
S3(WebSiteHosting) + API Gateway + Lambda + DynamoDB 
で簡単なアプリを構築中
インフラとフロントエンドが隣り合う技術になった

最後に
本日お話した内容は、あくまで個人の見解です
正直、どうなるかはわからないし、
廃業の危機はやっぱりありますが、
学ぶことは尽きないので楽しんでいきましょう

ご静聴ありがとうございました

アプリエンジニアからクラウド専用のインフラエンジニアになってみて

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to アプリエンジニアからクラウド専用のインフラエンジニアになってみて (20)

アプリエンジニアからクラウド専用のインフラエンジニアになってみて

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.