サステナブルなITとは、インフラストラクチャー、コーディング、オペレーション技術を活用して、環境や気候に及ぼす影響の最小化を目指すことを目的としています。これはかなり新しいアプローチであり、監視および測定システムを使用することで、何が効果があり、何がそうでないかを特定することができます。2022年The State of Green Cloud Software Practicesは、ITのサステナビリティへの4つの主なアプローチとして、以下を策定しています。
1. 運用効率
定義内容:アプリケーションとプロセス運用に必要とされるマシンとリソースの数。この数を減らし、使用される炭素量を削減する。
効果:運用効率の改善により「5〜10倍」のエネルギー比率の削減が見込まれる。
実施方法:
- 最適な処理能力を算出します。
- ジョブの実行時間をたとえばオフピーク時にするなど、オーケストレーターが選択できる、使用量ベースのインスタンスを使用します。
- メモリ、ストレージ、その他リソースなどのサービスの規模を適正化します。バックグラウンドで使用されずに稼働しているサービスの数を減らし、インフラストラクチャーの過剰なプロビジョニングを防ぎます。
- CPUを、アプリケーションを実行するために必要と記憶されたレベルにオートスケールします。
- 正しいタイプのインスタンスやサービスを使っていることを確認します。たとえば、AWS EC2のようなサービスには、計算に最適化されたインスタンスタイプ、メモリに最適化されたインスタンスタイプ、およびストレージに最適化されたインスタンスタイプがあります。計算に最適化されたインスタンスを使用しているのにメモリ使用量が高い場合、問題はCPUの最適化ではありません。
測定と監視方法:
- 各オペレーションまたはアプリケーションに必要なCPUの処理能力を計算して、エネルギー比率と掛け合わせます。Googleには、サーバーのアイドル時と、ワークロード実行時に使用されるエネルギーを比較測定するためのメソドロジーモデルがあります。そこから、各プロセスに必要なリソースの割り当てを算出します。
- 稼働していないアプリケーションとサービスを定期的に評価し、利用されていない時はオフにします。これには、潜在的なセキュリティリスクの低減というメリットもあります。
2. 最小限の炭素排出量を目的としたアーキテクチャ設計
定義内容:アプリケーションがエネルギー効率の観点から設計されている。
効果:最初の設計時からアプリケーションを最適化する。最初からもっとも優れた環境フットプリントの実現が期待されるアプリケーションに注力する。
実施方法:
- 保管前に画像を圧縮するなど、倹約型のデータストレージプロセスを採用し、データサイズを減らします。
- クラウドバーストを採用しているマネージドクラウドサービスを選択します。これは、パブリッククラウド経由で機能を拡張し、容量が限度に達した際のアプリケーションの制約を軽減します。
- グリーンコーディングのようなコーディング効率化の実践を活用し、コードが確実にエネルギー削減に寄与することで、全体の効率性を改善します。
- APIコールをさらに効率化します。緊急性の低いタスクを遅らせることで、APIコールの同時発生数を減らします。カンファレンスイベントシリーズのAPIDaysはレポートを発表して、重いペイロードを減らし、より具体的な情報をクエリし、APIレスポンスにおいて必要な情報のみを返すなどAPI関連のエネルギー効率化技術を説明しています。
- オートローディングの動画オプションを外します。
測定と監視方法:
- アプリケーション処理で保管されるデータ量や、APIコールのペイロードのサイズを時系列で測定し、減らせないかを確認します。
- アプリケーションに必要なサーバーのハードウェアを継続的に最小化できるように、サーバレス機能を追加します。
3. エネルギー効率
定義内容:アプリケーション実行に必要なデバイスのCPU、ストレージ、メモリの消費エネルギー量が削減されている。
効果:インフラストラクチャーとアプリを監視してネットワークとプロセッサーの必要負荷を減らし、それによりプログラム実行に必要なCPUのリソースを減らして、エネルギー効率をさらに高める。
実施方法:
- いつ、また何故、カスタムコードではなくライブラリを使用するかを定義します。
- パフォーマンスと可用性を監視してホストの規模をいかに適正化できるかを判断し、パフォーマンス、可用性、ユーザーエクスペリエンスに対するエネルギーリソースの使用の適正なバランスを見出します。
- アプリケーションをモバイルデバイスにおける実行、または低電力消費モードでの運用を実現しやすくようにします。そして、トレードオフとなった、品質およびパフォーマンスの低下を許容できるかのをユーザが判断できます。
- できる限り、バックグラウンドでのアプリケーション実行を要求しないようにします。
- モバイルデバイス向けのエネルギーを効率化するコーディング技法を適用します。
測定と監視方法:
- クラウドリソースの監視を行い、必要以上に過剰なプロビジョニングをしていないことを確認します。
- どのメソッドがもっとも効率的かを特定するように、ベンチマークを行います。
- ライブラリの数と容量、またはそのライブラリに依存性のあったライブラリの数と容量を監視し、他の候補オプションを含めて、効率性の観点で定期的に評価します。
4. ハードウェアの効率性
定義内容:ハードウェアの効率性とは、リソースを保護、または新規デバイスの作成を制限できるように、ハードウェアの寿命を延長すること。
効果:物理的なユーザーデバイスは、構築に膨大なエネルギーを必要とする。それらの使用を延長することでエネルギーを節約する。
実施方法:
- 強制的にサポート終了をしないように。ソフトウェアが、その機能を必要としていないユーザーに対して、デバイスの最新バージョンへのアップグレードを推奨しないようにします。
- ソフトウェアが既存デバイスとの後方互換性があることを確認します。
測定と監視方法:
- どのバージョンのデバイスがまだソフトウェアを実行できるのかを監視します。
- ベンチマークとして、長期サポート期間を算出します。これはつまり、ソフトウェアまたはアプリケーションが使用可能なデバイスの互換性を維持できる合理的な期間です。
サステナビリティメトリクスの測定方法
技術スタックのエネルギー使用状況を監視することで、ビジネスゴールや技術リソースを、環境・社会的価値に合わせることができます。アプリケーション監視は、サステナブルなITへの移行を支援する、もっとも優れたツールのひとつです。
サステナブルなITの測定には、技術基準(プロキシ)とバリュー基準(ビジネス)を統合するメトリクスにもとづいた主要パフォーマンス指標(KPI)の策定が必要です。
1. プロキシメトリクス
プロキシメトリクスは、ワークロードにおいてどの計算、ネットワーク、ストレージリソースがプロビジョニングされているかを測定します。最適なパフォーマンスに必要なリソースのみをプロビジョニングすべきです。
- 計算リソースは、CPUやメモリなど、ソフトウェアとアプリケーションの実行に使用されるコンポーネントです。個々のレベルに割り当てられたリソースを追跡して、使用エネルギー量を測定します。
- ネットワークリソースは、サーバーやプリンターなど、リモートでアクセス可能なハードウェアやソフトウェアです。ネットワークの運用地域と大多数のユーザーが居住する地域とを比較して、データの移動距離を測定します。ユーザーが複数地域に分散している場合、各地域でデータのコピーを設定し、ネットワークアクセス時のエネルギー量を減らすようにします。
- ストレージリソースは、オンプレでホストされたサーバーやクラウドストレージなど、データのストレージに使用されるものです。
2. ビジネスメトリクス
ビジネスメトリクスは、成果を定量化し、ワークロードにより提供された値を反映します。これは、エネルギー使用に関するリターンを分析するのに有用です。以下にいくつか例を示します。
- 同時アクティブユーザー数:APIコールとAPIユーザー数をマッピングするメトリクスとを組み合わせ、その削減を使用してエネルギー効率に優れたAPI設計を提示します。これは、APIコールの削減が、APIプロダクトの需要や使用の減少として認識されないため、とても重要です。APIコールのコンピューティングワークロードを減らすことで、サービスユーザーへの提供とその拡大を続けながら、メトリクスは、サステナブルなITプラクティスの導入により、ビジネスの目標がマイナスの影響を受けていないことを示します。
- 完了したトランザクション数:正常に完了したトランザクションの割合などのビジネスメトリクスは、導入されたサステナブルな手法が(ソフトウェアを使用してトランザクションを完了するその能力により)、ユーザーの受けるエンドバリューにマイナスの影響を与えていないことを示す、ベンチマークとして使用できます。これらのメトリクスは、ESGレポーティングでサステナビリティを重視しながらビジネスゴールを達成できることを示すためにも使用できます。
- クラウド費用のコスト。サステナブルであることに関して、ビジネス的観点から、もっとも説得力のある項目の一つは、コスト削減です。
3. KPI
プロキシとビジネスメトリクスが得られたら、特定の目標に関する長期的なパフォーマンスの定量化ができるようになります。以下の公式に従って計算してください。
KPI = プロキシ÷ビジネス
プロキシとビジネスメトリクスは、各業務単位に割り当てられたリソース数を計算します。これにより、各アプリケーションのワークロードまたはプロセスのKPIが作成されます。この数値を計算するには、割り当てられたリソース(プロキシメトリクス)を達成したビジネス成果(ビジネスメトリクス)で割ります。たとえば、KPIから実行済みの各トランザクションに使用されたエネルギー量を計算できます。
各トランザクションに使用されたエネルギー量が分かったら、このデータをパートナーやサードパーティープロバイダのエネルギー量と比較する際のベンチマークとして使用します。KPIデータを分析する際には、以下の質問に答え、エネルギー使用をいかに削減できるかを検討します。
- もっともパフォーマンスの優れたAPIのエネルギー消費に合わせて、APIを標準化できるか?
- 自社のAPIアーキテクチャのエネルギー消費を、どのようにパートナーやサードパーティープロバイダのエネルギー消費と比較できるか?
- 彼らのAPIアーキテクチャは異なっているか?
- 自社のAPIプラクティスは業界のベストプラクティスに適合しているか?
KPIメトリクスは、一定の経過期間における改善を追跡できます。運用効率、アーキテクチャ設計、エネルギーおよびハードウェア効率などについて、サステナビリティを重視した変更を実施した後、新たなメトリクスをもともとのベンチマークの数値と比較します。この変更が成功すれば、新たなエネルギー消費は元のデータより低くなるはずです。顕著な変化が見られなければ、ITプラクティスの再評価を最初から検討し直す必要があります。
Next steps
- 弊社のサステナビリティシリーズで、環境に優しい製品を概念化するための思考デザインとサステナビリティに向けたダッシュボートの構築についてぜひお読みください。
- 貴社のサステナビリティメトリクスを開始するには、無料のNew Relicアカウントにご登録ください。
- インフラストラクチャー、ネットワークリソース、ストレージリソースの監視方法については、こちらの文書をご覧ください。
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.