タダです.
新しい「Amazon Builders' Library」の記事が公開されました.オンラインの輪読会で一通り記事は読んだのですが,追加された「Automating safe, hands-off deployments(安全なハンズオフデプロイメントの自動化)」を読んで Amazon での取り組みを学んでいきます.
記事本文 aws.amazon.com
記事目次および著者
記事の大枠としては次のコンテンツがあります.
- Safe continuous deployments at Amazon
- Pipeline Phase
- Source and build
- Test deployments
- Production deployments
- Pipelines as Code
- Conclusion
著者は Clare Liguori(クレア リグオリ)さんです.コンテナサービスの開発に関わっているエンジニアで,昨年の re:Invent にはキーノートで登壇されていました(21:20秒あたり).
安全なハンズオフデプロイメントの自動化の Amazon の取り組みを学ぶ
Amazon での継続的デプロイ戦略
Clare さんは Amazon に入社前デプロイされるまでログやメトリクスをチェックしていて,人手から離れないオペレーションによるデプロイでした.ただ,Amazon ではデプロイに関する監視をしないし,人手がかからないオペレーションを行なっていると入社面接の時に知りました.Amazon のデプロイ戦略はソースコードをリポジトリにマージする時のみ開発者が関わるがそれ以外は完全に自動化したデプロイパイプラインになっています.このような戦略を取ったのは元々デプロイに開発者が多数のコストをかけて管理していたのを改善するために会社全体で取り組みを行うことを決めたからです.
Amazon では多い時に1時間に1000回以上もデプロイしている事例が話されていたこともあるし,会社全体で自動化が徹底されていることでこの1000回以上のデプロイを実現できているのだなと思います.
どんなパイプライン構成になっているか
では,どんなデプロイパイプラインが作られているからできるのでしょうか.Amazon のパイプラインは4つのフェーズがあり,Source,Build,Test,Prod のフェーズがあります.
Source フェーズ
本番環境への変更はコードレビューから始まり,専用ブランチにマージする前にチームメンバーの承認を得なければならず,レビュー受けていないとデプロイできません.コードレビューではテスト(ユニットテスト/統合テスト/カナリアテスト) があるかどうか,デプロイの監視のための準備,安全にロールバックできるかどうかをチェックします.レビューを受けたのちに個々のパイプラインにデプロイされていきます.
Build フェーズ
コードをコンパイルし,ユニットテストをこのフェーズで行います.ユニットテストは他の AWS サービスなどの依存関係への API 呼び出しをすべてモック環境を作って実行します.
Testフェーズ
パイプラインの中でのテストはアルファテスト,ベータテスト,ガンマテスト,統合テストの4つあります.それぞれの役割は次の通りです.
- アルファテスト/ベータテスト:機能的な API テストと E2E のテストを実行することによる機能検証を行う
- ガンマテスト:コードが本番環境に安全にデプロイできることを検証
- 統合テスト: 本番環境にデプロイする前にサービスの予期せぬ動作や不正確な動作を確認する
Prod フェーズ
Prod フェーズでは本番環境へのデプロイしていきますが,デプロイは全24リージョンおよび76のアベイラビリティーゾーンに展開する必要があるため,デプロイによるリスクを防ぎつつ信頼性も確保していきます.その取り組みを行なっていくにあたり段階的なデプロイを行われてます.つまり,大きく5つのステップを踏んでおり,最初にリクエスト数の少ないリージョンの1つのアベイラビリティーゾーンにデプロイしてリージョン内の影響を確認します.次に,リクエストの多いリージョンの1つのアベイラビリティーゾーンにデプロイしていきます.第3段階で3 つのリージョンに展開,第４段階で最大12 のリージョンに展開,第５段階で残りのリージョンに展開されていきます.
このデプロイにおいてワンボックスデプロイを行なった後にローリングデプロイを行なっているようで,失敗時のロールバックし,他のフェーズで影響を与えないようにしています.この点 Well-Architected Framework にも記載があります.
限定的なデプロイを使用してテストする: 完全なデプロイを行う前に、既存のシステムと並行して限定的なデプロイを実施してテストを行い、望ましい結果が得られるかどうか確認します。例えば、デプロイカナリアテストまたはワンボックスデプロイを使用します。
ロールバックの監視
ロールバックはサービスチームによって定義されたアラームによって行われ,自動的にロールバックしており,リクエスト数/リクエスト待ち時間/失敗数などのメトリクスを取っています.ロールバックは、以前にデプロイしたコンテナイメージ、AWS Lambda関数デプロイメントパッケージ、内部デプロイメントパッケージに環境を切り替えます。内部デプロイメントパッケージはコンテナイメージと似ていますが、パッケージは不変であり、チェックサムを使用して整合性を検証します。 各リージョンの各マイクロサービスには、通常、サービスの顧客に影響を与えるメトリクス（障害率や高遅延など）やシステムの健全性を示すメトリクス（CPU 利用率など）のしきい値でトリガーされる高レベルのアラームが設定されています（以下の例で説明）。この高頻度のアラームは、オンコールエンジニアにページングし、展開が進行中の場合にサービスを自動的にロールバックするために使用されます。多くの場合、オンコール・エンジニアがページングされてエンゲージメントを開始した時点で、ロールバックはすでに進行しています。
Bake time
ワンボックスデプロイの完了後,Bake time が行われます.Bake time では本番デプロイ前にパイプラインがサービスチームで定めたアラームでデプロイ後に発生する影響を監視し続ける時間です.本番前の最終チェックの時間というところでしょうか.Bake time の時間をどれほど確保するかは複数リージョンへの展開によるリスクおよび最終的なリリースへのスピードとのバランスをとっていくそうです.ワンボックスデプロイ後に少なくとも1時間,最初のリージョンへのデプロイ後には12時間,残りのリージョンへのデプロイ後に2~4時間待機していくようにしています.
アラームとタイムウィンドウのブロッカー
パイプラインでは悪影響を及ぼすリスクが高い場合に自動デプロイを停止します。このリスクの評価をブロッカーという仕組みで行います.途中で止まったデプロイも問題解決後開発者によって上書きデプロイができるようになっています.このアジリティの良さも素晴らしいと思います.デプロイには時間を設定して行えるようにもなっており,これはロールバック時に手動でのアクションが必要な場面でオンコールエンジニアが対応するため,夜間や休日を避けて設定されてます.
パイプラインのコード化
Amazon ではこのデプロイパイプラインをコード化しているようです.これでパイプラインの追加があっても対応が可能になり,サービスのスケールと合わせたデプロイ体制が整ったいい取り組みだと感じます.
まとめ
「Automating safe, hands-off deployments」で述べられていたのはデプロイの自動化とデプロイに関して開発者が懸念する点を削いで他のタスクに集中してもらうシチュエーションを作っていくためのプロセスだと思います.そのためにデプロイパイプラインで本番デプロイに至るまでのレビュー,ビルド,テストの徹底,自動化された失敗時のロールバック,本番デプロイ時のリスクを軽減するための戦略,デプロイ前の Bake time といった取り組みを記事から学ぶことができました.Amazon も最初から自動的かつハンズオフなデプロイができたわけではなく,継続的な改善による賜物だと思います.自分もデプロイパイプラインに関わった時はこの記事で学んだことをもとにデプロイ戦略を建てられるようになっていきたいです.
