Azure Kubernetes Service (AKS) での持続可能なソフトウェア エンジニアリング プラクティス
持続可能なソフトウェア エンジニアリングの原則は、持続可能なアプリケーションの定義、構築、実行に役立つ一連の能力です。 全体的な目標は、アプリケーションのすべての側面の炭素排出量を削減することです。 Azure Well-Architected Framework の持続可能性に関するガイダンスは、Green Software Foundation の「The Principles of Sustainable Software Engineering」(持続可能なソフトウェア エンジニアリングの原則) に沿っており、持続可能なソフトウェア工学の原則の概要を提供しています。
持続可能なソフトウェア エンジニアリングは、優先順位と焦点についての 1 つの転換です。 ほとんどのソフトウェアの設計および実行の方法では、多くの場合、高速パフォーマンスと、低待機時間に強調が置かれます。 持続可能なソフトウェア エンジニアリングでは、炭素排出量をできるだけ多く削減することに焦点を当てます。
- 全体的なネットワーク トラバーサルを減らすなど、持続可能なソフトウェア エンジニアリングの原則を適用することで、パフォーマンスの高速化や待機時間の短縮を実現できます。
- 炭素排出量を削減すると、パフォーマンスの低速化や、優先度の低いワークロードの遅れなどの、待機時間の増加を招く場合もあります。
次のガイダンスでは、Azure Kubernetes Service (AKS) を使用して Azure で構築または運用しているサービスに焦点を当ててます。 この記事には、設計と構成のチェックリスト、推奨される設計プラクティス、および構成オプションが含まれています。 持続可能なソフトウェア エンジニアリングの原則をアプリケーションに適用する前に、アプリケーションの優先順位、ニーズ、トレードオフを確認してください。
前提条件
- Well-Architected Framework の持続可能性に関するガイダンスを理解すると、高品質で安定した効率的なクラウド アーキテクチャを作成するのに役立ちます。 まず持続可能なワークロードの詳細を読み、Microsoft Azure Well-Architected レビュー評価を使ってワークロードを確認することから始めることをお勧めします。
- アプリケーションを構築するときには、ビジネス要件を明確に定義しておくことが重要です。なぜなら、クラスターとワークロードの両方のアーキテクチャと構成に直接影響があるからです。 既存のアプリケーションを構築または更新する場合は、アプリケーションの全体的なライフサイクルに加えて、Well-Architected Framework の持続可能性の設計領域を確認します。
共同責任モデルの概要
持続可能性は、クラウド プロバイダーと、プラットフォーム上で AKS クラスターを設計およびデプロイするお客様またはパートナーとの間の共同責任です。 データ センターが持続可能性のために最適化されているとしても、AKS をデプロイするだけで自動的に持続可能になるわけではありません。 適切に最適化されていないアプリケーションの場合、必要以上に炭素を排出する可能性もあります。
詳細については、持続可能性のための共同責任モデルに関する記事を参照してください。
設計原則
炭素効率: 炭素の排出量を最小限に抑えます。
炭素効率の高いクラウド アプリケーションとは、最適化されたものであり、その出発点はコストの最適化にあります。
エネルギー効率: 使うエネルギーを最小限に抑えます。
エネルギー効率を上げる方法の 1 つは、アプリケーションをできるだけ少ないサーバーで実行し、サーバーの稼働率を上げ、ハードウェアの効率も上げることです。
ハードウェア効率: 使う内包炭素量を最小限に抑えます。
ハードウェア効率には、大きく分けて 2 つのアプローチがあります。
- エンド ユーザー デバイスの場合は、ハードウェアの有効期間を延ばすことです。
- クラウド コンピューティングの場合は、リソース使用率を高めることです。
炭素意識: きれいな電気の場合は実行量を増やし、汚い電気の場合は実行量を減らします。
炭素意識とは、需要の増減によって炭素強度の変化に対応することです。
設計のパターンとプラクティス
各設計領域の詳細な推奨事項を確認する前に、AKS で持続可能なワークロードを構築するための次の設計パターンを慎重に検討することをお勧めします。
| 設計パターン | ワークロードに適用 | クラスターに適用 |
|---|---|---|
| 論理コンポーネントの独立したスケーリングを考慮して設計する | ✔️ | |
| イベントドリブン スケーリングを考慮して設計する | ✔️ | |
| ステートレス設計を目指す | ✔️ | |
| クラスターとノードの自動更新を有効にする | ✔️ | |
| サポートされているアドオンと拡張機能をインストールする | ✔️ | ✔️ |
| 該当する場合はワークロードをコンテナー化する | ✔️ | |
| エネルギー効率の高いハードウェアを使う | ✔️ | |
| スケーラビリティのニーズに合わせ、自動スケーリングとバースト機能を利用する | ✔️ | |
| 営業時間外にワークロードとノード プールをオフにする | ✔️ | ✔️ |
| 使用されていないリソースを削除する | ✔️ | ✔️ |
| リソースにタグを付ける | ✔️ | ✔️ |
| ストレージの使用率を最適化する | ✔️ | ✔️ |
| ユーザーに最も近いリージョンを選ぶ | ✔️ | |
| ノード間のネットワーク トラバーサルを減らす | ✔️ | |
| サービス メッシュを使って評価する | ✔️ | |
| ログ収集を最適化する | ✔️ | ✔️ |
| 静的データをキャッシュする | ✔️ | ✔️ |
| TLS 終端を使うかどうかを評価する | ✔️ | ✔️ |
| クラウド ネイティブのネットワーク セキュリティ ツールとコントロールを使う | ✔️ | ✔️ |
| 脆弱性をスキャンする | ✔️ | ✔️ |
アプリケーションの設計
このセクションでは、より持続可能性の高いアプリケーション設計のためにアプリケーションを最適化する方法について詳しく説明します。
論理コンポーネントの独立したスケーリングを考慮して設計する
マイクロサービス アーキテクチャで、必要なコンピューティング リソースを削減できます。これは、論理コンポーネントを独立してスケーリング可能であり、確実に需要に応じてスケーリングされるからです。
- Dapr Framework や他の CNCF プロジェクトを使って、アプリケーションの機能を複数のマイクロサービスに分け、その論理コンポーネントを独立してスケーリングできるようにすることを検討してください。
イベントドリブン スケーリングを考慮して設計する
HTTP 要求、キューの長さ、クラウド イベントなどの関連するビジネス メトリックに基づいてワークロードをスケーリングすると、リソース使用率と炭素排出量を削減できます。
- イベントドリブン アプリケーションを構築するときには Keda を使って、需要がないときにゼロになるようにスケールダウンしてください。
ステートレス設計を目指す
設計から状態を取り除くことで、ワークロードが機能するために必要なメモリ内またはディスク上のデータを減らすことができます。
- 不要なネットワーク負荷、データ処理、コンピューティング リソースを削減するために、ステートレス設計を検討してください。
アプリケーション プラットフォーム
このセクションでは、より適切な情報に基づいて、持続可能性を中心としたプラットフォーム関連の意思決定を下す方法について説明します。
クラスターとノードの自動更新を有効にする
最新のクラスターを使うことで、不要なパフォーマンスの問題を回避し、最新のパフォーマンス向上とコンピューティングの最適化の恩恵を受けることができます。
- クラスターの自動アップグレードを有効にし、GitHub Actions を使ってノードにセキュリティ更新プログラムを自動的に適用することで、クラスターに最新の改善を適用することができます。
サポートされているアドオンと拡張機能をインストールする
AKS サポート ポリシーの対象となるアドオンと拡張機能により、さらにサポートされる機能をクラスターに提供できます。さらに、クラスターのライフサイクルを通じて最新のパフォーマンス向上とエネルギーの最適化の恩恵を受けることができます。
- アドオンとして KEDA をインストールします。
- 拡張機能として GitOps & Dapr をインストールします。
該当する場合はワークロードをコンテナー化する
コンテナーを使うと、不必要なリソース割り当てを減らし、デプロイされたリソースをより有効に利用できます。これはビン パッキングが可能になり、仮想マシンよりも少ないコンピューティング リソースで済むからです。
- アプリケーションのコンテナー化を簡略化するには、Draft を使って Dockerfile と Kubernetes マニフェストを生成してください。
エネルギー効率の高いハードウェアを使う
Ampere のクラウド ネイティブ プロセッサは、クラウドのハイ パフォーマンスと電力効率の両方のニーズを満たすように独自に設計されています。
- Ampere Altra Arm ベースのプロセッサを搭載したノードが、お使いのワークロードに適しているかどうかを評価してください。
スケーラビリティのニーズに合わせ、自動スケーリングとバースト機能を利用する
クラスターのサイズが大きすぎると、コンピューティング リソースを最大限に利用できず、エネルギーの浪費につながる可能性があります。 アプリケーションを複数のノード プールに分け、アプリケーションの要件に応じたクラスターの適切なサイズ変更と独立したスケーリングを可能にしてください。 AKS クラスターの容量が不足したら、AKS から ACI に拡張して追加のポッドをサーバーレス ノードにスケールアウトし、割り当てられたすべてのリソースをワークロードから効率的に使用できるようにします。
- アプリケーションのスケーラビリティ ニーズに合わせてクラスターのサイズを設定します。 クラスターの自動スケーリング機能と仮想ノードを使い、迅速にスケーリングしてコンピューティング リソースの使用率を最大化します。
- 名前空間レベルでリソース クォータを適用し、需要がないときはユーザー ノード プールを 0 にスケーリングすることもできます。
営業時間外にワークロードとノード プールをオフにする
ワークロードは継続的に実行する必要がない場合があり、エネルギー浪費と炭素排出量を削減するためにオフにすることができます。 AKS クラスター内のノード プールを完全にオフにする (停止する) ことができます。これにより、コンピューティング コストも節約できます。
- ノード プールの停止/開始を使用して、営業時間外にノード プールをオフにします。
- KEDA CRON スケーラーを使用して、時間に応じてワークロード (ポッド) をスケールダウンします。
操作手順
このセクションでは、ワークロードのコストと炭素効率を測定し、継続的に改善するための環境を設定する方法について説明します。
使用されていないリソースを削除する
参照されない画像やストレージ リソースなどの使用されていないリソースは、ハードウェアとエネルギー効率に直接影響があるため、特定して削除する必要があります。 継続的なエネルギーの最適化を確保するために、使用されていないリソースの特定と削除は、ポイントインタイム アクティビティではなく、プロセスとして扱う必要があります。
- Azure Advisor を使用して、使用されていないリソースを特定します。
- ImageCleaner を使用して古いイメージをクリーンアップし、クラスターのリスク領域を削除します。
リソースにタグを付ける
適切なタイミングで適切な情報と分析情報を得ることは、パフォーマンスとリソース使用率に関するレポートを作成する上で重要です。
- クラスターに Azure タグを設定して、ワークロードの監視を有効にします。
ストレージ
このセクションでは、より持続可能性が高いデータ ストレージ アーキテクチャを設計し、既存のデプロイを最適化する方法について説明します。
ストレージの使用率を最適化する
データ取得とデータ格納の操作は、エネルギー効率とハードウェア効率の両方に大きな影響を及ぼす可能性があります。 適切なデータ アクセス パターンのソリューションを設計することで、エネルギー消費量と内包炭素量を削減できます。
- アプリケーションのニーズを理解して、適切なストレージを選び、ストレージ クラスを使って定義することで、低いストレージ使用率を防ぎます。
- ボリュームを動的にプロビジョニングし、ストレージ リソース数を自動的にスケーリングすることも検討してください。
ネットワークと接続性
このセクションでは、ネットワーク効率を高めて最適化し、不要な炭素排出量を削減する方法について説明します。
ユーザーに最も近いリージョンを選ぶ
データ センターからユーザーまでの距離は、エネルギー消費量と炭素排出量に大きな影響があります。 ネットワーク パケットの移動距離を短くすることで、エネルギー効率と炭素排出量の両方を改善できます。
- アプリケーションの要件と Azure 地域を見直して、大部分のネットワーク パケットの送信先に最も近いリージョンを選んでください。
ノード間のネットワーク トラバーサルを減らす
ノードを 1 つのリージョンまたは 1 つの可用性ゾーンに配置することで、インスタンス間の物理的な距離を短くすることができます。 ただし、ビジネス クリティカルなワークロードの場合は、クラスターを複数の可用性ゾーンに分散する必要があり、その結果、ネットワーク トラバーサルが増え、炭素排出量が増加する可能性があります。
- 近接配置グループ内にノードをデプロイしてコンピューティング リソースを物理的に近づけることで、ネットワーク トラバースを減らすことを検討してください。
- 重要なワークロードの場合は、可用性ゾーンを使って近接配置グループを構成してください。
サービス メッシュを使って評価する
サービス メッシュにより、通常はサイドカー パターンで、追加のコンテナーを通信用にデプロイすることで、より多くの運用機能を提供できます。これは、CPU 使用量とネットワーク トラフィックの増加につながります。 ただし、アプリケーションをこれらの機能から切り離し、アプリケーション レイヤーからインフラストラクチャ レイヤーに移動することができます。
- 使用を決定する前に、サービス メッシュ通信コンポーネントによって発生する CPU 使用量とネットワーク トラフィックの増加を十分に検討してください。
ログ収集を最適化する
考えられるすべてのソース (ワークロード、サービス、診断、プラットフォーム アクティビティ) からのすべてのログを送信し、格納すると、ストレージとネットワーク トラフィックが増加する可能性があり、これはコストと炭素排出量に影響します。
- 要件をサポートするために必要なログ データのみを収集し、保持するようにしてください。 AKS ワークロードのデータ収集規則を構成し、Log Analytics のコストを最適化するための設計上の考慮事項を実装します。
静的データをキャッシュする
コンテンツ配信ネットワーク (CDN) を使うと、ネットワーク全体のデータ移動を減らすことができるため、ネットワーク トラフィックを最適化する持続可能なアプローチです。 頻繁に読み込まれる静的データをユーザーの近くに格納することで、待機時間を最小限に抑え、ネットワーク トラフィックとサーバーの負荷を軽減できます。
- 必ず CDN のベスト プラクティスに従ってください。
- 使う帯域幅を減らし、コストを抑えるために Azure CDN の使用を検討してください。
セキュリティ
このセクションでは、持続可能で適切なサイズのセキュリティ体制につながる推奨事項について詳しく説明します。
TLS 終端を使うかどうかを評価する
トランスポート層セキュリティ (TLS) により、Web サーバーと Web ブラウザー間で渡されるすべてのデータがプライベートで暗号化されたままになります。 ただし、TLS の終端と再確立は CPU 使用率を高め、特定のアーキテクチャでは不要な場合があります。 バランスのとれたセキュリティ レベルにより、持続可能性が高くエネルギー効率の高いワークロードを実現できますが、高いセキュリティ レベルにより、コンピューティング リソースの要件が増える可能性があります。
- Application Gateway または Azure Front Door を使う場合は、TLS 終端に関する情報を確認してください。 境界ゲートウェイで TLS を終端し、ワークロードのロード バランサーとワークロードまでは非 TLS で進むことができるかどうかを判断します。
クラウド ネイティブのネットワーク セキュリティ ツールとコントロールを使う
Azure Font Door と Application Gateway は、Web アプリケーションからのトラフィックの管理に役立ちます。一方、Azure Web Application Firewall により、ネットワーク エッジでの OWASP の上位 10 個の攻撃と部分的送電停止につながる不適切なボットからの保護を実現できます。 これらの機能は、不要なデータ転送を排除し、帯域幅とインフラストラクチャの要件を抑えて、クラウド インフラストラクチャの負担を軽減する場合に役立ちます。
- AKS の Application Gateway Ingress Controller (AGIC) を使って、ネットワーク エッジでトラフィックをフィルター処理して配信元に到達しないようにオフロードし、エネルギー消費と炭素排出量を削減します。
脆弱性をスキャンする
クラウド インフラストラクチャに対する多くの攻撃は、デプロイされたリソースを悪用して攻撃者が直接利益を得ることを目的としており、使用量とコストが不必要な急増につながります。 脆弱性スキャン ツールを使うと、攻撃者の機会を最小限に抑え、リソースの悪用の可能性を軽減するのに役立ちます。
- Microsoft Defender for Cloud の推奨事項に従います。
- Defender for Containers などの自動脆弱性スキャン ツールを実行して、不必要なリソース使用を回避します。 これらのツールは、イメージの脆弱性を特定し、攻撃者の後期となる期間を最小限に抑えるのに役立ちます。