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

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

概要:

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

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

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

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

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

コスト最適化の推奨事項

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

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

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

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

ほとんどの Windows ワークロードは、次のカテゴリに該当します。

これをさらに単純化するには、各カテゴリのベースライン EC2 インスタンスを検討します。

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

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

バースト可能インスタンス

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

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

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

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

Intel プロセッサは、EC2 インスタンスの登場以来、その標準となっています。C5、M5、R5 などの旧世代の EC2 インスタンスでは、Intel をプロセッサアーキテクチャとして明示していません (デフォルトだったため)。C6i、M6i、R6i などの新世代の EC2 インスタンスには、Intel プロセッサの使用を示す「i」が含まれています。

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

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 インスタンスの時間単位の料金を示しています。

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

EC2 世代間の価格性能比の違いを理解する

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

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

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

コストは同じですが、プロセッサの高速化、ネットワークスループットの向上、Amazon Elastic Block Store (Amazon EBS) のスループットと IOPS の向上により、新世代では優れた価格性能比が提供されます。

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

シナリオ例

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

最適化前:

最適化後:

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

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

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

カスタム Windows AMI から、または 2018 年 8 月より前に作成された Amazon 提供の Windows AMI からインスタンスを起動する場合は、Amazon EC2 ドキュメントの「Migrate to latest generation instance types」の手順を完了することをお勧めします。

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

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

次の手順

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

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

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

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

その他のリソース