(メモ)20140722 TechTalk Ryuzeeさん Infrastructure as Code / Immutable Infrastructureのキホン

20140722 TechTalk Ryuzeeさん Infrastructure as Code / Immutable Infrastructureのキホン

• 写真は @TAKAKING22 より

• 弊社社内勉強会でRyuzeeさんがしゃべってくれました。

• この人の話はいつも、ネタを詰め込みまくってるんだけど、テーマを構成する一連のトピックがちゃんと繋がるように話してくれます。

• 断片化している知識がつながってスッキリした人も多いんじゃないかな？

• 僕は記憶を整理して、シナプスを繋ぎ直すために見直す事があります。

• 資料をゲットできたら整理します。

自動化が必要な背景

• ビジネスは変化していくよね
• １発狙いは大抵外れる
• 　　手数は多く
• 　　でも計測できないと次につながらないよね
• 　　Lean MVPの話
• 　　　　顧客の期待に応え続けるフィードバックの速度を維持するには。。？
• 　　AWSの場合、毎年前年比倍程度のプロダクトを世に出している
• 　　利用者の反応を見て、作るものを決めるスタイル

キホン：ビッグバンは避ける

• 　　小さい単位でリリースを
• 　　AWSを例に挙げると、平日は11秒強の間隔でリリースを行っている

キホン：資料待ち

Infrastructure as Codeのメリット

• ステークホルダーに説明を求められた際に答えられるようになっておこう。
• 　　資料のp.17を見てね

Infrastructure as Codeの基本理念

• 冪等性の話

Infrastructure as Codeのデメリット

• 学習コスト、準備に時間がかかる
• メンテナンスが必要
• 雑に作ると、保守にかえって時間がかかることがある

キホン：連続体として捉える

自動化しないリスク

• 前提：作業は繰り返し行われる

• やればやるほどリスクの顕在化の確率は上がるよね

• 手順書がメンテされない

• 手作業でまちがう

• 職人芸への依存

• リリース失敗・戻し失敗

• 長時間作業と失敗確率増大

• リリースに自信を持てなくなる。。

• プロセスが重くなる
  -　人海戦術に頼ることになり、技術的負債が蓄積していく。。

• じゃあ自動化する？

• 　　WHYをちゃんと持とう

• 　　ROIを意識しよう　少額で自動化できるところから。

• コストの考え方

• 　　手作業で実施した場合のコスト比較

• 　　リスクの顕在化への対処コストを含めて考えよう

• 　　ただし、損益分岐点は思った以上に早い

• 　　ビジネスの要求とマッチする場所を自動化しよう

• 　　　　年数回しか行わない作業を自動化するより、頻度の高いものから自動化しよう

• p.37 自動化するか、考えないといけない場所

キホン：自動化の5R

• Rapid
• Reliable
• Repeatable
• Reduce Risk
• Rollback

キホン：プロジェクトの最初から始める

• 開発プロセスの中で、自動化の仕組みを洗練していこう

キホン：ちゃんと顧客や周りの許可を得よう

キホン：全員で取り組む

キホン：カイゼンを続ける

デプロイの自動化

キホン：デプロイしやすいアーキテクチャーの維持
- デプロイしやすいように維持→疎結合（ステートレス）であるといいよね

• Amazonの6つの指針

キホン：デプロイ自動化に必要な要素
p.47

キホン：バージョン管理

• これを知らない人に開発コードを書かせてはいけない
• ブランチモデル

キホン：自動化されたテスト

• 早期に問題を解決し続けるほうがコストが安い
• どこまでテストを用意するか？→プロセスとして設計する
• 　　ex. 人の生き死にがかかってなければ、最悪の場合デプロイ後に発見＆修正してもよし！

キホン：デプロイしやすい

• マイグレーション
• 　　依存関係、前後関係の解決は人間だと難しい→機械にまかせよう

キホン：CI

• ここまでできていればCIできるよね
• プロジェクトの生命線だ
• CIのアンチパターン
• 　　CIサーバのリソースが貧弱
• 　　？？ケースが肥大化
• 　　→　時間がかかるんだよね
• AWSだと並列にCIを回せる→富豪的アプローチ

？？？？？資料待ち

p.59 キホン：デプロイプロセス設計

キホン：粒度を小さく

• ロールバックも簡単になるしね

• デプロイのよくあるパターン

• 　　バリエーションはできるだけ少なく　大規模・小規模の２種くらいがいい

• 　　アンチパターン

• 　　　　手作業を混ぜると失敗のリスクが高まる→何回もリリース作業を繰り返すからね

• 　　　　デプロイスクリプトは複雑になるからよくない

• blue green deploy

• 　　リスクの軽減

• 　　ABテスト

• 　　　　メリットたくさんだよね

• 　　→クラウドがAPIで制御でき、プラガブルに操作できるからこそ

• FacebookのようなABCD...テストも簡単

• PaaSならなお簡単

• EBSでワンクリックデプロイ

• 　　最近はDockerも対応したよ

キホン：デプロイ失敗の検知をおこなう

• スモークテスト

• 監視と検知

• あとからデプロイ自動化する場合

プロビジョニング自動化

• p.77 進め方

• 　　ツールの選択は押し付けるのではなく、チームに合ったものを選ぼう

• OpsWorksの話

• CloudFormationの話

• p.84 AMI作成の３つの選択肢

• 　　OpenStackなどでもそのまま使える考え方

• 　　Packer+Chef-soloで自動化出来る

• 　　　　自動化できる＝CIできる！

• Chefを使った構成例

• Chef

• 　　soloだといずれ破綻する

• 　　Ohai使って頑張れなくもないが。。

• 　　test書こう 現状ServerSpec一択

• 　　　　test-kitchen + Bats/Rspecなどもあるが、、 via. http://docs.opscode.com/kitchen.html

• Infraの人がコードを書けなくてもいい時代は終わった。

• 自動化しやすい物を選択しよう

• Chef CookbookもCIしよう

Immutable Infrastructure

• ここまでの流れとどう違うの？
• 　　一度S-inしたものには手を加えない

• 　　使いすてちゃう考え方

• 従来のInfrastructure as Codeの問題

• 　　常にサーバの状態を同一に保つのは結構難しい

• 　　　　Chefの冪等性。。はあるが、担保するのは至難

• 　　　　　　そこを諦めたのがDocker

• Immutable Infrastructureのメリット

• Immutable = インフラを秘伝のタレ化しない

• 　　いつでも新しいものと簡単に入れ替える

• 　　なのでCIしないとね

• Immutable Infrastructureを実現するには？

• 　　ステートレス！

• 　　　　そのサーバに依存する仕組みがあってはならない。

• 　　　　逆にDBなど状態を持つものはImmutableにならない、できない

• 　　　　

Docker

• Dockerとは？

• Dockerと仮想マシンの対比

• 　　ホストから隔離されていて軽く早い＝ポータビリティあり

• Dockerの特徴

• 　　Dockerfileを使ってIfraをコードで管理

• 　　あと３つ 資料待ち

• Docker.io

• 　　イメージが配布されている

• 　　ただし、どこの誰が作ったかわからないイメージなので、要注意

• OSイメージの作成

• 　　Chefに比べて簡単

• Dockerの使いドコロ

• 　　開発・テスト・CI

• 　　軽さを活かしてVagrantをDockerに置き換えるのもいいね

• 　　本番で使う場合（リスキー）

• 　　　　ポータビリティを活かす→1コンテナ on 1VM

• Docker利用例

まとめ

☆ここちゃんと見直す

• いつ壊れるかわからないからCIしよう
• Dockerは最初はテスト環境からがいいんじゃないか？
• メモりきれませんでした。資料待ち