Are You Well-Architected?
みなさん、Well-Architectedしてますか？
本記事では、Amazon Bedrockを用いたシステムに対して、どのようにAWS Well-Architected Frameworkを適用したらよいのかを解説します。
本記事は Amazon BedrockをWell-Architectedしてみたシリーズ の 運用上の優秀性編 です。
- 運用上の優秀性 (Operational Excellence) ← 本記事
- セキュリティ (Security)
- 信頼性 (Reliability)
- パフォーマンス効率 (Performance Efficiency)
- コスト最適化 (Cost Optimization)
- 持続可能性 (Sustainability)
対象読者
- AWS Well-Architected Frameworkに興味がある方
- Amazon Bedrockに興味がある方
- Amazon Bedrockを扱う際のベストプラクティスを知りたい方
なぜこの記事を書こうと思ったのか
昨今、生成AIが活況でAWS界隈でもAmazon Bedrockが注目を集めており、各種メディアや技術ブログでも様々な活用事例が紹介されています。
しかし、実際にそれらをプロダクト化しようとすると、セキュリティや信頼性、運用など様々な課題に直面します。
それらの課題を解決するには、AWS Well-Architected Frameworkが役に立ちます。
ただし、Amazon Bedrockは比較的新しいサービスであるため、それに対して、AWS Well-Architected Frameworkをどのように適用するのかについては、まだあまり語られていないと思います。
であれば、自分でやってみようじゃないか！ということで、この記事の執筆に至った次第です。
あとはまぁ、Amazon Bedrockに関する活用事例なんかはすでに山ほど出ているので、いまさら似たような話を書いても新鮮味はないので、別の切り口にしたほうがブログ的にも面白いかな、と。笑
シリーズ化
本記事を書くにあたり、以下の理由からAWS Well-Architected Frameworkの6つの柱ごとに記事を分け、シリーズ化しました。
- 1つの記事にまとめると結構なボリュームになるので読みづらくなる
- 柱ごと分かれていたほうが優先するテーマを確認しやすい
本記事は、その内の 運用上の優秀性 編に当たります。
他の柱を参照したい方は記事冒頭のリンクからどうぞ。
基礎知識
最初に本記事を読む上での基礎知識を説明します。
すでにご存じの方は読み飛ばしても構いません。
本章の内容は、他の柱の記事も同じ内容です。
すでに他の柱の記事を読んでいただいた方は読み飛ばしてください。
AWS Well-Architected Framework
AWS Well-Architected Frameworkとは、一言で表すなら AWSのベストプラクティスをまとめたフレームワーク です。
AWS Well-Architected Frameworkの6つの柱
AWS Well-Architected Frameworkは以下の 6つの柱 で構成されています。
- 運用上の優秀性 (Operational Excellence)
- セキュリティ (Security)
- 信頼性 (Reliability)
- パフォーマンス効率 (Performance Efficiency)
- コスト最適化 (Cost Optimization)
- 持続可能性 (Sustainability)
AWS Well-Architected Tool
AWS Well-Architected Frameworkには AWS Well-Architected Tool と呼ばれるツールが含まれています。
AWS Well-Architected Toolは、AWSマネジメントコンソールから利用可能です。
AWS Well-Architected Toolを利用し、ワークロードの定期的な評価やリスクを管理することができます。
AWS Well-Architected レビュー
AWS Well-Architected Frameworkに基づいて、アーキテクチャを評価するプロセスを AWS Well-Architected レビュー と呼びます。
Amazon Bedrock
Amazon Bedrockは、Amazon TitanやClaudeなど、Amazonや様々なAI企業が提供する基盤モデル (FM: Foundation Model)を統合APIを通じて利用できるようにするフルマネージドサービスです。
Amazon Kendra
Amazon Kendraは、機械学習を用いて最適されたエンタープライズ検索エンジンです。
RAG (Retrieval-Augmented Generation)
RAG (Retrieval-Augmented Generation)とは、大規模言語モデル (LLM: Large Language Models)によるテキスト生成に、外部情報の検索を組み合わせることにより回答精度を向上させる技術のことです。
日本語では「検索拡張生成」のように訳されます。
サンプルアーキテクチャ
本記事では、AWS Well-Architected Frameworkに基づいて、Amazon Bedrockを活用したシステムにおいて、考慮すべきベストプラクティスを解説していきます。
そのためにはレビュー対象となるアーキテクチャを定義する必要があります。
そこで、今回はAWS公式が提供している以下の AWS workshop studio 生成AI体験ワークショップ のアーキテクチャをサンプルとして進めていきます。
このアーキテクチャの肝は、Amazon BedrockとAmazon Kendraを用いたRAGの提供です。
Amazon BedrockやAmazon Kendraを用いたRAGに興味のある方は、ぜひこちらのワークショップもやってみてください。
Amazon BedrockやRAGを理解する上でとても良いコンテンツだと思います。
AWS Well-Architected レビューの実施
前置きが長くなりましたが、ここからが本題です。
先ほどのサンプルアーキテクチャを題材として、AWS Well-Architected レビューを実施≒AWS Well-Architected Frameworkに基づいたベストプラクティスのポイントを確認していきます。
本来、AWS Well-Architected レビューはシステム全体のアーキテクチャを評価するものであり、特定のサービスに着目して実施するものではありません。
しかし、本記事ではAmazon Bedrockに着目して進めていきます。（それが本記事のテーマなので）
運用上の優秀性 (Operational Excellence)
運用上の優秀性の柱には、開発をサポートし、ワークロードを効率的に実行し、運用に関するインサイトを得て、ビジネス価値をもたらすためのサポートプロセスと手順を継続的に改善する能力が含まれます。
組織 (OPS 1-3)
OPS 1-3は、ビジネスを成功させるための組織論です。
Amazon Bedrockに直接影響する内容ではありませんが、特にOPS 1の「優先順位」については明確化しておくことをおすすめします。
今回のシステム・サービスを提供する上で何が優先すべきものは何なのか？
例えば、RAGにより業務効率を上げることなのか、RAGの回答精度を上げることなのか、シビアな予算を超えないことなのか、定められた期日までに必ず提供することなのか、といったことを明確化し、定義しておきましょう。
ポイント
- このシステム・サービスを構築・導入する目的を定義する
- 何を優先すべきなのかを明確にする
- それらをステークホルダーやチームメンバーと合意し、共通認識を持つ
OPS 1. 優先順位はどのように決定すればよいでしょうか?
だれもが、ビジネスを成功させるうえで自分が果たす役割を理解する必要があります。リソースの優先順位を設定するため、共通の目標を設定してください。これにより、取り組みから得られるメリットが最大化されます。
OPS 2. ビジネスの成果をサポートするために、組織をどのように構築しますか?
チームはビジネスの成果を達成するうえでの役割を理解する必要があります。チームは他のチームが成功するためのそれぞれの役割を理解し、自分たちのチームが成功するための他のチームの役割を理解し、目標を共有する必要があります。責任、所有権、意思決定方法、意思決定を行う権限を持つユーザーを理解することは、労力を集中的に投入し、チームの利点を最大化するのに役立ちます。
OPS 3. 組織の文化はビジネスの成果をどのようにサポートしますか?
チームメンバーにサポートを提供することで、チームメンバーがより効果的に行動し、ビジネスの成果をサポートできるようにします。
準備 (OPS 4-7)
OPS 4-7は「準備」がテーマです。
具体的には、システムを構築・稼働する前に、システムの監視（モニタリング）方法や、リリースフロー、デプロイ方式、変更管理方法等を定め、運用準備に関するベストプラクティスが定義されています。
リリースフロー、デプロイ方式はシステム全体の話となるため、詳細は割愛し、ここではAmazon Bedrockに関するオブザーバビリティ（可観測性）に着目してみます。
Amazon Bedrockのモニタリングについては以下に詳しく記載されています。
S3やCloudWatch Logsへのログ送信や、CloudWatchによるメトリクス監視など、他のAWSサービスと大きな違いはありませんが、Amazon Bedrockに関して、どのようなイベントやメトリクスが存在し、その中で監視すべきイベントやメトリクスを定義しておきましょう。
また、OPS 4では、システムやサービスに関するメトリクスだけでなく、ビジネス的なメトリクスや、エンドユーザー視点のメトリクスも定義することが重要です。
エンドユーザー視点のメトリクスは、例えば、問い合わせしてから回答が得られるまでの時間や、回答精度（問い合わせにより問題を解決できたか）が該当します。
ポイント
- Amazon Bedrockに関するイベントやメトリクスを理解・把握する
- オブザーバビリティはシステム的なメトリクスだけでなく、ビジネス面やエンドユーザー視点のメトリクスも考慮する
OPS 4. オブザーバビリティをワークロードに実装するにはどうすればよいでしょうか?
ワークロードにオブザーバビリティを実装することで、ワークロードの状態を把握し、ビジネス要件に基づいてデータ主導の意思決定を行うことができます。
OPS 5. どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか?
リファクタリング、品質についてのすばやいフィードバック、バグ修正を可能にし、本番環境への変更のフローを改善するアプローチを採用します。これらにより、本番環境に採用される有益な変更を加速させ、デプロイされた問題を制限できます。またデプロイアクティビティを通じて挿入された問題をすばやく特定し、修復できます。
OPS 6. どのようにデプロイのリスクを軽減しますか?
品質に関する迅速なフィードバックを提供し、望ましい結果をもたらさない変更から迅速に復旧できるようにするアプローチを採用します。このような手法を使用すると、変更のデプロイによって生じる問題の影響を軽減できます。
OPS 7. ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか?
ワークロード、プロセス、手順、従業員の運用準備状況を評価し、ワークロードに関連する運用上のリスクを理解するようにします。
運用 (OPS 8-10)
OPS 8-10は実際に運用を開始した後のベストプラクティスです。
前項（OPS 4-7）でオブザーバビリティの準備をしましたが、ここでは実際にそれらをどのように活用するのかを検討し、定義します。
例えば、Amazon Bedrockには InputTokenCount（テキスト入力のトークンの数）や OutputTokenCount（テキスト出力のトークンの数）などのメトリクスが存在しますが、これらのメトリクスはどのように活用できるでしょうか。
一例ですが、Claudeモデルの場合、入力トークン数と出力トークン数が料金に影響します。（オンデマンド料金プランの場合）
つまり、これらのメトリクスを監視することで、Amazon Bedrockの料金の予測やコスト最適化に役立てることができます。
ポイント
- メトリクスやログ・イベントを監視することでコスト最適化やパフォーマンス改善に役立てることができる
OPS 8. 組織でワークロードのオブザーバビリティを活用するにはどうすればよいでしょうか?
オブザーバビリティを活用して、ワークロードの最適な状態を確保します。関連するメトリクス、ログ、トレースを活用して、ワークロードのパフォーマンスを包括的に把握し、問題に効率的に対処します。
OPS 9. オペレーションの正常性をどのように把握しますか?
適切な措置をとれるように、運用メトリクスを定義、取得、分析して運用チームのアクティビティの可視性を高めます。
OPS 10. ワークロードと運用イベントはどのように管理しますか?
イベントに対応するための手順を準備、検証してワークロードの中断を最小限にします。
進化 (OPS 11)
OPS 11は、OPS 1-10の内容を継続的に実施することによってシステムや運用を改善し、アーキテクチャを進化させましょう、という内容です。
運用プロセスやアーキテクチャ全体に関する内容であり、Amazon Bedrockに特化した内容ではないため、詳細は割愛します。
OPS 11. オペレーションを進化させる方法
漸進的な継続的改善に時間とリソースを費やすことで、オペレーションを効果的かつ効率的に進化させることができます。
あとがき
最後まで読んでいただき、ありがとうございました。
本記事が、これからAmazon Bedrockを活用していこうと考えている方やAWS Well-Architected Frameworkの導入を検討している方の一助になれば幸いです。
いいねやストックをいただけると励みになりますm(_ _)m