Amazon Web Services ブログ
持続可能な AWS インフラストラクチャの最適化、第一部:コンピュート編
このブログは Katja Philipp, Aleena Yunus, Otis Antoniou と Ceren Tahtasiz によって執筆された内容を日本語化したものです。原文はこちらを参照して下さい。
組織がビジネスを持続可能な方向に導くには、あらゆる機能領域を見直すことが重要です。IT スタックを構築、展開、保守している場合、その環境への影響を改善するには、情報に基づいた判断が必要です。
この 3 回のブログシリーズでは、コンピュート、ストレージ、ネットワーキングにおける AWS アーキテクチャを最適化するための戦略をご紹介します。
第一部では、AWS インフラストラクチャのコンピュートレイヤーを持続可能性のために調整する方法について、IT エグゼクティブには成功基準とメトリクスを提供し、アーキテクト/デベロッパーには実践的なガイドを提供します。この目標を達成するために、主要なメトリクスを提供し、よく使われるサービスやツールを紹介し、Amazon CloudWatch で分析するためのインサイトを用意し、それらを改善するためのステップを説明します。
持続可能な活動への取り組み
AWS では、可能な限り環境に優しい方法で事業を運営することをお約束します。また、お客様がクラウドのメリットを利用して、IT インフラストラクチャをよりよく監視し、最適化できるように努めています。The Carbon Reduction Opportunity of Moving to Amazon Web Services で報告されているように、私たちのインフラストラクチャは、米国の企業データセンターの中央値よりも 3.6 倍エネルギー効率性が高く、AWS に移行すると、同じタスクでワークロードの二酸化炭素排出量を 88% 削減することができます。
とはいえ、持続可能性は AWS とお客様の間で共有される責任です。図 1 に示すように、私たちはクラウドの持続可能性を追求し、お客様はクラウド上での持続可能性、つまりワークロードとリソース使用を最適化することに責任を持ちます。
ワークロードが消費するエネルギー量を減らすには、リソースを効率的に使用する必要があります。AWS Global Infrastructure の VP である Peter DeSantis が言っているように、「最も環境に優しいエネルギーは、私たちが使わないエネルギーである」ということです。しかし、使わなければならないときには、できるだけ少ないリソースを使い、それを最大限に活用することが、環境への影響を最も小さくすることにつながります。これをアーキテクチャの決定に反映させると、アーキテクチャが効率的であればあるほど、より持続可能なものとなります。
我々は、すべての AWS アーキテクチャは異なっており、あらゆる場合に通用する単一のソリューションが存在しないことを認識しています。したがって、提案されたソリューションがお客様の特定の要件に適合しているかどうかを最初に判断する必要があることをご理解ください。
AWS インフラストラクチャのコンピュート層の最適化
コンピュートサービスは、多くのお客様のワークロードの基盤となっており、そのため最適化の余地が大きいものとなっています。ハ-ドウェアのエネルギー比例(消費電力と使用率の比率)を見ると、The Case for Energy-Proportional Computing にあるように、アイドル状態のサーバーは相変わらず電力を消費しています。したがって、最も少ない計算リソースを使用し、高い使用率を達成することで、ワークロードの効率を向上させることができます。以下のセクションの推奨事項を実施することで、リソースをより効率的に使用し、コストを削減することができます。
アイドルリソースの削減と使用率の最大化
Energy-Proportional Computing: A New Definition では、コンピュートリソースを平均 70〜80%、最大化することが推奨されると報告しています。これはパフォーマンスが低下すると、エネルギー効率が急激に低下するためです。次の表は、最も広く使われているコンピュートサービス、それらが測定するメトリクス、および関連するユーザーガイドを示します。
サービス | メトリック | 参照 |
---|---|---|
Amazon Elastic Compute Cloud (Amazon EC2) | CPU 使用率 | インスタンスで利用可能な CloudWatch メトリクスのリスト |
総 vCPU 数 | CloudWatch でメトリクスを監視 | |
Amazon Elastic Container Service (Amazon ECS) | CPU 使用率 | 使用可能なメトリクスとディメンション |
Amazon EMR | IsIdle | CloudWatch でメトリクスを監視 |
これらのメトリクスは、図 2 に示したアーキテクチャで監視することができます。CloudWatch は、リソース・メトリクスの統合されたビューを提供します。
AWS のコストと使用状況レポートがあれば、リソースの使用状況を把握することができます。図 3 の AWS Usage Queries は、AWS Cloud Development Kit (AWS CDK) テンプレートを提供し、AWS のコストと使用状況レポートの作成、保存、クエリ、可視化を実現したサンプルソリューションです。
アイドル状態のリソースを減らし、使用率を最大化するために、以下のサービスやツールを推奨しています:
- Amazon EC2 Auto Scaling を設定しましょう。Amazon EC2 Auto Scaling を設定することで、ワークロードが需要に応じて自動的にスケールアップ/ダウンするようになります。
- 平均 CPU 使用率や平均ネットワーク入出力などの指標に基づき、スケジュールまたは動的なスケーリングポリシーを設定できます。
- AWS Instance Scheduler と Amazon EC2 Auto Scaling のスケジュールスケーリングを連携させ、営業時間内や平日のみ稼働するリソースのシャットダウンや終了をスケジュール化できます。
- AWS Cost Explorer と AWS Graviton2 でリソースを適切なサイズにしましょう。インスタンスタイプを決定する際、ワークロードの要件を考慮する必要があります。
- ワークロードが予測不可能なスパイクを何度も起こす場合は、バースト可能な性能を持つ T インスタンスの使用を検討してみましょう。これにより、キャパシティを過剰にプロビジョニングすることが少なくなります。
- AWS Cost Explorer を使用して、ワークロードに対する適切なサイズ設定の推奨事項を確認しましょう。可能な限りインスタンスをダウンサイジングすることにより、コストを削減し、リソース効率を向上させることができることを示します。
- Graviton2 ベースのインスタンスに切り替えることで、コンピュートワークロードの電力効率を改善しましょう。Graviton2 は、当社の最も電力効率の高いプロセッサーです。AWS の他のどのプロセッサーよりも、ワットあたり 2〜3.5 倍優れた CPU 性能を発揮します。さらに、Graviton2 は、さまざまなワークロードに対して、同等の現行世代の x86 ベースのインスタンスよりも最大 40% 優れたコストパフォーマンスを提供します。
- サーバーレス、イベント駆動型アーキテクチャを採用しましょう。全体のリソース使用を最大化するために、サーバーレス、イベント駆動型アーキテクチャの採用を検討ください。サーバーレスアーキテクチャは、AWS のサービスによって抽象化されているため、物理サーバーを運用・維持する必要性がなくなります。サーバーレスアーキテクチャのコストは通常、使用量に相関するため、ワークロードのコスト効率は向上します。
- 非同期ワークロードの場合、イベント駆動型アーキテクチャを使用することで、コンピュートを必要なときだけ使用し、待機中のアイドル状態にはなりません。
既存の供給に需要を合わせる
自動スケーリングなどの手法で需要と供給を一致させるのとは対照的に、既存の供給に需要を合わせることができます。この戦略は、特定の操作を実行する正確な時間が重要ではない柔軟なワークロードに適しています。例えば、夜間に実行される定期的なタスクや、中断可能なワークロードなどが該当します。
既存の供給に需要を合わせるために、以下のサービスやツールを推奨しています:
- Amazon EC2 スポットインスタンス を使用しましょう。スポットインスタンスは、AWS クラウドの未使用の EC2 キャパシティを利用したものです。EC2 インスタンス容量の既存の供給量に需要を合わせることで、全体的なリソース効率を向上させ、アイドル状態の容量を削減することができます。
- スポットインスタンスはオンデマンドインスタンスと比較して、最大 90% のコスト削減が可能です。
- スポットインスランスは、中断可能な耐障害性、柔軟性、ステートレスのワークロードに使用すると良いでしょう。
- スケジュールされたタスクにジッターを適用しましょう。スケジュールされたタスクにジッターを適用し、時間に柔軟性のあるワークロードをシフトすることで、負荷スパイクを回避することができます。
- スケジュールされたタスクが、時間内にランダムに実行されるように分散できるかどうかを確認しましょう。
- スケジュールされたタスクの開始時間(分)として 0 を使用することは避けてください。これは、一般的なデフォルト値でありますが、スケジュールされたタスクの開始時間(分)として 0 を使用することは避け、2〜58 の数値を使用してください。
まとめ
このブログ記事では、リソース効率を高めるために AWS インフラストラクチャを最適化する際に必要となる主要な指標と推奨アクションについて説明しました。これによって、コンピュートリソースの持続可能性を向上させることができます。
ビジネスが成長するにつれて、「総 vCPU 時間」のようなメトリクスが上がるのは当然のことです。このため、100 ユーザーまたはトランザクションあたりの vCPU 数など、作業単位ごとにこれらのメトリクスを把握することが重要です。この方法なら、測った KPI はビジネスの成長から独立したものとなります。
本シリーズの次のパートでは、クラウドでの持続可能性を実現するために、IT インフラストラクチャのストレージ部分を最適化する方法を紹介します!
翻訳はネットアップ合同会社の方氏、監修はソリューションアーキテクトの豊原 任が担当しました。
詳細はこちら
本シリーズの他のブログ記事
- 持続可能な AWS インフラストラクチャの最適化、第二部:ストレージ編
- 持続可能な AWS インフラストラクチャの最適化、第三部:ネットワーキング編
- 持続可能な AWS インフラストラクチャの最適化、第四部:データベース編