re:Invent 2025: AWSのCI/CDとAI駆動デプロイメント - AppConfigとfeature flagの活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Continuous integration and continuous delivery (CI/CD) for AWS (DVT202)
この動画では、AWSにおけるCI/CDの進化と、AIを活用した新しいデプロイメント手法について解説しています。Steve RiceとMihai Balaciが、AWS AppConfigとParameter StoreのGeneral Managerとして、段階的リリース、自動ロールバック、途中検証という3つの柱に基づくAWSのリリース戦略を紹介します。特に注目すべきは、AWS MCP serverを使用したAI駆動のデプロイメント手法で、KiroなどのIDEを通じて自然言語でインフラストラクチャをデプロイできる実演が行われました。さらに、feature flagとcontinuous configurationの重要性が強調され、trunk-based developmentの実現、fast rollback、本番環境での検証といった利点が説明されています。AWS AppConfigを使用したロギング詳細度の動的切り替えのデモでは、CloudWatch アラームと連携した自動化の実例が示されました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
re:Invent 2024 における CI/CD セッションの開幕
こちらは AWS における Continuous Integration と Continuous Delivery についてのセッションです。セッション番号は DVT202 です。これが皆さんが期待していた内容でしたら、皆さんは正しい場所にいます。私の名前は Steve Rice です。私は AWS AppConfig と Parameter Store の General Manager を務めています。後ほど Mihai Balaci が参加して、CI/CD の現状についてお話しします。ですが、まず皆さんにお聞きしたいのですが、ここにいる人の中で、これが初めての re:Invent という方はいますか？手を挙げていただけますか？これは素晴らしい。こんなに多くの新しい方々を見るのが大好きです。
2回の re:Invent に参加された方はいますか？3回？4回？5回？6回？7回？7回という方が後ろにいますね。わかりました。7回以上という方はいますか？これらのライトが結構眩しいので、後ろに誰かいるかどうか見えないのですが、とにかく皆さんのご参加ありがとうございます。re:Invent は私が一年の中で最も好きな時期の一つです。申し訳ないのですが、これはアメリカの感謝祭の直後なのです。アメリカの方でしたら、ご家族のもとを離れた直後にここに来るのは少し大変ですよね。実は私も昨晩遅くにここに到着したフライトに乗っていたので、私の時間で朝の3時にここにいたのです。ですから今は十分にカフェインが入っていますが、昨晩はあまり眠れませんでした。
皆さんがここにいるのですから、今は十分に集中していて、学ぶために来ているのだと思います。これが re:Invent の重要なポイントの一つです。皆さんは多くのことを学ぶことになりますし、おそらく圧倒されるでしょう。メモを取ることをお勧めします。良いニュースは、これらのセッションの多くが録画されており、後で YouTube やその他のストリーミングサービスで視聴できるということです。re:Invent で私たちが本当に皆さんにしてほしいもう一つのことは、互いに出会い、周りの人に対して積極的にフレンドリーに接することで、ネットワーキングができるということです。
ソフトウェアデリバリーの進化：25年の歴史を振り返る
私たちの顧客が皆で互いに話をしていて、AWS の従業員と話をしていないのを見るのは本当に素晴らしいことです。今後一週間の間にそのようなことが起こることを願っています。では、これに戻りましょう。私たちは CI/CD についてお話しします。私は時間を遡ります。ご覧の通り、私は白髪があり、25年間ソフトウェアをやってきました。私が最初にソフトウェアを構築していた頃のことを覚えています。私は AOL という会社で働いていて、私たちはソフトウェアを年に一度 CD でリリースしていました。私は AOL 7.0 のエンジニアリングリーダーでした。
それが意味していたのは、約200人の異なるエンジニアのところに行って、2週間ごとにビルドを実行する準備ができているかどうかを確認するために調整する必要があったということです。私は Instant Messenger で連絡を取って、「もう準備できていますか？」「ああ、準備できています、そうです」と言っていました。その後、ビルドの日である水曜日に、私はすべてのコードをマージしてビルドを実行するのですが、それは決して機能しませんでした。それで、私は失敗がどこにあるかを把握して、おそらくその200人のエンジニアの中の50人のところに行って、彼らに修正を依頼する必要がありました。
Visual Source Safe を使っていたんですよ。覚えている人もいると思います。灰髪の人たちが何人かいるのが見えます。それは本当に大変なプロセスでした。水曜日にビルドすることになっていたんですが、たいていは金曜日か翌週の月曜日にビルドすることになってしまいました。ビルド失敗がたくさんあったからです。その後、実際にブランチを使うビルドシステムに移行しました。それはソース管理における大きなイノベーションでした。自分たちのブランチで開発してから、マージインすることができるようになったんです。オートマージは素晴らしかったです。それは本当に私たちを前に進めるのに役立ったものでした。
振り返ってみると、あれは恐竜時代みたいなものでした。今日ほどの進歩は出ていませんでしたが、そのブランチングは大きなイノベーションでした。その後、CI/CD に移行して、すべてが自動化されました。コードをコミットすると、テストを経た後、本番環境に出ていくというプロセスを通じて出ていくんです。それは革命的なことでした。今日は、これからのことについて、そして CI/CD における新しいイノベーションについて話します。AI は re:Invent でたくさん聞くことになる大きなことになると思いますが、AI で大きな成功を見ている分野、そして開発の大きな機会がある分野があると思います。
AWS のリリース哲学：段階的デプロイと自動ロールバックの3つの柱
1 つはコード作成です。明らかに、AI エージェントができることは本当に素晴らしいです。もう 1 つは CI/CD スペースです。それは今後 3 年から 5 年で変わっていくでしょう。そして今日のやり方は、来年の終わりまでに、そしてその翌年までに、私たちがやることになる方法とは非常に異なるでしょう。ですから、いくつかのことについて掘り下げていきます。今日のアジェンダです。CI/CD がどこにあるかについて少し話しました。Mihai がエージェントを使用して AWS にデプロイする方法について話します。 そしてそのワークフローについて、アプリをプレビューすること、ライブに行くこと、そしてトラブルシューティングです。
後で戻ってきて、continuous configuration とフィーチャーフラグについて話します。そして主要なポイントでまとめます。会議室での質問はしません。会議室の外で質問をします。ですから、約 10 分残して終わるようにしようとしています。 そうすれば、皆さんが私たちに質問したり、次のセッションに行ったりできます。このスライドは AWS がソフトウェアをどのようにリリースするかを示しています。
ご存じなければ、外部にある私たちのツールはすべて、内部で使用するツールと全く同じか、非常に似ています。これが Amazon でのリリース方法についての私たちの考え方だということを知ってほしいです。私はいつも、私たちは非常に迅速に開発し、非常にゆっくりリリースすると言っています。
すべてのリリースメカニズムには3つの柱があります。1つ目は段階的にリリースするということです。ここで見ていただけるように、複数のウェーブがあります。右側を見ると、ウェーブ1、ウェーブ2、ウェーブNという具合です。私たちは非常にゆっくりと段階的にリリースしています。これにより、変更の影響範囲を限定することができます。2つ目は、常に自動ロールバックを設定しているということです。多くのツールには自動ロールバック機能がありますが、新しいコードや新しい設定のデプロイ中にアラームが発生した場合、自動ロールバックが実行されます。これは車の自動ブレーキのようなものです。今日、ほぼすべての車には何らかの衝突検知機能があります。正直なところ、今はそれがない車には乗りたくありません。本当に素晴らしいです。何か異常が検出されると、自動的にロールバックされます。
そして3つ目は、常に途中で検証を行うということです。integration testsのようなことを行っているのが見えます。設定データの場合、タイプミスがないかを検証することもあります。残念ながら、Amazonを含め、設定のタイプミスが原因で多くの障害が発生しているのを見てきました。これら3つの柱がここに反映されています。左から右へ、source、build、packageとなります。その後、gammaというものがあります。それがそこに置かれて、ベイクされ、その後、最初のウェーブ、2番目のウェーブに投入されます。
Amazonの場合、ご存知のように、30以上のリージョンがあり、それらをウェーブとしてパーティションを使用しています。最初のウェーブは私たちにとって小さいリージョンです。2番目のウェーブは2つのリージョンかもしれません。3番目はより大きなリージョンかもしれません。ほとんどの場合、小さいリージョンで変更したものが問題なく動作すれば、他のリージョンでも動作するでしょう。しかし、スケールでのみ何かを発見する場合があります。US East 1でのみ問題が発生し、他のリージョンでは問題がなかったというケースです。
しかし、繰り返しになりますが、皆さんに対しては、段階的にリリースでき、テストでき、少しベイクさせることができるような方法でリリースをパーティション化する方法を考えることをお勧めします。これはマーケティングチームとの文化的な変化が必要です。マーケティングは、すべてを一度にどこにでもリリースできたら素晴らしいと思うでしょう。しかし、繰り返しになりますが、顧客の1%、10%に何かをリリースしている場合、もし何か問題が発生しても、その10%だけがその問題を見て、ロールバックされるため、はるかに良い体験になります。ですから、マーケティングや他のチームと協力して、段階的なリリースを行う必要があります。
CI/CD パイプラインの成熟度と組織が直面する課題
では、AWSでは、ツールの完全なセットを持っています。また、多くの企業が長い間存在していて、AWSに移行する際に他のツールを使用してきたことも知っています。ですから、これらのツールを混在させることができるように構築しました。すべてのツールを使用する必要はありません。例えば、Jenkinsを使用している多くの顧客がいますし、それもこのツールスイートに適合します。それがそこにあることを期待しています。
左側に見えるのが Codewhisperer で、これは比較的新しいオファリングです。AI を使っています。ここで質問なんですが、この部屋で Codewhisperer を使ったことがある人はいますか？良かった。これはいわば spec-driven development というやつで、私は本当に感動しています。AWS で働いているからというわけではなく、本当に素晴らしいツールなんです。新しいプロジェクトを始めるときに、スタートを切るのに本当に役立つツールで、本当に魅力的です。
それでは、こちらの方に移動して、他のツールについて話していきます。Mihai がこれらの他のツールについて話してくれます。右側にある、監視ツールについては、ここでは詳しく話しません。これは CI/CD プランの重要な部分です。そして、右から二番目の AWS AppConfig については、最後に少し話すつもりです。では、Mihai に、業界と AWS の両方で起きている本当に素晴らしい変化について話してもらいましょう。
ありがとうございます、Steve。皆さん、おはようございます。今のところ調子はいかがですか？このスライドで私が一番好きなのは、これだけ多くのツールがあり、これだけ多くのステージが長年にわたって開発されてきたという事実です。これは本当に興味深いことです なぜなら、最近どれだけ多くのステージがあるかを見ると、ソフトウェア開発ライフサイクルを成熟させることは、今では本当にチャレンジングな旅だからです。持続可能な CI/CD の成熟度を実現するには、SDLC の成熟度が必要であり、同時にそれを強化します。
今日、この部屋の観客の中に vibe coder はいますか？一人いますね、良かった。あなたが素晴らしいアイデア、10 億ドルのアイデアを持っていて、今からスタートしようとしていると想像してみてください。この時点では、あなたの SDLC 成熟度は非常に低いでしょう。あなたの焦点は完全に実装のスピードに当てられます。
そして、おそらくテストはなく、セキュリティも十分ではなく、プラットフォームの知識もそこまでないでしょう。しかし、成長するスタートアップへと進化していくにつれて、あなたの SDLC 成熟度レベルは中程度のステージに達します。あなたの焦点もスピードからコラボレーションへと変わります。スケールアップへと成長していくにつれて、あなたの焦点は再び変わり、あなたの SDLC 成熟度はさらに高くなります。SDLC パイプラインのすべてのステップが適切にカバーされ始めますが、あなたの焦点も変わり、テクノロジーのスケーリングに向かいます。
ビジネスが成長していく最後の段階では、エンタープライズになり、すべてのステージが明確に定義され、完全にカバーされるようになります。そこでフォーカスが再び変わり、セキュリティ、監査、そしてガバナンスをどのようにスケールさせるかに目を向けるようになります。組織は CI/CD パイプラインの成熟度の過程で、様々な課題に直面します。過去 5 年から 10 年を考えると、これらのツールがいかに急速に進化してきたか、その進化によってチームと組織が最新の状態を保つことがほぼ不可能になっています。チームは新しいプラクティスの採用と安定性の維持のバランスを取るのに苦労しています。
また、標準化が 1 つのチームだけでなく、複数のチームに推し進められるときも苦労します。これは常に非常に時間がかかります。セキュリティの脆弱性はパイプラインのどのステージでも導入される可能性があり、この時点では継続的なセキュリティスキャンとコンプライアンスチェックが必要です。すべてをこなしながら、デリバリープロセスを遅くしないようにする必要があります。パイプラインのパフォーマンスは、コードベースの増加とそのパイプラインを使用するチーム数の増加に伴い、時間とともに低下します。かつて非常に効率的だったパイプラインは、ボトルネックになり、デリバリー時間が遅くなり、さらに高くつくようになる可能性があります。
パイプラインの障害はどのステージでも導入される可能性がありますが、診断や再現も非常に難しい場合があります。複雑な統合ポイントは、複数の障害の可能性を生み出します。CI/CD のインフラストラクチャコストはスケールに伴って増加します。ソフトウェア開発では、シームレスなコラボレーション、継続的なインテグレーション、そしてデリバリーの必要性が今日最も重要です。CI/CD パイプラインをオーケストレーションするための複数の複雑な可能性を持つことは非常に価値がありますが、私たちが時間をかけて観察してきたのは、AWS でのデプロイメントをオーケストレーションすることが非常に複雑になる可能性があるということです。Amazon では、この vibe coding と AI 駆動のイノベーションの新しい世界では、すべてのこの複雑性はシンプルなインタラクションによってトリガーされるべきだと考えています。もし、デプロイメントが単に自分が何をしたいかを説明するのと同じくらい簡単だったらどうでしょう。
AWS MCP サーバーを活用した AI 駆動のデプロイメント実演
今日、私がお見せするのは、AI と AWS MCP server を使用して AWS でのデプロイメントをオーケストレーションする方法です。CDK を通じたインフラストラクチャ・アズ・コードのようなベストプラクティスを使用して、環境の一貫性を保ち、素晴らしいアイデアを数分で本番環境にもたらす方法をお見せします。今、AI の領域では非常に多くのイノベーションが起こっています。MCP はそのうちの 1 つです。オーディエンスの中で MCP について知っている人はいますか？1 人、2 人、3 人、わかりました。MCP は Model Context Protocol の略で、モデルの知識と能力を強化する方法です。AWS MCP を使用したデプロイメントは、特に私が前に示した最初のクアドラント、ゼロから 1 のクアドラントにいる場合、あなたの最初の DevOps ハイアーであるべきだと私は考えています。
オーディエンスの中に Joe さんはいますか？おめでとうございます、Joe さん。新しい会社をリリースしようとしているようですね。Joe は vibe coding プラットフォームで最初のプロジェクトを作成したばかりの vibe coder で、そのアプリケーションのリンクを家族、友人、ステークホルダーと共有したいと考えています。
Joe は AWS が MCP server をリリースしたことを聞いて、試してみたいと思いました。彼のジャーニーを見てみましょう。彼がこのリンク を作成します。ここで彼のアプリケーションにアクセスできるようになります。まず、Joe は自分が選んだ ID を使用します。私たちの場合は、Kiro を使用します。これが私たちが選んだ ID です。彼は AWS MCP server をインストールして設定し、Joe は単純に彼のフロー、プレビューフローを開始します。Kiro に何をしたいのかを聞くことで。これをデプロイするために、私たちは agent SOP を使用します。これらは agent の標準的な操作手順であり、それらの SOP は agent が従うためのマークダウンで書かれた使用可能なワークフローです。これらの SOP はすべて AWS MCP server の一部です。このフロー終了時に、これらのチェックが完了すると、Joe は最終的に彼のリンク、CloudFront リンクを手に入れます。ここで彼のアプリケーションが実行されます。
これがどのように機能するかをお見せします。 Joe は彼の Lovable アプリケーションが保存されている GitHub リポジトリに行きます。Joe は今回は標準的な Lovable アプリを使用しています。標準的な Lovable アプリのデモをお見せします。 これは React フロントエンド、認証メカニズム、Supabase データベース、そして Lambda サーバーレス関数を持っています。Joe が最初にすることは、彼のアプリケーションをローカルでテストすることです。 ここで見られるように、localhost 8080 で、アプリケーションが読み込まれています。また、機能が期待通りであるかどうかも確認してみましょう。 Joe は新しい注文を作成しています。わかりました、動作しています。 チェックが実施されています。 現在、Kiro は MCP をネイティブサポートしています。このフローの次のステップは、Joe が AWS MCP server を設定してセットアップすることです。 これも動作しているようです。 現在、Joe は彼の AWS 認証情報をチェックしています。すべてうまくいっています。そして今、Joe は Kiro に彼のアプリをデプロイするよう依頼します。
ここで一度停止します。 あ、彼は停止していません、いいえ。わかりました。では、Kiro は agent SOP をロードします 。これはこのアプリをデプロイするための一連のステップに従います。Kiro がアプリケーションコードをスキャンすると、アプリケーションのタイプを理解します 。そして、CDK を使用して AWS にさらにデプロイされるコンポーネントのタイプを生成します。 インタラクションで見られるように、Joe は AWS からの出力を常に受け取ります 。チャットで読みやすい形式に変換されます。したがって、これらのアクションは Kiro に実行するよう依頼することで一度に実行できます。コマンドをコマンドラインにコピーペーストするか、AWS コンソールに移動して、これらのリンクを使用して AWS コンソールにログインしてアクションを実行します。 現在、アプリケーションはライブです。CloudFront リンクがあります。そして、以前に作成した注文がまだそこにあるかどうかを確認してみましょう 。そしてアプリケーションの機能を再度チェックします。Joe は別の注文を作成しています。 ここで技術的な問題があるようです。
AWS コンソールで見られるように、2 つのリソースが作成されています。API の CloudFormation スタック と、フロントエンドコンポーネント用の別のスタックがあります。IDE でも、モデルはインフラストラクチャコードファイルと Lambda 関数を生成しました。
Kiro が SOP によってガイドされて作成する 2 つの新しいマークダウンファイルがあります。 1 つは agents.md ファイルです。このファイルにより、モデルはコードをスキャンした後、Joe のアプリケーションでより効果的に機能できるようになります。2 つ目は skills ファイルです。現在、3 番目のステージでスキャンするときにモデルによって発見されたアプリケーションコンポーネントをマッピングする 4 つの識別されたスキルがあることがわかります。
では、このフローについて、AWS上では CloudFront、AWS S3、API Gateway を使用しており、Lovable からのサーバーレス関数を Lambda 関数に変換しています。 進展がありました。Joe は非常に満足しており、自分のアプリケーションを本番環境で稼働させたいという確信を持っています。彼はベストプラクティスを最大限に活用したいのですが、それを自分で設定するのに多くの労力をかけたくありません。そして彼は進めています。
本番環境にデプロイするために、Joe は Kiro に戻って、自分の AI チャットボットにアプリケーションを本番環境にデプロイしたいと伝えます。モデルは GitHub トークンの取得など関連する詳細情報を取得し、この場合の欠落しているコンポーネントを特定し、AWS MCP サーバーの下の適切なツールを呼び出して、デプロイパイプラインの作成を開始します。
Joe は素晴らしい時間を過ごしています。アプリケーションは本番環境で稼働しており、機能しており、顧客と友人たちがそれを使用しています。しかし、彼は多くの新機能リクエストも受け取っています。彼は機能リクエストの作業を終了しています。彼はコミットをプッシュしますが、失敗します。AWS MCP を持つ前、そして IDE での Vibe coding を持つ前は、Joe は AWS コンソールに戻り、ログインし、パイプラインを特定し、ログを検査し、コードベースを検査してから、パイプラインエラーをトラブルシューティングすることになっていました。今回は、これらすべての新しいツールが整備されているので、彼のトラブルシューティングフローは Kiro に問題を修正するよう依頼するのと同じくらい簡単になります。Joe は Kiro との会話を続け、 すぐにモデルにアプリケーションをデプロイするよう依頼します。
モデルは現在、CI/CD パイプラインが必要とするコンポーネントのタイプを特定しており、 ベストプラクティスを使用しているため、モデルはこのパイプラインに対して 2 つのステージを提案しようとしています。 そして、ご覧の通り、特定され生成されたコンポーネントが 1 つあります。CodePipeline を顧客に接続するために、 この場合、Joe の GitHub リポジトリに接続するために、CodeConnection インスタンスを作成する必要があります。
モデルは現在、パイプラインスタックを生成しており、このパイプラインスタックは、作成されると CDK を使用してデプロイされます。 Joe はこのデプロイを承認するよう求められます。
モデルが CDK bootstrap を実行しており、AWS 上でコンポーネントの構築が開始されます。この時点で、Joe は複数のステージを持つパイプラインを作成しているはずです。 コンポーネントが作成されるたびに、モデルは AWS コンソールでそれにアクセスするためのリンクを取得します。 Joe が今やる必要があるのは、AWS CodeConnections インスタンスを有効化して CodePipeline を GitHub に接続することだけです。このリンクをたどることで、彼は GitHub を認可します。接続を識別し、接続が有効になります。 次に、Joe は dev 環境と prod 環境の両方のシークレットを入力する必要があります。 パイプラインが作成され、すべてのテストを実行しています。CodeBuild では、パイプラインのステージ数に応じて複数のプロジェクトが作成されていることが確認できます。 パイプラインはすべてのテストを実行し、バックエンドとフロントエンドのコンポーネントをビルドしてから、まず dev 環境をデプロイし、その後本番環境をデプロイします。 すべてが完了すると、IDE の Kiro が Joe にこれらすべてのコンポーネントにアクセスするためのリンクを提示します。 では、アプリケーションが正常に動作するか確認してみましょう。 IDE での実行が成功しました。Joe は dev と prod の両方のリンクを持っています。 Joe は新しい機能リクエストを受け取り、アプリケーションに新しい機能を提供するために取り組んでいます。しかし残念なことに、パイプラインがフロントエンドのビルドステージでエラーが発生しました。 この場合のトラブルシューティングセッションは、Kiro に戻り、IDE に戻り、エージェントにトラブルシューティングを依頼するのと同じくらい簡単です。 エージェントは 2 つのことを行います。agents.md ファイルと deployment.md ファイルを読んで、このアプリケーションがどのようにデプロイされたかを理解し、スキャンセッション後のコードベースに関するすべての関連情報を取得して、どのタイプのアプリケーションを扱っているかを理解します。 その次に、MCP を呼び出します。これは AWS API を呼び出します。この場合、CodePipeline API を呼び出してパイプラインのステータスを理解します。 Kiro はコードベース全体にアクセスできるため、問題がどこにあるのか、変更の影響を受けるファイルが何であるかを簡単に特定し、修正することができます。 以前の指示に従い、Kiro は git push と git commit を実行することが許可されています。 git commit が実行されると、自己変異パイプラインであるパイプラインは自動的に再起動し、変更を再ビルドします。
AI による CI/CD の革命：数分で完成するパイプライン
AWS 上のこの本番ステージについて、 CI/CD コンポーネントの観点では、CodePipeline、CodeBuild、CloudFormation を使用しています。また、リポジトリを選択して接続できる CodeConnection インスタンスも作成しています。この場合は GitHub ですが、CodePipeline で GitLab や Bitbucket でも使用できます。
AI の力により、 パイプラインの設定や複数ステージのデプロイメントなどの時間がかかるタスクを最適化できます。かつては数時間または数日の設定が必要だったタスクを、数分で完了できるようになりました。AWS MCP サーバーを使用することで、ベストプラクティスを備えたインフラストラクチャコードをすぐに利用できます。必要なすべてのテストステップ、コードスキャン、パイプライン通知を実行します。
将来のアイデアとしては、フルスタックアプリケーションのようなより複雑なアプリケーションをサポートすることを検討しています。遅いパイプラインを高速化する方法を提案し、履歴デプロイメントパターンに基づいたスマートスケーリングを使用します。また、システムを継続的に監視し、異常を検出し、手動介入を必要とせずに是正措置を提案するエージェントも検討しています。また、アプリケーションのタイプに基づいた AI 生成パイプラインテンプレートも検討しており、特定のアプリケーションタイプのベストプラクティスが含まれます。
Deploy with AWS MCP はデプロイメントプロセスに革命をもたらしました。わずかなプロンプトで、完全に機能し、安全でスケーラブルな CI/CD パイプラインが完成し、AWS に直接デプロイされます。私が興奮しているのは、CI/CD の設定に費やすすべての分が、イノベーションに費やさない分だということです。私たちは開発者にこの時間を返しています。
Feature flags と continuous configuration による本番環境の動的制御
Steve にステージに上がってもらって、もっと時間がかかるアクションと例を続けてもらおうと思います。さっきのデモで新しいことをいくつか見てもらえたと思います。終わった後、来週仕事に戻ったときにこれをどう活用できるかについて、喜んでお話しします。ここで少し話題を変えて、continuous configuration と feature flags について話したいと思います。
今日、feature flags を使っている人、この部屋にどのくらいいますか？結構いますね、素晴らしい。Feature flagging は、速く動いて、さっき話題に出た時間を取り戻すための秘密兵器だと思います。AWS でどのようにこれを使っているかについて、高いレベルで話そうと思います。Feature flagging を発明したわけではありませんが、AWS ではスケールで使っています。CI/CD のツールセットにこれを導入したい、あるいはどのように使うかを微調整したいという人たちにとって、その利点は非常に大きいです。
ですから、CI/CD の後に何が起こるかについて考えるべきです。 ソフトウェアを開発して、パイプラインを通して、本番環境に行きます。物事がどのくらい複雑かによって、15 分かもしれませんし、2、3 時間かもしれませんし、2、3 日かもしれません。AWS では、実は数週間の時間がかかります すべてのリージョンにわたって変更をロールアウトするのに。
ここで、ボックスの中にあるこちら側、リリース部分にズームインしようと思います。変更を加えたいけれど、CI/CD 全体を通したくない場合、AWS AppConfig のようなものを使うか、または他にも素晴らしい feature flagging ソリューションがあって、本番環境でソフトウェアの動作を調整できるので、その 15 分を通す必要がありません。例を挙げます。システムに悪質なアクターがいて、その悪質なアクターをブロックしたいという状況があるとします。Allow list や block list の設定がコードに埋め込まれていて、変更を加えたいのに feature flags を使っていない場合、何が起こるかというと、その悪質なアクターが何かをするのを防ぐために block list を更新することになります。
それを CI/CD に送ります。そしてそれは、さっき言ったように、15 分、2、3 時間、あるいは数日かかる可能性があり、それよりもずっと速く対応できるようにしたいのです。ですから、本番環境にあるアプリケーションが動的に設定データを取得して読み込んでいて、本番環境にあるソフトウェアの動作を調整しているという状況になります。
コードを変更することなく実現できます。この継続的な設定というコンセプトにより、いくつかの異なることができるようになります。フィーチャーフラグという言葉を聞くと、多くの人は新しい機能をリリースすることを思い浮かべます。これは非常に一般的なユースケースで、私たちはこれをリリースフラグと呼んでいます。その方法は、あなたのコードがあります。覚えていますか、さっき長寿命ブランチについて話していました。もう長寿命ブランチは必要ありません。コードはトランクにありますが、そのコードまたはその機能へのアクセスは、小さな設定用のブール値で制御されます。フィーチャーが有効になっていれば、人々に新しいコードを使わせます。フィーチャーが有効になっていなければ、人々にそのコードを使わせず、コードを隠します。
これにより、ソフトウェアエンジニアは何かを開発して、それが完全に完成していなくても本番環境にプッシュできます。その状態ではフィーチャーフラグがオフになっているため、誰もアクセスできません。彼らはその機能を開発し続けることができます。数週間、数ヶ月、その機能を開発するのにかかる時間だけ続けることができます。その後、その機能をオンにすることができます。そしてそれを少数のユーザーのためにオンにします。最初はほんの数人の開発者のためだけかもしれません。その後、すべての内部ユーザーのためになり、その後、ユーザーの10%、20%というように進みます。時間をかけてゆっくりリリースします。
フィーチャーフラグと継続的な設定により、機能をゆっくりオンにすることができます。また、機能をオフにすることもできます。これは本当に強力なものです。キルスイッチです。例えば、20%の時点で何かが起こっていて、これがCPUを殺しているのに気づいたとします。オフにする必要があります。すべてのコードに戻って変更してから再デプロイしたくはありません。代わりに、その機能をオフにするだけです。もちろん、コードをより迅速にロールバックすることもできますが、継続的な設定とフィーチャーフラグについて本当にクールなことは、このシナリオです。大きなプッシュがあり、その中に10個の機能があり、それが進行中で、ゆっくりリリースしていて、その10個のうちの1つに問題があるとします。
すべてをロールバックして、すべての10個の機能をロールバックする代わりに、フィーチャーフラグを使用して、うまくいっていない1つの機能だけをオフにして、それを修正して、その方法で前に進むことができます。フィーチャーフラギングの別のユースケースは、私たちが operational flags と呼ぶものです。少し後で operational flag の例のデモをするつもりです。allow list または block list がそのようなものかもしれません。また、バックグラウンドプロセスの数を制限するようなことをしたいかもしれません。私が以前働いていた会社でそれをしていました。ピーク時には、実際に非本質的なものをオフにして、CPUが管理可能なレートに保たれるようにして、その後、物事が落ち着いたら、それらの機能を再度オンにしました。
そして、変更の影響を制限するというこの考え方です。ほとんどの障害はソフトウェアの変更によって引き起こされることをご存知だと思います。ですから、常にこれらのものの爆発半径を制限する方法でリリースしていることを確認したいのです。そして、フィーチャーフラグを使用すれば、コードを変更することなく、すべてこれを行っています。設定データを変更しているだけです。その変更を行い、設定データの変更をプッシュアウトすると、アプリケーションはその変更を動的に読み取り、数秒以内に自分自身を更新します。では、ここにいくつかの利点があります。長寿命ブランチはありません。繰り返しになりますが、少なくとも私のキャリアの中で戻ってきたとき、ブランチマージはあなたを遅くすることができます。月に1回だけリリースできると言っている顧客がいます。マージコンフリクトを解決するプロセスが非常に長いためです。
では、feature flags を使うことで、trunk-based development と呼ばれるものを実現しています。これは well-architected framework の一部なので、興味があれば調べてみてください。基本的には、その機能を feature flag の背後にデプロイするだけです。つまり、feature release とコードのデプロイメントという考え方を分離しているんです。これは非常に強力です。コードをいつ本番に出すかについてコントロールを持つことができます。ステージで何かが起こるのに合わせてリリースのタイミングを取ろうとして待つ必要がないんです。AWS AppConfig は、ほぼすべての AWS サービスが使用している feature flagging ソリューションですが、今週は私たちにとって本当に大きな週なんです。
今週、顧客向けに AWS でこれらの新機能をすべてローンチしているのですが、実はこれらの機能は数週間前からすでに出ていたんです。コードは出ていたんですが、すべて feature flags で隠されていて、ほんの数ユーザーだけに対してオンになっていました。そして今週、多くの feature flags がオンになるんです。そして fast rollback についてはすでに少し話しましたが、スピードは本当に重要です。変更をロールバックしたい、そしてその 1 つの変更だけを非常に素早くロールバックしたいという考え方ですが、feature flags はそれを可能にしてくれます。 これにより、本番環境の問題に非常に素早く対応できるようになります。MTTR が本当に減少するので、素晴らしいことです。
また、本番環境で検証することもできます。QA グループがいて、QA 環境を持っていて、これはいつも起こることなんですが、QA では失敗しなかったのに本番環境では失敗した、というようなことがあります。feature flag でやっていることは、その新しい機能へのアクセスを許可することで、例えば QA アカウントや内部アカウントだけに対して本番環境でテストできるようにしているんです。そうすることで、本番環境にあるデータの特性がどのようなものであれ、それで本当に検証することができます。
feature flags を A/B テストに使う人もいます。私はいつもこう言うんですが、これは部屋の中で一番声が大きい人、または一番上の立場の人の意見を排除する方法なんです。「青いボタンの方が緑のボタンよりもずっとパフォーマンスが良くなると思う、だから青いボタンにしよう」と誰かが言うかもしれません。feature flag があれば、実際にトラフィックを分割して、10% には青を見せて、別の 10% には緑を見せて、数週間にわたって実際のデータを見て、誰かの意見に頼るのではなく、実際に何がより良いパフォーマンスを発揮するかを本当に確認することができます。ソフトウェアのリリース頻度が増加するのが見えるでしょう。これは素早く動くために重要です。
Werner からの引用をみなさんも聞いたことがあると思います。 彼は後でキーノートをやるので知っていますが、彼がいつも言う有名な引用は「Everything fails all the time」で、これを念頭に置いて設計しろということです。これは continuous configuration に関する彼のブログポストからの別の引用です。この機能を持つことは、本番環境でソフトウェアをチューニングするための秘密兵器です。ここの 2 番目の段落が好きなんです。「将来的には、イベントが起こる前にそれに対応できるようになるでしょう。」これは AI agents の約束です。AI agents は本番環境に出ていって、テストして、何か正しくないと理論立てて、実際にほんの小さな設定変更でその問題に対処するんです。
AWS AppConfig を使ったロギング詳細度の自動切り替えデモと総括
では、ここで簡単なデモをやってみようと思います。 このデモでは、フィーチャーフラグの使用方法をお見せします。ユースケースとしては、ロギングの詳細度を切り替えるオペレーショナルフラグです。本番環境で何か重大なことが起きている場合、info から debug に切り替えたいかもしれません。こういったことをコードの中でやりたくはないですよね。コードを変更して CI/CD パイプラインを通すのは避けたいです。もっと素早く対応したいのです。本番環境で疑わしいアクティビティが発生している場合、非常に素早くそれに対応したいです。フィーチャーフラグはそのようなユースケースに適しています。
ここで見ていただいているのは AWS AppConfig のコンソールです。 これは他のフィーチャーフラギングサービスも持っている機能です。AppConfig にはいくつかの異なるタイプの設定があります。フィーチャーフラグと呼ばれるものがあります。 また、オープンエンドの自由形式の設定もあります。ここで設定しているのは、configuration profile と呼ばれるもので、これは単にフラグの集合です。複数のフラグをグループ化して、単一のデプロイ可能なユニットとしてデプロイしたい場合があります。AppConfig ではこれらのものをグループ化することができます。
フラグを作成しようとしています。 これは本質的にはロギングの詳細度で、わかりやすい名前を付けます。コード内でそれを参照する方法を指定します。それはここにリストされています。フィーチャーフラグに関して、顧客からよく聞く問題、または内部で見かける問題の 1 つは、フィーチャーフラグの散乱という考え方です。フラグがコード全体に散らばっていて、 もう誰も何をしているのかわからなくなっているかもしれません。2 年前に使われていて、削除するのが怖いのです。実は AppConfig には、フラグを短期的なものとして指定できる機能があります。 ここでフラグをオンにして、アクティブにします。そして、ロギングの詳細度の値を設定します。
ここでキーを作成します。info から debug への値を設定するので、これを string 型として設定します。 そして、それが info であることを確認します。これが通常の状態です。 これを保存して、ここでフラグを実際に設定します。まず保存して、その後、フラグと設定データをコードと同じように考えます。実際にフラグをデプロイするのです。世の中にはいくつかのソリューションがあって、 データベース内のレコードを更新するだけで、それが全員にすぐに反映されるようなものもあります。その方法では、段階的なデプロイと自動ロールバックの利点が得られません。ここでは、デプロイを行っています。 その設定変更を本番環境にデプロイして、アプリケーションがそれを読み込んでいます。ロギングの詳細度は info であるべき、info であるべきと、アクティブに言っています。
では、ここで素早く先に進んで、CloudWatch アラームを設定します。 Datadog や New Relic のような他のソリューションでもこれを行うことができます。疑わしいアクティビティを監視しようとしています。その例としては、API を呼び出して IAM ロールをリストするようなことが考えられます。これは週を通じて通常のサイクルで発生しますが、何かが起きてそれがスパイクした場合、それは疑わしく見えます。何か変なことが起きています。これは詳細度を debug に切り替えたいユースケースで、何が起きているのかについてより多くの情報を得ることができます。これはサンプルアラームです。1 日を通じてここで通常のパターンを通過し、 しきい値を設定しました。これは本当に異常検知を行っていて、この API が呼び出される回数は問題ないと言っています。
ここで事前に設定したアクションを紹介します。CloudWatch ではこのようなことができますし、他の APM ソリューションでも、アラームが発火したときにアラーム以上のアクションを設定することができます。実際にアクションを設定できるんです。この場合、アラームが発火したときにトリガーされるアクションとして、AppConfig 内の verbosity フラグをトグルする Lambda を作成することにしました。
また、通知機能も備えています。これが起きているときに私も知りたいですからね。この場合、SMS、SQS、Event Bridge など、他のソリューション を使って通知することができます。ここで先に進みます。既に事前に設定されていたもの があって、実際にアラームが発火しました。見ていただくと、この 2、3 個のピークが異常を示しています。何か変なことが起きているんです。下部の緑と赤のバーで、ここで何か変なことが起きたのが分かります。システムは自動的に feature flag を info から debug に切り替えました。誰かが何かをする必要はなかったんです。これが運用の一部を自動化するという考え方です。
AppConfig に戻ると、フラグの値 が debug に設定されているのが分かります。アラームがそのアクションをトリガーしたからです。今お見せしたことをまとめると、AppConfig 内に feature flag または operations flag を設定できます。非常に柔軟で、文字列、数字、または必要なものに設定できます。そしてそれをアプリケーション内で使用できます。feature flag の切り替えを自動化することもできます。
では、ここで本題に入ります。今日お見せしたことから、いくつかの重要なポイント があります。このトークの最初に、物事は非常に急速に変わっていると言いました。皆さんが新しいことを学ぶためにここにいることを願っています。去年何が起きたかを見るためではなく、今年以降何が起きるのかを見るためです。Mihai は CI/CD プロセスを簡素化するための非常にクールな機能を開発しています。MCP は本当にチームがより速く動くことを可能にします。そしておそらく、皆さんの会社で最も重要なリソースは時間です。人も重要ですが、時間は非常に重要です。より速く動くことを可能にするツールやテクノロジーは、どれも非常に重要になります。
最後に、feature flag と continuous configuration を見ることを強くお勧めします。これにより、本番環境の問題にもっと速く対応でき、チームがより頻繁にソフトウェアをリリースできるようになります。これが最後のスライドだと思います。ここで何点かお礼を申し上げます。1 つ目は、このプレゼンテーション を最後まで聞いていただいたことです。皆さんが何か学べることがあって、来週から何か実行に移してくれることを願っています。皆さん、本当にありがとうございました。re:Invent の残りの時間も楽しんでください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion