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に着目して進めていきます。（それが本記事のテーマなので）
コスト最適化 (Cost Optimization)
クラウド財務管理を実践する (COST 1)
PERF 5では、クラウド財務管理に関するベストプラクティスが定義されています。
文字通り、クラウド財務管理に関する内容であり、Amazon Bedrockを含めた個々のAWSサービスに関する内容ではありませんが、クラウド財務管理を行う上で個々のAWSサービスの料金プランを把握しておくことは重要です。
Amazon Bedrockの料金プランは以下に詳しく記載されています。
ポイントとしては、以下の3つのモードがあることと、基盤モデルによって料金が異なることを理解しておくことが重要です。
- オンデマンドモード
- バッチモード
- プロビジョンドスループットモード
COST 1. クラウド財務管理はどのように実装しますか?
組織はクラウド財務管理の実装により、AWS によってコストと使用状況の最適化とスケーリングをすることで、ビジネス価値と財務上の成功を実現できます。
経費支出と使用量の認識 (COST 2-4)
COST 2-4では、経費支出と使用量の認識に関するベストプラクティスが定義されています。
システム全体としてのコストの把握と最適化に関する内容であり、Amazon Bedrockを含めた個々のAWSサービスに関する内容ではないため、割愛します。
COST 2. 使用状況をどのように管理しますか?
発生コストを適正な範囲内に抑えつつ、目的を確実に達成するためのポリシーとメカニズムを設定します。チェックアンドバランスのアプローチを採用することで、無駄なコストを費やすことなくイノベーションが可能です。
COST 3. コストと使用量はどのように監視すればよいでしょうか?
コストをモニタリングし、適切に配分するためのポリシー手順を定めます。これにより、ワークロードのコスト効率を測定し、向上させることができます。
COST 4. 不要なリソースをどのように削除しますか？
プロジェクトの開始から終了まで変更管理とリソース管理を実装します。これにより、使用されていないリソースをシャットダウンまたは終了して、無駄を減らします。
費用対効果の高いリソース (COST 5-8)
COST 5-8では、費用対効果の高いリソースに関するベストプラクティスが定義されています。
主にEC2やRDSなどのリソースタイプやリソースサイズの最適化に関する内容ですが、Amazon BedrockについてはCOST 7の料金モデルを意識する必要があります。
COST 1で述べた内容と重複しますが、Amazon Bedrockには以下の3つのモードがあり、モードによって料金も変わります。
- オンデマンドモード
- バッチモード
- プロビジョンドスループットモード
また、使用する基盤モデルやリクエスト量（オンデマンドモードの場合）によっても料金が変動します。
料金プランを把握し、料金に影響を与える指標をモニタリングし、適切な料金プランを選ぶことにより、コストを最適化することができます。
COST 5. サービスを選択するとき、どのようにコストを評価しますか?
Amazon EC2、Amazon EBS、Amazon S3 は、基盤となる AWS のサービスです。Amazon RDS や Amazon DynamoDB などのマネージドサービスは、高レベルまたはアプリケーションレベルの AWS のサービスです。基盤となるサービスやマネージドサービスを適切に選択することで、このワークロードのコストを最適化できます。例えば、マネージドサービスを使用することで、管理や運用によって発生するオーバーヘッドを削減またはゼロにでき、アプリケーション開発やビジネス上の他の活動に注力できるようになります。
COST 6. コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか?
対象タスクについて適切なリソースサイズおよびリソース数を選択していることを確認します。最もコスト効率の高いタイプ、サイズ、数を選択することで、無駄を最小限に抑えます。
COST 7. コストを削減するには、料金モデルをどのように使用したらよいでしょうか?
リソースのコストを最小限に抑えるのに最も適した料金モデルを使用します。
COST 8. データ転送料金についてどのように計画していますか？
データ転送料金を計画し、モニタリングすることで、これらのコストを最小化するためのアーキテクチャ上の決定を下すことができます。小規模でも効果的なアーキテクチャ変更により、長期的な運用コストを大幅に削減できる場合があります。
需要を管理しリソースを供給する (COST 9)
COST 9では、需要に対する適切なリソースの供給に関するベストプラクティスが定義されています。
Amazon Bedrockの料金プランについては、前項（COST 5-8）で述べたので割愛します。
COST 9. どのように需要を管理し、リソースを供給しますか?
費用とパフォーマンスのバランスが取れたワークロードを作成するには、費用を掛けたすべてのものが活用されるようにし、使用率が著しく低いインスタンスが生じるのを回避します。利用が過剰でも過少でも偏りが生じると、運用コスト (利用過剰によるパフォーマンスの低下) または無駄な AWS 費用 (過剰なプロビジョニング) のいずれかで、組織に悪影響が及びます。
継続的最適化 (COST 10-11)
COST 10-11では、継続的なコスト最適化に関するベストプラクティスが定義されています。
COST 10では、新しいサービスや機能について言及されています。
Amazon Bedrockに限った話ではありませんが、AWSでは日々新たなサービスや機能がリリースされており、今後、Amazon Bedrockの代替となるサービスがリリースされたり、Amazon Bedrockに新たな機能が実装される可能性があります。
例えば、Amazon Bedrockに新たな料金プランが用意されたり、より安価な基盤モデルが提供される可能性もあります。
その際、それらを適切に評価し、取り込むことによって現状よりもコストを抑えることができる可能性があります。
継続的なコスト最適化を実現するには、そのためのプロセス（新しいサービスや機能の情報をどのように収集し、それらをどう評価するのか）を定めておくことが重要です。
COST 10. 新しいサービスをどのように評価していますか？
AWS では新しいサービスと機能がリリースされるため、既存のアーキテクチャの決定をレビューし、現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです。
COST 11. 労力コストを評価する方法は？
AWS が新しいサービスや機能をリリースした場合には、新しいサービスの実装に必要な労力のコストを見直すのがベストプラクティスです。
あとがき
最後まで読んでいただき、ありがとうございました。
本記事が、これからAmazon Bedrockを活用していこうと考えている方やAWS Well-Architected Frameworkの導入を検討している方の一助になれば幸いです。
いいねやストックをいただけると励みになりますm(_ _)m