ソリューションを開発してクラウドにデプロイする組織にも、信頼性の高いテストが必要です。 ワークロード テストを実行するための考慮事項と推奨事項、およびより持続可能なテスト モデル用に最適化する方法について説明します。
Important
この記事は、 Azure Well-Architected Framework の持続可能なワークロード シリーズの一部です。 このシリーズに慣れていない場合は、「持続可能なワークロードとは」から始めるのをお勧めします。
テストの効率
低炭素期間中に厳しいテストを実行する
統合、パフォーマンス、負荷、またはその他の集中的なテスト機能を実行すると、処理が大幅に増加する可能性があります。 デプロイされたワークロードに対して適切に作成されたテスト設計は、利用可能なリソースを完全に利用し、炭素排出量を削減するのに役立ちます。
Green Software Foundation alignment: Carbon awareness
勧告：
- エネルギー ミックス データが使用可能な場合は、データセンターが主に再生可能エネルギーを使用する場合にテストを実行することを計画します。 たとえば、一部の地域では、よりクリーンなエネルギー源がより普及している夜にテストを実行する方が有益な場合があります。
CI/CD を自動化してワーカー エージェントを必要に応じてスケーリングする
使用率が低い、または非アクティブな継続的インテグレーションおよび継続的デリバリー (CI/CD) エージェントを実行すると、排出量が増えます。
Green Software Foundation のアラインメント: ハードウェアの効率
Recommendations:
現在の需要に基づいてコンピューティング使用率を高く維持し、不要な容量の割り当てを回避します。
必要な場合にのみスケールアウトし、テストしない場合はスケールインします。 この方法により、テスト環境にアイドル状態のコンピューティング リソースが存在しないようにします。
プラットフォームを使用してメンテナンスを削減する仮想マシン (VM) でのテストよりも、コンテナーなどの最適化されたプラットフォーム サービスを検討してください。
CI/CD エージェントを使用する場合のキャッシュを検討する
CI/CD 中にキャッシュ メカニズムを使用すると、コンピューティング時間が短縮され、炭素排出量が削減されます。
グリーンソフトウェアファンデーションのアライメント: エネルギー効率
Recommendations:
ステップの結果をキャッシュに格納し、可能な場合は異なる CI/CD 実行間で再利用します。 実行の間に頻繁に変更されない成果物を生成するために CPU 時間が必要な場合は、後で使用できるように成果物を保存します。 この最適化により、同じ成果物を繰り返し生成するすべての実行で CPU 時間を無駄にすることを回避できます。
データ転送と排出量をさらに削減するために、セルフホステッド時に CI/CD エージェントに対してローカルなキャッシュを使用します。 このセットアップにより、キャッシュがネットワーク経由で転送されることが保証されます。これは、大量の排出源になる可能性があります。
大規模なコード リポジトリを分割する
大きなリポジトリを分割すると、コードの変更された部分のみがコンパイルされる CI/CD フェーズに役立ちます。 この戦略により、コンピューティング時間が短縮され、最終的に炭素排出量が削減されます。
グリーンソフトウェアファンデーションのアライメント: エネルギー効率
Recommendations:
大きなコード リポジトリをより小さなリポジトリに分割し、メイン コードをライブラリと依存関係から分離します。
複数のリポジトリ間で共通のコードの成果物とライブラリを発行して再利用します。
ワークロードのプロファイリングと測定
ワークロードの測定、プロファイリング、テストは、割り当てられたリソースを最適に使用する方法を理解するために不可欠です。
並列処理が可能な場所を評価する
ワークロードを適切にプロファイリングしてテストしないと、基になるプラットフォームとデプロイされたリソースを最大限に活用しているかどうかを把握することは困難です。
グリーンソフトウェアファンデーションの連携: 持続可能性の測定
Recommendations:
アプリケーションをテストして、同時要求、同時処理、およびその他の要因を理解します。
テスト用に機械学習を実行する場合は、効率を向上するために GPU ベースのマシンを検討してください。
ワークロードがパフォーマンスを集中的に消費しているかどうかを特定し、最適化に向けて取り組みます。
次のトレードオフを検討してください。 機械学習テスト用に GPU ベースのマシンを実行すると、コストが増加する可能性があります。
カオス エンジニアリングを使用して評価する
統合、パフォーマンス、ロード テストを実行すると、ワークロードの信頼性が向上します。 ただし、カオス エンジニアリングの導入は、信頼性、回復性、およびアプリケーションが障害に対してどのように反応するかを大幅に改善するのに役立ちます。 ワークロードを最適化して障害を適切に処理し、無駄なリソースを減らすことができます。
グリーンソフトウェアファンデーションの連携: 持続可能性の測定
Recommendations:
ロード テストまたは カオス エンジニアリング を使用して、ワークロードがプラットフォームの停止やトラフィックの急増や急落をどのように処理するかを評価します。 このプラクティスは、サービスの回復性と障害に対応する機能を向上させるのに役立ちます。これにより、より最適化された障害処理が可能になります。
カオス エンジニアリングを使用して、より多くの炭素を放出するエネルギー障害または瞬間をテストします。 できるだけ少ないエネルギーを消費するようにアプリケーションにチャレンジするテストを設定することを検討してください。 アプリケーションがこれらの条件にどのように対応するかを定義します。 エコ バージョンとも呼ばれる特定のエコバージョンを作成します。この バージョンでは、一部の機能と場合によってはパフォーマンスを犠牲にして、可能な限り最小限の炭素を放出していることをユーザーに通知します。 このバージョンは、持続可能性をスコア付けするためのベンチマーク アプリケーションとしても機能します。
次のトレードオフを検討してください。 カオス エンジニアリング中に障害を挿入し、システムの負荷を増やすと、テスト リソースに使用される排出量も増加します。 不要なテスト セッションの実行による気候の影響を考慮しながら、カオス エンジニアリングを使用してワークロードの信頼性を向上させる方法とタイミングを評価します。
テストで CPU とメモリのしきい値を確立する
アプリケーションで持続可能性をテストするためのテストを構築するのに役立ちます。 テストの実行時に CPU 使用率ベースラインの異常な変更を検出できるように、ベースラインの CPU 使用率の測定を行っていることを検討してください。 ベースラインがある場合は、以前に最近のコード変更で行われた最適でない決定を見つけ出すことができます。
デプロイとテスト パイプラインにテストと品質ゲートを追加すると、持続不可能なソリューションのデプロイを回避できます。 このアプローチは、排出量の削減に貢献します。
グリーンソフトウェアファンデーションのアライメント: エネルギー効率
Recommendations:
統合テストまたは単体テストを実行するときに、CPU とメモリの割り当てを監視します。
アプリケーション コードで異常に高いリソース消費領域を見つけ、最初に軽減することに重点を置きます。
アプリケーションが確立されたベースライン値を超えた場合は、アラートを構成するか、エラーをテストします。 この構成は、持続不可能なワークロードのデプロイを回避するのに役立ちます。
次のトレードオフを検討してください。 アプリケーションが拡大するにつれて、新しい機能を導入するときにテストの失敗を避けるためにベースラインの移行が必要になる場合があります。