Infrastructure as Codeと 組織のドキュメンテーション + Immutable Infrastructure事例
Upcoming SlideShare
Loading in...5
×
 

Infrastructure as Codeと 組織のドキュメンテーション + Immutable Infrastructure事例

on

  • 5,919 views

2014/3/15

2014/3/15
JAWS DAYS 2014
Immutable Infrastructureトラック
13:00〜

Statistics

Views

Total Views
5,919
Views on SlideShare
4,770
Embed Views
1,149

Actions

Likes
22
Downloads
43
Comments
0

15 Embeds 1,149

http://www.sawanoboly.net 589
http://n-sega.hatenablog.com 238
http://act2012bl.wordpress.com 154
https://twitter.com 80
http://opsrock.in 36
http://sawanoboly.squarespace.com 27
http://s.deeeki.com 8
http://feedly.com 6
https://act2012bl.wordpress.com 5
http://www.slideee.com 1
http://webcache.googleusercontent.com 1
http://sawanoboly.net 1
http://www.slidesharenet.org 1
http://www.google.co.jp 1
http://slideshare-download.seesaa.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Infrastructure as Codeと 組織のドキュメンテーション + Immutable Infrastructure事例 Infrastructure as Codeと 組織のドキュメンテーション + Immutable Infrastructure事例 Presentation Transcript

  • 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サーバ用の設定
  • ワークフロー その1
  • 手順を作成し、シェアしよう 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∼の パネルディスカッションも どうぞよろしく