サステナビリティプロキシメトリクスによるクラウド効率の測定と追跡、パート I :プロキシメトリクスとは

このブログは 2023 年 8 月 11 日に Katja Philipp、Jonas Bürkel、Steffen Grunwald によって執筆された内容を日本語化したものです。原文はこちらを参照して下さい。

持続可能性は、顧客、従業員、規制当局、投資家、パートナーにとって重要な意思決定要素となっています。顧客は持続可能な事業と運営への道を歩み始めています。IT インフラストラクチャを構築、導入、維持している場合、環境への影響を減らすことは、全社的な持続可能性目標を達成するための重要なステップです。そのため、現代のソフトウェアやシステムアーキテクチャでは、セキュリティ、保守性、信頼性などと並んで、持続可能性は非機能要件になりました。

クラウドでワークロードを設計する場合、持続可能性は AWS とお客様の間で共有される責任です。AWS がクラウドの持続可能性を最適化することで、お客様はクラウド内の持続可能性に責任を負うことになります。お客様はサービスの利用とリソース効率を最適化します。

このブログ記事シリーズでは、持続可能性の観点から AWS の使用を最適化したいと考えているチーム向けに、持続可能性プロキシメトリクスのショーバックメカニズムを確立する方法の概要を説明します。パート I では、プロキシメトリクスの概念と正規化の重要性について紹介します。また、お客様がこの概念をどのように利用してアプリケーションの環境への影響を軽減したかの例も示します。

プロキシメトリクスでワークロードを最適化

すべての最適化は、メトリクスや KPI に基づいた目標 (コスト削減、パフォーマンスの向上、温室効果ガス排出量の削減) から始める必要があります。AWS Customer Carbon Footprint Tool (CCFT) は、お客様の AWS サービスの使用に伴う温室効果ガス排出量の重要なアウトプットメトリクスを提供します。この排出データは、月次ベースでの大まかな影響の報告と把握に使用されます。ただし、AWS が CCFT の対象スコープの拡大と対象サービス粒度の改善に取り組んでいる一方で (このブログを読んでください)、継続的な最適化サイクルを実践するにはきめ細かなメトリクスが必要です。絶対排出量だけではワークロードの効率は明らかになりません。排出量は、アプリケーションの使用状況やエネルギーの炭素強度などアプリケーションチームが責任を負わない要素を含む、複数の要因による結果です。

これらの目的のために、AWS Customer Carbon Footprint Tool によって報告された二酸化炭素排出量をサステナビリティプロキシメトリクスと呼ばれる従属メトリクスで補完しています。また、クラウドインテリジェンスダッシュボードの一部として、サステナビリティプロキシメトリクスダッシュボード (このリンクからダッシュボードにアクセスできます) も公開しました。

優れたサステナビリティプロキシメトリクスは、二酸化炭素排出量のきめ細かい代替手段となりワークロードの効率に関する洞察を提供します。メトリクスはほぼリアルタイムで追跡され、アプリケーションチームやリソースに分類されるため、最適化サイクルタイムを短縮するのに適しています。コンピューティング、ストレージ、ネットワーキングの観点から見たリソースの使用状況を反映する具体的なメトリクスです (こちらのブログをお読みください)。

図 1 : AWS 排出量の概要

図 1 に示すように、AWS サービス使用時の温室効果ガス排出量の計算は、複数のデータソースに依存します。これには、クラウドリソースの運用に必要なエネルギー (スコープ 1 と 2) と、バリューチェーンの上流と下流の物理資源のライフサイクルに関連する間接的な排出量 (スコープ 3) が含まれます。同様に、コストは AWS のサービスの使用状況によって決まる単純な関数です。ただし、コストは使用量を反映しているとしても、ボリュームベースの割引はコストを削減しますが関連する排出量は削減しません。また、特定のサービスの料金体系にはリソース使用量のあらゆる側面が反映されているわけではありません。全てのサービスのリージョンへのインバウンドのデータ転送に料金がかからないことやデータ転送先のお客様の距離の違いによって転送料金が変わらないことを考えてみてください。AWS サービスの利用状況は、図中の左側のデータフローのようにお客様の業務プロセスに依存し、ビジネスニーズを満たすために利用されます。これらはすべて、効率化と最小限のリソースでビジネスニーズを満たすことに帰着します。

比較できるようにメトリクスを正規化

お客様がリソース消費量を定量化するために、Amazon EC2 インスタンスの数を数えたり、インスタンスの稼働時間をカウントすることがあります。これらのメトリクスはアプリケーションの比較、消費量の主な要因の特定、トレンドの特定には役立ちません。一部のアプリケーションでは終了前の数分間のみインスタンスを実行します。また、1 か月間 1 つのインスタンスを実行するアプリケーションもあります。同様に、インスタンスのサイズも重要です。インスタンスの稼働時間だけを利用するのではなく、インスタンスの vCPU の数を考慮に入れる必要があります。これを正規化と呼びます。

正規化する方法はたくさんあります。

• リソース使用量の正規化 : インスタンスタイプに関する情報を使用し、インスタンス稼働時間に vCPU の数を掛けます。あるいは、Amazon EC2 リザーブドインスタンスで使用されているような正規化要素を考慮に入れることもできます。Amazon S3 や Amazon EBS など、GB 時間を使用する他のサービスにも同じことが当てはまります。
• KPI については、総使用量に対する希望使用量の比率を計算します。CPU 使用率についてはすでにそのようになっています。Amazon EC2 のスポット導入が目標の場合、すべてのスポット時間をすべての vCPU 時間で割った値になります。また、AWS Graviton を採用する場合は、すべての Graviton の vCPU 時間を合計 vCPU 時間で割った値になります。この種の KPI について、アプリケーションチームの最小目標パーセンテージを定義します。
• スコアリングシステムを使用してサービスと機能に異なる重み付けを行い、アプリケーションチームがリソース効率の高いサービスを利用するように促します。例えば、Amazon S3 Standard ストレージクラスを Amazon S3 Intelligent-Tiering よりも高く重み付けします。これは、AWSにとって Amazon S3 Intelligent-Tiering の方がサービスを提供するためのエネルギーとハードウェアの使用量が少なくなるように最適化できる柔軟性があるからです。アプリケーションチームの目標は重み付けされた使用量を減らすことです。
• リソース効率とはビジネスニーズを満たすために使用するリソースを最小限に抑えることです。KPI またはメトリクスでは、リソース使用量をビジネスユニットのメトリクスで標準化することでこれを考慮に入れる必要があります。これについては次のセクションで詳しく説明します。

ビジネスメトリクスによる正規化

ビジネスが成長してもリソース使用量の増加は憂慮すべきものではありませんが、顧客の需要が減少してもリソース消費が継続していることは警戒すべきことです。KPI にビジネスメトリクスを考慮に入れると、長期にわたる効率性を追跡し、明らかにすることに役立ちます。ビジネスメトリクスはワークロードの目的に特化したものです。例としては、月間アクティブユーザー数、管理されている保険契約数、API の呼び出しの成功数などがあります。リソース使用量をビジネスメトリクス (このユーザーガイド「具体的な改善点を評価する」を参照) で割って、以下の式に示すように、トランザクションあたりの vCPU 時間などのサステナビリティ KPI を計算します。理想的には、サステナビリティ KPI が下がるか、少なくとも横ばいであることを望みます。コストに関するユニットメトリクスという関連する概念は、「アプリケーションのユニットメトリクスを選択、作成、追跡する」というブログ記事にあります。

図 2 : サステナビリティプロキシメトリクス方程式

AWS re: Invent 2022 (CMP204) で、コスト、エネルギー、リソース効率に優れたコンピューティング環境を構築する半導体業界のグローバルリーダーである Arm 社が、電子設計自動化 (EDA) ジョブの測定、追跡、影響を軽減した方法を紹介します (録画ををご覧ください)。彼らは Amazon EC2 インスタンスの vCPU 時間を使用して、Amazon EC2 スポット採用、AWS Graviton 採用のためのKPI、およびジョブごとに必要なリソースを計算しました。

同様に、Amazon Prime Video は、「AWS re: Invent 2022 Architecting sustainably and reducing your AWS carbon footprint (SUS205)」で、以下のサステナビリティプロキシメトリクスをどのように使用して最適化の効果を定量化および追跡したかを説明しています (録画をご覧ください)。

•  再生エクスペリエンス : 1,000 同時ストリームあたりのインフラストラクチャコスト ($)
• コンテンツ配信 : ストリームあたりの配信帯域幅 (Gbps)
• コンテンツディスカバリーエクスペリエンス : 1000 ページのインプレッションあたりの正規化インスタンス時間 (NIH)
• 顧客獲得 : サブスクリプションあたりのインフラストラクチャコスト ($)

Prime Video は、目標に向けて最適化を図り、持続可能性の目標とその他の非機能要件とのトレードオフを実施しました。「Thursday Night Football」の視聴者からの急増する需要に応えるため、システムに障害が発生した場合に重要ではないカスタマーエクスペリエンス機能をオフにする自動緊急時対応スイッチを実装しました。

まとめ

この記事では、サステナビリティプロキシメトリックと KPI の動機について説明しました。使用量ベースのメトリクス、ビジネスメトリクスの標準化と包含という概念を説明し、お客様がこれらのメトリクスを使用して持続可能性を最適化する方法の例を共有しました。

次の投稿では、持続可能性の観点から AWS の使用を最適化して効率のベストプラクティスを大規模に導入したいと考えているチーム向けに、プロキシメトリクスデータパイプラインを設定して持続可能性プロキシメトリクスのショーバックメカニズムを確立する方法について詳しく説明します。

持続可能性のためにワークロードを最適化する方法の詳細については、AWS Well Architected の持続可能性の柱を参照してください。アプリケーションのサステナビリティプロキシメトリクスの測定と最適化を始めたい場合は、「サステナビリティプロキシメトリクスダッシュボード」を見つけて今すぐ実装してください。

翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。