翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Windows ワークロードに適したインスタンスタイプを選択する ## 概要: クラウドで運用されているワークロードとオンプレミス環境との大きな違いは、過剰プロビジョニングの実践です。オンプレミス用の物理ハードウェアを購入する場合は、事前に決められた期間 (通常は 3～5 年) にわたって継続することが予想される設備投資を行います。ハードウェアの耐用年数中に予想される増加に対応するために、ハードウェアはワークロードが現在必要とするよりも多くのリソースで取得されます。したがって、物理ハードウェアは多くの場合、実際のワークロードのニーズをはるかに超えて過剰にプロビジョニングされます。 仮想マシン (VM) テクノロジーは、余剰ハードウェアリソースを利用する効果的な手段として登場しました。管理者は vCPU と RAM で VM を過剰にプロビジョニングし、各 VM に未使用のリソースを割り当てることで、ハイパーバイザーがビジーサーバーとアイドルサーバー間の物理リソース使用状況を管理できるようにしました。VM を管理する場合、各 VM に割り当てられた vCPU リソースと RAM リソースは、実際の使用状況の指標ではなく、リソースガバナーとして機能していました。VM リソースの過剰割り当ては、使用可能なコンピューティングリソースの 3 倍を簡単に超える可能性があります。 [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) は、基盤となるハードウェアに VM を過剰にプロビジョニングしないようにします。それは不要だからです。クラウドコンピューティングは、資本コストではなく運用コストであり、使用した分に対してのみ支払います。将来的にワークロードにより多くのリソースが必要になる場合は、事前に準備するのではなく、実際に必要になったときにプロビジョニングします。 適切な [Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)を選択するためのオプションは数百があります。Windows ワークロードをクラウドに移行する予定の場合、 は [AWS OLA](https://aws.amazon.com/optimization-and-licensing-assessment/) 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 インスタンスの時間単位の料金を示しています。 **** | インスタンス | vCPU | 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 クレジット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#earning-CPU-credits)に基づくシステムを使用します。これらのクレジットは、1 日を通してアイドル期間中に蓄積されます。バースト可能インスタンスは、さまざまな vCPU 対 RAM 比率を提供するため、場合によってはコンピューティング最適化インスタンスの代替となり、また場合によっては他の汎用インスタンスの代替となります。 次の例は、`us-east-1` リージョンで実行されている T3 インスタンス (つまりバースト可能インスタンス) の時間単位の料金を示しています。 **** | インスタンス | vCPU | 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` リージョンのオンデマンドの時間単位の料金に基づいています。 ### プロセッサアーキテクチャ間の料金の違いを理解する [Intel](https://aws.amazon.com/intel/) プロセッサは、EC2 インスタンスの登場以来、その標準となっています。C5、M5、R5 などの旧世代の EC2 インスタンスでは、Intel をプロセッサアーキテクチャとして明示していません (デフォルトだったため)。C6i、M6i、R6i などの新世代の EC2 インスタンスには、Intel プロセッサの使用を示す「i」が含まれています。 プロセッサアーキテクチャの注釈の変更は、追加のプロセッサオプションの導入によるものです。Intel に最も近いプロセッサは [AMD](https://aws.amazon.com/ec2/amd/) です (「a」で示されます)。AMD EPYC プロセッサは、同じ x86 アーキテクチャを使用し、Intel プロセッサと同様のパフォーマンスを低コストで提供します。次の料金例に示すように、AMD EC2 インスタンスでは、Intel インスタンスと比較してコンピューティングコストが約 10% 削減されます。 **** | Intel インスタンス | 時間料金 | 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 プロセッサ](https://aws.amazon.com/ec2/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 で実行できます](net-refactor-linux.md)。つまり、これらのワークロードは ARM プロセッサを使用し、より高速で手頃な価格の Graviton EC2 インスタンスからメリットを得ることができます。 次の例は、`us-east-1` リージョンで実行されている Graviton インスタンスの時間単位の料金を示しています。 **** | Intel インスタンス | 時間料金 | 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 シリーズ料金比較\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/m6_price.png) ### 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 シリーズ料金比較\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/ec2_compute_opt_price.png) ただし、次の表に示すように、第 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 インスタンス](https://aws.amazon.com/ec2/instance-types/x2i/)の強化です。この世代のインスタンスは、前世代よりも最大 55% 高い価格性能比を提供します。次の表に示すように、x2iedn は、パフォーマンスのあらゆる面で改善を示しています (すべて前世代と同じ料金)。 **** | インスタンス | 時間料金 | vCPU | RAM | プロセッサ速度 | インスタンスストレージ | ネットワーク | Amazon EBS スループット | EBS IOPS | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | x1e.2xlarge | 1.66 USD | 8 | 244 | 2.3 GHz | 237 GB SSD | 10 Gbps | 125 MB/秒 | 7400 | | x1iedn.2xlarge | 1.66 USD | 8 | 256 | 3.5 GHz | 240 GB 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 vCPU から 4 vCPU に削減することができます。 **最適化前:** **** | サーバー | EC2 インスタンス | SQL Server エディション | 月額コスト | | --- | --- | --- | --- | | ProdDB1 | x1e.2xlarge | Enterprise | 3,918.64 USD | | ProdDB2 | x1e.2xlarge | Enterprise | 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 インスタンスへの変更により、このシナリオ例では、本番用データベースサーバーで 1 か月あたり 5,407 USD を節約できます。これにより、ワークロードの合計コストが 69% 削減されます。 **注記** 料金は、`us-east-1` リージョンのオンデマンドの時間単位の料金に基づいています。 ### 新しいインスタンスに移行する 旧世代の Amazon EC2 は Xen ハイパーバイザーで動作し、新世代は [AWS Nitro System](https://aws.amazon.com/ec2/nitro/) で動作します。Nitro System は、ホストハードウェアのほぼすべてのコンピューティングリソースとメモリリソースをインスタンスに提供します。これにより、全体的なパフォーマンスが向上します。[Xen から Nitro ベースのインスタンスに移行する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/migrate-to-xen.html)場合は、特別な考慮事項があります。例えば、[AWS Windows AMI](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/windows-amis.html) は、Microsoft インストールメディアで使用されるデフォルト設定とカスタマイズで設定されます。カスタマイズには、最新世代のインスタンスタイプ ([Nitro System 上に構築されたインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)) をサポートするドライバーと設定が含まれます。 カスタム Windows AMI から、または 2018 年 8 月より前に作成された Amazon 提供の Windows AMI からインスタンスを起動する場合は、Amazon EC2 ドキュメントの「[Migrate to latest generation instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/migrating-latest-types.html)」の手順を完了することをお勧めします。 ### バースト可能インスタンスを使用する バースト可能インスタンスはコンピューティングコストを節約する良い方法ですが、以下のシナリオでは避けることをお勧めします。 + デスクトップエクスペリエンスを使用する [Windows Server の最小仕様](https://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements#ram)には、2 GB の RAM が必要です。RAM の最小容量を満たしていないため、Windows Server で t3.micro または t3.nano インスタンスを使用することは避けてください。 + ワークロードが急増しているが、バーストクレジットを構築するのに十分な時間アイドル状態にならない場合は、通常の EC2 インスタンスを使用する方が、バースト可能インスタンスを使用するよりも効率的です。[CPU クレジットをモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-monitoring-cpu-credits.html)してこれを確認することをお勧めします。 + ほとんどのシナリオでは、SQL Server でバースト可能インスタンスを使用しないことをお勧めします。SQL Server のライセンスは、インスタンスに割り当てられた vCPU の数に基づいています。SQL Server が 1 日の大半アイドル状態の場合、完全に活用されていない SQL ライセンスに対して料金が発生します。これらのシナリオでは、複数の SQL Server インスタンスをより大きなサーバーに統合することをお勧めします。 ## 次の手順 Amazon EC2 Windows インスタンスのコストを最適化するには、次のステップを実行することをお勧めします。 + 最高の価格性能比を得るには、最新世代の EC2 インスタンスを使用します。 + AMD プロセッサで EC2 インスタンスを使用すると、コンピューティングコストを 10% 削減できます。 + ワークロードに一致する EC2 インスタンスタイプを選択して、リソース使用率を最大化します。 次の表は、Windows ワークロードの一般的な開始点の例を示しています。SQL Server ワークロードを強化するためのインスタンスストレージボリュームや、vCPU と RAM の比率がはるかに大きい EC2 インスタンスなど、追加のオプションを使用できます。ワークロードを徹底的にテストし、 AWS Compute Optimizer などのモニタリングツールを使用して必要な調整を行うことをお勧めします。 **** | ワークロード | 標準 | オプションです。 | | --- | --- | --- | | Active Directory | T3、M6i | R6i | | ファイルサーバー | T3、M6i | C6i | | ウェブサーバー | T3、C6i | M6i、R6i | | SQL Server | R6i | x2iedn、X2iezn | EC2 インスタンスタイプを変更する必要がある場合、プロセスには通常、単純なサーバーの再起動のみが含まれます。詳細については、Amazon EC2 ドキュメントの「[Amazon EC2 インスタンスタイプの変更](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html)」を参照してください。 インスタンスタイプを変更する前に、次の点を考慮することをお勧めします。 + インスタンスタイプを変更する前に、Amazon EBS–backed インスタンスを停止する必要があります。インスタンスが停止している間のダウンタイムを計画しておいてください。インスタンスを停止し、インスタンスタイプの変更を行うと、数分かかります。インスタンスを再起動すると、アプリケーションの起動スクリプトによってかかる時間が変動する場合があります。詳細については、Amazon EC2 ドキュメントの「[Amazon EC2 インスタンスの停止と起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html)」を参照してください。 + インスタンスを停止して起動すると、 はインスタンスを新しいハードウェア AWS に移動します。インスタンスにパブリック IPv4 アドレスがある場合、 はそのアドレスを AWS 解放し、インスタンスに新しいパブリック IPv4 アドレスを付与します。変更されないパブリック IPv4 アドレスが必要な場合は、[Elastic IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)を使用します。 + [休止状態](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Hibernate.html)が有効になっているインスタンスのインスタンスタイプを変更することはできません。 + [[Spot Instance]](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#stopping-a-spot-instance) (スポットインスタンス) のインスタンスタイプを変更することはできません。 + インスタンスが Auto Scaling グループにある場合、Amazon EC2 Auto Scaling はインスタンスを異常と判断して停止し、場合によってはそれを終了して代わりのインスタンスを起動します。インスタンスタイプを変更するときに、そのグループのスケーリングプロセスを中断することで、これを防ぐことができます。詳細については、Amazon EC2 Auto Scaling ドキュメントの「[Amazon EC2 Auto Scaling プロセスの中断と再開](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-suspend-resume-processes.html)」を参照してください。 + NVMe インスタンスストアボリュームを使用してインスタンスのインスタンスタイプを変更すると、Amazon マシンイメージ (AMI) またはインスタンスブロックデバイスマッピングで指定されていない場合でもすべての NVMe インスタンスストアボリュームが利用可能であるため、追加のインスタンスストアボリュームが更新されたインスタンスに存在するようになる可能性があります。それ以外の場合、更新したインスタンスには、元のインスタンスの起動時に指定したのと同じ数のインスタンスストアボリュームが設定されます。 ## その他のリソース + [Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/) (AWS ドキュメント) + [AWS Optimization and Licensing Assessment](https://aws.amazon.com/optimization-and-licensing-assessment/) (AWS ドキュメント)