Amazon Web Services ブログ
サステナビリティプロキシメトリクスによるクラウド効率の測定と追跡、パート II : メトリクスパイプラインの構築
このブログは 2023 年 8 月 30 日に Katja Philipp、Jonas Bürkel、Steffen Grunwald によって執筆された内容を日本語化したものです。原文はこちらを参照して下さい。
このブログ記事シリーズでは、持続可能性を目的として AWS の使用を最適化したいと考えているチーム向けに、持続可能性プロキシメトリクスのショーバックメカニズムを確立する方法の概要を説明します。パート I では、持続可能性に関するプロキシメトリクスと重要業績評価指標 (KPI) の動機について説明しました。使用量ベースのメトリクス、正規化、ビジネスメトリクスの組み込みの概念を説明し、お客様がこれらのメトリクスを使用して持続可能性を最適化する方法の例を共有しました。
パート II では、持続可能性と効率化のベストプラクティスを組織的に大規模に採用するために AWS の利用を最適化したいチーム向けに、プロキシメトリクスデータパイプラインを設定してサステナビリティプロキシメトリクスのショーバックメカニズムを確立する方法について説明します。
プロキシメトリクスパイプラインの設定
以下の図 1 は、プロキシメトリクスデータパイプラインの概念的な概要を示しています。1 つの管理アカウントと複数の子アカウントで構成され、さまざまなワークロードが実行されているマルチアカウント構造を想定しています。1 つの中央最適化アカウントがすべてのワークロードアカウントからのコストとリソースの使用状況データの取り込み、処理、視覚化を担います。
AWS では、このようなマルチアカウントガバナンス戦略は通常 AWS Control Tower を使用して実装され、AWS ランディングゾーンと呼ばれます。この構成では、AWS Organizations を使用してアカウントを組織単位 (OU) の下に階層的に構造化します。図示されている最適化アカウントは通常、組織のインフラストラクチャ OU の一部であり、ワークロードアカウントはワークロード OU の一部です。リソースのタグ付け戦略を導入することを強くお勧めします。これは、キーと値のペアの形式でメタデータを割り当てることにより、リソースを一貫して分類およびグループ化するためのベストプラクティスです。これにより、後で特定のメトリクスに含めるリソースの範囲をきめ細かく定義できます。
図 1 : サステナビリティプロキシメトリクスデータパイプライン
これを踏まえて、最初のプロキシメトリクスパイプラインを確立するには以下が含まれます。
- 設定したユーザー定義のコスト配分タグを含めて組織の管理アカウントに保存する AWS コストと使用状況レポート (CUR) を作成し、中央最適化アカウントに複製します。CUR は、すべての AWS サービスの詳細な消費情報を得るための主要なデータソースです。
- アカウントとワークロード固有のメトリクスをそれぞれのワークロード OU から中央最適化アカウントに定期的にプッシュします。目的は CUR ではカバーされないメトリクスの計算に必要な追加のデータポイントを取り込むことです。
- Amazon CloudWatch では、複数のソースアカウントとリージョンからログとメトリクスをキャプチャします。複数のアカウントのログとメトリクスを処理するさまざまな方法については、AWS の規範ガイダンス「集中型または分散型アカウントでの CloudWatch の使用」をご覧ください。
- AWS Compute Optimizer は、使用率に関する情報や適切なサイジングに関する推奨事項を提供する優れた情報源です。Compute Optimizer はリージョン別のサービスであるため、複数の地域から中央最適化アカウントにデータを収集する必要があります。詳細な手順については、Compute Optimizer Data Collection lab をご覧ください。
- ワークロードによっては、追加のメトリクスが必要になります。対応する AWS Well-Architected lab の Data Collection Modules をチェックして、他のメトリクスソースを統合する方法を確認してください。
- プッシュまたはプルメカニズムを使用してビジネスメトリクスを取り込み、最適化アカウントの中心的な S3「メトリクスレイク」バケットを形成します。目的のメトリクスに応じてソースデータはデータウェアハウス、データベース、またはモニタリング / オブザーバビリティシステムに配置されます。ビジネスメトリクスを AWS リソースの使用状況と簡単に集計するには、そのデータを時系列形式で利用できる必要があります。
- 次に、メトリクスレイクバケット内のすべてのデータ（CUR、AWSメトリクス、ビジネスメトリクス）がカタログ化され、定期的に抽出、クリーンアップ、変換されて視覚化できるようになります。処理されるデータセットは時間ベースで、通常、(1) 適用可能な時間枠、(2) 識別基準となるワークロードメタデータタグまたは AWS アカウント、(3) 正規化に使用されるビジネス指標 (分母) の 3 つの要素で構成されます。
- サステナビリティのプロキシメトリクスと KPI はグローバルダッシュボードに表示され、通常は 1 時間ごとのデータ粒度で毎日更新されます。
図 1 は、上記の点がプロキシメトリクスパイプラインの特定のステップとどのように関連しているかを示しています。始めるための簡単なステップバイステップガイドとして、AWS Well-Architected lab の Turning Cost & Usage Reports into Efficiency Reports をご覧ください。
Visualize the data for impact
サステナビリティのプロキシメトリクスと KPI を、最適化の機会と企業目標の達成レベルを理解したいと考えている経営陣と KPI を所有するアプリケーションチームという 2 つの主要な対象者に伝えます。最適化の前提と実験を検証して次の最適化の機会を見極めるためには、わかりやすくアクセスしやすいものでなければなりません。その例を以下の図 2 に示します。詳細については、Amazon Builders’ Library に運用を可視化するためのダッシュボードの構築に関する詳細情報が掲載されています。
図 2 : サステナビリティプロキシメトリクスダッシュボード
コンピュートプロキシメトリクスについては、まず以下の可視化から始めてください。
- さまざまなアカウント ID またはワークロードタグでの全体的なコンピューティングリソース使用量を視覚化して、Amazon EC2、AWS Fargate、AWS Lambda の比率を確認します。
- 特定のワークロードタグ (タグ付け戦略が導入されていない場合はアカウント ID) の EC2 インスタンスタイプ別のコンピューティングキャパシティを視覚化します。これは最適化をどこから始めるべきかを示す一般的なグラフです。主な要因は一番上にあります。
- さらにドリルダウンしてあるアプリケーションの経時的な使用状況を、そのアプリケーションのビジネス指標で標準化して表示することを想像してみてください。
- お客様には、例えば AWS Graviton や Amazon EC2 スポットインスタンスを採用するという目標があります。導入率を時系列で視覚化します。
プロセスにおけるサステナビリティプロキシメトリクスの確立
サステナビリティプロキシメトリクスダッシュボードは、AWS のコストと使用状況レポートを使って計算されます。通常、このデータはすでにクラウドセンターオブエクセレンス (CCoE)、FinOps、またはクラウドコスト効率化チームによってコスト管理に使用され、理解されています。サステナビリティプロキシメトリクスによって確立されたコストショーバックプロセスを拡張することで、ゼロから始めるのではなく会社にとって何が有効で何が効果的でないかについて過去に学んだことを活用できます。ショーバックメカニズムの継続的な開発のためのスポンサーとプロダクトオーナーを定義しましょう。開発は 1 回限りの作業ではなく、フィードバックを集めて取り入れ、効果のある新しいメトリクスやビジュアルを実装する必要があります。メカニズムの価値を最大化するために、役に立たない邪魔になるビジュアルやデータを削除してください。
200 以上の AWS クラウドサービスにより、追跡、視覚化、最適化の可能性が数多くあります。まず、持続可能性に関する責任共有モデルで最もシェアが高い、組織内でよく利用されているサービスから始めてください。例えば EC2 インスタンスの場合、あなたがインスタンスサイズやファミリーを制御でき、利用状況を所有し、インストールされたソフトウェアの効率性を管理できるインスタンスから始めましょう。ポリシーを使用してデータセットのライフサイクルを管理したり、必要に応じてビルド環境のスケジュールを設定したり、マネージドサービスに移行したりするなど、リソース効率に継続的に影響する AWS Well-Architected 持続可能性の柱のベストプラクティスから得られる影響の大きい手間のかからない成果に焦点を当ててください。サービスの消費量が最も多いアカウントに焦点を当てた AWS Well-Architected Framework レビューのパイロット版を実施してください。
個々のアプリケーションチームがダッシュボードを利用できるようにして、チームミーティングや運用レビューなどで自由に利用できるようにします。メールレポートも同様に機能しますが、ドリルダウンのようなインタラクティブなコントロールが欠けていてすぐに時代遅れになります。個々のチームや会社全体へのデータの可視性について問い合わせてください。
最適化の成果をリーダーに見えるようにして、成功を再現しましょう。最適対策前後のサステナビリティ KPI を活用して、成功を伝えましょう。金銭的利益を重視するステークホルダーと、関連する費用対効果を共有できます。AWS Customer Carbon Footprint Tool の長期データで数字を補足してください。成功を祝い、リーダーシップが可視化されることで、持続可能な行動に対する意識と認識が高まります。最適化の詳細を共有することで、他のチームもそのアプリケーションの成功を再現するようになります。
結論と次にすべきこと
この投稿では、プロキシメトリクスのデータパイプラインを確立する方法、効果的なビジュアル、ショーバックメカニズムを確立するためのベストプラクティスを説明しました。実際にこの理論を使って、アプリケーションのサステナビリティプロキシメトリクスの測定と最適化を適用するために、CUDOS Sustainability Dashboard ワークショップで段階的な実装手順とベストプラクティスを紹介しています。
持続可能性のためにワークロードを最適化する方法に関する詳細情報をお探しの場合は、AWS Well Architected 持続可能性の柱と AWS re: Invent 2022 セッションの Delivering sustainable, high-performing architectures (SUS303) をご覧ください。
翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。