Infrastructure as Codeと
組織のドキュメンテーション
＋ Immutable Infrastructure事例
2014/3/15
JAWS DAYS 2014
Immutable Infrastructureトラック
13:00∼

誰ですか
どんな立場から
もの言うんですか？

トラック仕掛け人(初代)の
コネで来ました
• 曰く
• コアメンツでごりごりやろう
• AWS臭がしないレーンを実現する
3

ソーシャルベースの印象から
いただいた評価
•Chefの神 (千葉県:Aさん)
•Chefおじさん (大阪府:Bさん)
•そもそも振る舞いがChef
(神戸市:Cさん)
•変態的なChef使い
(神奈川県:Dさん ※人づて)
4

Chefの本を書きました
• 来月、4/12(土)発売予定
• 「Chef活用ガイド ∼ コードではじめる構成
管理」
• Infrastructure as Codeを実践しよう！
• 日本公式代理店の
クリエーションラインさんと
共著
5
NOW
Printing

『Chef活用ガイド』について
• 注意：すぐ使える！とかではない模様
• 公式Docsの流れを踏襲し、さらに詳しく記述
• 解説部分の元ネタは大体ソースコード
• Chef本体から離れる話は少なめ
• 付録
• 今日のセッションみたいなコラム
• Enterpriseアドオン
• 全リソース和訳
6
NOW
Printing

運営組織
7
• 代表社員をつとめる合同会社
• アプリケーションのためのプラットフォーム構築/運
用自動化をテーマに活動
• http://opsrock.in 共同開発・運営
• Chef関連を主に取り扱うソリューションを
提供
• 導入支援コンサルも

本日の内容
1.Infrastructure as Codeと
組織のドキュメンテーション
• ドキュメントにまつわるワークフロー
• みなさん既に、なんでもできます
2.Immutable Infrastructure事例
• 外部監視サービス
• Zookeeperでステート管理
8

2
Immutable Infrastructure事例

Immutable Infrastructure
• きっと今朝、このトラックで説明があった通
りです。
10

Immutableなデプロイに向く例など
• ステータスやローカルにユーザのファイルを
持たないとされるものが中心
• HTTPのロードバランサとか
• Railsのアプリケーションプロセスとか
• Serfなどのオーケストレーションツールでク
ラスタにすると良いなど言われるが…
!
• 結構限られた感じ (もちろん作りこめばアリ)
11

クローズドサービス：Giraffi
• 国内IaaSサービスのモニタリング/監視機能
を提供、一応SaaS (提供は2011年∼)
• 外部監視をユーザごとに個別のNagiosプロ
セスが担当
• 仮想基板KVM
12

最初の構成
• 各NagiosのセッテイングはAPI経由でDBに
• GlusterFSでNagios設定ファイルをシェア
• 任意の外部監視サーバでプロセス起動
13
GlusterFS
AppServer
外部監視サーバ
nagios.cfg
外部監視サーバ
外部監視サーバ
nagios.cfg
nagios.cfg nagios.cfg
action_log
kick

課題が
• GlusterFSに依存
=> 物理的に近くないと挙動怪しくなる
=> 複数拠点対応が面倒
• 監視サーバの変更は簡単、追加、削除も余裕
=> しかし、障害で落ちたらサーバが担当中の
Nagiosがつられていなくなる
• その他いろいろ
• 監視サーバのデプロイ設計が古いとか、な
んか飽きたとか
14

Zookeeperを中心にした
ステータス管理へ

Apache ZooKeeper
• 分散アプリケーションのためのコーディネーション
を行なう
• 高速、シンプルなデータモデル
• HadoopのNameNodeクラスタ(HA)にもつかわれる
• ZooKeeper自身もクラスタを組める、データの管理
はクォーラム制
16

監視プロセスの持ち方を変更
• Zokeeperにステータス管理を一任
• ロケーション情報
• ユーザの設定
• 監視サーバ担当状況
!
• とにかく監視サーバの数の増減とか死活を気
にしないように設計みなおし
17

location A
ZooKeeperを通じた協調動作
18
AppServer
外部監視サーバ
外部監視サーバ
location N
外部監視サーバ
外部監視サーバ
・S/C間はコネクション維持
・新規接続/切断を検出
・未担当の設定があれば
誰かが引き継ぐ
多分こいつらが
イミュータブル
Configure

運用を突き詰めた結果、
Immutableぽく
• 変更はしてもしなくてもよい
• サーバ追加時にバージョンの変更もOK
• 任意のサーバを廃棄するのも気分次第
• クライアントをグループ定義して、適当に切
り替えればBlue Green風
• Devと一緒に問題点を洗いだし、対策を協議
したら勝手にこうなりました感
19

しかし新構成の本番運用なし
• パブリックサービス化も視野に
• 2012年秋頃には既にひと通り動作
!
• 諸事情によって刷新リリース未定
• 諸事情とは
20

ZooKeeper補足
• 信頼性はServer/Client間の疎通で保つ
• メンバが離れすぎると全体がもっさり
21
※Google Maps
ap-northeast sa-east
AWSって便利ね

1.Infrastructure as Codeと
組織のドキュメンテーション

Immutable Infrastructure
• 大体さっきの事例っぽいかんじ
23

円滑に実践するには
• Infrastructure as Codeを活用するのがよい
と思います
• サーバほか論理リソースの調達、および構
成管理
• 先の事例でもChefを使用
• shell, puppet, chef, ansible.. syllabus..
!
• 導入したい企業も多いようです
24

• でも本当にこんなもの要るのだろうか？
• 導入するとして、どうするのかもわからない

ドキュメント礼賛
https://gist.github.com/azukiwasher/8571505
手順書こそが最善の方策である。

ドキュメント(手順書)の特徴
• 理解できるのは人間だけ
• コンピュータにとっては高級すぎる言語
• 行間など、コンテキストがもたらす神秘性
• 作れるのも人間だけ
• 制作物としてシェアできる
• 親密なコミュニティを形成、人間同士の強
い結束
27

機械に読解不能であること
• インフラの構築とは、人間の企みだ
28

• ワープロで編集する
手順書
比較1
• 機械で実行??
Chefのレシピ
29
構築手順書.txt
!
1. 共通パッケージの導入
2. Webサーバ用の設定
3. DBサーバ用の設定

ワークフロー
その１

手順を作成し、シェアしよう
31

シェアされた手順をレビューしよう
32

検証機でためしてみよう
33
Env: Staging

検証の結果を元に、承認をもらおう
34

手順を本番用に書き換えよう
35

本番へ
36
Env: Production

鉄板の
ワークフロー！

• 人にしかわからない
文字の羅列
比較1
• 機械が理解できる内容
38

ワークフロー
その2

手順を作成し、シェアしよう
40

シェアされた手順をレビューしよう
41

検証機でためしてみよう
42
Env: Staging

検証の結果を元に、承認をもらおう
43

手順を本番用に書き換えよう
44

本番へ
45
Env: Production

鉄板の
ワークフロー(再)！

Infrastructure as Codeの
抱える問題
人で置き換えやすい
※手でImmutableやっても全然こまらない
47

そもそもCodeって
• 自然言語だってコード
• 整形されたテキストで表現されたやたら高級なファ
イルももちろんコードです
• ドキュメント(コード)を中心にしたワークフローの
形式は確立している
• なら記述しやすいうえに実行可能な手順書になって
いくのは自然の流れ
• ワープロの手順書と、ChefのレシピはOffice97を使
うか、Office2013を使うかくらいの違い、と思いま
しょう
48

既存のワークフローに
のっとって
人のやることを
置き換えるだけでも十分
49

例：serverspecに対して持つ
個人的 な感想
• 作った後にチェック、なんか美しくない．．．
• でも受け入れられる世界なのも理解できるし勧めやすい
• ただ、
• どーせお前らログインして…
• このコマンド叩いて
• この出力確認すんだろ？
• そんくらいなら素早く正確にやったるわー
• という、人をおちょくった機能美がとても好きです
50

イマイチ
納得いかない方のため、
!
もう一つ
ワークフロー比較

障害対応のフロー
1. アラートを受け取って
2. 内容を確認して
3. 既知なら手順に沿って対応する
4. 分からなかったら報告・連絡・相談
52

障害対応のフロー++
1. アラートを受け取って
[受け取り口を用意(Listen)]
2. 内容を確認して
[パース＆チェック]
3. 既知なら手順に沿って対応する
[ディスパッチ・レスポンス]
4. 分からなかったら報告・連絡・相談
[ログなど]
53

[小話]
Webサーバ
運用担当のお仕事

Webサーバ?
• Apache httpd
• nginx
• lighttpd
• etc…
!
• で、Webサーバ運用担当者が使うのは
55

ところで、インフラの方ならば
• telnetでこのくらいのリクエストは日常的に
やりますよね？
• SMTP
• FTP
• HTTP
• munin-plugin
• sslなら openssl s_client とか・・
56

Netcat
+補助的にTCPdump

http://ja.wikipedia.org/wiki/Netcat

$ sudo nc -l 80

Webサーバ手順書一覧
• アクセス許可IPリスト.xlsx
• レスポンス手順書.docx
• index.html表示手順書.docx
60

例示：アクセス許可IPリスト.xlsx
61

担当者はnetcatでサーバ業務開始
• ついでにTCPdumpでアクセス元を監視
• アクセスが来ました！？
62
※撮影の都合上、8080でやっています

表で認証チェック! OKです
63

続いてリクエストチェック!
GET /index.html です！
64

index.html手順書
• まず `HTTP/1.0 200 OK` で表示の許可を
お伝えします。
• 一行開けます
• 続いてコンテンツを送信します、次の文書を
コピペして、Ctrl+Dで閉じましょう。
65
<html><body>
<h1>Hello World</h1>
</body></html>

捌きました！
66
Web担当者

アクセス増加、
10,000req/分の
人気サイトに！
!
どうしましょう・・？

もちろん、増員すりゃいいです
68
Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者
Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者
Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者Web担当者
Netcat!
Netcat! Netcat!
Netcat!
伝説の部長

Web担当部の抱える問題
httpdで置き換えやすい
69

Web運用担当とhttpdを
比較して検討
• 正確とかコストとか色々ありますが
• 単位あたりの所用時間が短く
• 繰り返し処理に強い
• 同じワークフローでも、内容が洗練されてい
けば結局こうなる
• インフラもそうかもしれない
70

Infrastructure as
Code導入のヒント

Chefでこんな相談受けます
• 開発環境とかは手でやってます
• でもその先とか、本番とかはChefにして、
なんかカッコよく自動でやりたいんです！
72
…Infra as Codeとかって、
多分そういうことちゃうんよ

短いスパンで
何度も繰り返そう

Infrastructure as Codeのいいとこ
• いろんな段階・レイヤから適用でき、つかい
まわせる、というかつかいまわそう
• すぐ試せる、何度も失敗できる
• そういうツールも沢山
• AWS使うのもいいよね
• 便利なツールになれると、さらに応用も利く
• アジャイル開発の手法に近づけるのかも
74

ワークフロー、ツールを
書籍執筆にだって応用
75
執筆中(6ヶ月間)は1回も
顔を合わせなかった
※Chef活用ガイドは4月発売予定です

新しめに見える概念の導入に
意外と課題は少ない
• 考え方、ワークフローは(多分)完成してい
る。
• 捉え方の問題
• 何の置き換えかを把握して、置き換えられた
事は停止する
76

最後：テーマについて諸々 1/2
• ただのディスポーザブルちゃうの?
• そこらへん、個人的にはあまり違いを意識
していません
• 単位がサーバだったりアプリだったりでも通
用する
• 例えばCapistranoのデプロイとか、似た
ような構造のフローです
77

最後：テーマについて諸々 2/2
• 適用できそうなところ・レイヤには優先して
適用していけば良いんじゃないか
• ZooKeeperの例とかは、多分一般的な構
成ですが、イミュータブルぽかったので紹
介しました
78

おわり。
!
17:00∼の
パネルディスカッションも
どうぞよろしく