Windows ワークロードに適したインスタンスタイプを選択する - AWS 規範ガイダンス
概要コスト最適化に関する推奨事項次のステップ追加リソース

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Windows ワークロードに適したインスタンスタイプを選択する

概要

オンプレミス環境と比較してクラウドで運用されているワークロードの大きな違いは、オーバープロビジョニングの手法です。オンプレミス用の物理ハードウェアを購入する場合、設備投資はあらかじめ決められた期間、通常は 3～5 年間継続することが予想されます。ハードウェアの存続期間中に予想される増加に対応するため、ハードウェアはワークロードが現在必要とするよりも多くのリソースで取得されます。そのため、物理ハードウェアは、実際のワークロードのニーズよりもはるかに過剰にプロビジョニングされることがよくあります。

仮想マシン (VM) テクノロジーは、余剰ハードウェアリソースを利用する効果的な手段として浮上しました。管理者は vCPUsと RAM を使用して VMs を過剰にプロビジョニングし、ハイパーバイザーが未使用のリソースを各 VM に割り当てることで、ビジーサーバーとアイドルサーバー間の物理リソースの使用状況を管理できるようにします。VMs を管理する場合、各 VM に割り当てられた vCPU および RAM リソースは、実際の使用状況の指標ではなく、リソースの輻輳として機能していました。VM リソースの過剰割り当ては、使用可能なコンピューティングリソースの 3 倍を簡単に超える可能性があります。

Amazon Elastic Compute Cloud (Amazon EC2) では、基盤となるハードウェアで VMs を過剰にプロビジョニングする必要はありません。クラウドコンピューティングは運用コストであり、設備投資ではなく、使用した分に対してのみお支払いいただきます。ワークロードに将来より多くのリソースが必要な場合は、事前に必要になるのではなく、実際に必要になったときにプロビジョニングしてください。

適切な Amazon EC2 インスタンスタイプ を選択するためのオプションは数百あります。Windows ワークロードをクラウドに移行する予定の場合、 は AWS OLA AWS を提供し、現在のワークロードをよりよく理解し、 でのパフォーマンスの例を提供します AWS。 AWS OLA 分析は、適切な EC2 インスタンスタイプとサイズを実際のオンプレミスの使用状況と一致させることを目的としています。

Amazon EC2 で実行されているワークロードがすでにあり、コスト最適化戦略を検討している場合、ガイドのこのセクションは、Amazon EC2 インスタンスと一般的な Windows ワークロードへの適用性の違いを特定するのに役立ちます。

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

EC2 インスタンスタイプのコストを最適化するには、以下を実行することをお勧めします。

  • ワークロードに適したインスタンスファミリーを選択する

  • プロセッサアーキテクチャ間の料金の変動を理解する

  • EC2 世代間の価格とパフォーマンスの違いを理解する

  • 新しいインスタンスに移行する

  • バーストインスタンスを使用する

ワークロードに適したインスタンスファミリーを選択する

ワークロードに適したインスタンスファミリーを選択することが重要です。

Amazon EC2 インスタンスは、次のさまざまなグループに分けられます。

  • 汎用

  • コンピューティングの最適化

  • メモリ最適化

  • 高速コンピューティング

  • ストレージの最適化

  • HPC 最適化

ほとんどの Windows ワークロードは、次のカテゴリに分類されます。

  • 汎用

  • コンピューティングの最適化

  • メモリ最適化

これをさらに簡素化するには、各カテゴリのベースライン EC2 インスタンスを検討してください。

  • コンピューティング最適化 – C6i

  • 汎用 – M6i

  • メモリ最適化 – R6i

前世代の EC2 インスタンスでは、プロセッサタイプにわずかな違いがありました。例えば、C5 コンピューティング最適化インスタンスは、M5 汎用インスタンスまたは R5 メモリ最適化インスタンスよりも高速なプロセッサを備えています。最新世代の EC2 インスタンス (C6i、M6i, R6i, C6a, M6a、R6a ) はすべて、インスタンスファミリー全体で同じプロセッサを使用します。プロセッサは最新世代のインスタンス間で一貫しているため、インスタンスファミリー間の価格差は RAM の量により大きくなりました。インスタンスの RAM が多いほど、コストも高くなります。

次の例は、 us-east-1リージョンで実行されている Intel ベースの 4 vCPU インスタンスの時間単位の料金を示しています。

インスタンス vCPUs RAM 時間料金
c6i.xlarge 4 8 0.17 USD
m6i.xlarge 4 16 0.19 USD
r6i.xlarge 4 32 0.25 USD
注記

料金は、 us-east-1リージョンのオンデマンド時間単位の料金に基づいています。

バーストインスタンス

クラウドコンピューティングでは、使用していないコンピューティングリソースをオフにして課金を回避するのがベストプラクティスですが、すべてのワークロードを必要なたびにオフにできるわけではありません。一部のワークロードは長期間アイドル状態のままですが、1 日 24 時間アクセス可能である必要があります。

バーストインスタンス (T3) は、コンピューティングコストを低く抑えながら、急増または使用率の低いワークロードを 1 日を通してオンラインに維持する方法を提供します。バースト可能な EC2 インスタンスには、インスタンスが短時間使用できる vCPU リソースの最大量があります。これらのインスタンスは、バースト CPU クレジット に基づくシステムを使用します。これらのクレジットは、1 日を通してアイドル期間中に蓄積されます。バースト可能なインスタンスは、vCPU と RAM の比率が異なるため、場合によってはコンピューティング最適化インスタンス、その他の汎用インスタンスの代わりに使用できます。

次の例は、 us-east-1リージョンで実行されている T3 インスタンス (バーストインスタンス) の時間単位の料金を示しています。

インスタンス vCPUs RAM (GB) 時間料金
t3.nano 2 0.5 0.0052 USD
t3.micro 2 1 0.0104 USD
t3.small 2 2 0.0208 USD
t3.medium 2 4 0.0416 USD
t3.large 2 8 0.0832 USD
t3.xlarge 4 16 0.1664 USD
t3.2xlarge 8 32 0.3328 USD
注記

料金は、 us-east-1リージョンのオンデマンド時間単位の料金に基づいています。

プロセッサアーキテクチャ間の料金の変動を理解する

インテルプロセッサは、EC2 インスタンスの設立当初から標準となっています。C5, M5 などの旧世代の EC2 インスタンスは、Intel をプロセッサアーキテクチャ (デフォルト) として示していません。 R5 C6i, M6i などの新世代の EC2 インスタンスには、インテルプロセッサの使用を示す「i」が含まれています。 R6i

プロセッサアーキテクチャの注釈の変更は、プロセッサオプションの追加導入によるものです。Intel と最も同等のプロセッサは AMD (「a」で表されます) です。AMD EPYC プロセッサは同じ x86 アーキテクチャを使用し、インテルプロセッサと同様のパフォーマンスを低価格で提供します。次の料金例に示すように、AMD EC2 インスタンスでは、Intel インスタンスと比較してコンピューティングコストが約 10% 削減されます。

インテルインスタンス 時間料金 AMD インスタンス 価格 % 差
c6i.xlarge 0.17 USD c6a.xlarge 0.153 USD 10%
m6i.xlarge 0.192 USD m6a.xlarge 0.1728 USD 10%
r6i.xlarge 0.252 USD r6a.xlarge 0.2268 USD 10%
注記

料金は、 us-east-1リージョンのオンデマンド時間単位の料金に基づいています。

3 番目の主要なプロセッサアーキテクチャオプションは、EC2 インスタンスの AWS Graviton プロセッサ (「g」で示されます) です。によって設計された Graviton プロセッサは AWS、Amazon EC2 で最高の価格パフォーマンスを提供します。現在の Graviton プロセッサは、Intel プロセッサよりも 20% 安価であるだけでなく、20% 以上のパフォーマンスの向上も実現します。次世代の Graviton プロセッサは、このパフォーマンスの差をさらに拡大することが予想され、テストではパフォーマンスが 25% 向上することがわかります。

Windows Server は、ARM アーキテクチャに基づく Graviton プロセッサでは実行できません。実際、Windows Server は x86 プロセッサでのみ動作します。Windows Server に Graviton ベースのインスタンスを使用して 40% の料金パフォーマンスの向上を実現することはできませんが、特定の Microsoft ワークロードで Graviton プロセッサを引き続き使用できます。例えば、新しいバージョンの .NET は Linux で実行できます。つまり、これらのワークロードは ARM プロセッサを使用し、より高速で手頃な価格の Graviton EC2 インスタンスからメリットを得ることができます。

次の例は、 us-east-1リージョンで実行されている Graviton インスタンスの時間単位の料金を示しています。

インテルインスタンス 時間料金 Graviton インスタンス 時間料金 % 差
c6i.xlarge 0.17 USD c6g.xlarge 0.136 USD 20%
m6i.xlarge 0.192 USD m6g.xlarge 0.154 USD 20%
r6i.xlarge 0.252 USD r6g.xlarge 0.2016 USD 20%
注記

料金は、 us-east-1リージョンのオンデマンド時間単位の料金に基づいています。

次のグラフは、M シリーズインスタンスの料金を比較したものです。

M シリーズ価格比較

EC2 世代間の価格パフォーマンスの違いを理解する

Amazon EC2 の最も一貫した特徴の 1 つは、各新世代が前世代よりも優れた価格パフォーマンスを提供することです。次の表に示すように、後続のリリースごとに、新世代の EC2 インスタンスの料金が下がります。

コンピューティング最適化インスタンス 時間料金 汎用インスタンス 時間料金 メモリ最適化インスタンス 時間料金
C1.xlarge 0.52 USD M1.xlarge 0.35 USD r1.xlarge 該当なし
C3.xlarge 0.21 USD M3.xlarge 0.266 USD r3.xlarge 0.333 USD
C5.xlarge 0.17 USD M5.xlarge 0.192 USD r5.xlarge 0.252 USD
注記

料金は、 us-east-1リージョンのオンデマンド時間単位の料金に基づいています。

次の表は、C シリーズインスタンスのさまざまな世代のコストを比較したものです。

C シリーズ価格比較

ただし、次の表に示すように、第 6 世代のインスタンスは第 5 世代と同じ料金です。

コンピューティング最適化インスタンス 時間料金 汎用インスタンス 時間料金 メモリ最適化インスタンス 時間料金
C5.xlarge 0.17 USD M5.xlarge 0.192 USD r5.xlarge 0.252 USD
C6i .xlarge 0.17 USD M6i .xlarge 0.192 USD r6i.xlarge 0.252 USD
注記

料金は、 us-east-1リージョンのオンデマンド時間単位の料金に基づいています。

同じコストがかかりますが、プロセッサの高速化、ネットワークスループットの向上、Amazon Elastic Block Store (Amazon EBS) のスループットと IOPS の向上により、新世代の は優れた価格パフォーマンスを提供します。

料金パフォーマンスの最も重要な改善の 1 つは、X2i インスタンス の強化です。この世代のインスタンスは、前世代よりも最大 55% 高い価格パフォーマンスを提供します。次の表に示すように、x2iedn はすべてのパフォーマンスの側面 (すべて前世代と同じ価格) の改善を示しています。

インスタンス 時間料金 vCPUs RAM プロセッサ速度 インスタンスストレージ ネットワーク Amazon EBS スループット EBS IOPS
x1e.2xlarge 1.66 USD 8 244 2.3 GHz 237GB SSD 10 Gbps 125 MB/秒 7400
x1iedn.2xlarge 1.66 USD 8 256 3.5 GHz 240GB NVMe SSD 25 Gbps 2500 MB/秒 65000
注記

料金は、 us-east-1リージョンのオンデマンド時間単位の料金に基づいています。

シナリオ例

配送車両を追跡し、SQL Server のパフォーマンスを向上させる分析会社の例を考えてみましょう。MACO SME がこの会社のパフォーマンスのボトルネックを確認すると、会社は x1e.2xlarge インスタンスから x2iedn.xlarge インスタンスに移行します。新しいインスタンスサイズは小さくなりますが、x2 インスタンスの機能強化により、バッファプール拡張機能を使用することで SQL Server のパフォーマンスと最適化が向上します。これにより、企業は SQL Server Enterprise Edition から SQL Server Standard Edition にダウングレードできます。また、SQL Server のライセンスを 8 vCPUs から 4 vCPUs。

最適化前：

[サーバー] EC2 インスタンス SQL Server エディション 月額コスト
ProdDB1 x1e.2xlarge エンタープライズ 3,918.64 USD
ProdDB2 x1e.2xlarge エンタープライズ 3,918.64 USD
合計     7,837.28 USD

最適化後：

[サーバー] EC2 インスタンス SQL Server エディション 月額コスト
ProdDB1 x2iedn.xlarge 標準 1,215.00 USD
ProdDB2 x2iedn.xlarge 標準 1,215.00 USD
合計     2,430.00 USD

合わせて、x1e.2xlarge インスタンスから x2iedn.xlarge インスタンスへの変更により、このシナリオ例では、本稼働データベースサーバーで月額 5,407 USD を節約できます。これにより、ワークロードの総コストが 69% 削減されます。

注記

料金は、 us-east-1リージョンのオンデマンド時間単位の料金に基づいています。

新しいインスタンスに移行する

古い世代の Amazon EC2 は Xen ハイパーバイザーで実行され、新しい世代は AWS Nitro System で実行されます。Nitro System は、ホストハードウェアのほぼすべてのコンピューティングリソースとメモリリソースをインスタンスに配信します。これにより、全体的なパフォーマンスが向上します。Xen から Nitro ベースのインスタンス に移行する場合は、特別な考慮事項があります。例えば、AWS Windows AMIs は、Microsoft インストールメディアで使用されるデフォルト設定とカスタマイズで設定されます。カスタマイズには、最新世代のインスタンスタイプ (Nitro System 上に構築されたインスタンス) をサポートするドライバーと設定が含まれます。

カスタム Windows AMIs または 2018 年 8 月以前に作成された Amazon が提供する Windows AMIs「最新世代のインスタンスタイプへの移行」の手順を完了することをお勧めします。 Amazon EC2

バーストインスタンスを使用する

バーストインスタンスはコンピューティングコストを節約する良い方法ですが、以下のシナリオでは避けることをお勧めします。

  • デスクトップエクスペリエンスを使用する Windows Server の最小仕様には、2 GB の RAM が必要です。Windows Server では t3.micro インスタンスまたは t3.nano インスタンスを使用しないようにします。RAM の最小量がないためです。

  • ワークロードが急増しているが、バーストクレジットを構築するのに十分な時間アイドル状態にならない場合、通常の EC2 インスタンスを使用する方が、バースト可能なインスタンスを使用するよりも効率的です。CPU クレジットをモニタリングして確認することをお勧めします。

  • ほとんどのシナリオでは、SQL Server でバーストインスタンスを使用しないことをお勧めします。SQL Server のライセンスは、インスタンスに割り当てられた vCPUsの数に基づいています。SQL Server が 1 日の大半アイドル状態の場合、完全に活用されていない SQL ライセンスに対して料金が発生します。これらのシナリオでは、複数の SQL Server インスタンスをより大きなサーバーに統合することをお勧めします。

次のステップ

Amazon EC2 Windows インスタンスのコストを最適化するには、次のステップを実行することをお勧めします。

  • 最新世代の EC2 インスタンスを使用して、最適な価格のパフォーマンスを実現します。

  • AMD プロセッサで EC2 インスタンスを使用すると、コンピューティングコストを 10% 削減できます。

  • ワークロードに一致する EC2 インスタンスタイプを選択して、リソース使用率を最大化します。

次の表は、Windows ワークロードの一般的な開始点の例を示しています。SQL Server ワークロードを強化するためのインスタンスストレージボリュームや、vCPU と RAM の比率が大幅に向上する EC2 インスタンスなど、追加のオプションを使用できます。ワークロードを徹底的にテストし、 などのモニタリングツールを使用して必要な調整 AWS Compute Optimizer を行うことをお勧めします。

ワークロード 一般的な オプションです。
アクティブディレクトリ T3, M6i R6i
ファイルサーバー T3, M6i C6i
ウェブサーバー T3, C6i M6i, R6i
SQL Server R6i x2iedn、X2iezn

EC2 インスタンスタイプを変更する必要がある場合、プロセスには通常、サーバーの再起動が単純にしか必要ありません。詳細については、Amazon EC2 ドキュメントの「インスタンスタイプを変更する」を参照してください。

インスタンスタイプを変更する前に、次の点を考慮することをお勧めします。

  • インスタンスタイプを変更する前に、Amazon EBS でバックアップされたインスタンスを停止する必要があります。インスタンスの停止中は、必ずダウンタイムを計画してください。インスタンスを停止し、インスタンスタイプの変更を行うと、数分かかります。インスタンスを再起動すると、アプリケーションの起動スクリプトによってかかる時間が変動する場合があります。詳細については、Amazon EC2 ドキュメントの「インスタンスの停止と起動」を参照してください。

  • インスタンスを停止して起動すると、 はインスタンスを新しいハードウェア AWS に移動します。インスタンスにパブリック IPv4 アドレスがある場合、 はそのアドレスを AWS 解放し、インスタンスに新しいパブリック IPv4 アドレスを付与します。変更されないパブリック IPv4 アドレスが必要な場合は、Elastic IP アドレス を使用します。

  • インスタンスで休止が有効になっている場合、インスタンスタイプを変更することはできません。

  • [Spot Instance] (スポットインスタンス) のインスタンスタイプを変更することはできません。

  • インスタンスが Auto Scaling グループにある場合、Amazon EC2 Auto Scaling は停止したインスタンスを異常としてマークし、インスタンスを終了して代替インスタンスを起動することがあります。インスタンスタイプを変更するときに、そのグループのスケーリングプロセスを中断することで、これを防ぐことができます。詳細については、Amazon EC2 Auto Scaling ドキュメントの「Auto Scaling グループのプロセスを停止および再開する Auto Scaling 」を参照してください。

  • NVMe インスタンスストアボリュームを使用してインスタンスのインスタンスタイプを変更すると、更新されたインスタンスに追加のインスタンスストアボリュームが含まれる場合があります。これは、すべての NVMe インスタンスストアボリュームが Amazon マシンイメージ (AMI) またはインスタンスブロックデバイスマッピングで指定されていない場合でも使用できるためです。それ以外の場合、更新したインスタンスには、元のインスタンスの起動時に指定したのと同じ数のインスタンスストアボリュームが設定されます。

追加リソース