re:Invent 2024: AWSのCI/CD進化とFeature Flags活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Continuous integration and continuous delivery (CI/CD) for AWS (DOP202)
この動画では、CI/CDの進化と最新動向について、AWS AppConfigのGeneral ManagerのSteve RiceとAWS Developer ToolsのProduct ManagerのRanjith Ramakrishnanが解説します。ブランチ機能やコードの自動マージなど、CI/CDの歴史的なブレークスルーから、AWS CodeBuild、AWS CodePipeline、AWS CodeDeployなどの最新ツールの活用方法まで幅広く説明されます。特に注目すべきは、Feature Flagsを活用したContinuous Configurationの手法で、amazoncomやAmazon Prime Videoなどで実際に活用されている事例が紹介されます。また、DatadogとAWS AppConfigの連携による自動ロールバック機能など、最新の機能についても言及されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
CI/CDセッションの開始：自己紹介と概要
みなさん、ようこそ。これは Continuous Integration and Continuous Delivery（CI/CD）についてのセッションです。CI/CDの最新動向や、ソフトウェアを安全かつ効率的にリリースする方法、そしてリリース速度を向上させる方法について学びたい方は、まさに適切な場所にいらっしゃいます。このセッションにお時間を割いていただき、ありがとうございます。約1時間のセッションとなります。質疑応答は、ヘッドホンを使用した双方向のやり取りではなく、ステージ脇で行います。私はAWS AppConfigのGeneral Managerを務めるSteve Riceです。では、同僚から自己紹介させていただきます。
AWS Developer Toolsチームで Product Managerを務めているRanjith Ramakrishnanです。
CI/CDの歴史と進化：ブランチからFeature Flagsまで
まずは過去を振り返ってみたいと思います。私の白髪からもわかるように、昔のソフトウェア開発や最初のパイプライン構築は、まさにこんな感じでした。CI/CDの歴史の中で、私が特に印象に残っている出来事についてお話しします。最初の大きなブレークスルーは、ブランチの発明でした。 Visual SourceSafeを使用して、ラベルを使っていた方はどれくらいいらっしゃいますか？あ、お一人手が挙がりましたね。ありがとうございます。後ほどお話ししましょう。私たちは、ブランチをサポートしていないとても原始的なツールから始めました。コードにラベルを付けて、トランクの先に開発を進めることはできましたが、同時進行での開発を本当の意味でコントロールすることはできませんでした。
次の忘れられないブレークスルーは、コードを自動的にマージできるようになったことです。当時、私たちはCVSというものを使用していましたが、2つの異なるブランチがある場合、ツール自体がマージを支援してくれるようになるまでは、それらを統合するのは大変な作業でした。これは画期的でした。私がキャリアをスタートしたAOL（America Online）では、巨大なモノリシックなソフトウェアを扱っていました。ビルドマネージャーとして、水曜日にビルドを開始してマージを始めようとしましたが、うまくいかないことばかりでした。すべてのマージを解決するのに、いつも数日かかっていました。
最後の大きなブレークスルーは、登場した自動化でした。コードをコミットすると自動的にビルドが開始され、さらにそれを本番環境にデプロイすることができるようになりました。これがCI/CDの始まりでした。自動化が実現し、小さな歯車が他の多くの歯車を回すようになると、私たちの開発速度は格段に向上しました。これらがCI/CDにおける重要な進展でしたが、今日は現在起きていることについてお話しします。現在のブレークスルーも、かつてのものと同じように大きなインパクトを持つことを期待しています。
本日は、いくつかのトピックについてお話しします。まず最初に、AWSのチームが社内でどのようにツールを使用しているかについて簡単に説明します。その後、ソースコードの管理、ビルドプロセス、本番環境へのデプロイのライフサイクルについて説明します。そこでいくつかのハイライトをご紹介します。また、Feature Flagsを使用してデプロイメントとローンチを分離する方法についても説明します - 私のシャツをご覧ください。さらに、継続的な設定、モニタリング、リリースについて、そしてAWSツールやサードパーティツールで使用できるテクニックやツールについても説明します。最後に、重要なサードパーティリリースの発表もあります。
このスライドは、AWS内部でのソフトウェア開発のライフサイクルを示しています。AWSのサービスをご利用の方は、AWS内部で私たちが各サービスを徹底的に使用していることをご存知でしょう。私たちは各サービスを入念にテストし、時には躓きながらも、その内部での使用経験が最終的にお客様にお届けする製品の機能となります。私たちは社内ですべてのCI/CDツールを使用していますが、すべてのお客様がAWSのCI/CDツールをすべて使用しているわけではないことを理解しており、エコシステム全体を積極的に受け入れたいと考えています。左側には、ソースツール、ビルド時の自動スキャン、実行されるテスト、パッケージングツールがあります。その後、Gamma（ステージングとも呼ばれます）にプッシュします。これはAWSにとって重要であり、お客様にもお勧めします。Gammaを超えて進むためには、ゲートを通過し、特定のテストを完了し、アラームが発生していないことを確認する必要があります。Gammaでは継続的に統合テストを実行し、システムの安定性を確保するためのモニタリングを行っており、問題が発生した場合は自動的にロールバックします。この自動ロールバックは多くのツールに組み込まれており、自信を持って前進するために絶対に不可欠です。
これは、自動的に車線に戻してくれる自動運転車のようなものです。この自動ロールバックは不可欠であり、ほとんどのツールでこの機能を見ることができます。ステージングで約1時間ベイクタイムを設け、その後自動的に次のウェーブに昇格します。ここにはいくつかの異なるウェーブがあります。AWSでは、通常、リージョンのウェーブを使用しています。AWSには30以上のリージョンがあるため、まず小規模なリージョンにデプロイし、変更に応じて1時間、場合によってはそれ以上のベイクタイムを設けた後、2つのリージョン、そして5つのリージョンへと展開していきます。
大規模なリージョンに入るまで見えない問題もあります。例えば、Dublinリージョンで何か問題が発生する可能性があります。このような場合、私たちは積極的にロールバックを行いますが、このようなゲート付きのウェーブという考え方があります。これをお話しするのは、この開発哲学が私たちのツールに反映されているからです。Amazonでは、コードの開発は非常に速く行いますが、リリースは非常にゆっくりと行います。これは非常に良い哲学であり、ここに示されています。私の製品では、13の異なるウェーブまで増えており、リージョンのグループ分けを行っています。その過程で、アラームが発生していないこと、すべてが期待通りに進んでいること、すべての統合テストが合格していることを確認しています。
右側にはFeature Flagsと呼ばれるものがあります。私の経験では、チームの約半分がFeature Flagsを使用しています。今日は、これをテクニックとしてお話しします。これはCI/CDの範囲を超えています。すべてのウェーブを通過するコードプッシュを行わなくても、ソフトウェアの動作を変更し、レジリエンシーとセキュリティを調整することができます。これについては後ほど詳しくお話しします。 これは、CI/CDのすべてのステージ、つまり作成、ビルド、デプロイ、リリース、モニタリングを左から右に示した全体像です。AWSには多くの異なるツールが用意されていますが、お客様がすべてを使用しているわけではないことを理解しています。Jenkinsのようなツールを使用している場合でも、それを組み込んで残りのパイプラインが正常に動作するようにしたいと考えています。
AWS CodeBuild、AWS CodeDeploy、AWS CodeCatalystなどのサービスがあります。モニタリングの面では、多くのソリューションが存在し、お客様は数多くのサードパーティソリューションをご利用されています。下部には、私たちが推奨するインフラストラクチャ・アズ・コードのツールとして、AWS CloudFormationやAWS Cloud Development Kitがあります。Terraformなども素晴らしく、このツールチェーンにうまく適合します。 この講演では、タイムライン上の点線の部分に注目し、ソース管理、ビルド、テスト、デプロイ、リリースの部分にズームインして、安全な方法でソフトウェアを開発し、チームが高品質なデプロイを実現しながら、より迅速に進められるようにする方法について説明します。
AWS CI/CDツールの最新機能と改善点
それでは、次のセクションをRanjithに引き継ぎたいと思います。 Steveが説明したように、このライフサイクルの各部分について詳しく見ていき、社内チームがどのようにソフトウェアをビルド、テスト、リリースしているかについて、お客様も同じような機能を使えるようにするために私たちが取り組んでいることをお話しします。始める前に、AWS CodeBuild、AWS CodePipeline、AWS CodeDeployなどのツールを使用したことがある方、または詳しい方は手を挙げていただけますか？何人かの方が手を挙げられましたね。このトークの前半は、ソース、ビルド、テスト、デプロイに関するAWS CodeBuild、AWS CodePipeline、AWS CodeConnections、AWS CodeDeployについてで、後半はSteveが戻ってきてAWS AppConfigについて説明します。
では、ソースのライフサイクルから始めましょう。 皆さんが様々なサードパーティのソースプロバイダーを使用されていることは承知しています。AWSでは、これらのソースプロバイダーとうまく連携し、簡単に利用できるようにしたいと考えています。私がよく話をする大規模なお客様によく見られるユースケースは、セルフホスト型のソースプロバイダー、つまり自社でホストしているGitHubや自社でホストしているGitLabでソースコードを管理しているケースです。
これらはAWS上でホストされ、Virtual Private Cloud（VPC）の背後に置かれることで、セキュアな環境が実現されます。入出力の接続を制御できるわけです。最近行った改善点としては、まずAWS CodeBuildとホステッドソースプロバイダーとのVPC統合を改善しました。さらに最近追加した変更点として、AWS CodeConnectionsとの統合機能があります。CodeConnectionsについて聞いたときには反応がありませんでしたね。CodeConnectionsは、他のAWSサービスがサードパーティのソースプロバイダーと接続するのを支援する統合サービスです。例えば、CodeWhispererはCodeConnectionsを使用しており、GitHub Enterpriseやセルフホスト型のGitLabとの接続を設定すると、その接続を他のAWSサービスでも利用できるようになります。
CodeBuildには独自のサードパーティソースプロバイダーとの統合機能がありましたが、私たちはこの管理を簡単にしたいと考え、CodeConnectionsのサポートを追加しました。これにより、サードパーティのソースプロバイダーとの統合を単一のサービスで管理できるようになりました。私たちは、お客様にビルド、テスト、デプロイにAWSのツールを使っていただきたいと考えていますが、同時にエコシステムとも良好な関係を保ち、安全性、制御性、AWSエコシステムへの統合という面で同じ機能を提供したいと考えています。ここ数ヶ月間、他のCI/CDツールでランナーとしてAWS CodeBuildを使用できる機能を追加してきました。これは、GitHub ActionsをCI/CDに使用していて、ビルドを実行したい場合に、セルフホストのランナーを用意する代わりにCodeBuildをランナーとして使用できるようにするものです。利点は、AWSエコシステムに統合されているため、同じセキュリティ原則を使用しながら、CodeBuildの優れた機能をすべて活用できることです。銀行のお客様を含む多くの大規模なお客様が、この機能を積極的に採用し、GitHubやGitLab内でCodeBuildをランナーとして使用されています。
ソースについて説明したところで、次はアプリケーションのビルドについて話しましょう。取り上げるべき点は多々ありますが、最近の改善点にフォーカスしたいと思います。私たちのビルドプラットフォームであるAWS CodeBuildは、Linuxベースのビルドに関しては一般的に優れた性能を発揮してきました。Windowsや様々なコンピュートプラットフォームをサポートし、AWS LambdaやAmazon EC2上でビルドを実行する機能も導入しました。しかし、特にWindowsの開発者向けのサポートにおいて、まだいくつかの課題がありました。特に大きな課題がVPC統合で、これについては多くのお客様からフィードバックをいただきました。そこで私たちは、VPCの背後にあるソースプロバイダーからコードを取得し、Windowsコンピュート上でアプリケーションをビルドできるよう、VPC統合の改善に力を入れてきました。
約1ヶ月半前、コンテナ外でビルドを実行する機能を導入しました。CodeBuildに馴染みのない方のために説明すると、私たちはホストを実行することで安全なビルド環境を提供しています。そのホスト上で、お客様が独自に用意したものか、または私たちの標準イメージのいずれかのコンテナイメージを実行し、その中ですべての処理を行います。これにより、コンテナ環境から外部への干渉を防ぐことができます。
セキュアで、すべての処理がコンテナ内で実行されますが、特にWindowsでのDockerベースのビルドなど、コンテナ内で直接実行するのに適さないワークロードもあります。WindowsでのDockerオンDockerは実現が難しいため、コンピュート上で直接ビルドを実行する機能を導入しました。ドライバーや特定の低レベルアプリケーションを開発されているお客様の中には、コンテナ環境でアプリケーションをビルドできないケースがあります。Windows向けのこのサポートは、非コンテナ化ビルドを実現するための第一歩となります。
Windows開発者向けの環境を改善する一方で、 AWS CodeBuildにおけるお客様からの最も多いリクエストの1つが、MacデベロッパーやiOSデベロッパーのサポートでした。これまでは良い解決策がありませんでした。様々な種類のコンピュートやオペレーティングシステムをサポートしていましたが、お客様は本当にMac上での実行を望んでいました。数ヶ月前、私たちはmacOSをコンピュート環境として利用できる機能を導入しました。AWS CodeBuildには2種類のコンピュートが用意されています。1つはオンデマンドで、ビルドのトリガー時にインスタンスをプロビジョニングし、イメージをダウンロードしてコンテナ環境を立ち上げます。もう1つは予約容量で、常時利用可能な状態で管理されているマシンのフリートです。
macOSの場合、この予約容量に基づいています。macOS Sonomaオペレーティングシステムを搭載したApple M2インスタンスを使用するmacOSベースのコンピュートのフリートを用意しています。基盤となるAWS CodeBuildの機能は同じなので、キャッシングのサポートとともにMac上で直接実行され、Mac上でのビルドをより高速に実行できます。アスタリスクがついている理由は、ライセンスの制約により、Macインスタンスには24時間の予約期間が必要だからです。この制限については別途説明させていただきますが、現状の制約について透明性を持ってお伝えしたいと思いました。
コードと、サードパーティのソースプロバイダーとの統合についてお話ししました。アプリケーションのビルドをどのように改善してきたかについても説明しました。最近導入した機能の1つに、ビルドが失敗した際に自動的にリトライする機能があります。これにより、手動でビルドを再開する必要がなくなりました。私たちの目標は、AWS CodeBuildのパフォーマンスを継続的に改善し、お客様の体験から不便な部分を取り除くことでした。 では、デプロイメントプロセスについて説明しましょう。
AWS CodePipelineについてお話しします。AWS CodePipelineは、リリースプロセスのオーケストレーションを支援するサービスとして最初にリリースされ、その後何年にもわたって改善を重ねてきました。Steveは、社内で運用しているパイプラインについて、各ステージを通じて変更を進めながら、そのステージでの影響を確認し、影響範囲を制限する方法について説明しました。現在のAWS CodePipelineでは、パイプラインには1つ以上のステージがあり、それらは順次実行されます。ステージには、ビルドの実行やECRへのデプロイとプッシュ、ユニットテストの実行、コードスキャンの実行など、1つ以上のアクションがあります。アクションは順次または並行して実行でき、次のステージに進む前にそのステージで定められたすべての処理が正常に完了したことを確認するため、ステージ内のすべてのアクションが成功した時点でステージは成功となります。ステージ内のいずれかのアクションが失敗すると、ステージは失敗となります。
Steveはステージの条件について説明しましたが、最近、ステージの出入り口の基準として条件を定義する機能を追加しました。この考え方の背景には、ステージにはそれぞれ異なるライフサイクルイベントがあり、変更がステージに入る前や、すべてのデプロイメントが完了して変更がステージを完了した時点で条件を設定できるというものです。Steveは、デプロイメント完了後のステージ条件として、統合テストの実行やAWS CloudWatchのアラーム状態のチェックを含むシナリオをデモンストレーションしました。これは「成功時の条件」と呼ばれるもので、ステージ内のアクションが失敗した場合の「失敗時の条件」も存在します。これらのステージゲートは組織の標準を強制する効果的な方法であり、変更がこれらの条件のいずれかに失敗した場合、権限のあるユーザーが手動で失敗を上書きすることができます。
ステージレベルの条件がどのようなものか見てみましょう。 パイプラインにおいて、ステージには3つのライフサイクルイベントがあります：入場前、ステージ成功時、ステージ失敗時です。これらのライフサイクルイベントのいずれかで条件を定義でき、条件は2つの部分で構成されます：1つ以上のルールと、これらのルールが失敗した場合に取るべき是正アクションです。 現在提供しているルールには、CloudWatchアラームとLambda呼び出しがあります。例えば、一部のお客様は外部の変更管理システムを使用しており、そのシステムに基づいて変更をデプロイできるかどうかを確認したいと考えています。Lambda呼び出しをカスタムルールとして使用し、ServiceNowで変更が承認されているかどうかを確認し、承認されている場合にのみその変更をステージに進めることができます。
これらのルールを定義する際、 複数のルールを条件として組み合わせることができ、いずれかのルールが失敗した場合、1つ以上の是正アクションを実装できます。入場レベルの条件で何かが失敗した場合、パイプラインの進行をブロックしたり、出口シナリオでロールバックを実行したりできます。 お客様が実現した実践的な例には、本番環境へのデプロイ前にデプロイメントウィンドウをチェックする（例：月曜から金曜の午前9時から午後5時（Pacific時間）の間のみデプロイを許可する）ことや、デプロイメント完了後にその成功を確認することなどがあります。
Continuous Configuration：Feature Flagsの活用と利点
私たちは、ステージをスキップする機能とともに、このGatingメカニズムを導入しました。これは、緊急デプロイメントに関してお客様から寄せられた一般的なリクエストの1つでした。条件チェックの一環として、1つまたは複数のルールをチェックでき、ルールが失敗した場合はそのステージをスキップすることができます。これにより、BetaステージとGammaステージで条件をチェックしてWave 1に素早く到達できる、疑似的な分岐パイプラインが実現します。私たちの目標は、自動化とマニュアルの両方のプロセスを通じてRollbackを使用して迅速に復旧できることを確保しながら、自信を持って変更をデプロイできるようにすることです。 最近、より堅牢なパイプラインを構築するための追加の統合機能を導入しました。
こちらが、Steveが先ほど話していたパイプラインの例です。ビルドステージでテストを実行し、 コードスキャンを行います。その後、異なるステージにデプロイする複数のWaveがあります。 これは、緊急デプロイメントとして変更を非常に迅速にプッシュしたかった場合のパイプラインの例です。ビルドを行い、いくつかのテストを実行した後、本番環境に素早く到達するためにBetaステージとGammaステージの両方をスキップすることにしました。これは明らかにリスクを伴いますが、 少なくとも変更をRoll Forwardしようとしているわけで、このパイプラインはそれを示しています。
これらの各ステージについて、 開始前にチェックできる条件があります。 この例では、コード品質が良好かどうかをチェックしています。Gammaステージでは、 外部システムからデプロイが可能かどうかをチェックしています。これらの条件をパイプラインで定義し、実行時に変更内容とその文脈に基づいて、先に進むべきかどうかを判断できます。変更をどのように制御し、本番環境にデプロイするかについて説明しましたので、ここでSteveに戻って、ソフトウェアを安全にリリースするために何ができるかについて説明してもらいます。
ありがとう、Ranjith。私は Continuous Configuration について説明します。 皆さんは Continuous Integration/Deployment についてはご存知だと思いますが、Configuration は、コードがリリースされた後、本番環境に展開された後に行われるものです。これは Amazon 内部で大規模に使用している手法です。私たちが発明したわけではありません - 多くの Feature Flag サービスが存在し、素晴らしいものがたくさんありますが、私たちは確実に大規模に活用しています。通常、Feature Flag（時には Operational Flag と呼んでいます）を使用して機能のオン/オフを切り替えます。今週は re:Invent での発表に向けて、多くのサービスが機能のオン/オフを切り替える非常に忙しい週です。実は、コードは先週か先々週にプッシュして、Feature Flag の背後に隠しておいたので、誰もアクセスできない状態でした。
今週、そして今日から数日間、私たちは多くの Feature Flag を切り替えて、コードと機能をお客様が利用できるようにします。バックグラウンドタスクの数の制限、タイムアウト時間、スレッドプールサイズなどを調整することで、運用を最適化しています。私たちは常に Operational Flag を使用して、本番環境で素早く調整や対応ができるようにしています。ロギングについては、ログの詳細度を変更する手法のデモを行う予定です。これらはすべて、変更の影響範囲を制限するための概念です。私たちが行うすべてのことにおいて、迅速に開発しながらもゆっくりとリリースすることを心がけています。Feature Flag を使用することで、より速く進めることができると同時に、本番環境での対応も可能になり、Mean Time to Recovery（MTTR）を非常に効果的に短縮することができます。
アプリケーションは定期的に（おそらく10秒ごとに）設定データをポーリングして読み取っています。設定データが変更された場合、それがFeature Flagであれば、アプリケーションも変更されます。アプリを再起動したり、新しいコードをProductionにデプロイしたりする必要はありません。もちろん、CI/CDパイプラインがスムーズかつ迅速に動作することは重要ですが、20分ではなく5秒で対応できるようになります。先ほど、ツリーとブランチの図をお見せしました。ブランチは大きなイノベーションでしたが、いくつかの問題を引き起こす可能性があります。Amazonの社内や多くのお客様が採用しているのは、Trunk-based developmentです。ブランチを作成してマージしようとするのではなく、すべてをTrunkで行い、すべての機能にFeature Flagを設定します。
例えば、あるコードに10個の機能があるとして、すべてがTrunkにあり、デフォルトではすべての機能がオフになっています。コードがデプロイされた後、10個の機能を徐々にオンにしていきます。ある機能に問題が発生した場合、すべてをロールバックする必要はなく、問題を引き起こしているその1つの機能のFeature Flagをオフにするだけで済みます。これは、コードのデプロイとローンチを分離する非常に強力なテクニックです。
AmazonのCTOであるDr. Werner Vogelsは、Continuous Configurationに関する注目すべきブログ記事を書いています。彼の言葉を引用すると：「リアルタイムの変更に対応するためにContinuous Configurationを使用することで、チャンスが訪れた時に対応できる能力を構築することができます。」これこそが重要なポイントです - イベントに素早く対応できることです。彼は、実際のインシデントに発展する前に対応できる何らかのシグナルについても示唆しています。これらのFeature Flagを使用するテクニックは非常に強力です。
多くのお客様が、外部および内部のFeature Flagを使用しています。AWS AppConfigは、Amazon S3、Amazon Bedrock、Amazon Prime Video、そしてamazon.comのFeature Flagサービスとして使用されています。お客様からは、Mean Time To Recovery（MTTR）を削減できたと聞いています。Productionで問題が発生した場合、5秒の停止時間と1分の停止時間、そして5時間の停止時間では大きな違いがあります。十分に素早く対応できれば、お客様は問題を経験することすらないかもしれません。
皆さんはおそらくGammaやQA環境でテストを行っており、QAチームがいる場合は、その環境で全てが問題なく見えるでしょう。しかし、Productionではデータの特性が異なり、テストでは発生しなかった問題が見つかるかもしれません。Feature Flagを使用することで、ユーザーに対して徐々にリリースし、影響範囲を制限することができます。Productionで全てが正常に動作することを確認し、ソフトウェアのデプロイ頻度を上げることができます。
Trunk-based developmentに移行したお客様から、以前は2週間に1回の大規模なプロダクションへのプッシュリリースを行っていたという話を聞いています。先ほどAOLの例で触れたように、何か問題が発生した際には、コードの再マージや削除が必要となり、それが複雑な状況を生み出し、2週間ごとのリリースに制限されていました。Trunk-basedリリースでは、より迅速なリリースが可能となり、リリース頻度を向上させることができます。
また、Feature flagsを使ってA/Bテストを実施することもできますが、この講演では詳しく触れません。ユーザーの半分に一方の機能を、残りの半分に別の機能を体験してもらい、収集したデータに基づいてその変更が有益だったかどうかを判断できます。私たちのある顧客である大手メディア企業では、毎日何百万ものPodcastを処理しています。自主制作のPodcastのメタデータは一貫性に欠けることが多いため、エピソードの取り込みと分類にアルゴリズムを使用しています。彼らはAWS AppConfigとFeature flagsを使用して、Podcast取り込みプロセスの新しい変更を段階的に導入し、最初は1%のエピソード、次に5%、そして10%と徐々に拡大して、予期せぬ下流での問題が発生しないことを確認しています。問題が発生した場合は、自動的にロールバックして素早く調整することができます。
AWS AppConfigのデモ：ログ詳細度の動的制御
ここでデモをお見せしたいと思います。私はデモを事前に録画しました - Ranjithさんはライブデモを行いましたが、私はそれほど勇気がないので、すぐにプレイボタンが表示されます。 このセットアップは、Feature flagを使用してログの詳細度を変更するユースケースです。通常はINFOに設定されているものをDEBUGに変更したい場合があります。これが必要な理由は、より多くの情報を得たい場合で、ログの詳細度をDEBUGに変更するためだけにコードリリースをプッシュしたくない場合です。
これはFeature flagで実現できることです。例えば、セキュリティインシデントが発生していて、何か不審な動きを示す兆候がある場合、ログを設定して、これらのさまざまな事象をしっかりと確認したい場合などが考えられます。
AWS AppConfigでFeature flagを作成することから始めましょう。 Feature flagの名前をLoggingVerbosityとします。ここにタイプミスがありますね。はい、Configuration profileの名前としてLoggingVerbosityとします。実際にAppConfigに入って、 これを読み取る特定のフラグの名前として設定します。ここに「短期的なフラグ」というチェックボックスがあります。Feature flaggingでは、古いフラグが残ってフラグの混雑が発生することがあります。これをチェックして、後でクリーンアップしたいと指定できるツールがあります。コードが自動的に行うわけではなく、AppConfigも自動的には行いませんが、リマインダーとして機能します。
Deprecation dateも設定できますが、今回の場合は長期的に使用するフラグなのでそのまま残しておきます。これをオンにして、 INFOやDEBUGという文字を設定できる属性を設定します。このキーは、確かvalueと呼んでいたと思います。そうですね、また typoがありましたね。ここでINFOに設定します。 この部分のセットアップが終わったら、デモの第2部に移ります。ここまでがFeature Flagの部分で、確認をしています。はい、これで設定は完了です。 ご覧の通り、INFOに設定されています。
第2部では、Alarmを設定します。 このAlarmが発動すると、このFeature Flagが切り替わります。ここでFeature Flagを本番環境にデプロイして、アプリケーションが読み取れるようにしています。 そうすると「INFOに設定されているので、ログの詳細度をINFOに保ちます」というようになります。ここでCloudWatchに移動します。CloudWatchの他にも、Datadog、New Relic、Dynatraceなどのサービスも使用できます。
不審な動作を検知するAlarmを設定します。このAlarmは IAM名を監視しています。APIを監視して、IAM名のリスト取得が何回行われているかをチェックしています。アプリケーションの通常の実行中では、この値はかなり一定しているはずですが、このAlarmは異常検知を行い、通常よりも頻繁にIAM名がリストされている場合に不審と判断します。CloudWatchのグレーのバンドは正常範囲を表していて、その中で上下に変動します。このAlarmには、Actionも設定されています。
これは「不審なアクティビティを検知」と呼ばれています。CloudWatchや他のサービスでも、Alarmが鳴った時にどのActionを実行するかを設定できます。ここでActionをクリックすると、2つのActionがあります。1つ目はLambdaを実行することで、そのLambdaが実際にFeature Flag を呼び出して切り替えます。また、SNSキューに通知を送信して、不審な動作があった可能性を通知することもできます。これで全ての設定が完了です。 Feature Flagがあり、Alarmがあり、そしてAlarmをトリガーすると、赤い部分が表示されます。
何か不審な動作があったということです。APIを頻繁に呼び出しすぎたため、Actionがトリガーされました。先ほど説明したように、ActionはLambdaを実行し、そのLambdaがFeature Flag をINFOからDEBUGに切り替えます。ここで見ることができますね。これは一連のイベントが瞬時に連鎖的に発生するものです。Feature Flagを自動化するというアイデアは非常に強力です。ここではコードのデプロイは一切行っていません。Feature Flagを設定し、Alarmを設定してFeature Flagを変更するトリガーとしただけです。
運転中のレーン制御や自動衝突検知などの機能は非常に重要です。 AWS AppConfigは現在、CloudWatchアラームに基づく自動ロールバック機能を備えており、本日、サードパーティのアラームに基づくロールバックを可能にするDatadogとの連携を発表しました。Datadogは立ち上げパートナーですが、New RelicやDynatraceなどの他の監視ソリューションも利用できます。さらに、APIを備えた独自の監視ソリューションをお持ちの場合、それを使用してFeature Flagの変更をロールバックすることも可能です。
段階的リリースプロセスの実装とパイプラインの詳細
VenetianのExpoホールにあるDatadogのブースにぜひお立ち寄りください。彼らは会場内でも大きなブースの1つを構えています。Datadogユーザーの方は、必見です。Datadogを使用されていない方々のために、他のサードパーティAPMプロバイダーとの連携も用意していますし、CloudWatchもネイティブに組み込まれています。これは素晴らしい発表ですね。会場にいらっしゃるJamesさんを紹介させていただきます。彼がDatadog拡張機能の開発者です。Jamesは質問にお答えできますし、お帰りの際にステッカーも配布しています。
申し訳ありません。先ほどの説明が少し早すぎましたね。セットアップについて改めて説明させていただきます。ここに、Steveが説明した段階的リリースプロセスを実装したパイプラインがあります。変更をリリースする際、主に2つのパラメータを制御しています。1つ目は、各ステージでの変更の適用時間をどれくらいにするかです。例えば、緊急デプロイメントの場合は、各段階を素早く進める必要があるかもしれません。2つ目のパラメータは、本番環境への緊急修正を急ぐ場合に、本番環境のみのデプロイメントかどうかを示します。このフラグをtrueに設定して変更を実装します。
パイプラインの構造を見ると、いくつかの入力パラメータがあります。これには各ステージのBake時間や、定義可能な確率変数が含まれます。各ステージでは、障害処理機能を実装しています。一時的なエラーに対処するために、ステージ失敗時の自動リトライを有効にでき、ステージ全体をリトライするか、失敗したアクションのみをリトライするかを選択できます。
特定の条件を持つステージを見てみましょう。このケースでは、本番環境のみのデプロイメントの場合、ステージをスキップする条件を実装しています。prod-only変数をチェックするルールを使用しており、それがtrueでない場合、ステージはスキップされます。終了ステージを見ると、Steveが言及したCloudWatchアラームについて、この実装では新しいデプロイメントに関連するトラフィックレベルを監視しており、アラームが発生した場合、ステージは自動的にロールバックします。この場合、ステージは実際にロールバックされます。
VariablesBigTimeパラメータを使用してdatetimeを設定することで、待機時間を指定することができます。これにより、パイプラインの変更をリリースする際に設定した値をここで使用することができます。これはこのままにしておきましょう。これらの各ステージに対して1つ以上の条件を設定しており、最終的にステージ2に進んでいきます。このようにしてパイプラインでステージレベルの条件を設定し、変更を進めていくことができます。
何が起こったのか見てみましょう。現時点では、ソースが完了しています。いくつかのテストを実行し、現在コードのスキャンを行っています。結果を確認してみましょう。スキャン中に重大な脆弱性は見つかりませんでした。重大な脆弱性が検出された場合に自動的にロールバックを開始するようにしきい値も設定しています。それが完了した後、このステージとこのステージをスキップしているのが分かります。そして直接Wave 1に進んでいます。
これが、セットアップ方法とパイプラインの実行方法についてお見せしたかったことです。これを見せるために戻ってきたことをお詫びします - 時間が気になっていたものですから。これで私たちのプレゼンテーションは終了です。ご清聴ありがとうございました。ご質問がございましたら、私たちは横にいますので、喜んでお答えさせていただきます。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion