アプリエンジニアからインフラエンジニアになり、AWSでの構築・運用、Infrastructure as codeを実践した上で苦労した点、そしてインフラ目線から今後アプリエンジニアに期待することや、関係性について思うことを話したいと思います。

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

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

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

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

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

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

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

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

9. AWSを触りはじめて

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

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

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

13. 詰まったところ

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

15. よかったところ

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

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

18. Infrastructure as codeへの取り組み

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

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

21. AWS構築のコード化

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

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

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

25. 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/

26. OS∼ミドルウェア構築のコード化

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

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

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

30. デプロイのコード化

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

32. 運用のコード化

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

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

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

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

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

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

39. API Gateway

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

41. 個人的には

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

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

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

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

46. 廃業かな？

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

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

49. 今後のシステム構築
① まずは、サーバレスで構築する方向で進める
（フロントエンド / モバイル ＋ API Gateway / Lambda）
② 厳しければ、EC2上にアプリケーションを作る
②ではインフラエンジニアにも仕事がある。
→ ①がダメなときにしか仕事がない？

50. 今後のシステム構築
① まずは、サーバレスで構築する方向で進める
（フロントエンド / モバイル ＋ API Gateway / Lambda）
② 厳しければ、EC2上にアプリケーションを作る
②ではインフラエンジニアにも仕事がある。
→ ①がダメなときにしか仕事がない？
→ ①もやろう

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

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

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

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

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

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

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

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

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