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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 9,059 views
Published

2014/3/15 …

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

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
9,059
On SlideShare
0
From Embeds
0
Number of Embeds
16

Actions

Shares
Downloads
51
Comments
0
Likes
26

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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