適切なサイズの Windows ワークロード

概要

適切なサイジングは、最も強力なコスト削減ツールの 1 つです。 は、AWS 最適化とライセンス評価 (AWS OLA） を使用して潜在的なワークロードを確認することから、 を使用して既存のワークロードを確認することまで、適切なサイジング情報を収集するためのさまざまな方法 AWS を提供しますAWS Cost Explorer。

このセクションでは、 AWS Compute Optimizerを使用して Amazon EC2の適切なサイジングの機会を特定する方法について説明します。Compute Optimizer は、次のタイプの AWS リソースの過剰プロビジョニングと過少プロビジョニングを防ぐのに役立ちます。

• Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプ

• Amazon Elastic Block Store (Amazon EBS) ボリューム

• 上の Amazon Elastic Container Service (Amazon ECS) サービス AWS Fargate

• AWS Lambda Amazon CloudWatch が提供する使用率データに基づく 関数

コスト最適化シナリオ

適切なサイジングの効果を測定するのは難しい場合があります。これは、適切なサイジングの取り組みを特定のアプリケーション、チーム、または組織全体に向けることができるためです。例えば、数千のインスタンスを に移行し AWS、フリートの 90% が Windows ワークロードで構成される組織を考えてみましょう。組織は Compute Optimizer を使用してフリートを分析し、アカウントと 全体で大幅なオーバープロビジョニングを検出できます AWS リージョン。その後、AWS Systems Manager オートメーションを使用して、複数のメンテナンスウィンドウを通じてフリートのサイズを適正化できます。その結果、組織はフリートの 70% で適切なサイズのインスタンスタイプを調整し、35% のコスト削減を達成しています。

次のダッシュボードは、この例の組織が Compute Optimizer の適切なサイジング推奨事項を戦略的に実装したため、数か月にわたって達成された削減を示しています。その目的は、契約の終了に近づいているコロケーションデータセンターからの停止した移行を再開するために、既存のワークロードをできるだけ効率的に運用することでした。

コスト最適化に関する推奨事項

Compute Optimizer を使用してコストを最適化するには、次のステップを実行することをお勧めします。

• Compute Optimizer を有効にする

• Windows ノードのメモリメトリクス収集を有効にする

• Compute Optimizer のレコメンデーションを使用する

• 適切なサイジングのためのインスタンスのタグ付け

• コスト配分タグが AWS 請求ツールと連携できるようにする

• Automation を使用して適切なサイジングのレコメンデーションを実装 AWS Systems Manager する

• 代替のサイズ変更方法を検討する

• Cost Explorer でコストの前後に確認する

Compute Optimizer を有効にする

Compute Optimizer は、組織または の単一アカウントレベルで有効にできます AWS Organizations。組織全体の設定では、すべてのメンバーアカウントのフリート全体で、新規および既存のインスタンスの継続的なレポートが提供されます。これにより、適切なサイズをアクティビティではなく繰り返しの point-in-timeアクティビティにすることができます。

組織レベル

ほとんどの組織にとって、Compute Optimizer を使用する最も効率的な方法は組織レベルです。これにより、マルチアカウントとマルチリージョンが組織を可視化し、レビューのためにデータを 1 つのソースに一元化できます。これを組織レベルで有効にするには、以下を実行します。

1. 必要なアクセス許可を持つロールを使用して Organizations 管理アカウントにサインインし、この組織内のすべてのアカウントをオプトインすることを選択します。組織で、すべての機能が有効になっている必要があります。

2. 管理アカウントを有効にすると、アカウントにサインインし、他のすべてのメンバーアカウントを表示し、そのレコメンデーションを参照できます。

注記

Compute Optimizer の委任管理者アカウントを設定するのがベストプラクティスです。これにより、最小特権の原則を行使できます。これにより、組織全体のサービスへのアクセスを提供しながら、組織の管理アカウントへのアクセスを最小限に抑えることができます。

単一アカウントレベル

コストの高いアカウントをターゲットにしているが、 にアクセスできない場合は AWS Organizations、そのアカウントとリージョンの Compute Optimizer を有効にできます。オプトインプロセスの詳細については、「Compute Optimizer ドキュメント」の「 の開始方法 AWS Compute Optimizer」を参照してください。

Windows ノードのメモリメトリクス収集を有効にする

メモリメトリクスは、Compute Optimizer に、組織内で十分な情報に基づいた適切なサイジングのレコメンデーションを行うために必要な必須メトリクスを提供します。これは、レコメンデーションを提供する前に CPU、メモリ、ネットワーク、ストレージの分析が行われているためです。

Windows EC2インスタンスから Compute Optimizer にメモリメトリクスを渡すには、 CloudWatch エージェントを有効にし、60 秒ごとにメモリメトリクスを収集するように設定する必要があります。でメモリメトリクスを使用する場合、追加料金は発生しません CloudWatch。

CloudWatch エージェントを有効にし、メモリメトリクスを設定する

ComputeOptimize.yml ファイルをダウンロードします。このファイルを使用して、アカウント内のすべてのインスタンスのメモリ収集を有効にできます。テンプレートファイルは、次のコンポーネントを生成します。

• AWS Systems Manager パラメータストア – メモリメトリクスの収集に必要な CloudWatch エージェントの設定を保存します。

• AWS Identity and Access Management （IAM) の AWS マネージドポリシー AWS Systems Managerがアタッチされたロール – これは Systems Manager Automation ドキュメント用です。

• AWS Systems Manager ドキュメント – エージェントをインストールして設定します CloudWatch (既存の CloudWatch 設定を置き換えます）。

• AWS Systems Manager ステートマネージャーの関連付け – これにより、Systems Manager ドキュメントをアカウント内のすべてのインスタンスで実行できます。

重要

このテンプレートを実行すると、インスタンス上の既存の CloudWatch 設定が上書きされます。

次に、以下の手順を実行します。

1. にサインイン AWS Management Console し、CloudFormation コンソール を開きます。

2. ナビゲーションペインで、[Stacks] を選択します。

3. [スタックの作成] を選択し、[既存のリソースを使用 (リソースのインポート)] を選択します。

4. [Next (次へ)] を選択します。

5. テンプレートリソース で、テンプレートファイルのアップロード を選択します。

6. ファイル を選択し、ComputeOptimize.ymlファイルをアップロードします。

7. [Next (次へ)] を選択します。

8. スタックの詳細を指定ページで、スタック名 にスタックの名前を入力し、次へ を選択します。

9. リソースの特定ページで、インポートするリソースの識別子値を入力します。

10. リソースのインポート を選択します。

11. スタックがデプロイされたら、Outputs タブを選択して、関連付けのキー、値、説明を見つけます。

関連付けの進行状況をモニタリングする

1. CloudFormation スタックのデプロイが完了したら、Systems Manager コンソール を開きます。

2. ナビゲーションペインのノード管理セクションで、ステートマネージャー を選択します。

3. 関連付けページで、関連付けの関連付け ID を選択します。

4. [Execution history (実行履歴の表示)] タブを選択します。

5. 実行 ID 列で、関連付けの実行 ID を選択します。ステータスは成功 である必要があります。

でメトリクスを表示する CloudWatch

メトリクスが に入力されるまで、少なくとも 5 分間待つことをお勧めします CloudWatch。

1. CloudWatch コンソール を開きます。

2. ナビゲーションペインで、メトリクスセクションを展開し、すべてのメトリクス を選択します。

3. メトリクスがCWAgent名前空間の下に表示されることを確認します。

注記

新しいインスタンスに設定を適用するには、関連付けを再実行します。

Compute Optimizer の推奨事項を使用する

1 つのアカウントと 1 つのリージョン内で適切なサイズ変更を行うことに焦点を当てた例を考えてみましょう。この例では、Compute Optimizer はすべてのアカウントで組織レベルで有効になっています。適切なサイジングは破壊的なプロセスであり、ほとんどの場合、数週間にわたるスケジュールされたメンテナンス期間中にアプリケーション所有者によって正確に実行されます。

組織の管理アカウント内から Compute Optimizer に移動した場合 (次のステップに示すように）、調査するアカウントを選択できます。この例では、us-east-1リージョン内の 1 つのアカウントで 6 つのインスタンスが実行されています。6 つのインスタンスすべてがオーバープロビジョニングされています。目標は、Compute Optimizer からの推奨事項に基づいてインスタンスのサイズを変更することです。

過剰にプロビジョニングされたインスタンスを特定し、レコメンデーションの詳細をエクスポートする

1. にサインイン AWS Management Console し、Compute Optimizer コンソール を開きます。

2. ナビゲーションペインで、ダッシュボードを選択します。

3. ダッシュボードページの検索ボックスに、リージョン=米国東部 (バージニア北部） と入力します。次に、Findings=Over-provisioned と入力します。これらのフィルターを使用すると、us-east-1リージョン内のすべてのオーバープロビジョニングされたインスタンスを表示できます。

4. オーバープロビジョニングされた EC2インスタンスの詳細なレコメンデーションを確認するには、EC2インスタンスカードまで スクロールダウンし、レコメンデーションの表示 を選択します。

5. エクスポートを選択し、後で使用するためにファイルを保存します。

6. S3 バケット には、エクスポートファイルの送信先とする Amazon S3 バケットの名前を入力します。

   注記

   今後のレビューのためにレコメンデーションを保存するには、Compute Optimizer が各リージョンで に書き込むことができる S3 バケットが必要です。詳細については、Compute Optimizer ドキュメントの「 の Amazon S3 バケットポリシー AWS Compute Optimizer」を参照してください。

7. フィルターのエクスポートセクションで、組織内のすべてのメンバーアカウントのレコメンデーションを含めるチェックボックスをオンにします。

8. リソースタイプ では、EC2インスタンス を選択します。

9. 含める列セクションで、すべて選択チェックボックスをオンにします。

10. [エクスポート] をクリックします。

レコメンデーションに基づいてインスタンスを選択する

インスタンスのレコメンデーションは、Compute Optimizer によって収集および分析されるパフォーマンスメトリクスに基づいています。最適なインスタンスを選択するには、インスタンスで実行されているワークロードに注意することが重要です。この例では、最新世代の Amazon EC2 R6iR5、T3 インスタンスから選択できることを前提としています。T3 インスタンスはバースト可能で、ネットワーク帯域幅機能も低くなります。R5 インスタンスと R6 インスタンスのコストは 1 時間あたり同じで、ほぼ同じです。ただし、R6 インスタンスはネットワーク帯域幅容量が大きく、最新世代の Intel プロセッサーを搭載し、R5 と同じコンピューティングフットプリントを提供します。この例では、R6 はサイズ変更に最適なオプションです。

1. Compute Optimizer コンソール で、ナビゲーションバーからEC2インスタンスのレコメンデーションを選択します。このページでは、現在のインスタンスタイプを置き換える推奨オプションと比較します。

2. 適切なサイズのインスタンスの ID を取得するには、 の管理アカウントから Amazon S3 コンソールを開きます AWS Organizations。

3. ナビゲーションペインでバケット を選択し、エクスポートした結果の保存に使用するバケットを選択します。

4. オブジェクトタブで、オブジェクトリストからエクスポートファイルを選択し、ダウンロード を選択します。

5. ファイルからインスタンス情報を抽出するには、Microsoft Excel のデータタブの Text to Columns ボタンを使用します。

   注記

   インスタンスIDsは Amazon リソースネーム () として表されますARNs。必ず区切り文字を「/」に設定し、インスタンス ID を抽出します。または、スクリプトを記述するか、統合開発環境 (IDE) を使用して をトリミングすることもできますARN。

6. Excel では、検出結果列をフィルタリングして OVER_PROVISIONED インスタンスのみを表示します。これらは、適切なサイジングをターゲットにしているインスタンスです。

7. 後で簡単にアクセスできるように、インスタンスをテキストエディタIDsに保存します。

適切なサイジングのためのインスタンスのタグ付け

ワークロードのタグ付けは、 でリソースを整理するための強力なツールです AWS。タグを使用すると、コストをきめ細かく可視化し、チャージバックを容易にできます。 AWS リソースにタグを追加するための戦略と方法の詳細については、「リソースのタグ付けに関する AWS ホワイトペーパーのベストプラクティス」を参照してください。 AWSこの例では、AWS タグエディタを使用して、メンテナンスウィンドウ中にサイズ変更の対象となるオーバープロビジョニングされたインスタンス全体でタグ付けを調整することができます。このタグを使用して、変更前後のコストを表示することもできます。

1. にサインイン AWS Management Console し、サイズ変更対象のインスタンスを含むアカウントのAWS Resource Groups コンソールを開きます。

2. ナビゲーションバーのタグ付けセクションで、タグエディタ を選択します。

3. リージョン では、ターゲットリージョンを選択します。

4. リソースタイプ では、 を選択します AWS::EC2::Instance。

5. [リソースを検索] を選択します。

6. リソース検索結果ページで、適切なサイズにするすべてのインスタンスを選択し、選択したリソースのタグの管理 を選択します。

7. [タグを追加] を選択します。

8. タグキー には、「ライツサイジング」と入力します。タグ値 には、有効な を入力します。次に、「レビュー」を選択し、タグの変更を適用します。

   注記

   チームやビジネスユニットなどの追加のメタデータを含めると、後で Cost Explorer の でフィルタリングできます。

ユーザー定義タグを作成してリソースに適用した後、アクティベーションのためにタグがコスト配分タグページに表示されるまでに最大 24 時間かかる場合があります。アクティベーションにタグを選択すると、タグがアクティブになるまでにさらに 24 時間かかる場合があります。

上級ユーザーの場合、ターゲットアカウントとリージョンAWS CloudShell内で を使用して、複数のインスタンスにタグ付けできます。例:

bash
#!/bin/bash
# Set variables
TAG_KEY="rightsizing"
TAG_VALUE="type-m5"
# Get a list of instance IDs
INSTANCE_IDS=$(aws ec2 describe-instances —query "Reservations[].Instances[].InstanceId" —output text)
# Loop through each instance ID and add the tag
for INSTANCE_ID in $INSTANCE_IDS; do
 aws ec2 create-tags —resources $INSTANCE_ID —tags Key=$TAG_KEY,Value=$TAG_VALUE
done

AWS 請求ツールを操作するためのコスト配分タグを有効にする

ユーザー定義のコスト配分タグをアクティブ化することをお勧めします。これにより、 AWS 請求ツール (Cost Explorer や など) で Rightsizing タグを認識してフィルタリングできるようになります AWS Cost and Usage Report。これを有効にしないと、タグフィルタリングオプションとデータは使用できなくなります。コスト配分タグの使用については、ドキュメントの AWS Billing and Cost Management 「ユーザー定義のコスト配分タグの有効化」を参照してください。

1. にサインイン AWS Management Console し、AWS Billing コンソール を開きます。

2. ナビゲーションペインの請求セクションで、コスト配分タグ を選択します。

3. ユーザー定義のコスト配分タグタブで、「ライツサイジング」と入力します。

4. Rightsizing タグキーを選択し、「 のアクティブ化」を選択します。

24 時間後、 タグは Cost Explorer に表示されます。

Systems Manager Automation を使用して適切なサイジングのレコメンデーションを実装する

サイズ変更は、インスタンスを停止して開始する必要があるシナリオです。このシナリオでは、この中断をメンテナンスウィンドウで処理する必要があり、独自のサイズ変更を処理するために異なるチームが必要になる場合があります。インスタンスタイプを変更する前に、Amazon EC2ドキュメントの互換性のあるインスタンスタイプの考慮事項を確認してください。

このセクションのステップ例では、 AWS-ResizeInstance という Systems Manager Automation ドキュメントを使用して、アカウントとリージョンごとに適切なサイジングのレコメンデーションを実装します。このアプローチは、ほとんどの組織で一般的です。ほとんどの組織では、目的に応じて異なるインスタンスタイプが必要です。また、同じAWS-ResizeInstanceオートメーションドキュメントを使用して、単一アカウントとマルチアカウントのデプロイをターゲットにすることもできます。

1. にサインイン AWS Management Console し、Systems Manager コンソール を開きます。

2. ナビゲーションペインの共有リソースセクションで、ドキュメント を選択します。

3. 検索バーに AWS-ResizeInstance と入力し、検索結果から AWS-ResizeInstance を選択します。

4. [オートメーションを実行] を選択します。

5. オートメーションランブックの実行ページで、シンプル実行 を選択します。

6. 入力パラメータ セクションで、 InstanceIdと を入力しますInstanceType。残りのデフォルト値は保持します。

7. 実行 を選択し、オートメーションがインスタンスタイプを変更するステップを経るのを 待ちます。

代替のサイズ変更方法を検討する

起動テンプレートを使用してインスタンスをデプロイする場合は、起動テンプレートを適切なサイズのインスタンスタイプで更新し、インスタンスの更新を実行してインスタンスを適切なサイズのバージョンに置き換えることができます。

複数のアカウントとリージョンで適切なサイジングプロセスを使用する場合は、カスタム Systems Manager Automation ドキュメントを作成する必要があります。このドキュメントでは、複数のインスタンスをパラメータとしてフィードし、ターゲットインスタンスを同じ送信先インスタンスタイプに移動できます (例えば、ソースインスタンスタイプに関係なく、t3a.medium に移行するすべてのインスタンス）。

Cost Explorer でコストの前後に確認する

リソースのサイズが適切になったら、Cost Explorer を使用して、Rightizing タグを使用してコストの前後に表示することができます。リソースタグを使用してコストを追跡できることを思い出してください。複数のタグレイヤーを使用することで、コストをきめ細かく可視化できます。このガイドで説明している例では、ライツサイジングタグを使用して、汎用タグをすべてのターゲットインスタンスに適用します。次に、チームタグを使用してリソースをさらに整理します。次のステップでは、アプリケーションタグを導入して、特定のアプリケーションを運用する際のコストへの影響をさらに示します。

次の図は、組織のタグ構造を示しています。

オペレーションチームが所有している本番稼働用ウェブサーバーのサイズを適切に調整するビジネスの例を考えてみましょう。Cost Explorer では、Rightizing タグは有効な に設定され、チームタグはオペレーション に設定されます。この例では、適切なサイジングにより、運用コストが 1 時間あたり 0.89 セントから 0.28 セントに削減されます。1 か月あたり 744 時間と仮定すると、適切なサイジング前の年間コストは 7,945.92 USD です。適切なサイズ変更後、年間コストは 2,499.84 ドルに低下します。これにより、年間ワークロードコストが 68.5% 削減されます。これを大規模な組織全体に与えた影響を想像してください。これはサンプル環境で行われ、インスタンスはほぼアイドル状態であることに注意してください。本稼働環境では、10～35% の節約が可能です。

次に、エンジニアリングチームが所有する本番用踏み台ホストのサイズを適切に調整することの影響について考えてみましょう。Cost Explorer では、Rightizing タグは有効 に設定され、チームタグはエンジニアリング に設定されます。この例では、適切なサイジングにより、コストが 1 時間あたり 0.75 セントから 0.44 セントに削減されます。1 か月あたり 744 時間と仮定すると、適切なサイジング前の年間コストは 6,696.00 USD です。適切なサイズ変更後、年間コストは 3,928.32 ドルに低下します。

複数のタグを使用する場合は、データを詳細なコスト詳細に絞り込むことができます。この例では、チームタグはノイズを減らし、チームレベルで影響を表示できます。Rightsizing タグが有効になっているため、そのタグを持つインスタンスを の値が有効であるか、値が存在しない場合にフィルタリングすることもできます。これにより、特に Cost Explorer レベルで管理アカウント (支払い者) で表示する場合に、適切なサイジングの取り組みをグローバルに表示できます。このビューでは、すべてのアカウントとインスタンスを表示できます。

単一のアカウントレベルで、Rightizing タグが有効な に設定されている例を考えてみましょう。  運用コストは 1 時間あたり 1.64 USD から 1 時間あたり 0.72 USD に低下します。1 か月あたり 744 時間と仮定すると、適切なサイジング前の年間コストは 14,641.92 USD です。適切なサイズ変更後、年間コストは 6,428.16 ドルに低下します。これにより、このアカウントのコンピューティングコストが 56% 削減されます。

適切なサイジングジャーニーを開始する前に、次の点を考慮してください。

• AWS には、コスト削減のための多くのオプションがあります。これにはAWS 、 OLAが含まれます。 は、 に移行する前にオンプレミスインスタンス AWS を確認します AWS。には、適切なサイズに関する推奨事項とライセンスガイダンス AWS OLAも用意されています。

• Savings Plans を購入する前に、適切なサイズをすべて完了してください。これにより、Savings Plans コミットメントで を超える購入を回避できます。

レコメンデーション

次のステップを実行することをお勧めします。

1. 既存のランドスケープを確認し、Amazon gp2 EBS ボリュームを gp3 ボリュームに変換することを検討してください。

2. Savings Plansを確認します。

追加リソース

• AWS Compute Optimizer (AWS ドキュメント）

• AWS リソースのタグ付けのベストプラクティス (AWS ホワイトペーパー）

• () AWS Compute OptimizerAWS Trusted Advisor との間でデータを収集する方法 AWS Organizations YouTube

• パフォーマンスの最適化とライセンスコストの削減: Amazon EC2 SQL Server インスタンス AWS Compute Optimizer の活用 ( AWS ブログの Microsoft Workloads)