re:Invent 2025: 生成AIでワークロードレジリエンスを向上させるSEEMS原則とAgentic Advisor
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Chaos & Continuity: Using Gen AI to improve humanitarian workload resilience
この動画では、AWSのプリンシパルソリューションズアーキテクトMike Georgeが、クラウドにおけるレジリエンスの5つの原則「SEEMS」を解説しています。Single point of failure、Excessive load、Excessive latency、Misconfigurations and bugs、Shared fateの各カテゴリーについて具体的な考慮点を示し、高可用性とディザスタリカバリーの違いを説明します。さらに、生成AIを活用した実践例として、Amazon BedrockとStrands agent SDKを使用したエージェンティック・レジリエンス・アドバイザーをデモンストレーションしています。このツールはAWSアカウント内のワークロードを自動分析し、RTO・RPOに基づいてレターグレードで評価、アーキテクチャ図の生成、可観測性の改善提案、ランブックの作成まで実行できることを実証しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
クラウドにおけるレジリエンスの5つの原則：SEEMSフレームワークと継続的改善
Amazon の CTO である Werner Vogels のことを聞いたことがあるかもしれません。彼の有名な言葉は「Everything fails all the time」です。re:Invent に何度か参加したことがある人なら、去年彼が自分の言葉がよく誤解されていると言ったのを覚えているかもしれません。実際の言葉は「Everything fails all the time, so plan for failure and nothing will fail」です。これが今日私たちが話す内容そのものです。失敗に備える方法をお話しして、皆さんのワークロードが失敗しないようにします。私の名前は Mike George で、AWS のプリンシパルソリューションズアーキテクトです。主に非営利団体と一緒に仕事をしています。今日お話しするコツやテクニックは、公共部門の組織が災害を通じて成功するのを支援するために使っているものです。
残念ながら、人道的な災害は世界中にあります。ウクライナでの戦争、中西部の洪水、そして世界中のいたるところに問題があるようです。これは継続的に起こり続けることです。しかし、もし自分の家の屋根に取り残されて助けを呼んでいるとして、電話をかけたときに繋がらなかったら、everything fails all the time だということを知っていても、あまり心強くはありませんよね。必要な時に物事が機能することを望みます。これは私たちが多くの人道支援組織で見つけることです。状況が最も悪い時こそが、皆さんのワークロードが成功する必要がある時なのです。ですから、今日お話ししたいのは、クラウドにおけるレジリエンスについて考える必要がある主な方法についてです。
クラウドにおけるレジリエンスについて考える時、人々は通常 N plus 1 の問題について考えます。つまり、EC2 インスタンスが 1 つあれば、2 つあればもっと良いだろうということです。アベイラビリティゾーンが 1 つあれば、2 つあればもっと良いだろう。リージョンが 1 つあれば、2 つあればもっと良いだろう。まあ、必ずしもそうではありません。実は、クラウドでレジリエンスを持つために考える必要がある 5 つの原則があります。最初のものは、本当に単一障害点を管理することです。これは大多数の人が考えることです。1 つは良いので、2 つはもっと良いはずだということです。
2 番目のことは過度な負荷です。過度な負荷とは、ワークロードをサポートするのに十分なリソースを持つことについてです。これには、ワークロードをサポートするための適切なサービスクォータなどを確保することも含まれます。また、過度なレイテンシーについても考えます。
過度なレイテンシーとは、ワークロードがレイテンシーにどのように対応するか、または、ワークロードのダウンストリーム依存関係が高いレイテンシーを持っている場合に何が起こるかについてです。
設定ミスとバグについて考えます。設定ミスとバグというのは、本質的には適切な CI/CD プロセスと自動化を備えていることを確認し、本番環境にワークロードを効果的にデプロイでき、手動での変更を行わないようにすることです。本番環境で手動の変更を加えている場合、今日はレジリエンスの問題がないかもしれませんが、いつかは問題が生じるでしょう。そして最後に考えるべきことは共有運命で、これは本質的にはワークロードの影響範囲を縮小することです。
影響範囲、つまり共有運命について考えてみてください。1 つのデータベースが 2 つ以上のワークロードをサポートしている場合を想像してください。そのデータベースに問題が発生すると、他のワークロードも影響を受ける可能性があります。つまり、望むよりも大きな影響範囲を持つことになります。では、これらの異なるカテゴリーの障害について考えるとき、SEEMS というアクロニムを使って覚えやすくしています。S は単一障害点、E は過度な負荷、次の E は過度なレイテンシー、M は設定ミスとバグ、そして最後の S は共有運命です。
これらの異なるカテゴリーについて考えるとき、単一障害点について考えます。ワークロードがどのようにアーキテクチャされているかを考えてください。冗長性を考慮してアーキテクチャされていますか？これらのコンポーネントが障害を起こした場合はどうなりますか？過度な負荷について考えるとき、このコンポーネントを圧倒する可能性があるものを考えたいです。このコンポーネントが他のダウンストリームコンポーネントを圧倒する可能性はありますか？このワークロードが成功するのに非常に長い時間がかかった場合はどうなりますか？人々が待つのをやめてしまいます。返されることのない作業を破棄することは可能ですか？このワークロードは二峰性の動作を経験する可能性がありますか？つまり、通常の条件下では一つの方法で動作し、障害シナリオでは別の方法で動作しますか？超過される可能性のあるクォータはありますか？そしてこのコンポーネントは負荷の下でどのようにスケールしますか？
過度なレイテンシーについて考えるとき、このコンポーネントがレイテンシーを経験した場合はどうなるか、またはダウンストリームの依存関係がレイテンシーを経験した場合はどうなるかのような同様のことを考えます。ワークロードはどのように動作しますか？設定ミスとバグについて考えるとき、繰り返しになりますが、失敗したデプロイメントまたは不正なデプロイメントを自動的にロールバックできるかどうかを考えたいです。または、障害のあるコンテナから、あるいは不正なデプロイメントが発生した可能性のある Availability Zone からトラフィックをシフトできますか？オペレーターエラーを防ぐためのガードレールやその他のものは用意されていますか？証明書や認証情報など、ワークロード内で期限切れになる可能性のあるものはありますか？最後に、共有運命について考えるとき、このコンポーネントをデプロイするときの変更の大きさについて考えます。大きな変更ですか？そうであれば、問題が発生するリスクが増加する可能性があります。このコンポーネントは他のワークロードとユーザーストーリーを共有していますか？このワークロードと密接に結合されているものはありますか？このワークロードが部分的な障害または完全な障害を経験した場合はどうなりますか？これらはすべて考える価値のあるさまざまな種類のことです。
では、レジリエンシーについて考えるときは、メンタルモデルを持つことが重要です。皆さんに心に留めておいてほしいメンタルモデルは 高可用性です。高可用性というのは、予想される特定の種類の障害に対応するようにアプリケーションを構築する方法です。皆さんは自分たちに問いかけるかもしれません。ワークロードの中で何が失敗することを期待するのか、と。簡単な例としては、複数のアベイラビリティゾーンに分散している場合、時間が経つにつれてアベイラビリティゾーンを失う可能性があります。これは計画すべき何かのように思えます。他の種類の障害についても考えることができます。予想したいかもしれない障害の種類です。
一方、ディザスタリカバリーがあります。ディザスタリカバリーは、予想した障害シナリオだが軽減することを決めなかった、あるいは単に予想していなかったことについてです。ディザスタリカバリーは、運用を再開するための方法です。高可用性とディザスタリカバリーの両方の下には、継続的改善というこのメンタルモデルがあります。ワークロードを継続的に改善するために何ができるか、ということです。なぜなら、レジリエンシーは一度きりのものではないからです。これはすべて、良い CI/CD プロセスを実装し、レジリエンシーテストを導入することについてです。ワークロードの障害をテストするだけでなく、チームの障害もテストするためです。
生成AIを活用したエージェンティック・レジリエンス・アドバイザーの実演
レジリエンシーについて多くの時間を費やしてきました。では、今度は生成 AI について話しましょう。 典型的な生成 AI アプリケーションを見てみましょう。ユーザーがエージェントと相互作用し、そのエージェントが foundation model とツールのセットと相互作用する場合です。そのツールのセットは MCP として聞いたことがあるかもしれません。
さて、興味深いと思うことの一つは レジリエンシーについて話してきたことです。アプリケーションをテストしたい5つの異なる領域について話してきました。アプリケーションが shared fate、高レイテンシー、容量不足、設定ミスとバグ、単一障害点に対して脆弱かどうかを判断したいのです。興味深いと思いませんか？生成 AI を使用して、クラウドで実行しているワークロードを自動的に調べて、これら5つの領域のいずれかに問題があるかどうかを判断できるでしょうか？それが私がやったことであり、今日皆さんに実演したいことです。
先ほど示したダイアグラムと同様に、これは今日皆さんに実演したいエージェンティック・レジリエンス・アドバイザーです。 レジリエンス・アドバイザーはこのように機能します。まず第一に、エージェントを構築しました。そのエージェントは Amazon Bedrock を通じて大規模言語モデルと相互作用し、その後ツールのセットと相互作用します。これらのツールのセットは、そのエージェントにネイティブに持っていない機能を与えます。3つのツールセットへのアクセスを与えました。
まず1つ目は AWS ツールの使用です。これは Strands agent SDK に組み込まれているツールで、このツールを使うことで、私の agent が AWS アカウントに入って、そこで実行しているリソースを検査することができます。次に私が作成したツールは、calculate letter grade ツールです。ワークロードのレジリエンスを知るために、シンプルなレターグレードを持ちたいんです。shared fate issue が発生した場合、これは A、B、C、それとも D なのか。これは単純な Python コードで、Strands agent 内の識別子で装飾されており、それがツールであることを agent に知らせます。
最後に、AWS documentation MCP server を使用しています。これは公開されている MCP server で、AWS に関連するほぼすべてのことについて、詳細なドキュメントを取得することができます。私がやりたいことは、この agent を実行することです。自分のアカウント内の特定のワークロードについて質問を投げかけて、レジリエンスの状況を得られるようにしたいんです。そうすれば、何か修正が必要かどうかがわかります。そこで私がやったことは、2つのコンソールを用意しました。右側の白い画面が、実際に実行している agent です。実際の運用では、このコンソールを通して実行することはありませんが、ここではあなたに見てもらうためにこうしています。
左側は、実際に agent と対話しているクライアントです。まず agent を起動することから始めます。実行が始まっているのが見えますね。では左側で、クライアントを起動して、いくつかの質問に答えることから始めます。AWS アカウントで実行しているワークロードのタグを指定します。 ワークロードの RTO と RPO を教えます。
agent 側では、 food-agent ワークロードを見ていることが識別され、RTO、つまり recovery time objective が 24 時間で、RPO、つまり recovery point objective が 12 時間というワークロードを分析しようとしています。AWS アカウントに出ていって、それらのリソースを引き戻し、 それらについて推論してから、ドキュメントを引き戻して、ワークロードを改善するために何ができるかを見ています。左側で結果が返ってきたのが見えますね。先ほど述べた5つのカテゴリーが表示されています。よく見ると、レターグレードはほぼ B と C が付いているのが見えます。つまり、RTO と RPO が 24 時間と 12 時間の場合、ワークロードは大丈夫です。改善の余地はおそらくあります。
ですが、ここで別の質問をしたいんです。recovery time objective を 24 時間から 2 時間に変更したら、レターグレードはどう変わるでしょうか。そして RPO、つまり recovery point objective を 12 時間から 30 分に変更したら、レジリエンスの状況はどう変わるでしょうか。右側で見えるように、agent は AWS アカウントに戻る必要がありません。既に実行しているワークロードを理解しています。 そのワークロードについてさらに推論し、修正すべきことについて主張を正当化するためのドキュメントを引き戻しています。
左側に表示されているのが、クライアントから返ってくる内容です。よく見ると、以前はほとんどの成績が B と C だったのに対して、今はほとんどが D と F になっています。つまり、このワークロードは 2 時間 30 分の RTO と RPO をサポートしていないということです。次にやりたいことは、本番環境で長年実行されてきたワークロードが多くあるのに、アーキテクチャ図を更新したことがないという事実に対処することです。図が古くなってしまいます。では、こう聞いてみたいのです。すでにアカウントから取得した内容に基づいて、アーキテクチャ図を作成してください。
エージェントがそれについて推論し、左側を見ると、Mermaid 形式でアーキテクチャ図を生成してくれています。これを Git にチェックインすれば、このようなグラフが得られます。これが分析対象のワークロードです。Bedrock Agent が Lambda 関数と相互作用し、S3 バケットから読み書きしています。Secrets Manager を使用しており、CloudWatch Logs にログを出力しています。IAM ロールがあり、KMS を通じた暗号化があります。
次にやりたいことは、このワークロードに問題があることを認識しているという事実に対処することです。改善したいことが確実にあるのですが、すべてが間違っているというリストは欲しくありません。まずは可観測性から始めたいのです。では、可観測性の観点から焦点を当てるべき上位 3 つのことは何かと聞いてみましょう。右側のエージェントがワークロードについて推論し、ドキュメントを取得します。左側を見ると、結果が表示されています。
CloudWatch アラームとダッシュボードを包括的に設定する必要があることが特定されています。もっともです。現在、アラームとダッシュボードがありません。次に、X-Ray でトレーシングを有効にすべきだと言っています。分散トレーシングがないので、これは良い次のステップです。そして、拡張ログと Log Insights をセットアップすべきだと言っています。繰り返しになりますが、ログファイルはありますが、実際にはそこまでログを出力していないので、これも別の良いステップです。これらの推奨事項それぞれについて、そのタスクを実行する方法に関する特定のドキュメントへのリンクが提供されています。ログの設定について話すときに、CloudWatch のメインページへのリンクを提供していないことに注意してください。ドキュメントの深い部分へのリンクを提供しています。
最後にエージェントでやりたいことは、誰もダウンタイムを望まないという事実に対処することですが、悪い運用の日に備えたいのです。では、運用イベントから復旧するために使用できるランブックを作成してください。
私のエージェントが実行されていて、私のワークロードについて推論しています。ドキュメンテーションにアクセスして、それを取得しているのが見えます。そして、ご覧の通り、ランブックを生成してくれました。ここでいくつかのインシデント重大度が見えます。下にスクロールすると、Lambda 関数の復旧手順、S3 バケットの復旧手順、そして Bedrock エージェントの復旧手順が見えます。Secrets Manager についても、サービス全体を検証する方法があるので、サービスが復旧して実行されていることを確認できます。そして、ここの一番下を見ると、インシデント後の分析を完了するために何をすべきかについてのステップを提供してくれます。
まとめとリソース紹介
つまり、私たちは質問に答えることができました。生成 AI を使ってワークロードの耐障害性を改善することはできるのか？答えは絶対にイエスです。ここに QR コードが 2 つあります。興味があれば参考にしてください。最初の QR コードは Strands Agent 用です。私は Strands SDK を通じてこのエージェントを構築したと述べました。Strands についてもっと知りたい場合は、その QR コードをスキャンしてください。
真ん中の QR コードは Resilience Agent 用です。今日デモンストレーションしたコードについてもっと知りたい場合は、その真ん中の QR コードをスキャンしてください。これにより、私たちの GitHub リポジトリ、つまり nonprofit samples リポジトリに直接移動します。そして、このコードを実際に構築する方法を見たい場合は、右側の QR コードをスキャンしてください。これは木曜日に開催される AIM 336 の QR コードで、そこで私はこの正確なコードを構築する方法を説明します。
次のステップとして、nonprofit 組織の場合、左側の QR コードは今週実施している nonprofit 関連のセッションをさらに表示しています。右側の QR コードは、nonprofit で、あなたのアカウントチームが誰なのかを知りたい場合は、それをスキャンして、あなたが誰なのかを教えてください。あなたが何をしているのかについてもっと話し合いたいです。それでは、お時間をいただきありがとうございました。セッションアプリで調査を完了していただくようお願いします。ありがとうございました、皆さん。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion