わかると楽しい Infrastructure as Code

Shohei Kobayashi@srockstyle

アジェンダ• 自己紹介

• Infrastructure as Codeって？

• 実例編

• まとめ

• 2005～2011インフラエンジニア

• 2011～2013フロントエンドエンジニア

• 2014～クラウド・サーバエンジニア

Shohei KobayashiTwitter / Facebook / Github : @srockstyle

サーバエンジニア出戻り組です!

Infrastructure as Codeって？Whats?

その前に インフラ管理の歴史

<前提から説明>

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

サーバ管理・構築は手動が当たり前その昔手順書からコマンドを一行一行コピペしてた

注：写真はイメージです

手順書コピペの弊害• コピペミス

• 依存関係があるとバグる（Aの処理やるまえにBの処理をしなければならないなど）

• 当時はソースからコンパイルが普通だったため止まるのが普通

• （RPM? Yum？なにそれおいしいの？）

サーバは安定して動いてなんぼ

そんなサーバエンジニアが周りから言われること

サーバ稼働率は100%が普通

サーバ？すぐ作れるでしょ

そんなサーバエンジニアですが

プロダクトリリース後

どんな感じかといいますと……

ローンチ打ち上げ飲み会ディレクター・デザイナー・開発チーム

サーバエンジニア

リリース直後のアクセス厳重監視業務

人人人人人人人人人人人人人人人人＿ ＞　サーバエンジニア辛い！！！　＜ ‾Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^

～精神を病んで休職するひと続出～

サーバエンジニアって仕事してなくね？

ディレクター・デザイナー・マーケター・営業・バックオフィス な皆様が抱く疑問

サーバエンジニア

いやいや、プロダクトが動いているってことは 僕らがちゃんと仕事してるってことです!!

よく言われること（これは今でもたまにある）

これがだいたい 7年～9年前の僕ら

僕はちゃんと扱われたくてサーバエンジニア一回やめました

2008～..だいたい最近六年くらい

Chef / Puppetが出てきた• これらはサーバ自動管理ツール

• サーバ設定を記したRubyコードを書いて実行することでサーバをあるべき状態に保つツール。

• 手順書コピペがいらない

• コードがドキュメントなのでそもそも手順書＆ドキュメントという概念がいらない

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

さらに

AWSができた

• サーバ・インフラのクラウドコンピューティング

• クラウド上で操作なのでデータセンターいらない

• サーバを会社の資産にしなくていい

• ハードウェアの故障に悩まされなくなった

• プログラムからAPIを叩くことでインフラ操作可能

ハイパー 革新的！！！

Otherside…• コードでインフラ操作＝あたりまえになる

• 当時はコード書けなくても仕事があった

• いまはコード書けないサーバエンジニア＝ダメ

• アプリケーションのコードを追ってデバッグする力が必要になった。

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

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

Infrastructure as Codeって？Whats?

サーバ・インフラ操作をコードで行うことで効率化し、ミスを少なくする仕組みのこと。

プログラマブルにサーバ操作できるのは古き時代を知っているサーバエンジニアにとっては天国なう。

（コード書けないサーバエンジニアが仕事失うこと以外は）

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

構築編

• Webサーバたてたい

• nginx + Passenger(Rails実行環境)

案件

むかーしむかーしはこれ# 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

全部コマンド手入力&スクリプト＆設定ファイル作成

手でやるとダメなとこ# 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 ←起動する保証は？

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

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

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

あとは以下のコマンドでイナフ

$ knife solo prepare <サーバ名>

<適用設定ファイルを編集>

$ knife solo cook <サーバ名>

注：今度Chef Zeroになってこのコマンドつかえなくなります

もっと何かしたかったですか？がっかりさせてごめんなさい！

これだけです！以外と簡単だよ

これのよいとこ

• 各サーバで同じことを何回もやらなくていい

• 使い回し可能

• コピペミス、依存関係のミスがない

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

運用編

• Webサーバたてて複数台で負荷分散したい

• 今何台くらいあげてればいいのか細かくしりたい

案件

むかーしむかーしはこれ1. 部長に稟議を出します

2. 割とえらいひとの決済を待ちます

3. 機器を買います

4. 届きます

5. データセンターにサーバを持って行ってラッキングします

6. ネットワークにつなぎます

7. 会社に戻ってSSHでつないで作業します

全部コマンド手入力&スクリプト＆設定ファイル作成

• 稟議通るのに時間かかりすぎ

• 社内政治とかでサーバ増やせない

• 経費精算面倒くさい（減価償却とか）

• 減価償却中に新しいサーバでちゃう（ CPUとか）

• データセンター寒いし遠いしお金かかるし行きたくない（僕はこれが嫌でサーバエンジニア一回やめた）

これのダメなとこ

AWS先生！ 出番だよ！

やること単純

一台あたりの負荷をみる

$ uptime / top / vmstat

予想アクセスを裁くだけの仮装サーバを増やす

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

AWS-SDK Ruby V2実例1• Elastic Load Balancerで負荷分散しているので、そのAPIで現在のインスタンス数を取得。

• 以下のコードでとれます。

……作るところ見せたかったんだけどコード間に合いませんでした。。。

以下のAPIがあるので今度つくったらブログとかに書きます。。

AWS-SDK Ruby V2実例2

なんでAuto Scalling じゃないの？

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

One More Thing.

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

• AWSでサーバ・インフラを持っている人向け

• デーモン監視＆リソース監視も完備。

• 状況をみてサーバインスタンスを増やしたり減らしたり最低台数最高台数、インスタンスタイプの設定可能。

• 現状利用料金の値段もわかるよ。

全部AWSAPI叩きまくり

• サーバのリソース状況を1～100で示すフレームワーク。

• Go言語でできてるよ（どこでも動きます）

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

• Auto Scallingのタイムラグがつらかった

Q：コードかければサーバエンジニアになれる？

A：コードかけても、動きや機能を理解してないと作れたとしてもなんとなく動いたになって運用で苦しむから仕事でサーバやるならちゃんと勉強しようね！

★まとめ★

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