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に着目して進めていきます。（それが本記事のテーマなので）
持続可能性 (Sustainability)
リージョンの選択 (SUS 1)
SUS 1は、リージョンの選択に関するベストプラクティスです。
信頼性編でも述べたとおり、Amazon Bedrockは比較的新しいサービスであるため、本記事執筆時点（2024年3月）では提供されるリージョンが限られています。
さらに、サービス自体は提供されているリージョンでも特定の機能やモデルが制限されている場合もあります。
それらを踏まえて、使用するリージョンを選択しましょう。
SUS 1. ワークロードにリージョンを選択する方法は？
ワークロードのためのリージョンの選択は、パフォーマンス、コスト、カーボンフットプリントなどの KPI に大きく影響します。これらの KPI を効果的に改善するには、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択する必要があります。
ユーザーの行動パターン (SUS 2)
SUS 2では、ユーザーの行動パターンを把握し、それに合わせてリソースを最適化するためのベストプラクティスが定義されています。
ユーザーの行動パターンを把握する方法は運用上の優秀性編を、リソースの最適化についてはコスト最適化編を参照してください。
SUS 2. クラウドリソースを需要に合わせる方法は？
ユーザーとアプリケーションがワークロードやその他のリソースを使用する方法によって、持続可能性の目標を達成するための改善点を特定できます。継続的に需要に合うようにインフラストラクチャをスケールし、ユーザーをサポートするために必要な最小リソースのみを使用していることを検証します。サービスレベルをお客様のニーズと整合させます。ユーザーとアプリケーションがリソースを消費するために必要なネットワークを制限できるようにリソースを配置します。未使用のアセットを削除します。チームメンバーには、ニーズをサポートし持続可能性への影響を最小限にするデバイスを提供します。
ソフトウェアとアーキテクチャのパターン (SUS 3)
SUS 3は、ソフトウェアとアーキテクチャのパターンに関するベストプラクティスです。
システム全体のアーキテクチャと持続可能性目標に関する内容であり、Amazon Bedrockを含めた個々のAWSサービスに関する内容ではないため、割愛します。
SUS 3. ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?
負荷平滑化を実行しデプロイされたリソースが一貫して高使用率で維持されるパターンを実装し、リソースの消費を最小化します。時間の経過とともにユーザーの行動が変化したため、コンポーネントが使用されずアイドル状態になることがあります。パターンとアーキテクチャを改定して、使用率の低いコンポーネントを統合し、全体の使用率を上げます。不要になったコンポーネントは使用停止にします。ワークロードコンポーネントのパフォーマンスを理解し、リソースの消費が最も大きいコンポーネントを最適化します。顧客がお客さまのサービスにアクセスするために使用するデバイスを把握し、デバイスをアップグレードする必要性を最小化するパターンを実装します。
データパターン (SUS 4)
SUS 2では、データパターンと持続可能性目標に関するベストプラクティスが定義されています。
データ管理については、セキュリティ編で詳しく解説していますので、そちらを参照してください。
また、不要なデータの削除については、コスト最適化編を参照してください。
SUS 4. データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか?
データ管理プラクティスを実装して、ワークロードのサポートに必要なプロビジョンされたストレージと、それを使用するために必要なリソースを削減します。データを理解し、データのビジネス価値とデータの使用方法を最もよくサポートするストレージテクノロジーと設定を使用します。必要性が小さくなった場合はより効率的で性能を落としたストレージにデータをライフサイクルし、データが不要になった場合は削除します。
ハードウェアパターン (SUS 5)
SUS 5は、ハードウェアパターンと持続可能性目標に関するベストプラクティスです。
主にEC2やRDSのインスタンスタイプやインスタンスサイズの話が中心となるため、割愛します。
SUS 5. アーキテクチャでクラウドのハードウェアとサービスをどのように選択して、持続可能性目標を達成しますか?
ハードウェア管理のプラクティスを変更することで、ワークロードの持続可能性に対する影響を軽減する機会を探します。プロビジョンおよびデプロイする必要があるハードウェア数を最小化し、個別のワークロードにおいて最も効率のいいハードウェアとサービスを選択します。
開発とデプロイのパターン (SUS 6)
SUS 6は、開発とデプロイなどの組織プロセスと持続可能性目標に関するベストプラクティスです。
文字通り、組織のプロセスに関する内容であり、Amazon Bedrockを含めた個々のAWSサービスに関する内容ではないため、割愛します。
SUS 6. 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか?
開発、テスト、デプロイのプラクティスを変更することで、持続可能性に対する影響を減らす機会を探します。
あとがき
最後まで読んでいただき、ありがとうございました。
本記事が、これからAmazon Bedrockを活用していこうと考えている方やAWS Well-Architected Frameworkの導入を検討している方の一助になれば幸いです。
いいねやストックをいただけると励みになりますm(_ _)m