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

12,411 views

Published on

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

Published in: Technology
0 Comments
34 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
12,411
On SlideShare
0
From Embeds
0
Number of Embeds
3,151
Actions
Shares
0
Downloads
63
Comments
0
Likes
34
Embeds 0
No embeds

No notes for slide

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

  1. 1. Infrastructure as Codeと 組織のドキュメンテーション + Immutable Infrastructure事例 2014/3/15 JAWS DAYS 2014 Immutable Infrastructureトラック 13:00∼
  2. 2. 誰ですか どんな立場から もの言うんですか?
  3. 3. トラック仕掛け人(初代)の コネで来ました • 曰く • コアメンツでごりごりやろう • AWS臭がしないレーンを実現する 3
  4. 4. ソーシャルベースの印象から いただいた評価 •Chefの神 (千葉県:Aさん) •Chefおじさん (大阪府:Bさん) •そもそも振る舞いがChef
 (神戸市:Cさん) •変態的なChef使い
 (神奈川県:Dさん ※人づて) 4
  5. 5. Chefの本を書きました • 来月、4/12(土)発売予定 • 「Chef活用ガイド ∼ コードではじめる構成 管理」 • Infrastructure as Codeを実践しよう! • 日本公式代理店の
 クリエーションラインさんと
 共著 5 NOW Printing
  6. 6. 『Chef活用ガイド』について • 注意:すぐ使える!とかではない模様 • 公式Docsの流れを踏襲し、さらに詳しく記述 • 解説部分の元ネタは大体ソースコード • Chef本体から離れる話は少なめ • 付録 • 今日のセッションみたいなコラム • Enterpriseアドオン • 全リソース和訳 6 NOW Printing
  7. 7. 運営組織 7 • 代表社員をつとめる合同会社 • アプリケーションのためのプラットフォーム構築/運 用自動化をテーマに活動 • http://opsrock.in 共同開発・運営 • Chef関連を主に取り扱うソリューションを 提供 • 導入支援コンサルも
  8. 8. 本日の内容 1.Infrastructure as Codeと
 組織のドキュメンテーション • ドキュメントにまつわるワークフロー • みなさん既に、なんでもできます 2.Immutable Infrastructure事例 • 外部監視サービス • Zookeeperでステート管理 8
  9. 9. 2 Immutable Infrastructure事例
  10. 10. Immutable Infrastructure • きっと今朝、このトラックで説明があった通 りです。 10
  11. 11. Immutableなデプロイに向く例など • ステータスやローカルにユーザのファイルを 持たないとされるものが中心 • HTTPのロードバランサとか • Railsのアプリケーションプロセスとか • Serfなどのオーケストレーションツールでク ラスタにすると良いなど言われるが… ! • 結構限られた感じ (もちろん作りこめばアリ) 11
  12. 12. クローズドサービス:Giraffi • 国内IaaSサービスのモニタリング/監視機能 を提供、一応SaaS (提供は2011年∼) • 外部監視をユーザごとに個別のNagiosプロ セスが担当 • 仮想基板KVM 12
  13. 13. 最初の構成 • 各NagiosのセッテイングはAPI経由でDBに • GlusterFSでNagios設定ファイルをシェア • 任意の外部監視サーバでプロセス起動 13 GlusterFS AppServer 外部監視サーバ nagios.cfg 外部監視サーバ 外部監視サーバ nagios.cfg nagios.cfg nagios.cfg action_log kick
  14. 14. 課題が • GlusterFSに依存
 => 物理的に近くないと挙動怪しくなる
 => 複数拠点対応が面倒 • 監視サーバの変更は簡単、追加、削除も余裕
 => しかし、障害で落ちたらサーバが担当中の Nagiosがつられていなくなる • その他いろいろ • 監視サーバのデプロイ設計が古いとか、な んか飽きたとか 14
  15. 15. Zookeeperを中心にした ステータス管理へ
  16. 16. Apache ZooKeeper • 分散アプリケーションのためのコーディネーション を行なう • 高速、シンプルなデータモデル • HadoopのNameNodeクラスタ(HA)にもつかわれる • ZooKeeper自身もクラスタを組める、データの管理 はクォーラム制 16
  17. 17. 監視プロセスの持ち方を変更 • Zokeeperにステータス管理を一任 • ロケーション情報 • ユーザの設定 • 監視サーバ担当状況 ! • とにかく監視サーバの数の増減とか死活を気 にしないように設計みなおし 17
  18. 18. location A ZooKeeperを通じた協調動作 18 AppServer 外部監視サーバ 外部監視サーバ location N 外部監視サーバ 外部監視サーバ ・S/C間はコネクション維持 ・新規接続/切断を検出 ・未担当の設定があれば
 誰かが引き継ぐ 多分こいつらが イミュータブル Configure
  19. 19. 運用を突き詰めた結果、 Immutableぽく • 変更はしてもしなくてもよい • サーバ追加時にバージョンの変更もOK • 任意のサーバを廃棄するのも気分次第 • クライアントをグループ定義して、適当に切 り替えればBlue Green風 • Devと一緒に問題点を洗いだし、対策を協議 したら勝手にこうなりました感 19
  20. 20. しかし新構成の本番運用なし • パブリックサービス化も視野に • 2012年秋頃には既にひと通り動作 ! • 諸事情によって刷新リリース未定 • 諸事情とは 20
  21. 21. ZooKeeper補足 • 信頼性はServer/Client間の疎通で保つ • メンバが離れすぎると全体がもっさり 21 ※Google Maps ap-northeast sa-east AWSって便利ね
  22. 22. 1.Infrastructure as Codeと
 組織のドキュメンテーション
  23. 23. Immutable Infrastructure • 大体さっきの事例っぽいかんじ 23
  24. 24. 円滑に実践するには • Infrastructure as Codeを活用するのがよい と思います • サーバほか論理リソースの調達、および構 成管理 • 先の事例でもChefを使用 • shell, puppet, chef, ansible.. syllabus.. ! • 導入したい企業も多いようです 24
  25. 25. • でも本当にこんなもの要るのだろうか? • 導入するとして、どうするのかもわからない
  26. 26. ドキュメント礼賛 https://gist.github.com/azukiwasher/8571505 手順書こそが最善の方策である。
  27. 27. ドキュメント(手順書)の特徴 • 理解できるのは人間だけ • コンピュータにとっては高級すぎる言語 • 行間など、コンテキストがもたらす神秘性 • 作れるのも人間だけ • 制作物としてシェアできる • 親密なコミュニティを形成、人間同士の強 い結束 27
  28. 28. 機械に読解不能であること • インフラの構築とは、人間の企みだ 28
  29. 29. • ワープロで編集する
 手順書 比較1 • 機械で実行??
 Chefのレシピ 29 構築手順書.txt ! 1. 共通パッケージの導入 2. Webサーバ用の設定 3. DBサーバ用の設定
  30. 30. ワークフロー その1
  31. 31. 手順を作成し、シェアしよう 31
  32. 32. シェアされた手順をレビューしよう 32
  33. 33. 検証機でためしてみよう 33 Env: Staging
  34. 34. 検証の結果を元に、承認をもらおう 34
  35. 35. 手順を本番用に書き換えよう 35
  36. 36. 本番へ 36 Env: Production
  37. 37. 鉄板の ワークフロー!
  38. 38. • 人にしかわからない
 文字の羅列 比較1 • 機械が理解できる内容 38
  39. 39. ワークフロー その2
  40. 40. 手順を作成し、シェアしよう 40
  41. 41. シェアされた手順をレビューしよう 41
  42. 42. 検証機でためしてみよう 42 Env: Staging
  43. 43. 検証の結果を元に、承認をもらおう 43
  44. 44. 手順を本番用に書き換えよう 44
  45. 45. 本番へ 45 Env: Production
  46. 46. 鉄板の ワークフロー(再)!
  47. 47. Infrastructure as Codeの 抱える問題 人で置き換えやすい ※手でImmutableやっても全然こまらない 47
  48. 48. そもそもCodeって • 自然言語だってコード • 整形されたテキストで表現されたやたら高級なファ イルももちろんコードです • ドキュメント(コード)を中心にしたワークフローの 形式は確立している • なら記述しやすいうえに実行可能な手順書になって いくのは自然の流れ • ワープロの手順書と、ChefのレシピはOffice97を使 うか、Office2013を使うかくらいの違い、と思いま しょう 48
  49. 49. 既存のワークフローに のっとって 人のやることを 置き換えるだけでも十分 49
  50. 50. 例:serverspecに対して持つ 個人的 な感想 • 作った後にチェック、なんか美しくない... • でも受け入れられる世界なのも理解できるし勧めやすい • ただ、 • どーせお前らログインして… • このコマンド叩いて • この出力確認すんだろ? • そんくらいなら素早く正確にやったるわー
 • という、人をおちょくった機能美がとても好きです 50
  51. 51. イマイチ 納得いかない方のため、 ! もう一つ ワークフロー比較
  52. 52. 障害対応のフロー 1. アラートを受け取って 2. 内容を確認して 3. 既知なら手順に沿って対応する 4. 分からなかったら報告・連絡・相談 52
  53. 53. 障害対応のフロー++ 1. アラートを受け取って
 [受け取り口を用意(Listen)] 2. 内容を確認して
 [パース&チェック] 3. 既知なら手順に沿って対応する
 [ディスパッチ・レスポンス] 4. 分からなかったら報告・連絡・相談
 [ログなど] 53
  54. 54. [小話]
 Webサーバ 運用担当のお仕事
  55. 55. Webサーバ? • Apache httpd • nginx • lighttpd • etc… ! • で、Webサーバ運用担当者が使うのは 55
  56. 56. ところで、インフラの方ならば • telnetでこのくらいのリクエストは日常的に やりますよね? • SMTP • FTP • HTTP • munin-plugin • sslなら openssl s_client とか・・ 56
  57. 57. Netcat +補助的にTCPdump
  58. 58. http://ja.wikipedia.org/wiki/Netcat
  59. 59. $ sudo nc -l 80
  60. 60. Webサーバ手順書一覧 • アクセス許可IPリスト.xlsx • レスポンス手順書.docx • index.html表示手順書.docx 60
  61. 61. 例示:アクセス許可IPリスト.xlsx 61
  62. 62. 担当者はnetcatでサーバ業務開始 • ついでにTCPdumpでアクセス元を監視 • アクセスが来ました!? 62 ※撮影の都合上、8080でやっています
  63. 63. 表で認証チェック! OKです 63
  64. 64. 続いてリクエストチェック! GET /index.html です! 64
  65. 65. index.html手順書 • まず `HTTP/1.0 200 OK` で表示の許可を お伝えします。 • 一行開けます • 続いてコンテンツを送信します、次の文書を コピペして、Ctrl+Dで閉じましょう。 65 <html><body> <h1>Hello World</h1> </body></html>
  66. 66. 捌きました! 66 Web担当者
  67. 67. アクセス増加、 10,000req/分の 人気サイトに! ! どうしましょう・・?
  68. 68. もちろん、増員すりゃいいです 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! 伝説の部長
  69. 69. Web担当部の抱える問題 httpdで置き換えやすい 69
  70. 70. Web運用担当とhttpdを 比較して検討 • 正確とかコストとか色々ありますが • 単位あたりの所用時間が短く • 繰り返し処理に強い • 同じワークフローでも、内容が洗練されてい けば結局こうなる • インフラもそうかもしれない 70
  71. 71. Infrastructure as Code導入のヒント
  72. 72. Chefでこんな相談受けます • 開発環境とかは手でやってます • でもその先とか、本番とかはChefにして、 なんかカッコよく自動でやりたいんです! 72 …Infra as Codeとかって、
 多分そういうことちゃうんよ
  73. 73. 短いスパンで 何度も繰り返そう
  74. 74. Infrastructure as Codeのいいとこ • いろんな段階・レイヤから適用でき、つかい まわせる、というかつかいまわそう • すぐ試せる、何度も失敗できる • そういうツールも沢山 • AWS使うのもいいよね • 便利なツールになれると、さらに応用も利く • アジャイル開発の手法に近づけるのかも 74
  75. 75. ワークフロー、ツールを 書籍執筆にだって応用 75 執筆中(6ヶ月間)は1回も 顔を合わせなかった ※Chef活用ガイドは4月発売予定です
  76. 76. 新しめに見える概念の導入に 意外と課題は少ない • 考え方、ワークフローは(多分)完成してい る。 • 捉え方の問題 • 何の置き換えかを把握して、置き換えられた 事は停止する 76
  77. 77. 最後:テーマについて諸々 1/2 • ただのディスポーザブルちゃうの? • そこらへん、個人的にはあまり違いを意識 していません • 単位がサーバだったりアプリだったりでも通 用する • 例えばCapistranoのデプロイとか、似た ような構造のフローです 77
  78. 78. 最後:テーマについて諸々 2/2 • 適用できそうなところ・レイヤには優先して 適用していけば良いんじゃないか • ZooKeeperの例とかは、多分一般的な構 成ですが、イミュータブルぽかったので紹 介しました 78
  79. 79. おわり。 ! 17:00∼の パネルディスカッションも どうぞよろしく

×