Azure での持続可能なワークロードのテストに関する考慮事項

ソリューションを開発してクラウドにデプロイする組織にも、信頼性の高いテストが必要です。 ワークロード テストの実行に関する考慮事項と推奨事項、およびより持続可能なテスト モデル用に最適化する方法について説明します。

重要

この記事は、 Azure Well-Architected 持続可能なワークロード シリーズの一部です。 このシリーズに慣れていない場合は、持続可能なワークロードとは何から始めてお勧めしますか?

テスト効率

低炭素期間中に統合、パフォーマンス、負荷、またはその他の厳しいテストを実行する

統合、パフォーマンス、負荷、またはその他の厳しいテスト機能を実行すると、多くの処理が発生する可能性があります。 デプロイされたワークロードをテストするための適切に細工された設計は、利用可能なリソースを完全に利用し、二酸化炭素排出量を削減するのに役立ちます。

Green Software Foundation alignment: Carbon awareness

推奨事項:

• データを利用できる場合は、データ センターのエネルギー ミックスで主に再生可能エネルギーが使用される場合のテストの実行を計画します。 たとえば、一部のリージョンで夜間にテストを実行する方が有益な場合があります。

CI/CD を自動化して、必要に応じてワーカー エージェントをスケーリングする

使用率の低い CI/CD エージェントまたは非アクティブな CI/CD エージェントを実行すると、より多くの排出量が発生します。

Green Software Foundation の配置: ハードウェア効率

推奨事項:

• 現在の需要に基づいてコンピューティング使用率を高く保ち、不要な容量割り当てを回避します。
• 必要な場合にのみスケールアウトし、テストしない場合はスケールインします。 最終的に、これにより、テスト環境にアイドル状態のコンピューティング リソースが存在しなくなります。
• VM でのテストよりもコンテナーなどの最適化されたプラットフォーム サービスを検討し、プラットフォームを利用してメンテナンスを削減します。

CI/CD エージェントの使用時にキャッシュを検討する

CI/CD 中にキャッシュ メカニズムを使用すると、コンピューティング時間と炭素排出量を削減できます。

Green Software Foundation alignment: Energy Efficiency

推奨事項:

• キャッシュにステップの結果を格納し、可能な場合は異なる CI/CD 実行間でそれらを再利用します。異なる実行間で頻繁に変更されない成果物を生成するために CPU 時間がかかる手順がある場合は、同じ成果物を生成するすべての実行で CPU 時間が無駄にされないように、将来の使用のために保存することをお勧めします。 を繰り返し行う必要があります。
• CI/CD エージェントがセルフホステッドの場合は、エージェントに対してローカルなキャッシュを使用して、データ転送と排出量をさらに削減します。 これにより、キャッシュがネットワーク経由で転送されないことが保証されます。これは、排出量の重要な原因になる可能性があります。

大規模なコード リポジトリを分割する

大きなリポジトリを分割すると、変更されたコードの部分のみがコンパイルされる CI/CD フェーズに役立ちます。 これにより、コンピューティング時間が短縮され、最終的に炭素排出量が削減されます。

Green Software Foundation alignment: Energy Efficiency

推奨事項:

• 大きなコード リポジトリを分割し、メインコードをライブラリと依存関係から分離します。
• 複数のリポジトリに共通するコードの成果物とライブラリを発行して再利用します。

推奨事項:

• コードの大規模なリポジトリを小さなリポジトリに分割し、メインコードをライブラリと依存関係から分離します。
• 複数のリポジトリに共通するコードの成果物とライブラリを発行して再利用します。

プロファイリングと測定

ワークロードの測定、プロファイリング、テストは、割り当てられたリソースを最適に使用する方法を理解するために不可欠です。

並列化が可能な場所を評価する

ワークロードを適切にプロファイリングしてテストしないと、基になるプラットフォームとデプロイされたリソースを最大限に活用しているかどうかを知ることは困難です。

Green Software Foundation のアラインメント: 持続可能性の測定

推奨事項:

• アプリケーションをテストして、同時要求、同時処理などを理解します。
• テスト用に Machine Learning (ML) を実行している場合は、効率を向上させるために GPU を搭載したマシンを検討してください。
• ワークロードがパフォーマンスを集中的に消費しているかどうかを特定し、最適化に向けて取り組む。
• 次のトレードオフを検討してください。 ML テスト用に GPU ベースのマシンを実行すると、コストが増加する可能性があります。

カオス エンジニアリングを使用して評価する

統合、パフォーマンス、ロード テストを実行すると、ワークロードの信頼性が向上します。 ただし、カオス エンジニアリングの導入は、信頼性と回復性、およびアプリケーションが障害にどのように反応するかを大幅に改善するのに役立ちます。 そうすることで、ワークロードを最適化して障害を適切に処理し、無駄なリソースを減らすことができます。

Green Software Foundation のアラインメント: 持続可能性の測定

推奨事項:

• ロード テストまたは カオス エンジニアリング を使用して、ワークロードがプラットフォームの停止やトラフィックの急増や急落をどのように処理するかを評価します。 これにより、サービスの回復性と障害に対応する機能が向上し、より最適化された障害処理が可能になります。
• 次のトレードオフを検討してください。 カオス エンジニアリング中に障害を挿入し、システムへの負荷を増やすと、テスト リソースに使用される排出量も増加します。 不要なテスト セッションの実行による気候への影響を考慮しながら、カオス エンジニアリングを利用してワークロードの信頼性を向上させる方法とタイミングを評価します。
• これに対するもう 1 つの角度は、カオス エンジニアリングを使用して、炭素排出量が多いエネルギー障害や瞬間をテストすることです。可能な限り最小限のエネルギーを消費するようにアプリケーションにチャレンジするテストを設定することを検討してください。 一部の機能と場合によってはパフォーマンスを犠牲にして、可能な限り最小限の炭素を放出していることをユーザーに通知する特定の "eco" バージョンを使用して、アプリケーションがこのような条件にどのように反応するかを定義します。 これは、その持続可能性をスコアリングするためのベンチマーク アプリケーションにもなります。

テストで CPU とメモリのしきい値を確立する

アプリケーションで持続可能性をテストするためのテストを構築するのに役立ちます。 ベースライン CPU 使用率の測定を行い、テストの実行時に CPU 使用率ベースラインの異常な変更を検出することを検討してください。 ベースラインを使用すると、最近のコード変更で行われた最適でない決定を、以前に検出できます。

デプロイおよびテスト パイプラインにテストと品質ゲートを追加すると、非持続可能なソリューションのデプロイを回避し、排出量の削減に貢献できます。

Green Software Foundation の配置: エネルギー効率

推奨事項:

• 統合テストまたは単体テストを実行するときに、CPU とメモリの割り当てを監視します。
• アプリケーション コードで異常に高いリソース消費領域を見つけ、最初にそれらの軽減に重点を置きます。
• 確立されたベースライン値を超える場合はアラートを構成するか、エラーをテストします。これにより、非持続可能なワークロードのデプロイを回避できます。
• このトレードオフを考慮してください。アプリケーションが拡大するにつれて、新しい機能を導入するときにテストの失敗を避けるために、ベースラインを適宜シフトする必要がある場合があります。

次のステップ

運用手順の設計上の考慮事項を確認します。

操作手順