Azure での持続可能なワークロードのアプリケーション設計
新規または既存のアプリケーションを更新する場合は、ソリューションが気候に与える影響と、改善と最適化の方法があるかどうかを検討することが重要です。 より持続可能なアプリケーション設計のためにコードとアプリケーションを最適化するための考慮事項と推奨事項について説明します。
重要
この記事は、 Azure Well-Architected持続可能なワークロード シリーズの一部です。 このシリーズに慣れていない場合は、持続可能なワークロードとは何から始めてお勧めしますか?
コード効率
アプリケーションに対する要求はさまざまであり、リソースの過剰または過小使用を防ぐために使用率を安定させる方法を検討することが不可欠であり、不要なエネルギー流出につながる可能性があります。
マイクロサービス アーキテクチャへのモノリスの移動を評価する
モノリシック アプリケーションは通常、1 つのユニットとしてスケーリングされるため、必要になる可能性がある個々のコンポーネントのみをスケーリングする余地はほとんどありません。
Green Software Foundation の配置: エネルギー効率、 ハードウェア効率
推奨事項:
- マイクロサービス アーキテクチャのガイダンスを評価します。
- マイクロサービス アーキテクチャを使用すると、ピーク時の負荷時に必要なコンポーネントのみをスケーリングできます。アイドル状態のコンポーネントがスケールダウンまたはスケールインされていることを確認します。 さらに、モノリシック アプリケーションのデプロイに必要なオーバーヘッドとリソースが削減される可能性があります。
- このトレードオフを検討してください。必要なコンピューティング リソースを減らす一方で、ネットワーク上のトラフィックの量が増える可能性があり、アプリケーションの複雑さが大幅に増加する可能性があります。
- この他のトレードオフを考えてみましょう。マイクロサービスに移行すると、デプロイ パイプラインに多数の類似点がある追加のデプロイ オーバーヘッドが発生する可能性があります。 モノリシック アーキテクチャとマイクロサービス アーキテクチャに必要なデプロイ リソースを慎重に検討してください。
- さらに、 モノリシック アプリケーションのコンテナー化に関する記事を参照してください。
API の効率を向上させる
多くの最新のクラウド アプリケーションは、サービスとコンポーネントの間で多くのメッセージを非同期的に処理するように設計されています。 ペイロード データのエンコードに使用される形式を検討してください。 アプリケーションが通信する必要がある情報の量と、チャットを減らす余地はありますか?
Green Software Foundation の配置: エネルギー効率
推奨事項:
- 多数の要求がパフォーマンスと応答性に与える影響をより深く理解するために、 チャット形式の I/O アンチパターン について説明します。
- 信頼性を向上させ、システムへの不要な負荷を軽減します。 API Managementを使用して高度な要求調整を実装します。
- アプリケーションが要求から返すデータの量を最小限に抑えるには、メッセージを選択的にエンコードします。 メッセージのエンコードに関する考慮事項を参照してください。
- 必要な場合を除き、バックエンド システムから同じ種類の情報を再処理しないように応答をキャッシュします。 「Azure API Management でのキャッシュ」を参照してください。
旧バージョンのハードウェアで動作するように下位ソフトウェアの互換性を確保する
アプリケーションで情報をレンダリングする方法を検討します。 アプリケーションは、最も高い品質ですべてを重要に処理する必要があり、その結果、帯域幅と処理が高くなりますか? UI のコンポーネントの品質を下げ、持続可能性の目標をより良く提供する余地はありますか?
Green Software Foundation の配置: ハードウェア効率
推奨事項:
- 古いブラウザーやオペレーティング システムなど、より多くのエンドユーザー コンシューマー デバイスをサポートします。 この下位互換性により、ソリューションを機能させるためにハードウェアのアップグレードを必要とするのではなく、既存のハードウェアを再利用することで、ハードウェアの効率が向上します。
- このトレードオフを考慮してください。最新のソフトウェア更新プログラムのパフォーマンスが大幅に向上している場合は、古いソフトウェア バージョンを使用する方が効率的ではない可能性があります。
クラウド ネイティブ設計パターンを活用する
クラウドネイティブの設計パターンについて学習することは、アプリケーションが Azure でホストされているか、他の場所で実行されているかに関係なく、アプリケーションを構築するのに役立ちます。 クラウド アプリケーションのパフォーマンスとコストを最適化すると、リソースの使用率も削減されるため、炭素排出量も削減されます。
Green Software Foundation の配置: エネルギー効率、 ハードウェア効率
推奨事項:
- アプリケーションを記述または更新するときに 、クラウドネイティブの設計パターン を活用します。
サーキット ブレーカー パターンの使用を検討する
失敗する可能性のある操作をアプリケーションが実行できないように評価することを検討してください。 エラーが繰り返し発生すると、適切な設計パターンで回避できるオーバーヘッドと不要な処理が発生する可能性があります。
Green Software Foundation の配置: エネルギー効率
推奨事項:
- サーキット ブレーカーは、失敗する可能性がある操作のプロキシとして機能し、発生した最近の障害の数を監視し、その情報を使用して続行するかどうかを決定する必要があります。
- サーキット ブレーカー パターンを検討し、アプリケーションにサーキット ブレーカー パターンを実装する方法を検討します。
- Azure Monitor を使用して障害を監視し、アラートを設定することを検討してください。
効率的なリソース使用のためにコードを最適化する
非効率的なコードを使用してデプロイされたアプリケーションは、持続可能性に固有の影響を与える可能性があります。
Green Software Foundation の配置: エネルギー効率、 ハードウェア効率
推奨事項:
- CPU サイクルと、アプリケーションに必要なリソースの数を減らします。
- 最適化された効率的なアルゴリズムと設計パターンを使用します。
- 「繰り返さない(DRY)」の原則を検討してください。
非同期アクセス パターン用に最適化する
アプリケーションに対する要求はさまざまであり、リソースの過剰または過小使用を防ぐために使用率を安定させる方法を検討することが不可欠であり、不要なエネルギー流出につながる可能性があります。
Green Software Foundation の配置: エネルギー効率
推奨事項:
- 即時処理を必要としないキュー要求とバッファー要求をバッチ処理します。 この方法でアプリケーションを設計すると、安定した使用率を実現し、消費をフラット化して要求が急増しないようにするのに役立ちます。
- 非同期アクセス パターンの最適化に関する記事を参照してください。
サーバー側とクライアント側のレンダリングを評価する
UI を持つアプリケーションを構築する場合、サーバー側とクライアント側のどちらでレンダリングするかを決定します。
Green Software Foundation の配置: エネルギー効率、 ハードウェア効率
推奨事項:
サーバー側レンダリングの次の利点を考慮してください。
- サーバーの電源がクライアントのロケールよりも汚染の少ない代替手段から得た場合。
- サーバー上のハードウェアの処理エネルギー比が優れている場合。
- 一元化されたキャッシュを使用して、複数の不要なレンダリングを減らすことができます。
- クライアントのデバイスに損失リンクがある場合は、ブラウザーとサーバー間のラウンドトリップの数を減らすことが特に重要な場合があります。
- クライアント デバイスが古く、CPU の速度が遅い場合。 ユーザーは、最新のブラウザーをサポートするためにデバイスをアップグレードする必要はありません。
クライアント側レンダリングの次の利点を考慮してください。
- エンド ユーザー デバイスの方が適している場合は、クライアントにレンダリングの責任をプッシュします。
- 少なくとも 1 回はレンダリングするのではなく、必要なものと要求に応じてレンダリングする方が効率的です。
- 静的ストレージに依存できるため、サーバーは必要ありません。
- ブラウザー キャッシュは、クライアントで使用されます。
持続可能性のための UX 設計に注意する
ワークロードの UX 設計が持続可能性にどのように影響するかを検討し、エネルギー効率を向上させ、不要なネットワーク負荷、データ処理、コンピューティング リソースを削減するためのオプションを決定します。
Green Software Foundation の配置: エネルギー効率
推奨事項:
- ページに読み込んでレンダリングするコンポーネントの数を減らすことを検討してください。
- アプリケーションが低解像度の画像とビデオをレンダリングできるかどうかを判断します。
- ブラウザーがサイズ変更を行っているサムネイルとしてフルサイズの画像をレンダリングしないでください。
- フルサイズの画像をサムネイルまたはサイズ変更された画像として使用すると、画像のサイズ変更とプリレンダリングにより、より多くのデータ、不要なネットワーク トラフィック、およびクライアント側の CPU 使用率が増えます。
- 未使用のページがないことを確認すると、UX 設計を最小限に抑えるのに役立ちます。
- 検索と検索可能性を検討してください。 ユーザーが探しているものを見つけやすくすることで、格納および取得されるデータの量を減らすことができます。
- より軽量な UI を提供し、使用するリソースを減らし、持続可能性への影響を軽減し、ユーザーに情報に基づいた選択を提供することを検討してください。
- 暗い背景を使用して、アプリと Web サイトをダーク モードで提供することで、エネルギーを節約できます。
- クライアントが追加のフォントを強制的にダウンロードすることを避けるために、可能な場合はシステム フォントを使用することを選択します。これにより、ネットワーク負荷が高くなります。
レガシ コードを更新する
最新のクラウド インフラストラクチャまたは最新の更新プログラムで実行されていない場合は、レガシ コードのアップグレードまたは非推奨化を検討してください。
Green Software Foundation の配置: ハードウェア効率
推奨事項:
- モダン化に適した非効率的なレガシ コードを特定します。
- サーバーレスまたは最適化された PaaS オプションに移行するオプションがあるかどうかを確認します。
- このトレードオフを検討してください。非推奨になる可能性がある古いコードを更新すると、貴重な時間が消費される可能性があります。
次のステップ
アプリケーション プラットフォームの設計上の考慮事項を確認します。