re:Invent 2024: AWSが語るGenerative AIの本番運用とレジリエンス設計
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Designing generative AI workloads for resilience (COP332)
この動画では、Generative AIアプリケーションの本番環境での運用に必要なレジリエンス設計について、AWSのSenior Principal Solutions ArchitectのRandy DeFauwとSenior Resilience Specialist Solutions ArchitectのJennifer Moranが解説しています。Proof of Conceptから本番環境への移行における課題や、Vector Database、Prompt Library、Fine-tuningモデルなどの共有リソースの管理方法、Fault Isolation、Sufficient Capacity、Timely Output、Accurate Output、Redundancyの5つのレジリエンス特性について具体的に説明しています。特にAmazon Bedrock、LangChain、AWS Step Functionsなどの実装例を交えながら、Chaos EngineeringやCross-Region Replicationといった実践的な対策手法まで踏み込んだ内容となっています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Generative AIアプリケーションのレジリエンス設計：本セッションの概要
皆様、こんにちは。本日は、Generative AIアプリケーションのレジリエンス設計についてのセッションにご参加いただき、ありがとうございます。本日のKeynoteで、CEOのMatt Garmonが、Generative AIのプロダクション化への道筋について言及していましたが、これは私が昨年多くのお客様から伺っていた内容と一致しており、Jenniferと私も心強く感じています。特に、エンドユーザーや顧客向けのアプリケーションにおいて、Generative AIアプリケーションを本番環境で大規模かつ安定的に運用する方法が重要となってきています。本日は、Generative AIアプリケーションを構築する際に考慮すべきレジリエンスのベストプラクティスについてお話しさせていただきます。
私はAWSのSenior Principal Solutions ArchitectのRandy DeFauwです。そしてJenniferをご紹介させていただきます。 皆様、本日はご参加いただきありがとうございます。私はJennifer Moranと申します。AWSのSenior Resilience Specialist Solutions Architectとして4年以上勤務しています。私の肩書きからお察しの通り、お客様のワークロードのレジリエンス構築をサポートすることが私の仕事です。そしてもちろん、Generative AIもその対象に含まれます。Randyが申し上げた通り、本日はそのテーマについてお話しさせていただきます。
本日のアジェンダ：Proof of Conceptから本番環境へ
本日のアジェンダをご説明させていただきます。まず、Proof of Conceptと本番環境向けアプリケーションの構築における顕著な違いについて詳しく見ていきます。これを理解することは、現実的な期待値の設定と効果的な計画立案に不可欠です。次に、ビジネス要件の確定に焦点を当てます。これは単に機能的なシステムを構築するだけでなく、ユーザーのニーズと組織全体のビジネス戦略に真に適合したシステムを確実に構築するための必須ステップです。
その後、Generative AIアプリケーションの全体像を探り、様々な階層とレイヤーについて解説していきます。レジリエンスの特性について議論する前に、Observabilityの前提条件について説明します。なぜなら、測定できないものは改善することができないからです。その基礎を踏まえた上で、レジリエントなワークロードが持つべき特性を確認し、それらの特性に影響を与える可能性のあるカテゴリーについて探っていきます。それぞれについて詳しく掘り下げ、従来のレジリエンスパターンとGenerative AIワークロード特有の考慮事項の両方を検討します。
Proof of Conceptと本番環境の違い：魔法から現実へ
Generative AI開発の世界へようこそ。ユニコーンと虹に彩られた、まさにユートピアのような世界ですね。Proof of Conceptの作成が、かつてないほど魅力的になっています。今日では、アイデアを持つ人なら誰でも、AIの力を借りて記録的な速さでそれを実現できます。わずか数行のコード、あるいはNo-codeソリューションを使用するだけで、AIアプリケーションのプロトタイプを作成し、現実世界の課題に対応することができます。例えば、複数の言語で問い合わせに対応するカスタマーサービスボットや、疾病の早期発見を支援する医療画像ツールを素早く構築できます。教育分野では、生徒一人一人の学習スタイルに適応するAIチューターのプロトタイプを作ることもできます。
これまで数ヶ月もの開発期間を要していた革新的なアイデアが、今では数日で構想を練り、テストすることができるようになりました。この創造の容易さは、まさに魔法のようです。あらゆる産業分野のイノベーター、起業家、問題解決者たちに、無限の可能性を開いています。私たちは今、Rapid PrototypingとAIの能力が融合する技術革命の最前線に立っており、かつてないスピードで野心的なアイデアをProof of Conceptsとして具現化できるようになっています。
AIのProof of Conceptsを作ることの容易さは確かにワクワクさせられますが、これが私たちの旅の第一歩に過ぎないことを認識することが重要です。有望なプロトタイプから本番環境に対応したアプリケーションへの飛躍は、このような世界へと私たちを導きます。もはや魔法のようには見えなくなってきましたね。AI開発の試練の場、つまりProof of Conceptから本番環境への移行にようこそ。多言語で問い合わせに対応するために構築したカスタマーサービスBotを覚えていますか？本番環境では、日々何百万もの問い合わせに対応する必要があり、その多くは学習していない方言やコンテキストを含んでいます。精度を維持しながらこの需要に対応することは大きな課題です。早期疾病検出のための医療画像ツールは、今や膨大な量の機密性の高い患者データを処理する必要があり、データプライバシー、セキュリティ、規制遵守に関する重要な問題を提起しています。
命が懸かっている場合、完璧またはそれに近い精度が必要なことは言うまでもありません。そして、あのAdaptiveなAIチューターは、何千人もの学生に同時にレッスンをパーソナライズしようとする中で、学習スタイルや教育コンテンツの多様性に対応しきれず、計算リソースを驚くべき速さで消費しています。スケーラビリティ、データプライバシー、精度、リソース管理といったこれらの課題は、私たちの回復力が本当に試されている領域です。複雑で時には困難を感じることもありますが、それこそがProof of Conceptsの約束を実現できる本番環境対応のAIシステムを構築するチャンスでもあるのです。
ビジネス要件の確立：レジリエンス戦略の基盤
興味深いことに、Proof of Conceptから本番環境への移行における最初のステップは、実は技術的なものではありません。ビジネス要件を確立することなのです。レジリエントなシステムを構築する際、私たちはしばしば時間、お金、リソースという3つの大きな制約に直面します。そのため、手持ちのリソースを賢く使うことが重要で、ここでビジネスインパクトとの整合性が非常に重要になってきます。これは技術的なセッションですが、私はいつもこのスライドを見せます。なぜなら、レジリエンスを設計する際には、潜在的な混乱がもたらす実世界への影響に直接結びついたレジリエンス戦略が必要となるため、ビジネス要件を理解することが不可欠だからです。
Business Impact Analysisから始めるかもしれません。これは重要な第一歩であり、失敗による潜在的な影響を定量化する必要があります。財務的損失、投資の無駄遣い、法的またはコンプライアンス上のペナルティ、信頼の喪失やネガティブな評判といった風評被害などが含まれます。Business Impact Analysisを行った後、Risk Assessmentを作成します。ここでは、モデルの劣化、データ損失、インフラの障害、APIの可用性といったさまざまなリスクの可能性と深刻度を評価します。これにより、最大の脅威をもたらす領域に焦点を当てて、レジリエンスへの取り組みの優先順位付けを行うことができます。
レジリエンスは単純な二元論ではありません。慎重なトレードオフが必要なのです。レジリエンス対策のコストと複雑さを、障害の潜在的な影響や全体的なリスク許容度とバランスを取る必要があります。レジリエンスは真空の中で構築することはできません - 組織の実際のニーズと優先順位に根ざしている必要があります。そうしてはじめて、Generative AIワークロードの完全性と継続性を真に保護する、包括的なリスク重視のアプローチを開発することができるのです。
Generative AIスタックの構造とObservabilityの重要性
では、Generative AIスタックがどのようなものか見ていきましょう。ありがとう、Jennifer。まず、私はUnicornが好きではありません - 額に尖ったものがついた奇妙な空飛ぶ馬のように見えて、少し不気味です。しかし、Jenniferが指摘したように、多くの企業にとってPoCから本番環境への移行が意外に難しいという点は正しいですね。私たちは、多くのアイデアをProof of Conceptで試し、時には相当な時間とお金を投資しているにもかかわらず、実際には本番環境にローンチできていない数多くの顧客を見てきました。その理由としては、ビジネスケースが不明確であることやコストが予想以上にかかることなどがありますが、単に大規模な本番環境で信頼性とセキュリティを確保して運用できるという確信が持てないということもあります。
まず最初に、完全なGenerative AIソリューションに何が必要かを見てみましょう。 この図は今ではよく理解されるようになってきていますが、約1年前はそれほど明確ではありませんでした。この図の基になっているのは、実はAndreessen Horowitzが約1年半前に発表した「The Emerging LLM Application Stack」という非常に良い記事です。彼らは、RAGやAgentなどの用語について話し始めると、実際に何が組み合わさっているのかを解きほぐす必要があるため、具体的にどのような要素が関係しているかを明確に示しました。これらの各ボックスは異なる機能領域を表しており、モデルは確かに重要ですが、それはボックスの1つに過ぎません。そのボックスの中でさえ、多くの選択肢があります - Amazon Bedrockのような完全マネージド型サービスを通じてモデルを利用することができ、その場合は単にAPIを呼び出すだけで、そのサービスが提供するスロットリング制限やSLAについて考え始めます。また、SageMakerを通じて、あるいはKubernetesやその他の方法でより自前のアプローチでセルフホストすることもできます。それぞれに考慮すべき異なるレジリエンスの側面がありますが、繰り返しになりますが、それは1つのボックスに過ぎません。また、Observabilityコンポーネントやガードレールのような有害な入出力を検出するためのTrust and Safety要素のボックスもあることに気付くでしょう。これらの各要素には、SAASプロバイダーへのAPI呼び出しを通じたもの、オープンソースソフトウェアに依存するもの、より自前のアプローチを取るものなど、複数の実装オプションがあります。Retrieval Augmented Generationを使用した質問応答システムでは、データ取り込みパイプラインとVector Databaseがあります。データエンジニアはデータ取り込みパイプラインの構築方法を知っているかもしれませんが、GPUがパフォーマンスのボトルネックとなり、Kafkaからストリーミングデータを取得するのではなく、PDFのような半構造化データをインデックス化するパイプラインの構築には慣れていないかもしれません。
詳しく見ると、Large Language Model自体以外に全く新しいコンポーネントがあるわけではありませんが、異なる種類の入出力を持つ新しいパターンで異なるピースを組み合わせているのです。これは、Observabilityに関する別の関連するポイントにつながります。 過去1年間の数十の顧客との会話に基づくと、本番環境でGenerative AIを成功裏に運用するために不可欠な2つのコアコンピテンシーが際立っていました。1つはModel Evaluationで、これ自体が大きなテーマですが、もう1つはObservabilityです。これは、監視が必要な異なるパフォーマンス特性を持つ新しいコンポーネントの組み合わせだからです。
私たちは現在、Observabilityを実装するためのメンタルモデルを、GitHubでの参照実装と共に公開しています。この実装には、いくつかの独自のツール選択が含まれています。収集が必要な3つの要素があります：モデルを自身でホストする際のGPU負荷やInferenceエンドポイントからのリクエスト量などのコアメトリクス、トラブルシューティングの動作を理解するためのログ、そしてトレースです。特にGenerative AIでは、完全なアプリケーションがモデルと周辺コンポーネント間の複雑な相互作用を含むため、トレースが特に重要となります。エージェントシステムでは、複数のモデル呼び出し、ツールの実行、コンテキストのためのVector Databaseのクエリが発生するため、そのチェーン全体にわたるデータフロー、レイテンシー、エラーを追跡することが極めて重要です。
私たちが開発したメンタルモデル（実際には、私は同僚が作成したものを具体化するのを手伝っただけですが）は、4つの層で構成されています。第1層は、Vector Databaseの使用率、アプリケーションサーバーのCPU負荷、Amazon Bedrockでのモデル呼び出し回数など、基本的なコンポーネントレベルのメトリクスをカバーします。第2層は、システム全体のデータフローを理解するためのトレースです。第3層は、エンドユーザーからのフィードバックに焦点を当てており、これはGenerative AIのパフォーマンス評価が単純ではないため、極めて重要です。Amazon Bedrockは現在、別の言語モデルを評価者として使用する機能を提供していますが、特に本番環境では人間からのフィードバックがゴールドスタンダードであり続けています。
第4層では、システムのパフォーマンスをより深く掘り下げた高度なメトリクスを検討します。質問応答システムの場合、これにはモデルがコンテキストをどれだけうまく活用しているかの評価や、簡潔さや事実性といった基準での採点が含まれます。また、ユーザーの質問の意味的な意味が時間とともに変化しているかどうかを判断するための、埋め込みドリフトなどの基礎的なデータ品質の側面も検討します。これらはすべて重要な観察可能な要素です。この導入を終えて、Jenniferにレジリエンス特性について話してもらいましょう。
Generative AIシステムの5つのレジリエンス特性
ありがとうございます。Generative AIシステムのレジリエンスを設計する際、 私たちは5つの重要な特性を設計に組み込む必要があります：Fault Isolation、十分なキャパシティ、タイムリーな出力、正確な出力、そして冗長性です。これらの特性はそれぞれが重要な役割を果たしますが、それらが連携して働く時に真の力を発揮します。これらは独立した概念ではなく、相互に連携し合う柱であり、Generative AIワークロードだけでなく、実際にはすべてのワークロードに対してレジリエントな基盤を作り出します。
各レジリエンス特性は、その効果を損なう可能性のある固有の課題に直面します。 これらの重要な関係性を見ていきましょう。Fault Isolationは、共有された依存関係の障害が連鎖的な障害を引き起こす可能性のある、Shared Fateのシナリオに直面します。 これらの障害は、意図されたFault Isolationの境界を越えて広がります。十分なキャパシティは、過剰な負荷がシステムを設計限界を超えて押し上げた時に、 スケーラビリティの弱点を露呈します。タイムリーな出力は、スピードへの要求がAIの計算の複雑さと衝突する中で、 過度のレイテンシーと戦います。正確な出力は、AIにおけるエラーとイノベーションの境界線が曖昧になる可能性のある、 設定ミスやバグと対峙します。冗長性は、コスト制約と一貫性の要求によってさらに複雑化された、 単一障害点に遭遇します。
これらの関係性を理解することで、脆弱性を予測し、より回復力のあるアーキテクチャを設計することができます。これから先の議論において、これらのマッピングが基礎となります。Generative AIワークロードにおけるこれらの具体的な課題のそれぞれについて詳しく見ていき、これらの特定の脅威に対する回復力特性を強化するための戦略を探っていきます。
Fault Isolationと共有リソースの課題
まずは、特に複雑なGenerative AIアーキテクチャにおいて、システムコンポーネント内の障害を封じ込めるための重要な戦略であるFault Isolationから始めましょう。これは、アーキテクチャレベルやインフラレベルのさまざまなアプローチで効果的に実装できます。複数の Generative AIアプリケーション間で、あるいは障害発生時に大きな影響範囲を持つ個々のコンポーネント間で共有される可能性のあるものを見ていくと、まず最初に注目すべきはVector Databaseです。
Vector Databaseは実際には、2つのことができる異なるツールのカテゴリーです：浮動小数点数のリストである埋め込みベクトルを保存し、類似性検索によってそれらを取り出すことができます。Vector Databaseについて、より重要なのは非機能要件に基づいて選択することです - 必要なパフォーマンスのタイプ、一定期間にどれだけのデータを取り込む必要があるか、そしてどのような信頼性特性が必要かということです。AWSの世界では、例えばOpenSearch、Aurora、MemoryDBなど、多くの選択肢があります。
Vector Databaseについて注意すべき点の1つは、私たちが通常のデータベースワークロードと同じように考えがちだということです - 大きなデータベースがあり、その運用方法を知っているので、どんどん詰め込んでいこうと。そうすると、複数のワークロード間でこれを共有している場合、あるワークロードがVector Databaseに大きな負荷をかけて遅くなったり利用できなくなったりすると、それを使用している他のすべてのアプリケーションに影響が及ぶという問題に直面します。
Prompt Libraryは、もう1つの興味深い共有リソースです。Promptは、モデルに送信する指示であり、モデルを特定の目的に合わせて調整する最初の、そして多くの場合最も効果的な方法であるため、ますます重要なリソースとなっています。場合によっては数段落の長さになることもあるこれらの慎重に作成されたPromptを、チーム間で共有するライブラリやテンプレートのセットとして保存したいと考えるかもしれません。これに対する変更は、どのようなソフトウェアの変更と同様に、すべての利用者に波及する可能性があります。
モデルをFine-tuningする場合、特定のタスクでより良いパフォーマンスを発揮できるよう、自社のデータを使用してモデルを適応させることになります。そして、そのモデルを複数のアプリケーションで活用する場合、それは共有リソースとなります。Fine-tuningに使用するデータも、多くの場合、異なるチーム間で共有されます。これからJenniferが、この問題をどのように緩和するかについて説明しますが、ここで覚えておいていただきたいのは、私たちが話す緩和策の多くは、実はGenerative AIに特有のものではないということです。これらは、私たちが適用している一般的なレジリエンスのベストプラクティスなのです。
Generative AIに特有の事項もいくつかありますが、それらについては途中で触れていきます。では、Jenniferに交代します。
組織がRetrieval-Augmented Generation（RAG）を試験的に導入するよくある状況を視覚化してみましょう。画面には、Randyが説明した共有リソースの一部が表示されており、複数の部門を持つ大規模な組織が示されています。Human Resources部門がRAGのProof of Conceptに取り組んでいます。次にFinance、Sales、R&D部門が独自のRAG Proof of Conceptの開発を始めます。そして最後に、Customer Service、Legal、Product部門もこの流れに加わり、各部門は一部のリソースを共有しています。同じVector Databaseを使用している部門もあれば、同じPrompt Libraryを使用している部門もあり、その時点で十分と思われる同じFine-tuned Modelを使用している部門もあります。なぜ一から作り直す必要があるでしょうか？
Vector Databaseを共有依存関係の例として考えてみましょう。Vector Databaseは順調に動作し、Embeddingsを提供し、それを使用する全部門の類似性検索を可能にしています。すべてが順調に動いていますが、Vector Databaseに何か問題が発生したとします。ハードウェアの故障かもしれませんし、ソフトウェアのバグかもしれません。あるいは、システムに負荷がかかる予期せぬトラフィックの急増かもしれません。何が障害の原因かは実はそれほど重要ではありません。重要なのは、共有依存関係の障害が組織全体にどれほど急速に連鎖的な影響を及ぼすかということです。HR部門は従業員記録にアクセスできなくなり、退職する従業員からの質問に答えられなくなります。Customer Serviceのチャットボットは突然一般的な応答しかできなくなり、顧客を困らせています。Legalの契約分析は完全に停止し、重要な取引が遅延する可能性があります。また、Product開発チームは重要な技術文書にアクセスできなくなり、作業が遅延します。
このように、単一のVector Databaseを共有するという一見賢明な近道が、結果として会社全体の重要な機能を麻痺させてしまいました。これは、部門という本来の障害分離境界を越えて依存関係の影響が及ぶ、典型的な共有運命（Shared Fate）のシナリオです。では、どうすればよいのでしょうか？各部門のRAGアプリケーションが独自のVector Databaseを使用し、障害分離境界内で分離されていたらどうでしょうか？これは様々なアーキテクチャアプローチで実現できます。各部門のRAGアプリケーションを独立してデプロイ可能な個別のサービスとするMicroservicesアーキテクチャを実装できます。関連するサービスをセルにグループ化し、単一の障害の影響範囲を制限するCellularアーキテクチャを使用できます。異なるAWS Availability Zoneを活用して、1つのゾーンの障害がシステム全体に影響を与えないようにすることができます。複数のAWS Regionに分散させることで、さらに高度な地理的分離とレジリエンスを確保できます。さらには、開発、ステージング、本番環境など、異なるAWS Accountに分けることで、ある環境の問題が他のすべての環境に影響を与えることを防ぐことができます。
これは良いアイデアですが、Fault Isolationが常に答えではなく、Shared Fateが常に問題とは限らないという観点から、この考え方に一度チャレンジしてみましょう。物事は必ずしも簡単にきれいな四角い箱に収まるとは限りません。すべてを箱で囲めるなら、それは素晴らしいことでしょう。重要なのは、戦略的な理解を持つことです。 Shared Fateのシナリオを特定し、システム間の相互接続を認識し、潜在的な影響を理解する必要があります。 そして、ある領域での障害が他の領域にどのように影響するかを予測する必要があります。それぞれの固有の課題に対して、 適切なアプローチを選択し、的確な対策を実施する必要があります。そのアプローチは、必ずしもFault Isolationとは限りません。
Sufficient CapacityとExcessive Load：スマートなスケーリング戦略
この点を強調させていただきたいのですが、各部門固有のニーズを尊重しつつも、私たちは包括的なAI戦略を強く推奨しています。部門のサイロ化を作り出すのではなく、 組織全体の一貫性を保ちながら、各チームが自身のAIの運命を自律的に決定できるようにしたいのです。
この包括的な戦略には、集中的なデータとモデルのガバナンスフレームワーク、すべてのAIイニシアチブにおける一貫したコンプライアンスと遵守、品質と倫理基準を維持するための統一されたモデルトレーニングポリシーなどが含まれます。自律性とコラボレーションのバランスを取ることで、レジリエントであるだけでなく、適応性と革新性を備えたエコシステムを作り出すことができます。
ここで、AIシステム、特にGenerative Modelにおける Sufficient CapacityとExcessive Loadについて考えてみましょう。スケーリングは単にコンピューティングパワーを追加することだけではなく、賢明なリソース管理が重要です。まずは、負荷がGenerative AIシステムにどのようなストレスを与えるかについて話してみましょう。 Generative AIがある程度容量制約を受ける可能性があるという考えは、おそらく目新しいものではありません。3年前にNVIDIAの株を購入できた方がいらっしゃれば、おめでとうございます。GPUは希少で高価なリソースであり、膨大な容量プールを持つクラウドでさえ、無制限ではありません。
Large Language Model自体が非常に制約のあるリソースである可能性があることは重要な点です。これはAmazon Bedrockでも見られます - すべてのAWSアカウントには特定のモデルごとの制限があり、一定のリクエストレートや入出力トークン量を超えるとスロットリングされます。これらの制限はある程度まで引き上げることができますが、Bedrockサービスには、自動的に他のAWS Regionでバーストキャパシティを提供するためのCross-Region Inferenceなど、AWSとしては珍しい機能が搭載されていることにお気づきでしょう。
マネージドサービスでは、これらのモデルはスロットリングの対象となります。これは、BedrockのようなAWSサービスだけでなく、例えばAnthropicのClaude AIの公開サイトでも見られる現象です。Proプランを契約していても、キャパシティの制約により、より小規模なモデルや簡潔な出力形式に切り替わることがあります。一方、モデルをセルフホスティングする場合は、システムの管理は自己責任となるため、モデルに過負荷をかけないよう細心の注意を払う必要があります。
生成AIの特徴的な点として、他のアプリケーションや一般的なMLアプリケーションとは異なり、SageMakerやKubernetesの推論エンドポイントでも素早いオートスケーリングが難しいということがあります。オートスケーリングポリシーを設定することはできますが、かなり積極的なスケールアップ設定が必要になるでしょう。その理由は、特に大規模なモデルの場合、VMの起動後、数ギガバイト、時には数十ギガバイトにも及ぶモデルの重みをダウンロードし、それらをGPUメモリにロードする必要があるためです。そのため、これらのモデルでは瞬時のオートスケーリングは実現できません。
Vector Databaseも他のデータベースと同様です。OpenSearchやAurora、Pineconeなど、どのデータベースを選択するにしても同じことです。PineconeのようなSaaSオプションの場合は、独自のスロットリング制限があるでしょう。OpenSearchやAuroraの場合は、確実に負荷をかけすぎることが可能です。例えば、大量のPDFを一度に取り込むとライターノードが過負荷になる可能性があり、さらにリードトラフィックも監視する必要があります。
生成AIのデータ取り込みパイプラインは興味深い特徴を持っています。従来のアナリティクス用の取り込みパイプラインは、水平方向のスケーリングが容易でした。テキストファイルやKafkaからの少量のストリーミングデータを読み込む場合、SparkクラスターやApache Flinkクラスターは、作業を小さな単位に分割して大規模なワーカーノード群に分散させることが容易なため、水平方向に非常にうまくスケールします。一方、RAGの取り込みパイプラインでは、PDFドキュメントなどを取り込んでチャンクに分割し、それらをEmbeddingモデル（GPUで実行される小規模な生成AI基盤モデル）に送ります。これは同じように水平方向にスケールすることができず、GPUがボトルネックとなります。
Rayのようなクラスタードサービスでは、GPUがスループットのボトルネックとなることを認識し、ジョブのスケジューリングと分散を調整する機能が追加されています。最後に、データ取り込みパイプラインについて、大規模な処理を実行して何百万ものPDFドキュメントをアップロードする場合、Vector Databaseに大きな負荷がかかることになります。これらは、生成AIシステムにおいてパフォーマンス負荷を考慮すべき特徴的な領域の一部です。
Fine-tuningとPre-trainingのジョブについて見てみましょう。Pre-trainingは、大規模なGPUクラスターで数週間かけて、Generative AIモデルを一から構築するプロセスです。この過程でGPUの障害は珍しくありません。あるお客様の研究論文によると、通常1日に数回のGPU障害が発生していたとのことです。比較的短時間で済むFine-tuningジョブでさえ、コストがかかり時間もそれなりにかかるため、パフォーマンスの観点から、これらのジョブが状態をチェックポイントとして保存し、自動的に再開できるようにすることが重要です。
従来のキャパシティ戦略は、将来のニーズを予測して適切にプロビジョニングするキャパシティプランニングと、需要に応じてサーバー数を自動的に調整するAuto Scalingで構成されていました。これらは良い出発点ですが、 さらに改善することができます。従来の戦略をAIOpsで強化できるのです。AI駆動のキャパシティプランニングを使用すると、Machine Learningモデルを活用して、リソースニーズを正確に予測し、実際の需要に密接に合わせた動的なキャパシティ調整が可能になります。これにより、過剰プロビジョニングとパフォーマンス不足の両方を最小限に抑えることができます。予測的なAuto Scalingを使用すると、過去のパターンとリアルタイムのトレンドを分析して、過剰な負荷が問題になる前に予測的にスケールすることができます。従来の戦略にAIOpsを統合することで、キャパシティ管理を反応的なものから予測的なものへと進化させ、データ駆動のインサイトを活用できます。
しかし、「より多く」が必ずしも「より良い」とは限らないことも分かっています。実際、リソースを闇雲にスケールすることは、時として収穫逓減の道へと導くことがあります。3つの重要なシナリオで説明させていただきます。アルゴリズムの非効率性がある場合、最適化されていないモデルや推論パイプラインは、ハードウェアを増やしても魔法のように改善されることはありません。実際、そのようなシステムをスケールすると、非効率性が悪化し、リソースの無駄遣いやパフォーマンスの低下を招く可能性があります。システムがIO boundの場合、モデルにデータを十分な速度で供給できないのであれば、GPUリソースを追加しても意味がありません。モデルトレーニングシステムにおける調整オーバーヘッドでは、ノードを追加することで通信オーバーヘッドとデータスワップが増加し、全体的なパフォーマンスが低下し、貴重なGPUを無駄にする可能性があります。ただし、Embeddingモデルのような一部のワークロードは、並列実行が可能なため、ノードを追加することで実際にパフォーマンスが向上します。ここでの教訓は、ワークロードの性質が非常に重要だということです - スケーリングは単に「増やす」ことではなく、「賢く」スケールすることが重要なのです。
さらにいくつかのスマートなスケーリング戦略をご紹介しましょう。Pruningなどのテクニックを使用してパフォーマンスを大きく損なうことなくリソース需要を削減できるModel Optimizationがあります。 ビジネス価値、ユーザーSLA、計算の複雑さに基づいてリクエストの優先順位付けを行うインテリジェントなキューイングシステムを実装することで、 単純なラウンドロビン分散を超えることができます。AIタスクの性質、モデルの専門性、受信リクエストの複雑さを考慮して、スマートなルーティングの判断を行うことができます。レイテンシーの低い大量のリクエストにはEdge Computingを使用し、より複雑なタスクには AWS Availability ZonesやRegionsにまたがる分散処理を組み合わせることができます。 現在の負荷やリクエストの特性に基づいて、異なるサイズのモデルやアーキテクチャを動的に選択することができます。
ピーク負荷に対応するために、一時的に生成出力の品質や複雑さを下げるGraceful Degradationを使用できます。システムの健全性やビジネスの重要度に基づいて、 どのリクエストを遅延させるか、あるいは破棄するかをAIを使用して判断するIntelligent Load Sheddingを実装できます。 リアルタイムのシステム動作に基づいて、Circuit Breakerのトリガー閾値を自動的に調整することができます。目標は単に多くの負荷を処理することではなく、インテリジェントに処理することを忘れないでください。
これらの戦略を実装することで、私たちはシステムをスケールさせるだけでなく、実際に進化させているのです。
Generative AIにおいて、タイムリーな出力は速度と品質のデリケートなバランスであり、これはモデルの応答時間が大きく変動することでさらに複雑になります。従来のシステムとは異なり、モデルが応答を生成するのに必要な時間は、様々な要因によって大きく変動する可能性があります。私たちの最終的な目標は、速度と品質の両方のバランスを取ったシステムを作ることです。つまり、単に速いだけでなく、与えられた状況に応じて必要な品質基準も満たす応答を提供することを目指しています。
Model latencyは、おそらく顧客から最も多く耳にする不満の一つです。プロトタイプ段階では特定のP50やP99のレイテンシーを経験していたのに、本番環境に移行すると大きく変動することに気づくというケースです。まず、レイテンシーの測定方法について基本的な理解を確立することが重要です。一般的な指標が2つあります：最初のトークンが出力されるまでの時間と、完全な応答を得るまでの時間です。リアルタイムのエンドユーザーシステムでは、最初のトークンまでの時間の方が重要になることが多いです。なぜなら、ユーザーに「何かが始まっている」という認識を与えるからです。
Model latencyに影響を与える要因は複数あります。マルチテナントシステムでは、大量のリクエストが入ってくることで処理が遅くなる可能性があります。使用するモデルによって、明らかにレイテンシーの挙動が異なってきます。例えば、Anthropic Claudeファミリーを見ると、小さい順にHaiku、Sonnet、Opusがあります。他の条件が同じであれば、Haikuは小さいモデルなので他の2つよりもずっと速くなります。特定のモデルでも、どれだけの入力を与え、どれだけの出力を求めるかが重要です。Claude Haikuに1段落の入力を与えて箇条書きの要約を求める場合と、20ページのPDFドキュメントを与えて全体の要約を求める場合では、前者の方がはるかに速くなります。
モデル以外にも要因があります。RAGワークフローやAgentを使用する場合、Vector databaseにアクセスして情報を取得する必要があり、これがレイテンシーを追加します。Andreessen Horowitzのスペース図には含まれていませんでしたが、来年注目すべき興味深い要素が2つあります。1つはAI gatewayと呼ばれるもので、現時点では緩やかに定義されていますが、顧客の関心が高まっています。このシステムは、呼び出し元のユーザーアプリケーションとGenerative AIシステムの残りの部分の間に位置します。異なるモデルへのルーティングが可能で、Jenniferが言及したように、あるモデルが過負荷になった場合、別のモデルにトラフィックを振り分けることができます。また、シンプルなリクエストの場合、パフォーマンスとコストを考慮してSonnetではなくHaikuに送信することもできます。API gatewayをベースにしたDIY実装もありますし、LiteLLMのような優れたサードパーティやオープンソースのオプションも検討する価値があります。
Jennifer が言及したように、エッジインフラストラクチャの利用が increasingly 魅力的になってきています。Small Language Model は日常的なタスクにおいてかなり優れた性能を発揮するようになっており、モバイルデバイスやエンドユーザーにより近い場所でこれらを活用することで、レイテンシーを削減できる可能性があります。 Agent は多くの人々が実験的に取り組んでいる分野で、来年にはより多くの本番ユースケースが登場すると予想されています。ここでいう Agent とは、基本的に複数のコンポーネントで構成されるシステムを指します：複雑なタスクを実際の手順に分解できる計画・推論コンポーネント、それらの手順を実行するために他のシステムと連携する必要がある場合に呼び出せるツール、そして実行済みの手順と次の手順を管理するコーディネーターです。
私は LangChain という人気のオープンソースフレームワークを使って小さなアプリケーションを作成しました。このアプリケーションは、AWS アカウントで実行中のものについての簡単な質問に答えられるようにすることが目的でした。モデル単独ではそれができないため、API コールを発行できる Lambda 関数というツールへのアクセス権を与えました。
与えたツールは、実行中の EC2 インスタンスをリストアップできる Lambda 関数だけでした。そこに示されているのが LangChain のコードスニペットで、単に実行中の EC2 インスタンスをリストアップするように指示しました。興味深いのは - この例は少し古いので、その後改善されているかもしれませんが - 最初のステップはうまくいったものの、モデルが勝手にインスタンスのリストアップだけでなく、各インスタンスの詳細情報も取得しようと判断し、存在しないツールを呼び出そうとしたことです。
これは面白い例ですが、多くのお客様から同様の経験を伺っています。オープンソースパッケージの Agent フレームワークを使い始めると、予期せぬ動作に遭遇するというものです。この単純な例のように、エラーが発生して問題が生じることもあります。また、ここでモデルが「考える」ために多くの潜在的なレイテンシーが発生する可能性があることにもお気づきでしょう。つまり、基本的にモデルはループの中で、アプローチの方法を考え、ツールを呼び出し、結果を確認し、次のステップを考えるという処理を繰り返しているのです。これは多くのお客様が経験する予期せぬレイテンシーの主な原因となっています。
モデルが計画と推論のステップを実行する完全な自律型 Agent が、必ずしも最適な出発点とは限らないということを認識することが重要です。モデルにツールへのアクセス権を与えつつ、その使用方法を指示する方がはるかにシンプルなアプローチかもしれません。例えば、モデルに無制限の次のステップを考えさせるのではなく、「これがあなたが呼び出せるツールで、その機能はこれです。このような質問が来たら、このツールを呼び出してください」というようなプログラムを書くこともできたはずです。Amazon Bedrock では、完全な自律型の Bedrock Agents フレームワークの代替として、Converse API がツール呼び出しをサポートしています。 同僚の一人が適切に表現していたように、理想的な動作のフローチャートを考えて描くことができるのであれば、おそらく完全な自律型 Agent は必要ありません。なぜなら、Agent は余分なレイテンシーや興味深いエラーパターンをもたらす可能性があるからです。
スピードと品質のバランスを取るための戦略をいくつか見ていきましょう。Streamingを使った非同期処理では、バックグラウンドで改善と洗練を続けながら、出力の生成とストリーミングを即座に開始することができます。これによってユーザーは即時のフィードバックを得られ、応答性の体感も向上します。また、処理時間のかかる複雑なクエリにも柔軟に対応できます。このハイブリッドアプローチを使えば、明確なルールが定義された単純なシナリオには迅速で予測可能な応答を提供し、より複雑なクエリやルールベースのシステムでは十分な回答が得られない場合にAIへ処理を引き継ぐことができます。
意味的に類似した質問に対するレスポンスをキャッシュできるSemantic Cachingを使用すると、類似または関連するクエリの応答時間を大幅に短縮し、モデルの計算負荷を軽減できます。Amazon MemoryDB for Redisを使用した永続的なSemantic Cachingの実装フローを見ていきましょう。ユーザーからリクエストを受け取ると、それはEmbeddingに変換され、キャッシュ内で類似のEmbeddingを検索します。一致するものが見つかった場合（キャッシュヒット）、キャッシュされた出力がすぐに返されます。一致するものがない場合（キャッシュミス）、Knowledge BaseとFoundation Modelを使用して出力を生成し、将来の使用のためにキャッシュに保存します。
ご覧の通り、基本的なパターンはキャッシュメカニズムを活用する一般的なワークロードと同じです。Generative AIワークロードにおける違いは、全体的なアーキテクチャではなく、使用される具体的なコンポーネントにあります。Generative AIワークロードにおける最重要課題の1つは、正しい出力を確保することです。従来のソフトウェアシステムと同様に、設定ミスやバグが出力の正確性を脅かす可能性がありますが、Generative AI環境では少し異なる点があります。正しい出力とは、単にクラッシュやエラーメッセージを避けることだけでなく、モデルが一貫して信頼性が高く、正確で、適切な結果を生成することを意味します。さらに、AIの急速な革新と、絶えず変化する環境やツールが、これらの能力をより複雑にする可能性があります。
正確な出力の確保とレジリエンスのための冗長性
ありがとう、Jennifer。では Randy、これらの問題の潜在的な原因について教えてください。
通常のバグの原因以外にも、注目すべき点がいくつかあります。Amazonの多くのPrincipal Engineerが繰り返し指摘しているように、設定ミス、ソフトウェアのバグ、人的エラーの方がインフラの問題を引き起こす可能性が高いので、これらには特に注意を払う必要があります。特に指摘したいのは、AgentとToolの間のインターフェースが明確に定義されていないことが多い点です。Agentとそれが呼び出すToolの間の契約を定義するためのオープンソースや商用のフレームワークが多数競合しており、まだ成熟段階にあると思います。そのため、正確性とセキュリティの両面でテストに特に注意を払う必要があります。
2つ目のポイントは、エージェントが本来期待される範囲を超えて動作してしまうことです。多くの企業は、エージェントに対して読み取り専用のアクセス権限のみを付与し、APIやデータベースへのフルアクセスは与えないという方針で始めています。また、LangChainやStreamlitのような高速プロトタイピング用のツールキットは非常に優れたツールであることも付け加えておきたいと思います。これらを批判するつもりはありませんが、非常に急速に進化しているため、新しいバージョンにアップグレードする際には、互換性を破壊するような変更に注意を払う必要があります。
また、現在この分野はPythonが非常に優勢な環境であることにも注目しています。Go、Rust、Java、C#といった、より強力な型システムとメモリ管理特性を持つシステムに慣れている運用環境では、Pythonはそれらの面で特別な注意が必要です。モデルをセルフホスティングする場合は、GPUのパフォーマンスに十分な注意を払う必要があります。予期せぬメモリ不足エラーが発生しやすく、それによってシステムが不確定な状態に陥り、出力の品質が低下する可能性があります。最後に、組織レベルでは、多くの新しい人材が加わっていることを認識しておく必要があります。先ほどの様々なビルディングブロックの図を思い出してみると、ソフトウェア開発者、サイトエンジニア、MLエンジニア、運用担当者、Promptエンジニアなど、多くの新しい役割があり、これらのチームの連携が最初から円滑にいかない可能性があります。
データ取り込みパイプラインについては、ファイルシステムからPDFドキュメントを取得したり、APIからCRM情報を取得したりする作業があることを念頭に置く必要があります。Kafkaバスからレコードを取得するような一般的なパイプラインと比べて、エラー処理やリトライロジックをより堅牢にする必要があるかもしれません。PDFや画像のような非構造化データについては、アナリティクス分野で使用しているデータカタログ化やアクセス制御、権限管理のためのツールが、このタイプのデータを想定して作られていないことに注意が必要です。これらのツールはまだ進化の途中にあり、Data Meshにおけるデータ消費者とデータ生産者の間の契約に関する期待を満たすには、追加の作業が必要になるかもしれません。
さて、Randyは生成AIワークロードで設定ミスやバグが発生しやすい領域をいくつか挙げました。これらについて詳しく見ていき、効果的な対策について議論しましょう。エージェントとツールの間のあいまいなインターフェースについて話しましたが、これは予期せぬ動作につながる可能性があります。Protocol BuffersやOpenAPI仕様などのツールを使用して、厳密なインターフェース構造を実装することが重要です。これによりエージェントとツール間の明確な通信境界が確保されます。また、様々なエージェントとツールの相互作用をシミュレートする包括的な統合テストを開発することも重要です。これにより、インターフェースの不整合を早期に発見することができます。
LangChainやStreamlitのような急速に進化するツールは、また別の課題を提示します。ツールのアップデートに対して厳密な変更管理プロセスを確立し、新しいバージョンを既存のAIワークロードに対して検証する自動化されたテストパイプラインを実装する必要があります。柔軟性の高いPythonの多用は型関連のバグにつながる可能性があるため、静的型チェックツールを採用して型関連のエラーを開発プロセスの早い段階で発見することが重要です。型アノテーションを推奨するPythonフレームワークの使用を検討し、エッジケースや型関連のシナリオに焦点を当てた包括的なユニットテストを実装することが、GPUのメモリ不足などのセルフホストモデルの問題に対して有効です。
Amazon CloudWatchやその他のモニタリングツールを使用したプロアクティブなモニタリングを実装することは、リソース使用率のトレンドを検知し、アラートを発するために不可欠です。すでに説明したように、これらのメトリクスを使用して予測し、プロアクティブにスケーリングを行う予測的Auto-scalingソリューションを実装することが重要です。また、これらの大規模モデルのメモリ使用を最適化するためにGradient Checkpointingなどのテクニックを使用し、新しいペルソナによってもたらされる課題に確実に対応することを検討してください。 これらの新しい役割に対する明確な役割ガイドラインを実装して、責任とベストプラクティスを確実にする必要があります。また、本番システムに変更を加える他の役割と同様に、ピアレビューなどの同じメカニズムを使用して、組織やチームのダイナミクスとどのように協力し、相互作用するかを理解することが重要です。
複雑なデータ取り込みパイプラインでは特に、堅牢なエラー処理とリトライメカニズムを作成・実装する必要があります。複雑な場合は、AWS Step Functionsなどを使用してオーケストレーションすることができます。また、リトライとエラー処理機能が組み込まれているAWSマネージドサービスを活用することも重要です。 データの一元管理場所を提供し、ガバナンスルールが確実に遵守されるよう、セキュアなData Lakeを確保することが極めて重要です。同時に、Chaos Engineeringも採用する必要があります。
Chaos Engineeringでは、AIパイプラインに制御された障害を意図的に注入することで、システムが様々な障害にどのように対応するかを明らかにします。これは構造化された反復プロセスで行われ、まずシステムの定常状態（通常の動作）を理解し、次に特定の障害モードに直面した際のシステムの反応について仮説を立てます。実験を実行し、結果を元の仮説と照らし合わせて検証します。これらの知見は、システムのレジリエンスを向上させるために活用されます。このアプローチにより、潜在的な障害を防ぐための不足している保護機能を特定・実装し、問題が発生した際に素早く検知できるよう可観測性を向上させ、迅速な対応のためのアラートメカニズムを確立し、避けられない障害に対する緩和戦略を開発・改善することができます。
実験の基準として、これまで議論してきた障害カテゴリーを出発点として使用できます。Chaosの実験を実行するためのツールや製品は複数あります。AWS Fault Injection Serviceを使用することもできますし、オープンソースを探しているならNetflixが開発したChaos Monkeyを使用することもできます。しかし最終的に、Chaos Engineeringはカオスを作り出すことではなく、システムの未知の部分を明らかにすることが目的です - 脆弱性を発見するために、制御された障害を積極的に注入できる必要があります。
最後のレジリエンス特性は、Generative AIワークロードにおける冗長性とSingle Point of Failureの排除に焦点を当てています。この重要な側面は、単なるデータバックアップを超えて、AIパイプライン全体にわたる冗長コンポーネントの作成にまで及びます。この議論では、まずデータから始めましょう。 データに起こり得る問題を考えると、データの破損、誤削除、悪意のある活動などの典型的な問題があります。ナレッジベースやRAGシステムを実行する場合、ソースデータとVector Databaseに格納された中間表現の両方があります。Fine-tuningを行う場合は、Fine-tuningに使用するデータや、より高度なシナリオ、そして生成するモデルアーティファクトも重要なデータ資産となります。
Foundation Modelそのものが重要です。Amazon Bedrockのようなシステムを使用する場合、すべてのFoundation ModelがすべてのAWS Regionで利用できるわけではないことに注意が必要です。独自のモデルを使用する場合は、運用しているすべてのRegionで利用可能であることを確認する必要があります。Vector Databaseそのもの、GPU、モデルのキャパシティも重要です。バックアップとリストアのDR戦略を使用する場合、フェイルオーバーRegionで十分なGPUキャパシティを確保して、ワークロードを稼働できるようにする必要があります。Experiment TrackingとMonitoringは、保護すべき重要な履歴情報の源となることが多いのです。
それでは、データストレージ戦略について話し、モデルを支える重要なコンポーネント、つまりデータに焦点を当ててみましょう。これらの要素は、私たちの機能の基盤となるものです。Randyが説明した3つの主要な脅威、つまりデータの破損、誤削除、悪意のある行為を考慮すると、多層的なデータ保護アプローチの実装が不可欠です。
まず最初に、プライマリデータと同じRegionにバックアップを実装したいと思います。 このアプローチは、誤削除やデータ破損に対する第一の防衛線となります。特定の時点へのロールバックを可能にするAmazon S3のバージョニングや、Amazon OpenSearchの迅速なスナップショットリストアを利用できます。同一Region内のバックアップは価値がありますが、すべての種類の障害から保護できるわけではありません。
これに対処するため、次の保護層としてCross-Regionバックアップを実装します。これには、別の場所（おそらく別のAWS Region）にデータのコピーを保存することが含まれます。さらに強固な保護とほぼリアルタイムのデータ可用性を実現するために、Cross-Region Replicationを導入することもできます。この戦略には、Region間でデータを積極的にレプリケーションすることが含まれます。Replicationは、マルチRegionのディザスタリカバリ戦略を持つ組織や、標準的なバックアップリストアプロセスの機能を超えるRecovery Objectiveが必要な場合に特に重要です。
データ保護戦略の最後の層は、 別のAWSアカウントへのデータのレプリケーションです。これにより、悪意のある攻撃から保護することができます。プライマリアカウントが侵害された場合でも、セキュアな環境で論理的にエアギャップされたデータのコピーにアクセスでき、最後の既知の正常なデータの状態に戻ることができます。データバックアップについて話す際には、このような多層的な戦略を持つことが非常に重要です。
冗長化によるデータ保護は重要ですが、これは「冗長性のパラドックス」という新たな課題をもたらします。 このコンセプトは、システムの回復力を高めようとする取り組みが、逆説的に複雑さを増大させる様子を示しています。特に、データのダイナミックな性質とリソースの集中的な要件により、状況は一層複雑になります。Generative AIモデルは、カスタマーインタラクションなどのリアルタイムデータストリームから学習することが多く、この常に変化するデータの複数のコピー間で一貫性を保つことは大きな課題となっています。
この問題に対処しようとすると、実際にはシステム設計の複雑さが増していきます。リソース管理には大量の計算能力が必要です。計算リソースの冗長性を実現するには、高性能なGPUクラスターを複製する必要があります。これにより、コストが大幅に増加するだけでなく、負荷分散やフェイルオーバーメカニズムにも課題が生じます。冗長性はレジリエンスと信頼性を確保するために不可欠ですが、慎重に実装する必要があります。単一障害点を排除することと、これらのパラドックスがもたらす追加の複雑さを管理することとの間でバランスを取る必要があるのです。
ここまでで、Generative AIワークロードのレジリエンスに関する興味深い洞察をお伝えできたと思います。私はどちらかというとデータ分析やML分野の出身で、Jenniferは明らかにレジリエンスのSMEの一人です。このような協力関係は非常に有用だと考えています。Jenniferのようなレジリエンスの専門家は、ここで説明したような課題や問題のほとんどに対処する方法を理解していますが、Generative AIには、よりデータサイエンスの専門知識を必要とする新しい側面もいくつかあります。皆さんへの重要なメッセージは、Generative AIワークロードで実際に何が起きているのかを見て、アーキテクチャ図の各ボックスの中身を理解すれば、レジリエンスのSMEと協力して非常に信頼性の高いワークロードを設計できるということです。これは組織内でGenerative AIを運用するすべての人々と共有できる知識です。
ご参加いただき、ありがとうございました。JenniferもPrivateも、この後数分間は会場に残っています。LinkedInで私たちを見つけることもできます。私たちの連絡先情報は入手可能なはずです。また、AWS VillageにあるCloud Ops Kioskにお立ち寄りいただければ、VR体験をしていただけます。本やその他の景品もあると思います。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion