AWS の Green IT Analyzer で持続可能なモダナイゼーションを加速 – IBM ブログ

企業は、ハイパフォーマンス コンピューティング、人工知能 (AI)、機械学習 (ML) などのデータ集約型のワークロードをますます採用しています。これらのテクノロジーは、復元力、パフォーマンス、セキュリティ、コンプライアンスに重点を置きながら、ハイブリッド マルチクラウドへの移行におけるイノベーションを推進します。企業はまた、このイノベーションと増大する環境、社会、ガバナンス (ESG) 規制とのバランスを取るよう努めています。ほとんどの組織にとって、IT 運用と最新化は ESG 目標の一部を形成しており、 ファウンドリの最近の調査、約 60% の組織がグリーン テクノロジー分野に特化したサービス プロバイダーを求めています。

炭素排出量報告が世界中で一般的になる中、IBM は、コストを削減しながらエネルギー需要とそれに伴う炭素への影響に対処できるよう、お客様が十分な情報に基づいた意思決定を行えるよう支援することに尽力しています。より持続可能な IT 資産の構築を支援するために、IBM はアマゾン ウェブ サービス (AWS) と提携して、持続可能なクラウドのモダナイゼーションの取り組みを促進します。

企業がデジタル変革を加速し、ビジネス上の優位性を獲得するために IT の最新化を急ぐにつれて、大きなチャンスが生まれます。この機会には、より環境に優しく、より持続可能な設計に向けて IT 環境とアプリケーション ポートフォリオを再設計することが含まれます。このようなアプローチは、コスト効率を高めるだけでなく、より広範な企業の持続可能性目標にも貢献します。

デジタルテクノロジーからの炭素排出を理解する

IBM が構築および実行するすべてのビジネス アプリケーションには、外部顧客向けか内部顧客向けかを問わず、 炭素コスト、これは主に電力消費によるものです。 IBM がこれらのアプリケーションやサービスの開発に使用したテクノロジーに関係なく、それらを動作させるには電力を消費するハードウェアが必要です。
グリッド電力によって生成される二酸化炭素 (CO2) 排出量は、発電方法によって異なります。石炭やガスなどの化石燃料は大量の炭素を排出しますが、風力や太陽光などの再生可能資源が排出する炭素の量はごくわずかです。したがって、消費される電力の各キロワット (kW) は、大気中に放出される特定量の CO2 換算量 (CO2e) に直接寄与します。

したがって、電力消費量の削減は炭素排出量の削減に直接つながります。

実際の二酸化炭素排出量

コンピューティング、ストレージ、ネットワーキングは、アプリケーションやサービスを構築するプロセスでエネルギーを消費する重要な技術リソースです。彼らの活動には、活動するデータセンタースペースの積極的な冷却と管理が必要です。持続可能な IT 実践の管理者として、私たちは日常の活動を通じてリソースの消費をどのように削減できるかを考慮する必要があります。

データセンターは、運用領域に電力を供給する送電網から電力を供給します。この電力はサーバー、ネットワーク スイッチ、ストレージなどのさまざまな IT 機器を稼働させ、顧客のアプリケーションやサービスをサポートします。この電力は、ハードウェアを動作制限内に保つ環境を維持するために不可欠な、暖房、換気、空調または冷却などの補助システムも動作させます。

脱炭素化への道

アプリケーションの最新化 はイノベーションを推進し、ビジネスを変革する上で極めて重要になりつつあります。 IBM Consulting® は、AWS Well-Architected フレームワークを適用して持続可能性のためのカスタム レンズを作成し、オンプレミスと AWS クラウドの両方でアプリケーションのワークロード評価を実行します。 IBM Consulting® Custom Lens for Sustainability の他の主要なシナリオとエントリー・ポイントについては、次のブログ投稿をご覧ください。 AWS クラウドを使用した持続可能なアプリの最新化.

このブログ投稿では、サステナビリティの観点から、AWS 上で実行されるモノリシック アプリケーションの二酸化炭素排出への影響を評価、推奨事項の実装、分析するための詳細な分析を掘り下げます。

Green IT Analyzer: 総合的なIT脱炭素化プラットフォーム

Green IT Analyzer プラットフォームを使用すると、クライアントは従来の IT をよりエネルギー効率が高く持続可能なグリーン IT に変換できます。ワンストップ ショップとして機能し、プライベート データ センター、パブリック クラウド、ユーザー デバイスを含むハイブリッド クラウド環境全体にわたる二酸化炭素排出量の測定、レポート、ベースラインの作成を行い、統合されたダッシュボード ビューを提供します。このプラットフォームは、IT 資産の二酸化炭素排出量を詳細なレベルと仮想マシン (VM) レベルの両方で測定できます。エネルギーまたは炭素のホットスポットを特定して、最適化ロードマップを作成するのに役立ちます。使用されている炭素評価技術は以下と一致しています。 温室効果ガス (GHG) 情報通信技術分野の原則。

位置ベースの方法論

IT ワークロードからの炭素排出を理解するには、いくつかの重要な概念と指標に精通している必要があります。概要は次のとおりです。

• 二酸化炭素排出量 (CFP): 二酸化炭素排出量の概念は私たちの分析の中心です。 CFPはCOの総量を表します₂ ゼロ以上の CFP のベースライン測定から始まる、データセンターへの電力供給に関連する同等の GHG 排出量。これは、データセンター運営が環境に与える影響を評価するための重要な指標です。
• 電力使用効率 (PUE): もう 1 つの重要な指標は、電力使用効率です。 PUE は、データセンターのエネルギー効率を測定します。これは、施設の総エネルギーを IT 機器によって消費されるエネルギーで割ることによって計算されます。この除算により、効率を示す比率が得られます。PUE が XNUMX に近い場合は効率が高いことを示し、値が高いほどエネルギーの無駄が大きいことを示します。
  計算式: PUE = (施設の総エネルギー)/(IT 機器によって消費されるエネルギー)
• 炭素強度 (CI): 最後に、炭素強度を考慮します。 CI は、データセンターに電力を供給するグリッド発電による二酸化炭素排出量をキロワット時あたりのグラム数 (g/kWh) で測定します。この指標はエネルギー源によって異なります。石炭火力発電所の CI は 1,000 g/kWh を超える可能性がありますが、風力や太陽光などの再生可能エネルギー源で電力を供給する電力網の CI はゼロに近いはずです。 (ソーラー パネルには CFP が組み込まれていますが、化石燃料に比べてはるかに少ないです。)

クライアントの主要な課題を考えてみましょう。どの組織もネットゼロ排出の達成に取り組んでおり、IT は持続可能性の課題を達成する上で重要な役割を果たしています。これには、IT 資産自体の二酸化炭素排出量の削減 (特に、IT による二酸化炭素排出量が多い金融顧客に関係します) や、グリーン IT で実行される持続可能なプラットフォームの構築が含まれます。

古いモノリシック アプリケーションは、通常、オンプレミス データ センターまたはパブリック クラウドの VM ベースのプラットフォームで実行され、重要な重点分野です。一般的に IT ポートフォリオ全体の 20 ～ 30% を占めるこれらの古いモノリシック アプリケーションによる IT リソースの消費を、どのようにして削減できるのかという重要な疑問が生じます。 VM ベースのモノリシック アプリケーションから、コンテナ プラットフォーム上で実行される、よりエネルギー効率の高いマイクロサービス ベースのアーキテクチャに移行する方が、エネルギー効率が高くなります。ただし、画一的なアプローチが常に効果的であるとは限らないため、各ケースを個別に評価することが重要です。

この基準は、アプリケーション変換の候補を選択するために使用できます。

• 以上のアプリケーション 70％〜80％ CPU使用率

• アプリケーションが経験していること 季節的なスパイク クリスマスイブ、ディワリ祭、その他の祝日などの取引時

• を使用したアプリケーション 毎日のトランザクションの急増 早朝や夜間の航空会社の搭乗など、特定の時間に

• 使用量の急増を示すモノリシック アプリケーション内の一部のビジネス コンポーネント

モノリシックアプリの現状分析

AWS 上の Elastic Compute Cloud (EC2) VM で実行される単純な e-Store アプリケーションの例を考えてみましょう。このアプリケーションである e-CART は季節的なワークロードを経験し、オンプレミスから AWS EC2 インスタンスに再ホスト (リフトアンドシフト) されています。このようなモノリシック アプリケーションは、すべてのビジネス機能を XNUMX つの展開可能なユニットにパッケージ化します。

次の表では、e-Store レガシー アプリケーションの主な特徴を説明します。

ワークロードの二酸化炭素排出量は、コンピューティング、ストレージ、ネットワークなどのリソースの消費に直接関係しており、多くの場合、コンピューティングが最も大きな原因となります。これはワークロードの特性によって異なります。たとえば、メディアまたはストリーミング業界では、ネットワーク上のデータ送信と大規模な非構造化データ セットの保存にかなりのエネルギーが消費されます。

このグラフは、単一の EC2 インスタンスで実行されているモノリシック アプリケーションで最小限のユーザー アクティビティが発生しているときの CPU の使用率パターンを示しています。

私たちは、Green IT Analyzer プラットフォームを使用して、モノリシック アプリケーションの現状の状態のカーボン アカウンティングを実行し、それを、同じアプリケーションで実行されるマイクロサービス アーキテクチャに再設計されたときのターゲットの状態と比較しました。 Amazon Elastic Kubernetes サービス (EKS) プラットフォームを提供します。

ステップ 1: モノリシック アプリケーションの包括的な二酸化炭素排出量分析

まず、さまざまな動作条件下でのモノリシック ワークロードの現在の二酸化炭素排出量を調査することに焦点を当てます。これにより、改善すべき領域を特定するためのベースラインが得られます。

ユーザー トランザクションが最小限で CPU 使用率が 45% の場合の、モノリシック ワークロードの推定二酸化炭素排出量を計算してみましょう。

• 米国東部 1d AZ の PUE: 1.2
• CI: 415.755 グラムの CO2/kWh

A. ユーザー アクティビティがない場合の推定炭素量の計算:

• 消費エネルギー: 9.76 g/W @ 45% 使用率
• 同じワークロードの実行時間: 300 時間
• 300 時間の推定二酸化炭素排出量 = PUE × CI × ワークロードによって消費されるエネルギー
• = [(1.2 × 415.755 × 9.76) × 300] ÷ 1,000 = 1,460.79 グラムの CO2e

B. 同時ユーザー 500 人による二酸化炭素排出量の推定値:

日々のピークをサポートするシステムの能力をテストするために、非機能要件 (NFR) に従ってピークレベルのトランザクションが作成されたシナリオでは、同時ユーザー アクティビティ中に CPU 使用率が 80% に急増しました。この状況により、80% の CPU 使用率でアクティブ化する自動スケーリング ルール セットがトリガーされました。このルールは、各 VM の負荷が 60% 未満に保たれるように、追加の VM をプロビジョニングします。ロード バランサーは、既存の VM と新しい VM の両方に負荷を効率的に分散します。

新しい EC2 インスタンスの自動スケーリングにより、追加の t2.large VM が利用可能になり、平均使用率が 40% に低下しました。

• 両方の同一の VM を 300 時間実行した場合のこのシナリオの推定二酸化炭素排出量 = PUE × CI × ワークロードによって消費されるエネルギー
• = {[(1.2 × 415.755 × 9.76) × 300] × 2} ÷ 1,000 = 2,921.59 グラムの CO2e

ステップ 2: 持続可能性に関する推奨事項の実施

このステップでは、持続可能性に関するさまざまな推奨事項と、モノリシック アプリケーションに対するその実践的な実装について検討します。これらの推奨事項をガイドするために、持続可能性に関するカスタム レンズの評価を使用します。

まず、モノリシック アプリケーションをアクションベースのリアクティブ マイクロサービスに分解することを検討します。このアプローチは、アプリケーションの季節的な動作とさまざまな使用パターンに合わせて調整されており、トラフィックが急増し、バックエンド トランザクションよりもアーティファクトの閲覧に重点が置かれるお祭りシーズンなどのピーク期間に特に役立ちます。

2 番目に、この計画には、特にデータセンター グリッドがグリーン エネルギーで動作している場合に、アイドル期間中にバッチ処理をスケジュールすることでエネルギー消費を削減することが含まれています。このアプローチは、長時間実行されるトランザクションの期間を最小限に抑えて電力を節約することを目的としています。

最後に、この戦略では、AWS EKS や Red Hat® OpenShift® on AWS (ROSA) など、ネットワーク トラフィックに基づいてリソースを動的に拡張できる柔軟なプラットフォームを選択することの重要性を強調しています。このようなプラットフォームの選択は、最適化されたリソース割り当てを確保するのに役立ち、アクションベースのリアクティブ マイクロサービスをホストするのに有益です。

要約すると、提案された戦略には、使用パターンに合わせたマイクロサービスの分解、エネルギーを意識したトランザクション スケジューリング、アプリケーションの効率とリソースの使用率を高めるための柔軟なプラットフォームの選択が含まれます。

マイクロサービスにリファクタリングされたアプリケーションを次の図に示します。

次に、持続可能なモダナイゼーションの一環としてアプリケーションをリファクタリングしながら、持続可能な設計原則に従ってモノリシック アプリケーションをマイクロサービス ベースのアーキテクチャに変換した後の二酸化炭素排出量を計算してみましょう。

A. 負荷がないか、負荷が少ない場合の推定炭素アカウンティング:

• ワーカーノード: 2 × t2.medium
• 使用率: 10% (アプリケーションに負荷がかかっていない場合)
• 消費エネルギー: 6% 使用率で 5 g/W
• PUE (1.2) および CI (CO 415.755 グラム)₂/kWh) は同じアベイラビリティ ゾーンを使用し続けるため、同じままです。
• 営業時間：300
• 300 時間の推定二酸化炭素排出量 = PUE × CI × ワークロードによって消費されるエネルギー
• = [(1.2 × 415.755 × 6) × 300] ÷ 1,000 = 1,796 グラムの CO₂e

観察： システムに負荷がかかっていない場合、VM 上で実行されるアプリケーションは、EKS クラスター上で実行されるマイクロサービスよりも炭素効率が高くなります。

B. ピーク負荷時の推定炭素アカウンティング:

モノリシック アプリケーションの負荷テストと同様に、構築したマイクロサービスの NFR 要件を満たすために、500 人のユーザーをオンボードし、同時トランザクションをトリガーしました。

• ワーカーノード: 2 × t2.medium
• 負荷による使用率の増加: 10% ～ 20%
• 消費エネルギー: 7.4% 使用率で 20 g/W
• PUE と CI は変わりません。
• 営業時間：300
• 300 時間の推定二酸化炭素排出量 = PUE × CI × ワークロードによって消費されるエネルギー
• = [(1.2 × 415.755 × 7.4) × 300] ÷ 1,000 = 2,215.14 グラムの CO₂e

ここでは、UI サービスに対してポッドの自動スケーリングが発生しましたが、カート サービスのスケールアップには追加のリソースは必要ありませんでした。モノリシック アプリケーションでは、どのビジネス機能やサービスがより多くのリソースを必要とするかに関係なく、プラットフォーム全体をスケールアップする必要があり、その結果、使用率が 20% 増加します。

観察： 両方のシナリオを比較してみましょう。

1. システムがアイドル状態であるか、24 時間安定した負荷プロファイルがある場合: 負荷がほとんどない場合、モノリシック アプリケーションは消費するリソースが少なくなり、ほぼすべてのリソースを排出します。 視聴者の３８%が EKS クラスターでホストされるマイクロサービスベースのアプリケーションよりも炭素が少なくなります。
2. システムが全負荷または変動負荷の場合: システムがフルロード状態の場合、 視聴者の３８%が CO削減₂ VM ベースのワークロードと比較した Kubernetes プラットフォームでの排出量。これは、使用するコアの数が少なく、使用率が低いためです。同じクラスター内でより多くのワークロードを移動し、他のアプリケーションからより多くのコアを解放して、より大きなメリットを得ることができます。

このシナリオは、IBM がどのようにして^® AWS ワークロードの持続可能性のカスタムレンズ評価は、持続可能な最新化パスを設計し、IT 資産の総二酸化炭素排出量を削減するのに役立ちます。

アクションガイド

持続可能性を重視する組織にとって、責任あるコンピューティングとグリーン IT は単に不可欠であるだけではありません。それらは完全に実現可能です。 IT リーダーは、IT 戦略、運用、プラットフォームを含む環境に優しい活動を追求することで、これらの目標を達成できます。

• IT プラットフォームをグリーン化する: リファクタリングを使用してアプリケーションをパブリック クラウドに移行します。この環境向けにワークロードを最適化せずにパブリック クラウドに移行すると、運用コストが増加し、持続可能性が低下する可能性があります。代わりに、ライフサイクル、更新と展開の頻度、ビジネスの重要性などの要素に基づいてアプリケーションをリファクタリングすることで、ワークロードをよりクラウドネイティブになるように強化します。
• アイドル状態の VM 容量とその他の未使用のクラウド リソースを最適化する: インフラストラクチャ レベルの可観測性を有効にして、IT 資産全体でアイドル状態の VM を特定します。ルールベースの自動化を実装して、ビジネス機能を提供しなくなったアイドル状態の VM や関連リソースの削除などの修正措置を講じます。さらに、自動スケーリングを通じてネットワーク トラフィックに基づいて VM のサイズを最適化します。
• 必要に応じてリソースを作成します。 クラウド リソースは弾力的ですが、使用状況に関係なく継続的に実行される固定リソースにワークロードをデプロイすると、得られる効率性のメリットは限られています。クラウド サービス内の VM スケジュールや柔軟な機能の使用など、必要に応じてリソースをプロビジョニングおよび削除する機会を特定します。
• ワークロードのコンテナ化: 従来の VM 環境の代わりにコンテナ プラットフォームを使用することで、年間のインフラストラクチャ コストを最大で削減できます。 視聴者の３８%が。コンテナー プラットフォームを使用すると、リソース要件に基づいて VM のクラスター全体でコンテナーを効率的にスケジュールできます。
• モノリシック アプリケーションをマイクロサービス ベースのアーキテクチャに最新化する: ニーズに基づいてリアクティブ マイクロサービスを選択します。リソース使用率を最適化するイベントベースの呼び出し用のリアクティブ マイクロサービス、非同期呼び出し用のイベント ドリブン マイクロサービス、または単一関数のニーズベースの実行用のサーバーレス マイクロサービスです。

IBM コンサルティングのグリーン IT トランスフォーメーション フレームワーク、持続可能性のためのカスタム レンズ、およびグリーン IT アナライザー プラットフォームは、お客様の脱炭素化への取り組みを総合的に支援します。どちらのフレームワークも、ワークロードを評価し、エネルギー消費を削減できる最適化手段を特定し、持続可能性の目標を達成できるアプリケーションの最新化ロードマップを作成するのに役立ちます。

AWS クラウド向けの IBM コンサルティング サービスの詳細をご覧ください。