Creators MeetUP Vol22で発表した資料です！ 最後にサプライズあるよ！ インフラをコードで説明することってなあにっていう話です！

1. わかると楽しい
Infrastructure as Code
Shohei Kobayashi@srockstyle

2. アジェンダ
• 自己紹介
• Infrastructure as Codeって？
• 実例編
• まとめ

3. • 2005∼2011インフラエンジニア
• 2011∼2013フロントエンドエンジニア
• 2014∼クラウド・サーバエンジニア
Shohei Kobayashi
Twitter / Facebook / Github : @srockstyle
サーバエンジニア出戻り組です!

4. Infrastructure as Codeって？
Whats?

5. その前に
インフラ管理の歴史
<前提から説明>

6. LongLongTime Ago..
僕が社会人始めた2005年くらい

7. サーバ管理・構築は手動が当たり前
その昔手順書からコマンドを一行一行コピペしてた
注：写真はイメージです

8. 手順書コピペの弊害
• コピペミス
• 依存関係があるとバグる（Aの処理やるまえにBの
処理をしなければならないなど）
• 当時はソースからコンパイルが普通だったため止ま
るのが普通
• （RPM? Yum？なにそれおいしいの？）

9. サーバは安定して動いてなんぼ
そんなサーバエンジニアが周りから言われること
サーバ稼働率は100%が普通
サーバ？すぐ作れるでしょ

10. そんなサーバエンジニアですが
プロダクトリリース後
どんな感じかといいますと……

11. ローンチ打ち上げ飲み会
ディレクター・デザイナー・開発チーム
サーバエンジニア
リリース直後のアクセス厳重監視業務

12. 人人人人人人人人人人人人人人人人＿
＞ サーバエンジニア辛い！！！ ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^
∼精神を病んで休職するひと続出∼

13. サーバエンジニアって仕事してなくね？
ディレクター・デザイナー・マーケター・営業・バックオフィス
な皆様が抱く疑問
サーバエンジニア
いやいや、プロダクトが動いているってことは
僕らがちゃんと仕事してるってことです!!
よく言われること（これは今でもたまにある）

14. これがだいたい
7年∼9年前の僕ら
僕はちゃんと扱われたくてサーバエンジニア一回やめました

15. 2008∼..
だいたい最近六年くらい

16. Chef / Puppetが出てきた
• これらはサーバ自動管理ツール
• サーバ設定を記したRubyコードを書いて実行する
ことでサーバをあるべき状態に保つツール。
• 手順書コピペがいらない
• コードがドキュメントなのでそもそも手順書＆ドキュ
メントという概念がいらない

17. 革新的！
注：写真はイメージです

18. さらに

19. AWSができた
• サーバ・インフラのクラウドコンピューティング
• クラウド上で操作なのでデータセンターいらない
• サーバを会社の資産にしなくていい
• ハードウェアの故障に悩まされなくなった
• プログラムからAPIを叩くことでインフラ操作可能

20. ハイパー
革新的！！！

21. Otherside…
• コードでインフラ操作＝あたりまえになる
• 当時はコード書けなくても仕事があった
• いまはコード書けないサーバエンジニア＝ダメ
• アプリケーションのコードを追ってデバッグする力
が必要になった。

22. サーバエンジニアも
コードの読み書きできないと仕事がない

23. 時代はDevOps
でぶおぷすがあたりまえのじだいに

24. Infrastructure as Codeって？
Whats?
サーバ・インフラ操作をコードで行うことで効率化し、
ミスを少なくする仕組みのこと。
プログラマブルにサーバ操作できるのは古き時代を知っ
ているサーバエンジニアにとっては天国なう。
（コード書けないサーバエンジニアが仕事失うこと以外は）

25. 実践
じゃあコードで実際どうやってサーバしてるの？

26. 構築編
• Webサーバたてたい
• nginx + Passenger(Rails実行環境)
案件

27. むかーしむかーしはこれ
# gem install passenger
# passenger-install-nginx-module
# vi /opt/nginx/conf/nginx.conf
# vi /etc/init.d/nginx
# chmod 700 /etc/init.d/nginx
# /etc/init.d/nginx start
全部コマンド手入力&スクリプト＆設定ファイル作成

28. 手でやるとダメなとこ
# gem install passenger←Passengerのバージョンは？
# passenger-install-nginx-module ←プロンプト面倒
# vi /opt/nginx/conf/nginx.conf ←作るの面倒
# vi /etc/init.d/nginx ←スクリプトデバッグは？
# chmod 700 /etc/init.d/nginx ←権限間違うとヤバス
# /etc/init.d/nginx start ←起動する保証は？

29. なうな構築・管理はChefを使いまっす

30. Chefだとこんな風に書けます実例1

31. Chefだとこんな風に書けます実例2

32. あとは以下のコマンドでイナフ
$ knife solo prepare <サーバ名>
<適用設定ファイルを編集>
$ knife solo cook <サーバ名>
注：今度Chef Zeroになってこのコマンドつかえなくなります

33. もっと何かしたかったですか？
がっかりさせてごめんなさい！
これだけです！
以外と簡単だよ

34. これのよいとこ
• 各サーバで同じことを何回もやらなくていい
• 使い回し可能
• コピペミス、依存関係のミスがない

35. Githubにレシピいろいろ上がってるよ

36. 運用編
• Webサーバたてて複数台で負荷分散したい
• 今何台くらいあげてればいいのか細かくしりたい
案件

37. むかーしむかーしはこれ
1. 部長に稟議を出します
2. 割とえらいひとの決済を待ちます
3. 機器を買います
4. 届きます
5. データセンターにサーバを持って行ってラッキングします
6. ネットワークにつなぎます
7. 会社に戻ってSSHでつないで作業します
全部コマンド手入力&スクリプト＆設定ファイル作成

38. • 稟議通るのに時間かかりすぎ
• 社内政治とかでサーバ増やせない
• 経費精算面倒くさい（減価償却とか）
• 減価償却中に新しいサーバでちゃう（ CPUとか）
• データセンター寒いし遠いしお金かかるし行きたく
ない（僕はこれが嫌でサーバエンジニア一回やめた）
これのダメなとこ

39. AWS先生！ 出番だよ！

40. やること単純
一台あたりの負荷をみる
$ uptime / top / vmstat
予想アクセスを裁くだけの仮装サーバを増やす

41. この作業を自動化します
Auto Scalling使わないのって質問は後で答えるね

42. AWS-SDK Ruby V2実例1
• Elastic Load Balancerで負荷分散しているので、そのAPIで現在の
インスタンス数を取得。
• 以下のコードでとれます。

43. ……作るところ見せたかったんだけどコード間に合いませんでした。。。
以下のAPIがあるので今度つくったらブログとかに書きます。。
AWS-SDK Ruby V2実例2

44. なんでAuto Scalling じゃないの？
自動でインスタンス増やす機能がAWSにあるんだ。
なんでそれを使わないかって説明の前に！

45. One More Thing.

46. 僕がつくったサーバ監視ツール・オープンソースで公開するよ
会社でつくったから会社のGithubで近々公開予定。

47. • AWSでサーバ・インフラを持っている人向け
• デーモン監視＆リソース監視も完備。
• 状況をみてサーバインスタンスを増やしたり減らし
たり最低台数最高台数、インスタンスタイプの設定
可能。
• 現状利用料金の値段もわかるよ。
全部AWSAPI叩きまくり

48. • サーバのリソース状況を1∼100で示すフレーム
ワーク。
• Go言語でできてるよ（どこでも動きます）

49. なんでAuto Scalling じゃないの？
• 細かい設定しまくりたかった
• 会社のデプロイタイミング、予算状況などに合わせた
監視体制をつくりたかった
• Auto Scallingのタイムラグがつらかった

50. Q：コードかければサーバエンジニアになれる？
A：コードかけても、動きや機能を理解してないと作
れたとしてもなんとなく動いたになって運用で苦しむ
から仕事でサーバやるならちゃんと勉強しようね！
★まとめ★

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