メモった。間違い等あるかもしれませんが、その場合はごめんなさい。
デプロイとは
- あらゆるコードやバイナリ、アセットなどの配布をデプロイと定義
- インフラストラクチャーの構築はプロビジョニングとする
なぜデプロイに注目する必要があるのか
- AWSのイノベーションのペース
- 合計1000以上の新サービス、新機能をリリース
- フィードバックループを回し続け、顧客の期待に応え続ける
Amazon.comのデプロイ
- 平日のデプロイ間隔 11.6秒
- 1時間あたりの最高デプロイ回数 1079回
- 1回のデプロイで平均10000台のホストに変更を加える
- 1回のデプロイで最大30000台のホストへの変更
Two pizzaルール
- 1チームの大きさは、2枚のピザで全員お腹いっぱいになれる規模
- それを保って頻繁にデプロイできるレベルに
- 作った人が運用をやるポリシー
クロスファンクショナルチーム
各チームメンバーが何ができるかをマトリクスにして、チーム全体で必要な技術をカバーする
ポイント
- 多くのチームが非同期にデプロイする必要
- APIによるチーム間の疎結合化
- デプロイの自動化と全チームでの利用
従来型のデプロイの問題点
- 手順書がメンテナンスされない
- 手作業で間違う
- いままで何度もやっているはずなのに
- 職人芸への依存
- リリース失敗・戻しにも失敗
- 長時間作業と失敗率の拡大
- 結果としてコスト増大・流出
- リリースにいつも自信を持てない
- どんどんプロセスが重くなる
- 失敗するとチェックを重ねる事になる、トラブルごとに増える
TPSの側面からみると、色々なムダがある。ムダを排除して本業にリソースを集中できるように。
デプロイの戦略検討のポイント
- いつ？
- 誰が？
- 要件は？
- ダウンタイムの許容度、グレースフルの必要性
- プロセスは？
- 承認の必要性
チームサイズ・プロダクト規模・アーキテクチャが関係
自動化の基本原則
- 完全自動化の原則
- 変更量最小化の原則
- 高速完了の原則
- 不可逆変更回避の原則
- 成功・失敗自動判定の原則
- 失敗時ロールバックの原則
- デプロイパターン集約の原則
ベストプラクティス
- バージョン管理
- テスト自動化
- 継続的インテグレーション
※ 安全な開発のためPJ初期からやるべし
※ 常にリリース可能な状態に保つようにする
費用対効果
- ソフトウェアの複雑化が進行
- 手作業で同時に複数箇所を間違えずに操作する事が困難
- デプロイ回数はそもそもとても多い現実
- 本番環境にだけデプロイするわけじゃない。様々な環境に何度もデプロイしているはずなので、プロセス全体をみて考える
- 自動化しればすぐに損益分岐点を交差する
- その他の潜在的コスト
- 新人の教育コスト削減
- 失敗した際に発生する損失の削減
デプロイのパターン
- 単純デプロイ
- サービス停止＆デプロイ
- 読み取り専用化＆...
- 機能縮退化＆...
- 半数切り離し＆...
- ブルーグリーンデプロイメント
- カナリアリリース
AWSにおける開発系サービス
- Code Commit
- Code Pipeline
- Elastic BeansTalk
- OpsWorks
- CodeDeploy
- Cloud Formation
- Cloud Watch
Sorryページへの切り替えパターン
- ELBを手前に入れる
- Route53によるDNSフェイルオーバー
- TTLを考慮しないといけない
ELBのConnection Draining
- ELBでは切り離した際、新規割り振りを中止して、処理中のリクエストが終わるまで待つ
- タイムアウトは3600秒
その他注意ポイント
- 処理フローの互換性の確保
- 前バージョンから新バージョンがリクエストを受けても、処理を継続できるようにする
- 開発環境と本番環境の相違点を確認
- 接続先DBやパスワード、環境によって変化するもの
- 環境変数か設定ファイルのどちらかで管理、おすすめは環境変数
- ハードコードやAMI埋め込みは避ける
AutoScalingを使っているパターン
- 最新のアプリケーションがデプロイされている必要がある
- 稼働中インスタンスへのデプロイをどうするか
- AMIをどこまで作り込むか
- インスタンス起動時のcloud-initの活用
どんなAMIを使うか
- 1. 全部いるAMI (デプロイすれば終わり)
- 同一性が確保、ただしデプロイごとにAMI作り直し
- 2. Golden Image (ライブラリやコードは起動時にとってくるとか)
- アプリコードを取得するのみなので、扱いやすい
- 3. 最小構成AMI (Chefとかだけ入れておいて、起動時にプロビジョニングからやる)
- 中身は自由に変更できるが、起動処理に時間がかかる
AMI自動作成例
Jenkins + Packer + Serverspec とか
マイクロサービスでの注意点
- サービスの後方互換性を確保する
- 各サービスは同じタイミングでデプロイしない
- インターフェースを変えるときは新旧両方用意しておく
まとめ
クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)
- 作者: 並河祐貴,安達輝雄,ITpro/日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2009/11/05
- メディア: 単行本
- 購入: 4人 クリック: 372回
- この商品を含むブログ (18件) を見る
