翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# SQL Server
お客様は、他のクラウドプロバイダーよりも AWS 15 年以上、 で Microsoft ワークロードを実行しています。これは主に、 AWS がクラウドでの Microsoft アプリケーションの使用経験が最も高く、以下の領域で Windows Server と Microsoft SQL Server に最適なプラットフォームを提供しているためです。
+ より高いパフォーマンスおよび信頼性
+ より優れたセキュリティおよびアイデンティティサービス
+ さらなる移行サポート
+ 最も広範で深い機能
+ 低い総保有コスト (TCO)
+ 柔軟なライセンスオプション
AWS は、Active Directory、.NET、SQL Server、サービスとしての Windows デスクトップ、サポートされているすべてのバージョンの Windows Server など、SQL Server に依存する Windows アプリケーションの構築と実行に必要なすべてをサポートします。実証済みの専門知識により、 AWS は Windows ワークロードを簡単にリフトアンドシフト、リファクタリング、またはモダナイズするのに役立ちます。
**Topics**
+ [高可用性とディザスタリカバリのソリューションを選択する](sql-server-hadr.md)
+ [SQL Server ライセンスを理解する](sql-server-licensing.md)
+ [SQL Server ワークロードに適した EC2 インスタンスを選択する](right-ec2-instance.md)
+ [インスタンスを統合する](consolidate-instances.md)
+ [SQL Server エディションの比較](sql-server-editions.md)
+ [SQL Server Developer Edition を評価する](sql-server-dev.md)
+ [Linux 上の SQL Server を評価する](sql-server-linux.md)
+ [SQL Server バックアップ戦略を最適化する](sql-server-backup.md)
+ [SQL Server データベースをモダナイズする](modernize-sql-server.md)
+ [SQL Server のストレージを最適化する](storage-sql-server.md)
+ [Compute Optimizer を使用して SQL Server ライセンスを最適化する](sql-server-compute-optimizer.md)
+ [Compute Optimizer を使用して SQL Server のサイズ設定を最適化する](sql-server-sizing-compute-optimizer.md)
+ [SQL Server ワークロードの Trusted Advisor レコメンデーションを確認する](sql-server-trusted-advisor.md)
# 高可用性とディザスタリカバリのソリューションを選択する
## 概要:
目標復旧時間 (RTO) や目標復旧時点 (RPO) などの[ディザスタリカバリ (DR) 目標](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)も達成しながらビジネスニーズを満たす、 AWS 上の SQL Server デプロイ用のアーキテクチャを設計することをお勧めします。以下のソリューションは、SQL Server ワークロードのコストも最適化しながら、Amazon Elastic Compute Cloud (Amazon EC2) 上の SQL Server に適したアーキテクチャを設計するのに役立ちます。
+ **SQL Server Always On 可用性グループ **–** **SQL Server Always On 可用性グループは、SQL Server データベースの高可用性とディザスタリカバリ (HA/DR) ソリューションを提供します。可用性グループは、フェイルオーバーされるユーザーデータベースのセットで構成されます。Always On 可用性グループもデータベースレベルで冗長性を提供しますが、共有ストレージは必要ありません。各レプリカには独自のローカルストレージがあります。この機能は HA/DR ソリューションとしてデプロイできます。詳細については、Microsoft ドキュメントの「[What is an Always On availability group?](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver16)」を参照してください。
+ **SQL Server Always On フェイルオーバークラスターインスタンス (FCI)** –** **SQL Server Always On FCI は Windows Server フェイルオーバークラスタリング (WSFC) を使用して、SQL Server インスタンスレベルで HA を提供します。FCI では、データベースをホストするために共有ストレージが必要です。共有ブロックストレージまたは共有ファイルストレージを使用できます。例えば、Amazon FSx for Windows File Server または Amazon FSx for NetApp ONTAP を、複数のアベイラビリティーゾーンを持つ共有ストレージソリューションとして使用できます。詳細については、Microsoft ドキュメントの「[Always On Failover Cluster Instances (SQL Server)](https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-ver16)」を参照してください。
+ **SIOS DataKeeper** –** **SIOS DataKeeper は、アベイラビリティーゾーンと AWS リージョンの両方にまたがる SQL Server FCI を有効にすることで、HA と DR の両方の要件を満たすのに役立ちます。SIOS DataKeeper は、ローカル Amazon Elastic Block Store (Amazon EBS) ボリュームを使用してクラスター化された仮想 SAN を作成し、HA のアベイラビリティーゾーン間の同期レプリケーションを使用し、ディザスタリカバリのためにリージョン間の非同期レプリケーションを使用します。詳細については、SIOS ドキュメントの「[High Availability Protection for Windows Applications](https://us.sios.com/products/windows/)」を参照してください。
+ **分散可用性グループ** –** **分散可用性グループは、2 つの別々の Always On 可用性グループにまたがる特殊な種類の可用性グループです。可用性グループは、2 つの別々のリージョン (`us-east-1` や `us-west-1` など) にまたがって存在できます。基盤となる Always On 可用性グループは 2 つの異なる WSFC クラスターに設定されているため、分散可用性グループを、可用性グループの可用性グループと考えることができます。分散可用性グループをデプロイするには、SQL Server Enterprise Edition が必要です。詳細については、Microsoft ドキュメントの「[Distributed availability groups](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/distributed-availability-groups?view=sql-server-ver16)」を参照してください。
+ **ログ配布** –** **万が一リージョンが影響を受けて使用できなくなった場合に備えて、ログ配布を実装して、複数のリージョンにまたがるデータベースを保護できます。トランザクションとログ配布の頻度に応じて、数分以内に RPO と RTO を達成できます。詳細については、Microsoft ドキュメントの「[About Log Shipping (SQL Server)](https://learn.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server?view=sql-server-ver16)」を参照してください。
+ **AWS Elastic Disaster Recovery** – Elastic Disaster Recovery は、DR AWS 目的で任意のインフラストラクチャから へのサーバーのレプリケーションを管理する Software as a Service (SaaS) アプリケーションです。Elastic Disaster Recovery を使用して、リージョン間で SQL Server をレプリケートすることもできます。Elastic Disaster Recovery は、オペレーティングシステム、インストールされているすべてのアプリケーション、すべてのデータベースを含む仮想マシン全体をステージングエリアにレプリケートするエージェントベースのソリューションです。詳細については、Elastic Disaster Recovery ドキュメントの「[What is Elastic Disaster Recovery?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)」を参照してください。
+ **AWS Database Migration Service (AWS DMS)** – は AWS、別の リージョンを含む、 との間のデータのライブ移行** **AWS DMS をサポートします。この機能を使用して、ディザスタリカバリデータベースとして機能する別のリージョンに別個の SQL Server インスタンスをセットアップできます。詳細については、 AWS DMS ドキュメントの[「What is AWS Database Migration Service?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」を参照してください。
## SQL Server Always On 可用性グループ
高可用性 [Always On 可用性グループ](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver16)のみに SQL Server Enterprise Edition を使用している場合は、基本的な可用性グループを利用して SQL Server Standard Edition にダウングレードできます。Always On 可用性グループの代わりに基本的な可用性グループを使用することで、コストを 65～75% 削減できます。
**注記**
異なる SQL Server エディション間のコストの違いの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。
**特徴**
+ SQL Server Standard Edition で使用可能
+ レプリカは 2 つまで (プライマリとセカンダリ)
+ セカンダリレプリカへの読み取りアクセスなし
+ セカンダリレプリカの整合性チェックなし
**制限事項**
+ 可用性グループごとに 1 つの可用性データベースのみをサポート
+ 基本的な可用性グループを分散可用性グループの一部にすることはできない
次の図は、Windows Server フェイルオーバークラスターソリューションのアーキテクチャの例を示しています。
![\[Windows Server フェイルオーバークラスターアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/wfc_arch.png)
## SQL Server Always On フェイルオーバークラスターインスタンス
フェイルオーバークラスターインスタンス (FCI) を使用して、ダウンタイムを最小限に抑え、データ損失のリスクを減らしながら、データベースの継続的なオペレーションを確保できます。FCI は、リードレプリカの設定なしで SQL Server データベースの高可用性を求める場合に、信頼性の高いソリューションを提供します。
可用性グループとは異なり、FCI は SQL Server Enterprise Edition を必要とせずに、信頼性の高いフェイルオーバーソリューションを提供できます。代わりに、FCI では SQL Server Standard Edition ライセンスのみが必要です。FCI を使用して、SQL Server のライセンスコストを 65～75% 削減できます。
**注記**
SQL Server エディション間のコストの違いの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。
以下の点を考慮してください。
+ Amazon FSx for Windows File Server は、SQL Server FCI 共有ストレージ要件を満たすための強力なソリューションを提供します。FSx for Windows File Server を使用すると、ストレージレプリケーションソリューションのライセンスを購入し、共有ストレージを自分で管理する必要がなくなります。これにより、30～40% の大幅なコスト削減につながります。詳細については、 AWS ストレージブログの[「Amazon FSx for Windows File Server を使用した Microsoft SQL Server の高可用性デプロイの簡素化](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)」の投稿を参照してください。
+ 「[Software Assurance benefits summary](https://download.microsoft.com/download/0/0/3/0039F316-45CF-4083-AA6E-C35DA9D25C1B/SA_InteractiveBenefitsChart.pdf)」(ダウンロード可能な PDF) と Bring Your Own License (BYOL) モデルを使用すると、セカンダリサーバーがパッシブである限り、パッシブフェイルオーバーのメリットを活用できます。これにより、クラスターのパッシブノードにライセンスを提供する必要がないため、SQL ライセンスのコスト削減につながります。
次の図は、FSx for Windows File Server を使用した SQL Server FCI のアーキテクチャの例を示しています。
![\[FSx for Windows File Server アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/fsx_arch.png)
## SIOS DataKeeper
SQL Server FCIsデプロイする場合は、共有ストレージ要件を検討することをお勧めします AWS。従来のオンプレミスインストールでは通常、共有ストレージ要件を満たすためにストレージエリアネットワーク (SAN) が使用されますが、これは AWSでは実行可能なオプションではありません。Amazon FSx for Windows File Server は、 上の SQL Server FCI に推奨されるストレージソリューションですが AWS、異なる にクラスターサーバーを追加することを妨げる制限があります AWS リージョン。
[SIOS DataKeeper](https://aws.amazon.com/blogs/architecture/field-notes-implementing-ha-and-dr-for-microsoft-sql-server-using-always-on-failover-cluster-instance-and-sios-datakeeper/) を使用して、コストを 58～71% 削減しながら、アベイラビリティーゾーンとリージョンの両方をカバーする SQL Server FCI を作成できます。SIOS DataKeeper は、FCI の高可用性のメリットを実現するのに役立ちます。これにより、SIOS DataKeeper は組織にとってコスト効率と信頼性に優れたソリューションになります。
SIOS DataKeeper を使用することで得られる次のような利点も考慮してください。
+ SIOS DataKeeper は、ローカル EBS ボリュームを使用して、クラスター化された仮想 SAN を作成し、アベイラビリティーゾーン間の同期レプリケーションを使用して高可用性を実現します。ディザスタリカバリの場合、SIOS DataKeeper はリージョン間の非同期レプリケーションを使用します。
+ SIOS DataKeeper は、SQL Server Standard Edition を使用してエンタープライズクラスのクラスタリング機能を提供します。これにより、SQL Server Enterprise Edition を使用する SQL Server Always On 可用性グループによる高可用性の実装と比較して、SQL Server のライセンスコストが 65～75% 削減されます。SIOS DataKeeper を使用すると、組織のニーズを満たす、可用性が高くて柔軟で費用対効果の高い SQL Server 環境を作成できます。
**注記**
SQL Server エディション間のコストの違いの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。
次の図は、クラスター化された仮想 SAN ソリューションを使用した SQL Server FCI のアーキテクチャの例を示しています。
![\[クラスター化された仮想 SAN ソリューションを使用した SQL Server FCI\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/clustered_vsan_arch.png)
## Always On 可用性グループ
Always On 可用性グループは、高可用性とディザスタリカバリの両方の目的で使用できます。SQL Server を 1 つのリージョンの 2 つのアベイラビリティーゾーンにデプロイすることで、高可用性を実現できます。リージョン間で可用性グループを拡張することで、ディザスタリカバリを実現できます。
次の図は、Always On 可用性グループに基づくソリューションのアーキテクチャの例を示しています。図のリージョン 1 のレプリカは、可用性グループの自動フェイルオーバーを提供する同期コミットを使用しています。リージョン 2 のレプリカは非同期コミットを使用しているため、可用性グループの手動フェイルオーバーが必要になります。
![\[Always On 可用性グループアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/alwayson_ag_arch.png)
## 分散可用性グループ
信頼性やディザスタリカバリで妥協できないミッションクリティカルな SQL Server デプロイの場合は、マルチリージョンアプローチをお勧めします。複数のリージョンに可用性グループを分散させることは、ビジネス継続性を維持し、ダウンタイムを最小限に抑えるための最も回復力の高いソリューションです。
このアーキテクチャは、共有ストレージ、同期ブロックレベルレプリケーション、SQL Server FCI など、Amazon FSx for Windows File Server の機能を最大限に活用します。これらの機能により、複数のアベイラビリティーゾーンにまたがる高可用性 SQL Server 環境を作成できるようになります。この設定を別のリージョンにレプリケートすることで、最も深刻な中断にも対応できる完全に冗長なシステムが得られます。このソリューションを際立たせているのは、それが提供する柔軟性とセキュリティのレベルです。分散可用性グループのドメインに依存しないアーキテクチャにより、基盤となる Windows クラスターサーバーを異なる Active Directory ドメインに参加させることができると同時に、証明書ベースの認証により、SQL Server 環境に対する最大限の保護が保証され、マルチリージョン DR 戦略に高い RTO および RPO 要件が提供されます。マルチリージョンアーキテクチャの構築の詳細については、「 アーキテクチャブログ」の[「Field Notes: Building a Multi-Region Architecture for SQL Server using FCI and Distributed Availability Groups](https://aws.amazon.com/blogs/architecture/field-notes-building-a-multi-region-architecture-for-sql-server-using-fci-and-distributed-availability-groups/)」を参照してください。 AWS
次の図は、分散可用性グループを使用したマルチリージョンソリューションのアーキテクチャの例を示しています。
![\[マルチリージョンアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/multi_region_arch.png)
## ログ配布
ログ配布は、予期しない停止が発生した場合にリージョン間でデータベースを保護するための、実績があり、信頼性が高く、費用対効果の高い方法です。組織は数十年にわたってログ配布を使用してデータを保護してきました。
ログ配送を実装する場合 AWS、トランザクションの頻度とログ配送ジョブに応じて、RPO と RTO を数分で実現できます。万一、リージョンにアクセスできなくなった場合、ログ配布によりデータの安全性と回復性が維持されます。
ログ配布を使用することで得られる次のような利点も考慮してください。
+ リージョン間のディザスタリカバリ耐障害性のためにログ配布を使用することで、コストを削減し、ビジネス要件を満たします。SQL Server Standard Edition または SQL Server Web Edition のライセンスのみが必要なため、ログ配布は TCO を削減します。
+ アクティブな[ソフトウェアアシュアランス](https://download.microsoft.com/download/0/0/3/0039F316-45CF-4083-AA6E-C35DA9D25C1B/SA_InteractiveBenefitsChart.pdf)でのログ配布を使用して、ディザスタリカバリ/パッシブサーバーからライセンスコストを削減します。ソフトウェアアシュアランスでのログ配布を使用する場合は、プライマリ/アクティブ SQL Server のみをライセンスする必要があります。
+ SQL Server Enterprise Edition でリージョン間で分散可用性グループをセットアップする必要がなくなるため、SQL Server のライセンスコストが 65～75% 削減されます。これを行うには、SQL Server Standard Edition と SQL Server FCI をログ配布と組み合わせて使用して、ディザスタリカバリ要件を満たします。
**注記**
SQL Server エディション間のコストの違いの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。
詳細については、 AWS アーキテクチャブログの[「Amazon FSx for Windows 設定で SQL Server FCI のログ配信を使用して SQL Server DR を拡張](https://aws.amazon.com/blogs/architecture/extend-sql-server-dr-using-log-shipping-for-sql-server-fci-with-amazon-fsx-for-windows-configuration/)する」を参照してください。
次の図は、ログ配布ソリューションのアーキテクチャの例を示しています。
![\[ログ配布アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/log_shipping_arch.png)
## AWS Database Migration Service
AWS Database Migration Service (AWS DMS) を使用して、アプリケーションのニーズに基づいて HA/DR ソリューションを設計できます。 AWS DMS を使用すると、同じリージョン (HA) またはリージョン (DR) 間でセカンダリ SQL Server データベースにデータを簡単にコピーできます。このアプローチは技術的に健全であり、リソース使用量を最適化しながら AWS インフラストラクチャへの投資を最大化できます。
AWS DMS はコスト効率の高いサービスです。転送プロセス中に使用される CPU リソースと追加のログストレージに対してのみ課金されます。つまり、大幅な追加コストを発生させることなく、このソリューションのメリットを享受できます。を使用して AWS DMS 、ライセンスとリソースの使用に関連するコストを最小限に抑えながら、データの可用性とアクセス性を確保できます。
次の図は、 AWS DMSに基づくソリューションのアーキテクチャの例を示しています。
![\[AWS DMS アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/aws_dms_arch.png)
## AWS Elastic Disaster Recovery
組織によっては、すべての重要なビジネスアプリケーションにディザスタリカバリ計画が導入されていることを確認する必要があります。以前は、このような組織の多くは、従来のディザスタリカバリソリューションに多額の投資を行っていました。この場合、重複するインフラストラクチャ全体を事前に構築して維持する必要があります。このアプローチはコストも時間もかかり、スケーリングも困難です。
これで、 AWS Elastic Disaster Recovery を使用してディザスタリカバリインフラストラクチャを事前に構築する必要がなくなります。ディザスタリカバリマシンは、必要になるまで Elastic Disaster Recovery で起動されないため、必要なときに使用した分だけお支払いいただきます。つまり、ソフトウェアライセンスと高性能コンピューティングのコストを大幅に削減できます。
さらに、ディザスタリカバリソリューションのステージングエリアには、低コストの Amazon Elastic Block Store (Amazon EBS) ボリュームが含まれています。EBS ボリュームは、重複リソースのプロビジョニングコストをさらに削減します。これにより、ビジネス要件を満たす堅牢で信頼性の高いディザスタリカバリソリューションを維持しながら、全体的なディザスタリカバリコストを削減できます。Elastic Disaster Recovery を使用してコアビジネス活動に集中できますが、 AWS はディザスタリカバリソリューションの基盤となるインフラストラクチャを処理します。
SQL Server では、費用対効果の高いディザスタリカバリオプションとして Elastic Disaster Recovery を使用できます。耐障害性があり可用性の高い SQL Server アーキテクチャのパッシブノードのライセンスは、アクティブなソフトウェアアシュアランスを使用する場合にカバーされます。ただし、パッシブサーバーがオンラインになるためのコンピューティングコストは引き続き発生します。Elastic Disaster Recovery を使用すると、プライマリサーバーは、アクティブなソフトウェアアシュアランスを維持しなくても DR 環境にレプリケートでき、ディザスタリカバリのコンピューティングコストを支払う必要もありません。このコスト削減の組み合わせにより、SQL Server のディザスタリカバリコストを 50% 以上削減できます。
次の図は、Elastic Disaster Recovery に基づくソリューションのアーキテクチャの例を示しています。
![\[Elastic Disaster Recovery アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/aws_drs_arch.png)
詳細については、 AWS ブログの Microsoft Workloads の「 [を使用して復元された DR サイトで SQL Server の高可用性を設定する方法 AWS Elastic Disaster Recovery](https://aws.amazon.com/blogs/modernizing-with-aws/set-up-high-availability-for-sql-server-at-dr-site-using-aws-elastic-disaster-recovery/)」を参照してください。
## コスト比較
次の表は、このセクションで説明する HA/DR ソリューションのコストを比較したものです。この比較では、次の前提が適用されます。
+ **インスタンスタイプ** – r5d.xlarge
+ **ライセンスタイプ** – Windows と SQL Server の両方に含まれるライセンス
+ **[Region]** (リージョン) - `us-east-1`
****
| ソリューション | 高可用性 | ディザスタリカバリ | Enterprise Edition | Standard Edition | Cost |
| --- | --- | --- | --- | --- | --- |
| ログ配布 | いいえ | はい | はい | はい | SQL Server Enterprise Edition: 32,674.8 USD (2 ノード)SQL Server Standard Edition: 14,804.4 USD (2 ノード) |
| Always On 可用性グループ | はい | はい | はい | あり。ただし、基本的な可用性グループ (2 ノード) | SQL Server Enterprise Edition: 32,674.8 USD (2 ノード)SQL Server Standard Edition: 14,804.4 USD (2 ノード) |
| Always On FCI | はい | なし | はい | あり (2 ノード) | SQL Server Standard Edition: 14,804.4 USD |
| 分散可用性グループ | はい | はい | あり | なし | SQL Server Enterprise Edition: 65,349.6 USD (4 ノード) |
| Elastic Disaster Recovery | いいえ | はい | はい | はい | 1 インスタンスと 1 TB のストレージのレプリケーションの場合、月額約 107.48 USD**注**: Elastic Disaster Recovery は、レプリケートするサーバーごとに時間単位で請求されます。ディスク数、ストレージサイズ、ドリルまたはリカバリの起動数、レプリケートするリージョンに関係なく、コストは同じです。 |
| SIOS DataKeeper | はい | はい | はい | はい | ソフトウェアアシュアランスを使用する Always On 可用性グループ (2 ノード、24 コア): 213,480 USDSIOS DataKeeper とソフトウェアアシュアランスを使用する SQL Server Standard Edition で実行される 2 ノード SQL Server クラスター: 61,530 USD (2 ノード) |
| AWS DMS | いいえ | はい | はい | はい | r5.xlarge インスタンスと 1 TB のストレージの場合、月額 745.38 USD |
## コスト最適化の推奨事項
組織の要件を満たす HA/DR ソリューションを選択するには、次のステップを実行することをお勧めします。
+ このガイドの「[SQL Server ワークロードに適した EC2 インスタンスを選択する](right-ec2-instance.md)」セクションを確認します。
+ ピークワークロード中にパフォーマンスカウンターを実行して、ワークロードの IOPS とスループットの要件を決定します。
+ IOPS = ディスク読み取り/秒 \$1 ディスク書き込み/秒
+ スループット = ディスク読み取りバイト/秒 \$1 ディスク書き込みバイト/秒
+ パフォーマンスとコスト削減を向上させるには、次のストレージボリュームタイプを使用します。
+ `tempdb` およびバッファプール拡張用の NVMe インスタンスストレージ
+ データベースファイル用の io2 ボリューム
+ Amazon EC2 上の SQL Server のコスト最適化に関する推奨事項については、[AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) を使用します。SQL Server 最適化チェックを実行する Trusted Advisor ために、 のエージェントをインストールする必要はありません。 は、仮想 CPUs (vCPUs)、バージョン、エディションなど、Amazon EC2 SQL Server のライセンス込みインスタンス設定 Trusted Advisor を検査します。次に、 はベストプラクティスに基づいてレコメンデーション Trusted Advisor を行います。
+ Amazon EC2 インスタンスと Amazon EBS の両方の適切なサイジングのレコメンデーション AWS Compute Optimizer に使用します。
+ [AWS 料金見積りツール](https://calculator.aws/#/) を使用して、コスト見積もりのための HA/DR 戦略を設計します。
+ SQL Server Enterprise Edition から SQL Server Standard Edition へのダウングレードが可能なオプションかどうかを判断するには、[sys dm\$1db\$1persisted\$1sku\$1features](https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-persisted-sku-features-transact-sql?view=sql-server-ver16) 動的管理ビューを使用して、現在のデータベースでアクティブなエディション固有の機能を特定します。
**注記**
ライセンス込み EC2 インスタンスを使用する場合、SQL Server エディションの変更にはサイドバイサイド移行が必要です。
+ 定義された RTO と RPO でデータベースを復旧できる設計をより適切に構築するために、半年または年に 1 回のディザスタリカバリドリルを実行します。これは、アーキテクチャの弱点を特定するのにも役立ちます。
## その他のリソース
+ [Amazon FSx for Windows File Server を使用して Microsoft SQL Server の高可用性デプロイを簡素化する](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server) (AWS ストレージブログ)
+ [フィールドノート: FCI と分散可用性グループを使用した SQL Server のマルチリージョンアーキテクチャの構築](https://aws.amazon.com/blogs/architecture/field-notes-building-a-multi-region-architecture-for-sql-server-using-fci-and-distributed-availability-groups/) (AWS アーキテクチャブログ)
+ [SQL Server のディザスタリカバリの設計 AWS: パート 1](https://aws.amazon.com/blogs/database/part-1-architect-a-disaster-recovery-for-sql-server-on-aws/) (AWS データベースブログ)
+ 「[Microsoft SQL high availability with Amazon FSx for Windows](https://www.youtube.com/watch?v=8dsRkVLy0Nc)」(YouTube)
+ 「[Maximizing Microsoft SQL Server Performance with Amazon EBS](https://aws.amazon.com/blogs/storage/maximizing-microsoft-sql-server-performance-with-amazon-ebs/)」(AWS ストレージブログ)
+ [オンプレミスストレージパターンと AWS ストレージサービスの比較](https://aws.amazon.com/blogs/storage/comparing-your-on-premises-storage-patterns-with-aws-storage-services/) (AWS ストレージブログ)
+ [データセンター NAS を Amazon FSx File Gateway に置き換える計画](https://aws.amazon.com/blogs/storage/planning-to-replace-a-data-center-nas-with-amazon-fsx-file-gateway/) (AWS ストレージブログ)
+ [での高可用性 SQL Server デプロイのコストの最適化 AWS](https://aws.amazon.com/blogs/storage/optimizing-cost-for-your-high-availability-sql-server-deployments-on-aws/) (AWS ストレージブログ)
+ 「[How to set up disaster recovery for SQL Server Always On Availability Groups using AWS Elastic Disaster Recovery](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-set-up-disaster-recovery-for-sql-server-always-on-availability-groups-using-aws-elastic-disaster-recovery/)」(Microsoft Workloads on AWS)
+ [を使用して復元された DR サイトで SQL Server の高可用性を設定する方法 AWS Elastic Disaster Recovery](https://aws.amazon.com/blogs/modernizing-with-aws/set-up-high-availability-for-sql-server-at-dr-site-using-aws-elastic-disaster-recovery/) (Microsoft ワークロードオン AWS)
# SQL Server ライセンスを理解する
## 概要:
ワークロードをクラウドに移行する企業が増えるにつれて、クラウドプラットフォームのコストの最適化が最優先事項となっています。ライセンスは、Microsoft ワークロードの実行に関連する最も重要なコストの 1 つです AWS。このセクションでは、SQL Server の Microsoft ライセンスを最適化 AWS して のコストを最適化する方法について説明します。
## AWS ライセンスオプション
AWS は、ライセンス用にさまざまな柔軟なコスト最適化の選択肢を提供します。これらのライセンスオプションは、コストを削減し、コンプライアンスを維持し、ビジネスニーズを満たすのに役立つように設計されています。
![\[ライセンスの購入や持ち込みなどのライセンスオプションを確認します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/aws_licensing_options.png)
AWS はライセンスを 3 つの主なタイプに分類します。
1. **ライセンス込み** – このライセンスオプションを使用すると、ライセンスをオンデマンドで購入して使用でき、使用した分に対してのみ料金が発生します。ライセンス込みオプションは、ライセンスの使用に柔軟性が必要で、前払いコストを回避したいシナリオに最適です。Windows Server、SQL Server、その他の Microsoft 製品から選択できます。
1. **ライセンスモビリティを備えた Bring Your Own License (BYOL) 製品** – このライセンスオプションは、既存のライセンスがすでにあり、クラウドで使用するシナリオ向けに設計されています。 AWS では、Microsoft の[ライセンスモビリティ](https://www.microsoft.com/en-us/licensing/licensing-programs/software-assurance-license-mobility)プログラムを通じて独自のライセンスをクラウドに持ち込むことができます。SQL Server with Software Assurance (SA) などのライセンスモビリティを持つ製品を共有テナンシーまたは専用テナンシーに持ち込んで、 AWS インスタンスコストを削減できます。
1. **ライセンスモビリティのない BYOL 製品** – Windows Server などのライセンスモビリティを持たない Microsoft 製品の場合、 はクラウドでこれらの製品を使用するための専用オプション AWS を提供します。さらに、専有ホストは、物理コアレベルでライセンスする機会を提供します。これにより、ワークロードの実行に必要なライセンス料を 50% 以上節約できます。専有ホストは、ほぼ常時実行される安定した予測可能なワークロードに最適なオプションです。
## ライセンス持ち込みによるコストへの影響
ライセンスの持ち込みは、 AWSで Microsoft ワークロードを実行するコストに大きな影響を与える可能性があります。独自のライセンスを持ち込む場合、クラウドで実行されているインスタンスに対して追加のライセンスコストを支払う必要はありません。これにより、大幅なコスト削減につながる可能性があります。
次の比較は、1 つの c5.xlarge インスタンスを 24 時間 365 日実行した場合のオンデマンドの月額コストを示しています。
+ Windows Server \$1 SQL Server Enterprise Edition: 1,353 USD/月 (ライセンス込み)
+ Windows Server \$1 SQL Server Standard Edition: 609 USD/月 (ライセンス込み)
+ Windows Server のみ: 259 USD/月 (ライセンス込み)
+ コンピューティングのみ (Linux): 127 USD/月
結局のところ、独自のライセンスを持ち込むと、 AWSで Microsoft ワークロードを実行するコストに大きな影響を与える可能性があります。既存のライセンスを使用すると、ライセンスコストを削減し、 AWS 請求全体のコストを削減できます。
## ライセンスの最適化
AWS 最適化とライセンス評価 (AWS OLA) は、コンピューティングとライセンスのコストを削減することで、ライセンスの最適化に役立ちます。 AWS OLA は、 で実行されているワークロード AWS 、または移行が予定されているワークロードのライセンス要件を評価するように設計されています。 AWS OLA は、ライセンスの使用を最適化するための推奨事項を提供します。
ライセンスの使用を最適化するための重要な戦略の 1 つは、[インスタンスの適切なサイズ設定](rightsize.md)です。適切なサイズ設定を行うには、CPU、メモリ、およびストレージの要件に基づいて、ワークロードに適したインスタンスタイプを選択する必要があります。適切なインスタンスサイズを選択することで、リソースをコスト効率の高い方法で使用できるようになります。これにより、大幅なコスト削減につながる可能性があります。
Microsoft ソフトウェアライセンスでは、ソフトウェアが実行されるコアの数は、ライセンスコストを決定する上で重要な要素です。例えば、Windows Server および SQL Server ライセンスは通常、コア数に基づいてライセンスされます。インスタンスのサイズを適切に設定することで、Microsoft ソフトウェアが実行されるコアの数を減らし、インスタンスのコストと必要なライセンスの数の両方を減らすことができます。
## コスト最適化の推奨事項
ライセンスの最適化は、 AWSでのコスト最適化の重要な要素です。適切な戦略を実装することで、ライセンスコストを削減し、コンプライアンスを維持し、ライセンス投資から最良の価値を実現することができます。このセクションでは、ライセンス最適化のいくつかの戦略の概要を説明します。
### 対象となる Windows Server ライセンスの持ち込み
独自の Windows Server ライセンスの持ち込みは、ライセンス最適化の最も効果的な戦略の 1 つです。この戦略により、既存の投資を活用して AWS 支出を削減できます。
例えば、2019 年 1 月 10 日より前にライセンスを購入した場合、またはその日付より前に署名された有効な Enterprise 契約の下でライセンスを調整として購入した場合は、Windows Server 2019 以前のバージョンを [Amazon EC2 専有ホスト](https://aws.amazon.com/ec2/dedicated-hosts/)にデプロイできます。このルールは、Microsoft が 2019 年に、Windows Server などのライセンスモビリティのない製品のライセンス条項を、[出品プロバイダー](https://www.microsoft.com/licensing/docs/view/Listed-Providers) (Alibaba AWS、Google Cloud など) にデプロイした場合に行った変更に基づいています。新しい条件では、独自の Windows Server ライセンスを に持ち込むことはできません AWS が、代わりにライセンス込みインスタンスを使用する必要があります。ただし、その日より前に永続的ライセンスを購入した場合は、引き続きそれらの Windows Server ライセンスを Amazon EC2 専有ホストにデプロイできます。
### 物理レベルのライセンス
物理コアレベルでライセンスすることで、ホストの物理コアのみをライセンスできるため、必要なライセンス数に影響を与えることなく、最大数のインスタンスをデプロイできます。これは通常、Windows Server Datacenter および SQL Server Enterprise Edition を使用して行われます。
例として、48 個のコアを持つ R5 専有ホスト (96 個の vCPU に相当) について考えてみましょう。Windows Server Datacenter Edition を使用する場合、必要なライセンスは 48 個のみです。これにより、次の図に示すように、最大 96 個の vCPU を持つインスタンスの組み合わせをデプロイできるようになります。
![\[物理レベルのライセンス\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/r5_dh_licenses.png)
このアプローチは、ホストで実行できるインスタンスの数を最大化するのに十分なワークロードがある場合に、特に費用対効果が高くなります。物理コアレベルでライセンスすることで、インスタンスごとの追加のライセンスコストを回避し、ライセンス投資に対して最良の価値を実現できます。
### SQL Server の物理コアレベルでのライセンス
共有テナンシーでは、SQL Server ライセンスは、インスタンスに割り当てられた vCPU の数に基づきます。これに対し、専有ホストでは、物理コアレベルまたは vCPU レベルで SQL Server Enterprise Edition をライセンスできます。
前述の R5 専有ホストの例と同様に、物理コアレベルで SQL Server Enterprise Edition をライセンスする場合、ホストのライセンスに必要な SQL Server Enterprise Edition ライセンスは 48 個のみです。これに対し、共有テナンシー (オプションは vCPU 単位のライセンスのみ) では、同じワークロードに対して 96 個の SQL Server Enterprise Edition ライセンスが必要です。したがって、専有ホストは、共有テナンシーと比較して SQL Server のライセンスコストを最大 50% 削減できます。これは、対象となる Windows ライセンスを持ち込むことでインスタンスコストを節約することに加えて行われます。
### SQL Server インスタンスの統合
[SQL Server の統合](consolidate-instances.md)は、複数の SQL Server インスタンスを 1 つのサーバーに結合するプロセスです。SQL Server では、インスタンスに vCPU が 2 つしかない場合でも、インスタンスごとに最低 4 つのコアライセンスが必要です。つまり、4 コア未満のサーバーで SQL Server を実行すると、これらのインスタンスを過剰にライセンスし、必要以上のライセンスを使用することになります。
![\[SQL Server の統合\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/sql_server_consolidation.png)
例えば、それぞれ 2 つの vCPU を持つ 2 つのインスタンスを、4 つの vCPU を持つ 1 つのインスタンスに統合すると、ライセンス要件を 50% 削減できます。これは、8 つではなく 4 つのコアライセンスのみ必要となるためです。
統合の詳細については、このガイドの「[SQL Server consolidation](consolidate-instances.md)」セクションを参照してください。
### SQL Server エディションのダウングレード
[SQL Server エディションの変更](sql-server-editions.md)は、ライセンスの使用を最適化し、コストを削減するための重要な戦略となります。SQL Server の Enterprise エディションは Standard エディションよりもかなり高価であるため、ダウングレードすると大幅なコスト削減につながる可能性があります。
透過的なデータ暗号化 (TDE) と Always On 可用性グループは、SQL Server Enterprise Edition で人気の高い 2 つの機能です。ただし、SQL Server Enterprise Edition の完全な機能セットが必要ない場合は、これらの機能に代わるコスト効率の高い代替方法を検討することもできます。例えば、TDE は、SQL Server 2019 以降の SQL Server Standard Edition で利用できます。Always On 可用性グループの代わりに、FSx for Windows File Server の共有ストレージでフェイルオーバークラスタリングを使用することで、SQL Server Standard Edition で高可用性を実現できます。
SQL Server Enterprise Edition から SQL Server Standard Edition にダウングレードすることで、ライセンスコストを大幅に削減できます。詳細については、 AWS ストレージブログの記事の[「高可用性 SQL Server デプロイのコストの最適化 AWS](https://aws.amazon.com/blogs/storage/optimizing-cost-for-your-high-availability-sql-server-deployments-on-aws/)」を参照してください。
ライセンスコストの削減に加えて、SQL Server エディションをダウングレードすると、ソフトウェアアシュアランスの支出を削減し、将来の調整を回避することができます。未使用のライセンスをシェルフに返せば、追加のライセンスコストを回避し、ライセンス投資から最良の価値を得ることができます。
SQL Server ワークロードを慎重に評価し、ビジネスニーズにとって重要な機能を判断することが重要です。詳細については、 AWS 「 規範ガイダンス[」の「環境の評価](https://docs.aws.amazon.com/prescriptive-guidance/latest/evaluate-downgrading-sql-server-edition/assess-environment.html)」を参照し、Microsoft SQL Server データベースが SQL Server Enterprise エディション固有の機能を使用しているかどうかを確認します。
SQL Server の適切なエディションを選択し、SQL Server Enterprise Edition の機能に代わるものを使用すると、コンプライアンスを維持し、ビジネスニーズを満たすと同時に、大幅なコスト削減を実現できます。ダウングレードオプションの詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。
### 非本番環境での SQL Server Developer Edition の使用
非本番環境では、オンプレミス環境で MSDN サブスクリプションを使用して、Enterprise Edition や Standard Edition などの SQL Server のライセンス可能エディションをデプロイできます。ただし、MSDN サブスクリプションにはライセンスモビリティはありません。したがって、 に移行する場合 AWS、これらのライセンスを引き継ぐことはできません。代わりに SQL Server Developer Edition を使用する必要があります。
SQL Server Developer Edition は、SQL Server のフル機能のエディションで、無料で利用できます。このエディションは、SQL Server バージョン 2016 以降で使用できます。また、Microsoft のウェブサイトからダウンロードできます。SQL Server Developer Edition は、本番環境のライブデータに接続していない限り、開発、テスト、ステージングなど、すべての非本番環境で使用することを目的としています。
SQL Server Developer Edition を非本番環境で使用した場合、追加のライセンスコストを回避できます。詳細については、このガイドの「[SQL Server Developer Edition を評価する](sql-server-dev.md)」セクションを参照してください。
### SQL Server ワークロードの CPU の最適化
RAM やネットワークの制限などの他の要因により、ワークロードに必要な数よりも多くの CPU を持つインスタンスタイプを選択しなければならない場合があります。ただし、 AWS は、このような状況でライセンスコストを最適化するのに役立つソリューションを提供します。
SQL Server コアライセンスを持ち込むほとんどのお客様と同様に、EC2 インスタンスでハイパースレッディングを無効にするか CPU をオフにして、ホストで使用できる CPU の数を制限できます。このオプションを使用すると、追加のライセンスを購入するコストを節約しながら、RAM などの他のインスタンス機能を利用できます。
たとえば、ワークロードに必要なメモリが 128 GB で、SQL Server のコアが 8 つしかないために r5.4xlarge インスタンスをデプロイする場合、アクティブな CPUs が 8 つしかないインスタンスのハイパースレッディングを無効にすることができます。これにより、アクティブに使用されている 8 個のコアのライセンスのみが必要となるため、必要な SQL Server ライセンスを 50% 削減できます。
****
| インスタンスタイプ | vCPU の合計 | CPU の最適化機能を備えたアクティブな vCPU | SQL Server ライセンスの節約 |
| --- | --- | --- | --- |
| r5.4xlarge | 16 | 8 | 50% |
| r5.12xlarge | 48 | 8 | 83% |
CPU の最適化機能は、Amazon EC2 起動設定中、または既存のインスタンスを変更することで設定できます。また、BYOL インスタンスとライセンス込みの Amazon EC2 インスタンスの両方に適用することもできます。この柔軟性により、CPU をワークロードのニーズに合わせてサイズ変更しながら、 Windows Server および SQL Serverライセンスを削減できます。ライセンス込みの Amazon EC2 インスタンスの場合、CPUsことでライセンスコストを即座に削減できます。
インスタンスのサイズを適正化すると、ワークロードに対して最も費用対効果の高いインスタンスタイプを確実に使用できるようになります。に新しいインスタンスタイプ AWS が導入されたため、これらの新しいインスタンスがより少ないコアでワークロード要件を満たすことができるかどうかを評価することが重要です。
## その他のリソース
+ [アマゾン ウェブ サービスと Microsoft: よくある質問](https://aws.amazon.com/windows/faq/) (AWS ドキュメント)
# SQL Server ワークロードに適した EC2 インスタンスを選択する
**重要**
このセクションを読む前に、このガイドの「[SQL Server ライセンスを理解する](sql-server-licensing.md)」セクションと「[Select the right instance type for Windows workloads](right-size-selection.md)」セクションを読んでおくことをお勧めします。
## 概要:
Microsoft SQL Server は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで 15 年以上実行されています。 AWS はその経験を積んでおり、最小限の仕様から高パフォーマンスのマルチリージョンクラスターまで実行される SQL Server ワークロードに合わせて Amazon EC2 インスタンスを開発するのに役立ちます。
SQL Server の正しい EC2 インスタンスの選択は、ワークロードに大きく依存します。SQL Server のライセンス方法、メモリの使用方法、そして SQL Server の機能が Amazon EC2 サービスとどのように連携しているかを理解することは、アプリケーションに最適な EC2 インスタンスを導くのに役立ちます。
このセクションでは、さまざまな SQL Server ワークロードと、ライセンスとコンピューティングのコストを最小限に抑えるために特定の EC2 インスタンスと組み合わせる方法について説明します。
## コスト比較
Amazon EC2 では、Bring Your Own License (BYOL) を使用するか、Windows Server および SQL Server ライセンスで従量制料金を使用することができます。従量制料金ライセンスの場合、Windows Server および SQL Server ライセンスのライセンスコストは、EC2 インスタンスの時間単位のコストに組み込まれます。例えば、異なる料金の異なる AMI を持つことができます。AMI の料金は、AMI が実行される SQL Server エディションによって異なります。
Windows Server と SQL Server の料金は項目化されません。[AWS 料金見積りツール](https://calculator.aws/) のようなツールには項目別料金はありません。ライセンス込みサービスのさまざまな組み合わせを選択した場合は、次の表に示すようにライセンスコストを推定できます。
****
| EC2 インスタンス | AMI | コンピューティング料金 | Windows ライセンス料金 | SQL ライセンス料金 | 合計料金 |
| --- | --- | --- | --- | --- | --- |
| r5.xlarge | Linux (コンピューティング料金) | 183.96 USD | - | - | 183.96 USD |
| r5.xlarge | Linux \$1 SQL Developer | 183.96 USD | \$10 | \$10 | 183.96 USD |
| r5.xlarge | Windows Server (LI) | 183.96 USD | 134.32 USD | - | 318.28 USD |
| r5.xlarge | Windows \$1 SQL Developer | 183.96 USD | 134.32 USD | \$10 | 318.28 USD |
| r5.xlarge | Windows \$1 SQL Web (LI) | 183.96 USD | 134.32 USD | 49.64 USD | 367.92 USD |
| r5.xlarge | Windows \$1 SQL Standard (LI) | 183.96 USD | 134.32 USD | 350.4 USD | 668.68 USD |
| r5.xlarge | Windows \$1 SQL Enterprise (LI) | 183.96 USD | 134.32 USD | 1,095 USD | 1413.28 USD |
**注記**
前の表の料金は、`us-east-1` リージョンのオンデマンド料金に基づいています。
SQL Server を実行する最も費用対効果の高い方法は、上位エディションの機能が必要になるまで、下位エディションのままにしておくことです。詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」セクションを参照してください。SQL Server Web Edition から SQL Server Standard Edition へのアップグレードは、SQL Server ライセンスコストの 7 倍を超え、Standard Edition から Enterprise Edition への移行コストの 3 倍を超えます。ライセンスコストの格差は考慮すべき重要な要素であり、このセクションの残りの部分で説明します。
## コスト最適化シナリオ
配送車両を追跡する分析会社が SQL Server のパフォーマンスの向上を検討しているというシナリオの例を考えてみましょう。MACO の専門家が会社のパフォーマンスのボトルネックを確認した後、会社は 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` リージョンのオンデマンド料金に基づいています。
## コスト最適化の推奨事項
### メモリ最適化インスタンス
SQL Server の最も重要な側面の 1 つは、メモリへの依存を理解することです。SQL Server は、オペレーティングシステムで使用されていない使用可能なすべての RAM を使用しようとします (デフォルトのインストールでは最大 2 TB)。これはパフォーマンス上の理由から行われます。メモリ内のデータを操作する方が、絶えずディスクからデータをプルし、変更を加えてディスクに書き戻すよりもはるかにパフォーマンスが高くなります。代わりに、SQL Server はアタッチされたデータベースからできるだけ多くのデータをロードしようとし、そのデータを RAM に保持します。データに対する変更はメモリ内で実行され、後でディスクに書き込まれます。
**注記**
SQL Server が変更を書き込む方法の詳細については、Microsoft ドキュメントの「[Writing Pages](https://learn.microsoft.com/en-us/sql/relational-databases/writing-pages?view=sql-server-ver16)」を参照してください。
SQL Server は RAM 容量が大きいほどパフォーマンスが向上するため、通常は [Amazon EC2 メモリ最適化](https://aws.amazon.com/ec2/instance-types/#Memory_Optimized)インスタンスタイプから始めることをお勧めします。メモリ最適化インスタンスは汎用性が高く、さまざまなオプションを提供します。R ファミリーは、vCPU と RAM の比率が 1 対 8 で、インテルプロセッサ、AMD プロセッサ、拡張ネットワーキング、拡張 EBS パフォーマンス、インスタンスストレージ、拡張プロセッサ速度のオプションがあります。メモリ負荷の高いワークロード向けに、同じオプションを多数組み合わせ、vCPU と RAM の比率を 1 対 32 に拡張する X ファミリーもあります。メモリ最適化インスタンスは汎用性があるため、あらゆる形状およびサイズの SQL Server ワークロードに適用できます。
### 最小リソース未満 (4 vCPU 未満) のワークロード
一部のユースケースはバースト可能 (T3) インスタンスでうまく機能しますが、通常は SQL Server ワークロードにバースト可能インスタンスを使用しないことをお勧めします。SQL Server のライセンスは、インスタンスに割り当てられた vCPU の数に基づいています。SQL Server が 1 日の大半がアイドル状態で、バーストクレジットを取得している場合は、完全に活用されていない SQL ライセンスに対して料金が発生します。さらに、SQL Server には、サーバーあたり 4 コアの最小ライセンス要件があります。つまり、4 vCPU 分のコンピューティング能力を必要としない SQL Server ワークロードがある場合、使用していない SQL Server ライセンスを支払っていることになります。これらのシナリオでは、より大きなサーバーに[複数の SQL Server インスタンスを統合する](consolidate-instances.md)のが最適です。
### 最小リソース (64 GB 未満の RAM) を使用するワークロード
64 GB RAM 未満の SQL Server ワークロードの多くは、高パフォーマンスまたは高可用性を優先しません。これらのタイプのワークロードでは、アプリケーションが Microsoft のライセンス制限の対象である場合、SQL Server Web Edition が適している可能性があります。
**重要**
SQL Server Web Edition には、Microsoft のライセンス条項に基づいてユースケースが制限されています。SQL Server Web Edition のライセンスは、パブリックアクセスやインターネットアクセスが可能なウェブページ、ウェブサイト、ウェブアプリケーション、およびウェブサービスをサポートします。基幹業務アプリケーション (顧客関係管理、企業リソース管理、その他の類似アプリケーションなど) のサポートには使用できない可能性があります。
SQL Server Web Edition は、最大 32 vCPU および 64 GB RAM までスケール可能で、SQL Server Standard Edition よりも 86% 安価です。リソースの少ないワークロードでは、Intel の同等のものと比較してコンピューティング料金が 10% 安価な r6a などの AMD メモリ最適化インスタンスを使用することも、コンピューティングと SQL のライセンスコストを最小限に抑える良い方法です。
### 平均リソース (128 GB 未満の RAM) のワークロード
SQL Server Standard Edition は、最大 128 GB の RAM の SQL Server ワークロードの大部分で使用されます。SQL Server Standard Edition は、SQL Server Enterprise Edition よりも 65～75% 安価で、最大 48 vCPU および 128 GB RAM までスケールできます。通常、128 GB RAM の制限は 48 vCPU の制限より前に発生するため、この点が、SQL Server Enterprise Edition へのアップグレードを避けたいほとんどのお客様の焦点となります。
SQL Server には、[バッファプール拡張機能](https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/buffer-pool-extension?view=sql-server-ver16)と呼ばれる機能があります。この機能により、SQL Server はディスクの一部を使用して RAM の拡張として機能させることができます。バッファプール拡張機能は、[Amazon EC2 インスタンスストレージ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)で使用される NVMe SSD などの超高速ストレージと組み合わせると、うまく機能します。インスタンスストレージを含む Amazon EC2 インスタンスは、インスタンス名に「d」と表示されます (r5d、r6id、x2iedn など)。
バッファプール拡張機能は、通常の RAM に代わるものではありません。ただし、128 GB を超える RAM が必要な場合は、r6id.4xlarge や x2iedn.xlarge などの EC2 インスタンスでバッファプール拡張機能を使用して、Enterprise Edition ライセンスへのアップグレードを遅らせることができます。
### 高パフォーマンスワークロード (128 GB を超える RAM)
高いパフォーマンスを必要とする SQL Server ワークロードは、多くのリソースに依存するため、コスト最適化が困難です。ただし、EC2 インスタンスの違いを理解することで、間違った選択を防ぐことができます。
次の表は、さまざまなメモリ最適化 EC2 インスタンスとそのパフォーマンス制限を示しています。
****
| | r5b | r6idn | r7iz | x2iedn | x2iezn |
| --- | --- | --- | --- | --- | --- |
| プロセッサ | 3.1 GHz第 2 世代インテル Xeon プロセッサ | 3.5 GHz第 3 世代インテル Xeon プロセッサ | 3.9 GHz第 4 世代インテル Xeon スケーラブルプロセッサ | 3.5 GHz第 3 世代インテル Xeon プロセッサ | 4.5 GHz第 2 世代インテル Xeon プロセッサ |
| CPU と RAM の比率 | 1:8 | 1:8 | 1:8 | 1:32 | 1:32 |
| 最大 vCPU | 96 | 128 | 128 | 128 | 48 |
| 最大 RAM | 768 GB | 1,024 GB | 1,024 GB | 4,096 GB | 1,536 GB |
| インスタンスストレージ | – | NVMe SSD(4x 1900 GB) | – | NVMe SSD(2x 1900 GB) | – |
| io2 Block Express | サポート対象 | サポート対象 | サポート対象 | サポート | – |
| 最大 EBS IOPS | 260,000 | 350,000 | 160,000 | 260,000 | 80,000 |
| 最大 EBS スループット | 60 Gbps | 80 Gbps | 40 Gbps | 80 Gbps | 19 Gbps |
| 最大ネットワーク帯域幅 | 25 Gbps | 200 Gbps | 50 Gbps | 100 Gbps | 100 Gbps |
各インスタンスは異なる目的に使用されます。SQL Server ワークロードを理解すると、最適なインスタンスタイプを選択するのに役立ちます。
属性の詳細:
+ **r5b** – r5b の「b」属性は、このインスタンスタイプが高 EBS パフォーマンスに焦点を当てていることを意味します。第 5 世代のメモリ最適化インスタンスでは、r5b が優先選択肢でした。これは、io2 Block Express ボリュームを使用し、最大ストレージ IOPS が 260,000 に達した最初のインスタンスタイプでした。r5b インスタンスタイプは、依然として、高 EBS パフォーマンスのニーズに対するコスト効率の高い代替手段です。
+ **r6idn** – 第 6 世代のメモリ最適化インスタンスは、前世代よりも大幅に改善されました。r5b からの EBS パフォーマンスの強化は、r6idn でさらに一歩前進し、最大 IOPS が 350,000 に向上しました。r6idn には、SQL Server のパフォーマンスをさらに向上させるために、tempdb およびバッファプール拡張用のインスタンスストアボリュームもあります。
+ **x2iedn** – x2iedn は r6idn に似ています。同様のレベルの拡張 EBS、拡張ネットワーキング、NVMe SSD インスタンスストレージを提供しますが、高メモリワークロードと低 CPU 量 (SQL Server ライセンスコストが低い) では vCPU と RAM の比率が 1:32 になります。
+ **x2iezn** – x2iezn の「z」属性は、このインスタンスタイプが高プロセッサパフォーマンスに焦点を当てていることを示します。Cascade Lake プロセッサの全コアターボ周波数は最大 4.5 GHz です。vCPU の数を低く抑えたいシナリオでは、この EC2 インスタンスを 1:32 の vCPU と RAM の比率と組み合わせて使用することをお勧めします。これにより、SQL Server のライセンスコストを低く抑えることができます。
+ **r7iz** – r7iz の「z」属性は、このインスタンスタイプが高プロセッサパフォーマンスに焦点を当てていることを示します。Sapphire Rapids プロセッサの全コアターボ周波数は最大 3.9 GHz です。x2iezn インスタンスと同様に、r7iz は高周波プロセッサのパフォーマンスを優先しますが、vCPU と RAM の比率は 1:8 です。
## その他のリソース
+ [汎用 Amazon EC2 インスタンス](https://aws.amazon.com/ec2/instance-types/) (AWS ドキュメント)
+ 「[Comparison tool](https://instances.vantage.sh/)」(Vantage)
+ [ライセンス – SQL Server](https://aws.amazon.com/windows/faq/#licensing-sql) (AWS ドキュメント)
# インスタンスを統合する
このセクションでは、複数の SQL Server インスタンスを同じサーバーに結合してライセンスコストを最小限に抑え、リソース使用率を最大化するコスト最適化手法に焦点を当てます。
## 概要:
インスタンスの作成は、SQL Server データベースエンジンをインストールするプロセスの一部です。SQL Server インスタンスは、独自のサーバーファイル、セキュリティログイン、システムデータベース (マスター、モデル、msdb、tempdb) を含む完全なインストールです。インスタンスには独自のファイルとサービスがすべて備わっているため、インスタンスの相互の干渉なく、同じオペレーティングシステムに複数の SQL Server インスタンスをインストールできます。ただし、インスタンスはすべて同じサーバーにインストールされるため、コンピューティング、メモリ、ネットワークなどの同じハードウェアリソースを共有します。
通常、本番環境ではサーバーごとに 1 つの SQL Server インスタンスのみを使用し、「ビジー」インスタンスが共有ハードウェアリソースを過剰に使用しないようにします。各 SQL Server インスタンスに、独自のリソースを持つ独自のオペレーティングシステムを提供することは、リソースガバナンスに依存するよりも優れた境界となります。これは、大量の RAM と CPU のリソースを必要とする高パフォーマンス SQL Server ワークロードに特に当てはまります。
ただし、すべての SQL Server ワークロードが大量のリソースを使用するわけではありません。例えば、一部の組織では、コンプライアンスまたはセキュリティの目的で、各顧客に独自の専用 SQL Server インスタンスを割り当てています。小規模なクライアントや通常はアクティブではないクライアントの場合は、最小限のリソースで SQL Server インスタンスを実行することになります。
「[Microsoft SQL Server 2019: Licensing guide](https://download.microsoft.com/download/e/2/9/e29a9331-965d-4faa-bd2e-7c1db7cd8348/SQL_Server_2019_Licensing_guide.pdf)」に記載されているように、SQL Server を実行している各サーバーは、最低 4 つの CPU ライセンスを考慮する必要があります。つまり、2 つの vCPU のみでサーバーを実行する場合でも、4 つの vCPU の SQL Server ライセンスを取得する必要があります。[Microsoft が公開している SQL Server の価格](https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing)に基づくと、SQL Server Standard Edition を使用する場合の差額は 3,945 USD になります。最小限のリソースを使用して 1 つの SQL Server インスタンスで複数のサーバーを実行している組織では、未使用のリソースをライセンスしなければならない場合の合計コストが高額になる可能性があります。
## コスト最適化シナリオ
このセクションでは、それぞれが 1 つの SQL Server インスタンスを持つ 4 つの Windows Server サーバーの実行と、複数の SQL Server インスタンスを同時に実行する 1 つの大きな Windows Server サーバーの実行の違いを比較するシナリオの例について説明します。
各 SQL Server インスタンスが 2 つの vCPU と 8 GB RAM のみを必要とする場合、サーバーあたりの合計コストは、SQL Server ライセンスに対して 7,890 USD、さらに 1 時間あたりのコンピューティング コストとして 0.096 USD になります。
****
| EC2 インスタンス | vCPU | RAM | 料金 | ライセンスする vCPU | SQL Server ライセンスコストの合計 |
| --- | --- | --- | --- | --- | --- |
| m6i.large | 2 | 8 | 0.096 | 4 | 7,890 USD |
これを 4 つのサーバーに拡張すると、合計コストは、SQL Server ライセンスに対して 31,560 USD、さらに 1 時間あたりのコンピューティング コストとして 0.384 USD になります。
****
| EC2 インスタンス | vCPU | RAM | 料金 | ライセンスする vCPU | SQL Server ライセンスコストの合計 |
| --- | --- | --- | --- | --- | --- |
| 4x m6i.large | 2 | 32 | 0.384 | 16 | 31,560 USD |
4 つの SQL Server インスタンスをすべて 1 つの EC2 インスタンスに結合した場合、コンピューティングリソースとコンピューティングの合計量は同じままになります。ただし、不要な SQL Server ライセンスコストを排除することで、ワークロードを実行する合計コストを 15,780 USD 削減できます。
****
| EC2 インスタンス | vCPU | RAM | 料金 | ライセンスする vCPU | SQL Server ライセンスコストの合計 |
| --- | --- | --- | --- | --- | --- |
| m6i.2xlarge | 8 | 32 | 0.384 | 8 | 15,780 USD |
**注記**
上記の表では、コンピューティングコストは、`us-east-1` リージョンで Windows Server を実行している Amazon EC2 サーバーの時間単位のオンデマンド料金を示しています。SQL Server Standard Edition のライセンスコストは、[Microsoft が公開している SQL Server の価格](https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing)を参照しています。
## コスト最適化の推奨事項
SQL Server インスタンスの統合を検討している場合、最大の懸念事項は、統合する各インスタンスのリソース消費量です。各サーバーのワークロードパターンをよりよく理解するには、長期間にわたってパフォーマンスメトリクスを取得することが重要です。リソース消費モニタリングの一般的なツールには、[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-basic-detailed.html)、[Windows Performance Monitor](https://techcommunity.microsoft.com/t5/ask-the-performance-team/windows-performance-monitor-overview/ba-p/375481) (perfmon)、SQL Server の[ネイティブモニタリングツール](https://learn.microsoft.com/en-us/sql/relational-databases/performance/performance-monitoring-and-tuning-tools?view=sql-server-ver16)があります。
SQL Server ワークロードを組み合わせて互いに干渉することなく同じサーバーリソースを使用できるかどうかを分析するときは、次の質問を検討することをお勧めします。
+ 定常状態で消費されるリソースは何か (CPU、メモリ、ネットワーク帯域幅)。
+ スパイク時に消費されるリソースは何か (CPU、メモリ、ネットワーク帯域幅)。
+ スパイクはどのくらいの頻度で発生するか。スパイクは一貫しているか。
+ あるサーバーのリソーススパイクが別のサーバーのリソーススパイクと一致しているか。
+ SQL Server で使用されるストレージの IOPS とスループットはどれくらいか。
SQL Server インスタンスを組み合わせる計画を進める場合は、 AWS クラウド運用および移行ブログの記事「[Run multiple instances of SQL Server on one Amazon EC2 instance](https://aws.amazon.com/blogs/mt/run-multiple-instances-sql-server-on-one-amazon-ec2-instance/)」を参照してください。この記事では、SQL Server で設定を変更してインスタンスを追加する方法について説明しています。開始する前に、同じサーバーに複数のインスタンスがインストールされる場合の小さな違いを考慮してください。
+ デフォルトの SQL Server データベースインスタンスの名前は `MSSQLSERVER` で、ポート 1433 を使用します。
+ 同じサーバーにインストールされる各追加インスタンスは、「名前付き」データベースインスタンスです。
+ 各名前付きインスタンスには、一意のインスタンス名と一意のポートがあります。
+ 名前付きインスタンスへのトラフィックを調整するには、[SQL Server Browser](https://learn.microsoft.com/en-us/sql/tools/configuration-manager/sql-server-browser-service?view=sql-server-ver16) を実行する必要があります。
+ 各インスタンスは、データベースデータファイル用に個別の場所を使用でき、個別のログインを使用できます。
+ SQL Server の[最大サーバーメモリ設定](https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/server-memory-server-configuration-options?view=sql-server-ver16)は、各インスタンスのパフォーマンスニーズに応じて設定する必要があり、合わせた合計において、基盤となるオペレーティングシステムに十分なメモリも残しておく必要があります。
+ 移行や統合には、SQL Server の[ネイティブバックアップおよび復元](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases?view=sql-server-ver16)機能、または [AWS DMS](https://aws.amazon.com/blogs/database/consolidate-data-from-identical-sql-server-databases-into-a-single-amazon-rds-for-sql-server-database-using-aws-dms/) を使用できます。
## その他のリソース
+ [SQL Server Licensing Datasheet](https://download.microsoft.com/download/0/5/c/05c60185-ebdd-4472-895a-3d8e8da55682/SQL_Server_2019_Licensing_Datasheet.pdf) (AWS クラウドオペレーションと移行ブログ)
+ [SQL Server マルチインスタンスセットアップブログ記事](https://aws.amazon.com/blogs/mt/run-multiple-instances-sql-server-on-one-amazon-ec2-instance/) (AWS クラウドオペレーションと移行ブログ)
# SQL Server エディションの比較
## 概要:
Microsoft SQL Server ライセンスは、Windows ワークロード環境の最大のコストの 1 つです。SQL Server のライセンスコストは、ワークロードを実行するためのコンピューティングコストを簡単に超える可能性があります。間違ったエディションを選択すると、使用していない機能や不要な機能に対して料金が発生する可能性があります。このセクションでは、次の SQL Server エディションについて、機能や相対コストなどを比較します。
+ **Enterprise** – SQL Server Enterprise Edition は、高パフォーマンス、無制限の仮想化、および複数のビジネスインテリジェンス (BI) ツールを備えたデータセンター機能を提供します。
+ **Standard** – SQL Server Standard Edition は、小規模な組織や部門に基本的なデータ管理機能およびビジネスインテリジェンスを提供します。
+ **Web** – SQL Server Web Edition は、ウェブホスティング業者またはウェブ付加価値プロバイダー (VAP) である企業に適しています。このエディションは、総保有コストが低く、小規模から大規模のウェブプロパティにスケーラビリティおよび管理機能を提供します。
**重要**
SQL Server Web Edition を使用すると、パブリックアクセスやインターネットアクセスが可能なウェブページ、ウェブサイト、ウェブアプリケーション、およびウェブサービスのみをサポートできます。SQL Server Web Edition を使用して、基幹業務アプリケーション (顧客関係管理アプリケーションやエンタープライズリソース管理アプリケーションなど) をサポートすることはできません。
+ **Developer** – SQL Server Developer Edition には Enterprise Edition のすべての機能が含まれていますが、開発のみを目的としています。
+ **Express** – SQL Server Express Edition は無料のデータベースであり、学習やデスクトップアプリケーションの構築に使用できます。Express Edition は、他のエディションにアップデートできます。
**注記**
SQL Server Evaluation Edition は、180 日間のトライアル期間で利用できます。
## コストへの影響
Microsoft 販売代理店から SQL Server ライセンスを購入し、ソフトウェアアシュアランスを使用して AWS に持ち込むことができます。または、ライセンス込みの Amazon EC2 AMI が含まれる従量制料金モデルで SQL Server ライセンスを使用することもできます。
Microsoft 販売代理店から SQL Server ライセンスを購入する場合、コアライセンスは 2 つのパックで販売され、サーバーごとに最低 4 つのコアをライセンスする必要があります。次の表は、Enterprise Edition と Standard Edition のコストの比較を示しています。
****
| バージョン | SQL Server Enterprise Edition (2 コアパック) | SQL Server Standard Edition (2 コアパック) | 削減量 |
| --- | --- | --- | --- |
| 2022 | 15,123 USD | 3,945 USD | 74% |
| 2019 | 13,748 USD | 3,586 USD | 74% |
**注記**
上記の表の料金は、Microsoft が公開している、[SQL Server 2022](https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing) および [SQL Server 2019](https://www.microsoft.com/en-us/sql-server/sql-server-2019-pricing) の価格に基づいています。
次のコスト比較は、ライセンス込みの Amazon EC2 AMI を使用して SQL Server のさまざまなエディションをホストする場合を示しています。この比較では、SQL Server は `us-east-1` リージョンの r6i.xlarge (4 vCPU) でホストされます。
****
| インスタンス | コンピューティングコスト | Windows ライセンスコスト | SQL Server ライセンスコスト | Total |
| --- | --- | --- | --- | --- |
| R6i.xlarge (Linux) | 183.96 USD | – | – | 183.96 USD |
| R6i.xlarge \$1 Windows | 183.96 USD | 134.32 USD | – | 318.28 USD |
| R6i.xlarge \$1 SQL Server Web Edition | 183.96 USD | 134.32 USD | 49.35 USD | 367.63 USD |
| R6i.xlarge \$1 SQL Server Standard Edition | 183.96 USD | 134.32 USD | 350.4 USD | 668.68 USD |
| R6i.xlarge \$1 SQL Enterprise Edition | 183.96 USD | 134.32 USD | 1,095 USD | 1,413.28 USD |
ワークロードに適した SQL Server エディションを選択することで、SQL Server のライセンスコストを最大 95% 削減できます。次の表は、r6i.xlarge インスタンスの SQL Server ライセンスのコストを比較したものです。
****
| Edition | 削減 (%) |
| --- | --- |
| Standard と Enterprise の比較 | 68% |
| Web と Standard の比較 | 86% |
| Web と Enterprise の比較 | 95% |
ほとんどのシナリオでは、組織は Enterprise Edition から Standard Edition に切り替えますが、Standard Edition または Enterprise Edition から Web Edition への切り替えが可能な場合もあります。
## コスト最適化の推奨事項
スケーリング制限、高可用性、パフォーマンス、セキュリティに基づいて、ワークロードに最適なエディションを選択できます。次の表は、SQL Server エディションでサポートされている機能を示しています。これは、使用するエディションを決定するのに役立ちます。この比較は、[SQL Server 2016 SP1 以降のバージョン](https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2022?view=sql-server-ver16)に適用されます。
### [Scaling limits]（スケーリング履歴）
次の表は、さまざまな SQL Server エディションのスケーリング制限を比較したものです。
****
| 機能 | Enterprise Edition | Standard Edition | Web Edition | Express Edition |
| --- | --- | --- | --- | --- |
| SQL Server データベースエンジン、SQL Server Analysis Services (SSAS)、または SQL Server Reporting Services (SSRS) の単一のインスタンスで使用される最大コンピューティングキャパシティ | オペレーティングシステムの最大数 | 4 ソケットまたは 24 コアのいずれか小さい方に制限 | 4 ソケットまたは 16 コアのいずれか小さい方に制限 | 4 ソケットまたは 4 コアのいずれか小さい方に制限 |
| SQL Server データベースエンジンのインスタンスあたりのバッファプールの最大メモリ | オペレーティングシステムの最大数 | 128 GB | 64 GB | 1410 MB |
| SQL Server データベースエンジンのインスタンスあたりのバッファプール拡張機能の最大キャパシティ | 最大メモリ設定の 32 倍 | 最大メモリ設定の 4 倍 | 該当なし | 該当なし |
| 最大リレーショナルデータベースサイズ | 524 PB | 524 PB | 524 PB | 10 GB |
| 列ストアキャッシュまたはメモリ最適化データの最大メモリ | オペレーティングシステムの最大数 | 32 GB | 16 GB | 352 MB |
アプリケーションが 16 コア (32 vCPU) 未満のコア数と 64 GB の RAM を必要とする場合は、SQL Server Web Edition から評価を開始できます。ワークロードが 64 GB を超えるメモリやその他の高可用性オプションを必要とする場合は、SQL Server Standard Edition にアップグレードする必要があります。
SQL Server Web Edition を使用して、パブリックアクセスやインターネットアクセスが可能なウェブページ、ウェブサイト、ウェブアプリケーション、ウェブサービスをサポートすることはできますが、SQL Server Web Edition を使用して基幹業務アプリケーションをサポートすることはできません。SQL Server Web Edition のユースケースの詳細については、[Microsoft ライセンスサポート](https://www.microsoft.com/licensing/docs/view/Licensing-Use-Rights)または Microsoft 販売代理店にお問い合わせください。
SQL Server Standard Edition は、最大 24 コア (48 vCPU) と 128 GB のメモリのワークロードに使用できます。ただし、[バッファプール拡張機能](https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/buffer-pool-extension?view=sql-server-ver16)を使用して、SQL Server Standard Edition が、r6id EC2 インスタンスに存在するような[ローカルインスタンスストレージ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)を利用できるようにすることができます。これにより、メモリは最大メモリ設定の 4 倍のサイズまで拡張されます。この機能の組み合わせにより、メモリ要件が増加し始めたときにサーバーを Enterprise Edition にアップグレードするのを先延ばしにすることができます。
メモリ使用率を特定するには、バッファプールのデータベースページと[ページの平均寿命](https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/sql-server-buffer-node?view=sql-server-ver16)のカウンターを見つけます。ページの平均寿命は、ページがディスクにフラッシュされるまでにメモリ内にとどまる時間を示します。このカウンターのデフォルト値は 300 です。ページが数時間または数日間メモリに存在する場合、割り当てられたメモリを減らす可能性があります。
### 高可用性
次の表は、さまざまな SQL Server エディションの高可用性機能を比較したものです。
****
| 機能 | Enterprise Edition | Standard Edition | Web Edition | Express Edition |
| --- | --- | --- | --- | --- |
| サーバーコアサポート 1 | はい | はい | はい | はい |
| ログ配布 | はい | はい | あり | なし |
| データベースのミラーリング | はい | 完全安全モード | ウィットネスとしてのみ | ウィットネスとしてのみ |
| バックアップ圧縮 | はい | あり | なし | いいえ |
| Always On フェイルオーバークラスターインスタンス | 16 ノード | 2 ノード | いいえ | いいえ |
| Always On 可用性グループ | 2 つの同期セカンダリレプリカを含む、最大 8 つのセカンダリレプリカ | いいえ | なし | いいえ |
| 基本的な可用性グループ | いいえ | 2 ノード | いいえ | いいえ |
| オンラインページとファイルの復元 | はい | なし | なし | いいえ |
| オンラインインデックス作成 | はい | なし | なし | いいえ |
| オンラインスキーマの変更 | はい | なし | なし | いいえ |
| 高速リカバリ | はい | なし | なし | いいえ |
| ミラーリングされたバックアップ | はい | なし | なし | いいえ |
| メモリと CPU のホットアド | はい | なし | なし | いいえ |
| 暗号化されたバックアップ | はい | あり | なし | いいえ |
| Microsoft Azure へのハイブリッドバックアップ (URL へのバックアップ) | はい | あり | なし | いいえ |
| ディザスタリカバリ用のフェイルオーバーサーバー | はい | あり | なし | いいえ |
| 高可用性のためのフェイルオーバーサーバー | はい | あり | なし | いいえ |
### その他の一般的な機能
次の表は、さまざまな SQL Server エディションの最も一般的な機能を比較したものです。機能の広範なリストについては、Microsoft ドキュメントの「[Editions and supported features of SQL Server 2019](https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2019?view=sql-server-ver16)」を参照してください。
****
| 機能 | Enterprise Edition | Standard Edition | Web Edition | Express Edition |
| --- | --- | --- | --- | --- |
| (パフォーマンス) リソースガバナー | はい | なし | なし | いいえ |
| (セキュリティ) 透過的データベース暗号化 (TDE) | はい | あり | なし | いいえ |
| (セキュリティ) 拡張キー管理 (EKM) | はい | なし | なし | いいえ |
| (レプリケーション) Oracle の公開 | はい | なし | なし | いいえ |
| (レプリケーション) ピアツーピアトランザクションレプリケーション | はい | なし | なし | いいえ |
| 変更データキャプチャ | はい | あり | なし | いいえ |
### SQL Server Developer Edition
開発、QA、テスト、ステージング、UAT 環境など、非本番ワークロードはすべて、SQL Server Developer Edition を使用して SQL Server のライセンスコストを 100% 節約できます。[SQL Server をダウンロード](https://www.microsoft.com/en-us/sql-server/sql-server-downloads)したら、共有テナンシーを使用して EC2 インスタンスに SQL Server Developer Edition をインストールできます。SQL Server Developer Edition には、専用のインフラストラクチャは不要です。詳細については、このガイドの [SQL Server Developer Edition](sql-server-dev.md) に関する推奨事項を参照してください。
### エディションの切り替え
既存のワークロードの場合、あるエディションから別のエディションに切り替えるには広範なテストが必要です。Enterprise Edition または Standard Edition で実行されているワークロードをチェックして、エディション固有の機能が使用されているか、それらの機能に代替ソリューションがあるかを確認するのがベストプラクティスです。例えば、データベースが Enterprise レベルの機能を使用しているかどうかを確認する場合は、次のコマンド例に示すように、すべてのデータベースで[動的管理ビュー (DMV)](https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-persisted-sku-features-transact-sql?view=azuresqldb-current) を実行できます。
`SELECT feature_name FROM sys.dm_db_persisted_sku_features; GO`
SQL メンテナンスジョブの一環としてのオンラインインデックス再作成など、T-SQL でキャプチャできない Enterprise Edition の機能がいくつかあります。これらは手動で検証する必要があります。
### 移行に関する考慮事項
SQL Server をライセンスする方法によって、エディションを切り替えるためのオプションが決まります。SQL Server AMI を含む AMI では、EC2 インスタンスの料金にライセンスコストが含まれています。ライセンスコストは AMI にバインドされます。[AWS 請求コード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/billing-info-fields.html)を使用して、AMI に含まれる SQL Server のバージョンを検証できます。 AWS ライセンス込みインスタンスの場合、オペレーティングシステム内で SQL Server エディションを変更しても、AMI に関連する請求は変更されません。SQL Server の新しいエディションを実行する AMI を使用して、データベースを新しい EC2 インスタンスに移行する必要があります。
独自のライセンスを持ち込む場合は、柔軟性が高まります。それでも通常は、新しいバージョンを実行している別の EC2 インスタンスに移行することをお勧めします。これにより、何かが計画どおりに進まない場合に簡単にフェイルバックできます。ただし、既存のサーバーを使用する必要がある場合は、SQL Server のサイドバイサイドインストールを実行し、インスタンス間でデータベースを移行することができます。サイドバイサイドエディションダウングレードの詳細な手順については、MSSQLTips ウェブサイトの「[Edition Upgrade and Downgrade in SQL Server](https://www.mssqltips.com/sqlservertip/6686/edition-upgrade-and-downgrade-in-sql-server/)」を参照してください。
## その他のリソース
+ 「[Editions and supported features of SQL Server 2022](https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2022?view=sql-server-ver16)」(Microsoft Learn)
+ 「[sys.dm\$1db\$1persisted\$1sku\$1features (Transact-SQL)](https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-persisted-sku-features-transact-sql?view=azuresqldb-current)」(Microsoft Learn)
+ 「[Which Version of SQL Server Should You Use?](https://www.brentozar.com/archive/2019/01/which-version-of-sql-server-should-you-use/)」 (Brent Ozar Unlimited)
+ [AWS 料金見積りツール](https://calculator.aws/#/estimate?id=e138c18348afd3853a4874681c660bc1947ec5ca) (AWS)
# SQL Server Developer Edition を評価する
## 概要:
[SQL Server Developer Edition](https://www.microsoft.com/en-us/sql-server/sql-server-downloads) は、Enterprise Edition のすべての機能を含む SQL Server の無料エディションであり、非本番環境で使用できます。Microsoft Developer Network (MSDN) ライセンスを使用できないクラウドでは、SQL Server Developer Edition は、開発およびテストワークロードのライセンスを提供することなくコストを削減する優れた方法です。これは、大規模な開発環境とテスト環境を実行し、不要なコストを削減しようとするチームにとって特に当てはまります。
本番環境は、アプリケーションのエンドユーザー (インターネットウェブサイトなど) がアクセスする環境として定義され、そのアプリケーションのフィードバックの収集や受け入れテスト以外にも使用されます。本番環境を構成するその他のシナリオは次のとおりです。
+ 本番データベースに接続する環境
+ 本番環境のディザスタリカバリまたはバックアップをサポートする環境
+ アクティビティのピーク時に本番環境にローテーションされるサーバーなど、少なくともある程度の時間、本番環境に使用される環境
ライセンスの詳細については、 AWS ドキュメントの「[AWS と Microsoft に関するよくある質問](https://aws.amazon.com/windows/faq/)」を参照してください。
## コストへの影響
非本番ワークロードに SQL Server Developer Edition を使用すると、開発環境とテスト環境の現在の SQL Server ライセンスコストを 100% 節約できます。
****
| SQL Server version | SQL Server Enterprise Edition (2 コアパック) | SQL Server Standard Edition (2 コアパック) | SQL Server Developer Edition |
| --- | --- | --- | --- |
| 2022 | 15,123 USD | 3,945 USD | 空き |
| 2019 | 13,748 USD | 3,586 USD | 空き |
**注記**
上記の表の料金は、Microsoft が公開している、[SQL Server 2022](https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing) および [SQL Server 2019](https://www.microsoft.com/en-us/sql-server/sql-server-2019-pricing) の価格に基づいています。
次の表は、`us-east-2` リージョンで 4 つの vCPU で実行され、オンデマンド料金を使用するさまざまな SQL Server エディションのコストを比較したものです。これは、 のライセンス込みインスタンスに依存するシナリオに適用されます AWS。
****
| EC2 インスタンス | AMI | コンピューティング料金 | Windows ライセンス料金 | SQL Server ライセンス料金 | 合計料金 |
| --- | --- | --- | --- | --- | --- |
| r5.xlarge | Linux (コンピューティング料金) | 183.96 USD | – | – | 183.96 USD |
| r5.xlarge | Linux \$1 SQL Server Developer Edition | 183.96 USD | \$10 | \$10 | 183.96 USD |
| r5.xlarge | Windows Server (LI) | 183.96 USD | 134.32 USD | – | 318.28 USD |
| r5.xlarge | Windows \$1 SQL Server Developer Edition | 183.96 USD | 134.32 USD | \$10 | 318.28 USD |
| r5.xlarge | Windows \$1 SQL Server Web Edition (LI) | 183.96 USD | 134.32 USD | 49.64 USD | 367.92 USD |
| r5.xlarge | Windows \$1 SQL Server Standard Edition (LI) | 183.96 USD | 134.32 USD | 350.4 USD | 668.68 USD |
| r5.xlarge | Windows \$1 SQL Server Enterprise Edition (LI) | 183.96 USD | 134.32 USD | 1,095 USD | 1413.28 USD |
### コスト最適化シナリオ
データ整合性企業が新たな買収を行った後、新しく取得したワークロードをマネージドホスティングプロバイダーの現在の場所から移行し、 AWS クラウドの他のワークロードと統合したいと考えました。初期料金では、会社の SQL Server ワークロードは、現在のマネージドサービスプロバイダー AWS よりも で実行されるコストが 60% 高いことがわかりました。MACO SME は見積もりを評価し、顧客が実際に開発環境とテスト環境のマネージドホスティングプロバイダーの SQL Server ライセンスに対して料金を支払っていることがわかりました。この会社は、移行中に非本番ワークロードを SQL Server Developer Edition に切り替えることで、SQL Server のライセンスを 40% 削減しました。
### Amazon EC2 に含まれる SQL Server ライセンス
[ライセンス込み AMI](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/sql-server-on-ec2-amis.html) を使用する EC2 インスタンスに SQL Server がある場合、Enterprise Edition から Developer Edition に直接変換することはできません。ライセンス込みインスタンスのライセンスコストは AMI にバインドされます。SQL Server がオペレーティングシステム内からアンインストールされても、EC2 インスタンスには引き続きライセンスコストが請求されます。
Developer Edition に変換するには、[SQL Server Developer Edition をダウンロード](https://download.microsoft.com/download/c/c/9/cc9c6797-383c-4b24-8920-dc057c1de9d3/SQL2022-SSEI-Dev.exe)し、新しい EC2 インスタンスにインストールしてから、データベースを移行する必要があります。さまざまな方法を使用して EC2 インスタンス間で SQL Server データベースを移行できます。詳細については、「*Microsoft SQL Server データベースの AWS クラウドへの移行*」ガイドの「[SQL Server データベースの移行方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html)」を参照してください。また、[自動化 SQL Server Developer ソリューション](https://aws.amazon.com/blogs/modernizing-with-aws/automating-sql-server-developer-deployments/)を使用して、移行する新しいインスタンスを準備することもできます。
### Amazon EC2 上の SQL Server BYOL
BYOL を使用する SQL Server インスタンスがある場合は、次のインプレース変換またはサイドバイサイドダウングレードオプションから選択できます。
+ Microsoft ウェブサイトから [SQL Server Developer Edition](https://www.microsoft.com/en-us/sql-server/sql-server-downloads) をダウンロードします。手動または自動インストールの手順については、 AWS ブログの記事「[Automating SQL Server Developer deployments](https://aws.amazon.com/blogs/modernizing-with-aws/automating-sql-server-developer-deployments/)」を参照してください。
+ [SQL Server のネイティブバックアップと復元](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases?view=sql-server-ver16)を使用して、データベースを移行するか、ある SQL インスタンスから別の SQL インスタンスにデータベースをデタッチ/アタッチします。
+ 一括デプロイには[自動化ツール](https://github.com/aws-samples/ssm-automation-deploy-sql-developer)を使用します。
**注記**
SQL Server Developer Edition は、非本番環境専用です。
## その他のリソース
+ [EC2 に SQL Server Developer Edition をデプロイするための SQL Server Developer デプロイの自動化](https://aws.amazon.com/blogs/modernizing-with-aws/automating-sql-server-developer-deployments/) (AWS ブログ)
+ 「[SQL 2022 pricing](https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing)」(Microsoft)
+ 「[SQL 2019 pricing](https://www.microsoft.com/en-us/sql-server/sql-server-2019-pricing)」(Microsoft)
+ 「[Licensing options](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/sql-server-on-ec2-licensing-options.html)」(Amazon EC2 での SQL Server)
+ [AWS 料金見積りツール](https://calculator.aws/#/addService/ec2-enhancement) (Amazon EC2 での SQL Server ドキュメント)
+ 「[Microsoft SQL Server 2019 Licensing guide](https://download.microsoft.com/download/e/2/9/e29a9331-965d-4faa-bd2e-7c1db7cd8348/SQL_Server_2019_Licensing_guide.pdf)」(Microsoft からダウンロード)
+ [SQL Server 2022 Developer Edition](https://download.microsoft.com/download/c/c/9/cc9c6797-383c-4b24-8920-dc057c1de9d3/SQL2022-SSEI-Dev.exe) (Microsoft からダウンロード)
# Linux 上の SQL Server を評価する
## 概要:
SQL Server 2017 以降、SQL Server を Linux オペレーティングシステムにインストールできるようになりました。Linux 上の SQL Server はエンタープライズ対応であり、柔軟性、高パフォーマンス、セキュリティ機能、TCO の削減、HA/DR 機能、優れたユーザーエクスペリエンスを提供します。Windows Server の SQL Server から Linux の SQL Server に切り替えることで、Windows Server のライセンスコストを節約できます。
Linux の場合、SQL Server は、Red Hat Enterprise Linux (RHEL)、SUSE Linux Enterprise Server (SLES)、Ubuntu、Amazon Linux 2 にデプロイできます。SQL Server データベースエンジンは、Windows Server でも Linux でも同じ方法で実行されますが、Linux を使用する場合は、特定のタスクにいくつかの基本的な変更があります。SQL Server Always On アプリケーションを Linux と Windows で実行する場合の主な違いの 1 つは、フェイルオーバークラスタリングに関連しています。Windows Server ホストに Always On 可用性グループをデプロイする場合は、フェイルオーバークラスタリングをサポートする組み込み機能として [Windows Server フェイルオーバークラスタリング (WSFC)](https://learn.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server?view=sql-server-ver16) と Active Directory を利用できます。しかし、WSFC も Active Directory も Linux でのフェイルオーバークラスタリングをサポートできません。Linux で SQL Server のフェイルオーバークラスタリングを起動する場合は、[AWS Launch Wizard](https://aws.amazon.com/launchwizard/) で、[ClusterLabs Pacemaker](https://aws.amazon.com/blogs/opensource/deploying-a-highly-available-microsoft-sql-server-on-linux-on-aws/) を使用して、Linux インスタンスでのクラスターのセットアップと SQL のインストールを簡素化できます。
Windows 上および Linux 上の SQL Server は、共通のコードベースを共有します。つまり、SQL Server コアエンジンは、Linux 上で実行するための変更はまったく加えられていません。次の図に示すように、SQL Server はプラットフォーム抽象化レイヤー (SQLPAL) を導入しました。
![\[Sequel Server Platform Abstraction Layer (SQLPAL)\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/sql_pal.png)
SQLPAL は、SQL Server と基盤となるオペレーティングシステム間の呼び出しと通信の抽象化を担当します。ホスト拡張機能は、単なるネイティブ Linux アプリケーションです。低レベルのオペレーティングシステム関数は、I/O、メモリ、CPU 使用率を最適化するためのネイティブ呼び出しです。ホスト拡張機能が起動すると、SQLPAL をロードして初期化し、SQL Server を起動します。SQLPAL は、残りのコードに必要な変換を提供する分離したソフトウェアプロセスを起動します。この新しいレイヤーを SQL Server アーキテクチャに追加すると、Windows 上で SQL Server を強化しているのと同じエンタープライズレベルのコア機能と利点が、オペレーティングシステムに関係なく利用できるようになります。
## コストへの影響
r5.2xlarge インスタンスの場合、Windows Server ライセンスのコスト削減は、各シナリオで約 268 USD です。この削減は、より安価な SQL Server エディションを使用する場合と比較して、サーバーの合計コストの割合が高くなります。次の表は、コスト削減を示しています。
****
| インスタンス | Edition | Windows 上の SQL Server の月額コスト | Linux 上の SQL Server の月額コスト | 削減量 |
| --- | --- | --- | --- | --- |
| r5.2xlarge | Web | 735 USD | 466 USD | 37% |
| r5.2xlarge | 標準 | 1,337 USD | 1,068 USD | 20% |
| r5.2xlarge | Enterprise | 2,826 USD | 2,558 USD | 10% |
**注記**
上記の表の料金見積もりは、`us-east-1` リージョンのオンデマンド料金に基づいており、[AWS 料金見積りツール](https://calculator.aws/#/estimate?id=fd37122637710aa7ba46d1949e8b6a15f68d3c0f) で直接表示できます。
SMB セグメントの ISV 顧客が開発環境のコストを削減しようとしているシナリオの例を考えてみましょう。Windows サーバーのセットで SQL Server Developer Edition を既に使用しています。Windows の SQL Server Developer Edition から Linux の SQL Server Developer Edition に切り替えることで、ISV 顧客は開発ワークロードを 33% 削減できます。次の表は、このシナリオの推定コストを示しています。
****
| Estimate | 月額コスト |
| --- | --- |
| [Windows \$1 SQL Server](https://calculator.aws/#/estimate?id=da0a0f5f58ddf91aa3398af3a78691cfa2204673) | 9,307.72 USD |
| [Linux \$1 SQL Server](https://calculator.aws/#/estimate?id=131966c579020eaec957f441c67e9aa0bfd32411) | 6,218.36 USD |
| 推定コスト削減額 | 3,089.36 USD (33%) |
別のシナリオ例では、ある企業がライセンス込みの SQL Server EC2 インスタンスを Windows から Linux に移行します。同社は、Windows Server のライセンスコストを年間合計 300,000 USD 削減しています。これは合計 AWS 請求額の約 20% です。
## コスト最適化の推奨事項
以下を検討することをお勧めします。
+ Linux 上の SQL Server は、SQL Server 2017 以降でサポートされています。
+ 切り替えを行うには、[Microsoft SQL Server データベースの Windows から Linux へのリプラットフォームアシスタント](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/replatform-sql-server.html)を使用できます。リプラットフォームアシスタントは、一般的な非互換性をチェックし、Windows ホストからデータベースをエクスポートし、Ubuntu 16.04 で Microsoft SQL Server 2017 を実行している EC2 インスタンスにデータベースをインポートすることで、既存の SQL Server ワークロードを Windows オペレーティングシステムから Linux オペレーティングシステムに移行するのを支援するスクリプトツールです。
+ SQL Server の[バックアップおよび復元](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases?view=sql-server-ver16)機能を使用して、Windows 上の SQL Server から Linux に切り替えることもできます。
+ [AWS Launch Wizard](https://docs.aws.amazon.com/launchwizard/latest/userguide/what-is-launch-wizard.html) を使用すると、Linux または Ubuntu 上の SQL Server に簡単かつ迅速にデプロイできます。Launch Wizard では、アプリケーションのニーズに基づいて、スタンドアロンシナリオと高可用性シナリオの両方で SQL Server を Linux または Ubuntu にデプロイできます。詳細については、 AWS ブログの「Microsoft Workloads」の[「Deploying to SQL Server Always on Linux with AWS Launch Wizard](https://aws.amazon.com/blogs/modernizing-with-aws/deploy-microsoft-sql-server-always-on-to-linux-with-aws-launch-wizard/) post」を参照してください。
次の図は、Microsoft SQL Server データベースの Windows から Linux へのリプラットフォームアシスタントを使用するソリューションのアーキテクチャを示しています。
![\[Windows から Linux へのリプラットフォームアシスタントのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/replatforming_assistant.png)
## その他のリソース
+ 「[Overview of SQL Server on Linux](https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-overview?view=sql-server-ver16)」(Microsoft Learn)
+ 「[Installation guide for SQL Server on Linux](https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver16)」(Microsoft Learn)
+ [を使用した SQL Server Always on Linux へのデプロイ AWS Launch Wizard](https://aws.amazon.com/blogs/modernizing-with-aws/deploy-microsoft-sql-server-always-on-to-linux-with-aws-launch-wizard) (Microsoft Workloads on AWS Blog)
+ [Linux での高可用性 SQL Server](https://aws.amazon.com/blogs/opensource/deploying-a-highly-available-microsoft-sql-server-on-linux-on-aws/) (AWS オープンソースブログ)
# SQL Server バックアップ戦略を最適化する
## 概要:
ほとんどの組織は、SQL Server 上のデータを [Amazon EC2](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/ec2-sql.html) に保護し、前回のバックアップからの最大許容時間である目標復旧時点 (RPO) とサービス中断からサービス復旧までの最大許容遅延時間である目標復旧時間 (RTO) に関する現在の要件を満たす、適切なソリューションを求めています。EC2 インスタンスで SQL Server を実行している場合、データのバックアップを作成したり、データを復元したりする複数のオプションがあります。SQL Server on Amazon EC2 でデータを保護するバックアップ戦略には、次のようなものがあります。
+ Windows Volume Shadow Copy Service (VSS)-enabled [Amazon Elastic Block Store (Amazon EBS)](https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service) スナップショットまたは [AWS Backup](https://aws.amazon.com/backup/) を使用するサーバーレベルのバックアップ
+ SQL Server の[ネイティブバックアップと復元](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases)を使用するデータベースレベルのバックアップ
[データベースレベルのネイティブバックアップ](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-managing-on-aws/database-level-backup.html)を選択した場合、以下のストレージオプションがあります。
+ [Amazon EBS ボリューム](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-managing-on-aws/database-level-backup.html#ebs-volumes)を使用したローカルバックアップ
+ [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-managing-on-aws/database-level-backup.html#amazon-fsx) または Amazon FSx for NetApp ONTAP を使用したネットワークファイルシステムのバックアップ
+ [AWS Storage Gateway](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-managing-on-aws/database-level-backup.html#storage-gateway) を使用した Amazon Simple Storage Service (Amazon S3) へのネットワークバックアップ
+ SQL Server 2022 の Amazon S3 への直接バックアップ
このセクションでは次のことを行います。
+ ストレージスペースを節約するのに役立つ機能に焦点を当てる
+ さまざまなバックエンドストレージオプション間のコストを比較する
+ これらの推奨事項の実装に役立つ詳細なドキュメントへのリンクを提供する
## VSS 対応スナップショットを使用したサーバーレベルのバックアップ
VSS 対応スナップショットアーキテクチャでは、 AWS Systems Manager [Run コマンド](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)を使用して、SQL Server インスタンスに VSS エージェントをインストールします。この Run Command は、オペレーティングシステムとアプリケーションのバッファをディスクにフラッシュし、I/O オペレーションを一時停止し、EBS ボリュームのポイントインタイムスナップショットを取得して I/O を再開する、ワークフロー全体の呼び出しにも使用できます。
この Run Command は、ターゲットインスタンスにアタッチされたすべての EBS ボリュームの自動スナップショットを作成します。ユーザーデータベースファイルは、通常は他のボリュームに保存されるため、ルートボリュームを除外する選択もできます。複数の EBS ボリュームをストライピングして SQL Server ファイル用の 1 つのファイルシステムを作成する場合、Amazon EBS は、1 つの API コマンドで Crash-consistent なマルチボリュームのスナップショットもサポートします。アプリケーション整合性のある [VSS 対応 EBS スナップショット](https://aws.amazon.com/blogs/mt/take-microsoft-vss-enabled-snapshots-using-amazon-ec2-systems-manager/)の詳細については、Amazon EC2 ドキュメントの「[Create a VSS application-consistent snapshot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html)」を参照してください。
次の図は、VSS 対応スナップショットを使用したサーバーレベルのバックアップのアーキテクチャを示しています。
![\[VSS 対応スナップショットのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/snapshots_backup_arch.png)
VSS 対応スナップショットを使用する次の利点を考慮してください。
+ DB インスタンスの初期のスナップショットには、フル DB インスタンスのデータが含まれています。同じ DB インスタンスの後続のスナップショットは[増分](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html#how_snapshots_work)です。つまり、直近のスナップショット以降に変更されたデータのみが保存されます。
+ EBS スナップショットは、ポイントインタイムリカバリを提供します。
+ [スナップショットから、新しい SQL Server EC2 インスタンスに復元する](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html)ことができます。
+ インスタンスが Amazon EBS を使用して暗号化されている場合、または、データベースが TDE を使用しているインスタンス内で暗号化されている場合、そのインスタンスまたはデータベースは、同じ暗号化を使用して自動的に復元されます。
+ 使用している[自動化されたクロスリージョンバックアップ](https://docs.aws.amazon.com/ebs/latest/userguide/event-policy.html)をコピーできます。
+ EBS ボリュームをスナップショットから復元したとき、アプリケーションからすぐにアクセスすることができます。つまり、基盤となる 1 つ以上の EBS ボリュームをスナップショットから復元した後に、SQL Server をすぐにオンラインにすることができます。
+ 復元したボリュームは、デフォルトでは、アプリケーションが初めてブロックを読み込む際に、Amazon S3 から基盤のブロックを取得します。これにより、EBS ボリュームをスナップショットから復元した後に、パフォーマンスの低下が生じる場合があります。ボリュームは、最終的には通常のパフォーマンスに追いつきます。ただし、このようなパフォーマンスの低下は、[高速スナップショット復元 (FSR)](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html) のスナップショットを使うことで回避できます。
+ [EBS スナップショットのライフサイクル管理](https://aws.amazon.com/blogs/aws/new-lifecycle-management-for-amazon-ebs-snapshots/)を使用できます。
VSS 対応スナップショットを使用する際には、次の制限事項を考慮してください。
+ SQL Server インスタンスの暗号化されたスナップショットでは、クロスリージョンのポイントインタイムリカバリを実行できません。
+ 暗号化されていないインスタンスの、暗号化されたスナップショットを作成することはできません。
+ スナップショットは EBS ボリュームレベルで作成されるため、個々のデータベースを復元することはできません。
+ インスタンスをそれ自体に復元することはできません。
+ DB インスタンスのスナップショットは、DB インスタンスと同じ AWS Key Management Service (AWS KMS) キーを使用して暗号化する必要があります。
+ Storage I/O は、スナップショットのバックアッププロセス中に一瞬 (約 10 ミリ秒) 中断します。
## を使用した SQL Server バックアップ AWS Backup
を使用して[AWS Backup](https://aws.amazon.com/backup/)データ保護を一元管理および自動化できます AWS のサービス。 AWS Backup は、大規模なデータ保護を簡素化する、費用対効果の高いフルマネージド型のポリシーベースのソリューションを提供します。 AWS Backup は、規制コンプライアンスの義務をサポートし、ビジネス継続性の目標を達成するのにも役立ちます。と を併用 AWS Backup すると AWS Organizations、データ保護 (バックアップ) ポリシーを一元的にデプロイして、組織の AWS アカウント および リソース全体でバックアップアクティビティを設定、管理、管理できます。
以下の図は、 AWS Backupを使用した SQL Server on EC2 のバックアップと復元ソリューションのアーキテクチャを示したものです。
![\[AWS Backup アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/aws_backup_arch.png)
AWS Backupを使用して SQL Server をバックアップする次の利点を考慮してください。
+ バックアップのスケジュール設定、保持の管理、ライフサイクル管理を自動化できます。
+ バックアップ戦略を組織全体で一元化し、複数の アカウントと にまたがることができます AWS リージョン。
+ AWS のサービス全体のバックアップアクティビティのモニタリングとアラートの発信を一元化できます。
+ ディザスタリカバリ計画のリージョンを横断したバックアップを実装できます。
+ このソリューションは、クロスアカウントバックアップをサポートしています。
+ 二次的なバックアップ暗号化を使用した、安全なバックアップを実行できます。
+ すべてのバックアップは、暗号化キーを使用した AWS KMS 暗号化をサポートしています。
+ このソリューションは、TDE と連携しています。
+ AWS Backup コンソールから復旧ポイントに復元することができます。
+ SQL Server インスタンス全体をバックアップできます。これには、すべての SQL Server データベースが含まれます。
## データベースレベルのバックアップ
以下のアプローチでは、Microsoft SQL Server ネイティブのバックアップ機能を使用します。SQL Server 上のインスタンスの、個々のデータベースのバックアップを作成し、個々のデータベースを復元することができます。
SQL Server ネイティブのバックアップと復元に使用されるオプションは、以下もサポートしています。
+ 圧縮と複数ファイルのバックアップ
+ フルバックアップ、差分バックアップ、T ログバックアップ
+ TDE によって暗号化されたデータベース
### SQL Server のネイティブバックアップと Amazon S3 への復元
SQL Server on Amazon EC2 は、SQL Server データベースのネイティブバックアップと復元をサポートしています。SQL Server データベースのバックアップを作成して、バックアップファイルを、既存のデータベースか、新しい SQL Server EC2 インスタンス、Amazon RDS for SQL Server、オンプレミスサーバーのいずれかに復元することができます。
Storage Gateway は、オンプレミスアプリケーションがクラウドストレージに実質的に無制限でアクセスできる、ハイブリッドクラウドのストレージサービスです。Storage Gateway を使用して Microsoft SQL Server データベースを Amazon S3 に直接バックアップすれば、オンプレミスのストレージフットプリントを減らすことができ、Amazon S3 を使用して耐久性と拡張性に優れた、費用対効果の高いストレージを実現することができます。
次の図は、Storage Gateway と Amazon S3 を使用したネイティブバックアップと復元のソリューションのアーキテクチャを示したものです。
![\[Storage Gateway と Amazon S3 のアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/storage_gateway_backup_arch.png)
Storage Gateway を使用した SQL Server ネイティブのバックアップを使用する次の利点を考慮してください。
+ ストレージゲートウェイを、EC2 インスタンスのサーバーメッセージブロック (SMB) ファイル共有としてマッピングし、バックアップを Amazon S3 に送信できます。
+ バックアップは S3 バケットに直接行われるか、Storage Gateway のファイルキャッシュを介して行われます。
+ 複数ファイルのバックアップがサポートされています。
Storage Gateway を使用したネイティブバックアップの次の制限事項を考慮してください。
+ バックアップと復元をデータベースごとに設定する必要があります。
+ バックアップファイル用の [Amazon S3 ライフサイクルポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)の管理が必要になります。
Storage Gateway の設定方法の詳細については、 AWS ブログの記事「[AWS Storage Gatewayを使用して SQL サーバーバックアップを Amazon S3 に保存する](https://aws.amazon.com/blogs/database/storing-sql-server-backups-in-amazon-s3-using-aws-storage-gateway/)」を参照してください。
### EBS ボリュームへの SQL Server のネイティブバックアップ
SQL Server データベースのネイティブバックアップを作成し、そのファイルを Amazon EBS ボリュームに保存することができます。Amazon EBS は、きわめて高性能なブロックストレージサービスです。EBS ボリュームは伸縮自在で、暗号化をサポートしています。デタッチして EC2 インスタンスにアタッチすることができます。EC2 インスタンス上の SQL Server は、同じ EBS ボリュームタイプで、または異なる EBS ボリュームタイプでバックアップすることができます。異なる EBS ボリュームにバックアップする利点の 1 つが、コストを削減できることです。
以下の図は、EBS ボリュームへのネイティブバックアップのアーキテクチャを示したものです。
![\[Amazon EBS ボリュームのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/ebs_backup_arch.png)
EBS ボリュームへの SQL Server のネイティブバックアップを使用する次の利点を考慮してください。
+ SQL Server の EC2 インスタンスにある個々のデータベースのバックアップを作成し、すべてのインスタンスを復元するのではなく個々のデータベースを復元することができます。
+ 複数ファイルのバックアップがサポートされています。
+ バックアップジョブを SQL Server エージェントと SQL Server ジョブエンジンを使用してスケジュールできます。
+ 選択したハードウェアによって、パフォーマンス上の利点が得られます。例えば、st1 ストレージボリュームを使用するとスループットを高めることができます。
EBS ボリュームへのネイティブバックアップを使用する際には、次の制限事項を考慮してください。
+ EBS ボリュームから Amazon S3 にバックアップを移動するときは、手動で行う必要があります。
+ 大規模なバックアップの場合、Amazon EC2 のディスク容量を管理する必要があります。
+ EC2 インスタンスでは、Amazon EBS のスループットがボトルネックになる可能性があります。
+ Amazon EBS にバックアップを保存するには追加のストレージが必要になります。
### Amazon FSx for Windows File Server への SQL Server ネイティブバックアップ
[Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) は、FSx for Windows File Server での[マルチ AZ ファイルシステムデプロイのネイティブサポート](https://aws.amazon.com/blogs/aws/amazon-fsx-for-windows-file-server-update-new-enterprise-ready-features/) AWS を導入し、高速で予測可能で一貫したパフォーマンスを実現するように設計された、最大 64 TB のストレージを提供するフルマネージドのネイティブ Windows ファイルシステムです。ネイティブサポートにより、複数のアベイラビリティーゾーンを横断する高可用性と冗長性とを備えた AWS に、Windows ファイルストレージを簡単にデプロイできるようになりました。 AWS では、[SMB Continuously Available (CA) ファイル共有](https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-fsx-for-windows-file-server-adds-support-for-high-availability-microsoft-sql-server-deployments/)のサポートも開始しました。FSx for Windows File Server を、SQL Server データベースのバックアップストレージとして使用できます。
以下の図は、FSx for Windows File Server への、SQL Server のネイティブバックアップのアーキテクチャを示したものです。
![\[FSx for Windows File Server のバックアップのアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/fsx_backup_arch.png)
FSx for Windows File Server への SQL Server のネイティブバックアップを使用する次の利点を考慮してください。
+ お使いの SQL Server データベースを Amazon FSx ファイル共有にバックアップすることができます。
+ SQL Server インスタンスにある個々のデータベースのバックアップを作成し、すべてのインスタンスを復元するのではなく個々のデータベースを復元することができます。
+ 複数の要素からなるバックアップがサポートされています。
+ バックアップジョブを SQL Server エージェントとそのジョブエンジンを使用してスケジュールできます。
+ インスタンスで Amazon EBS よりも高いネットワーク帯域幅を利用できます。
FSx for Windows File Server への SQL Server のネイティブバックアップを使用する際には、次の制限事項を考慮してください。
+ AWS Backup または を使用して、Amazon FSx から Amazon S3 にバックアップを手動で移動する必要があります AWS DataSync。 FSx
+ 大規模なバックアップでは、Amazon FSx のディスク容量の管理のため、追加のオーバーヘッドが必要になる場合があります。
+ EC2 インスタンスのネットワークスループットがボトルネックになる可能性があります。
+ FSx for Windows File Server にバックアップを保存するには追加のストレージが必要になります。
### Amazon FSx for NetApp ONTAP への SQL Server のバックアップ
FSx for ONTAP のスナップショットは常に Crash-consistent ですが、アプリケーション整合性のあるスナップショットを作成するには、データベースを休止 (または I/O を一時停止) する必要があります。NetApp SnapCenter (SQL Server を含む特定のアプリケーションのプラグインを備えたオーケストレーションツール) と FSx for ONTAP を使用して、アプリケーション整合性のあるスナップショットを作成し、データベースを追加料金なしで保護、レプリケート、およびクローンすることができます。
#### NetApp SnapCenter
NetApp SnapCenter は、アプリケーション整合性のあるデータ保護のための統合プラットフォームです。SnapCenter では、スナップショットをバックアップと呼びます。本ガイドでは、この同じ命名規則を採用しています。SnapCenter には、アプリケーション整合性のあるバックアップ、復元、クローンを管理するための一元的なウィンドウが用意されています。特定のデータベースアプリケーションに SnapCenter プラグインを追加して、アプリケーション整合性のあるバックアップを作成します。SQL Server 用 SnapCenter プラグインには、データ保護ワークフローを簡素化する次の機能があります。
+ 完全バックアップとログバックアップの粒度を備えたバックアップおよび復元オプション
+ インプレース復元と別の場所への復元
SnapCenter の詳細については、 AWS ストレージブログの[「Amazon FSx for NetApp ONTAP で NetApp SnapCenter を使用して SQL Server ワークロードを保護する](https://aws.amazon.com/blogs/storage/using-netapp-snapcenter-with-amazon-fsx-for-netapp-ontap-to-protect-your-sql-server-workloads/)」の投稿を参照してください。
### バックアップのコスト最適化
次のオプションは、 AWSに SQL Server のバックアップを保存するコストを削減するのに役立ちます。
+ バックアップファイルの作成中に [SQL Server の圧縮](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/backup-compression-sql-server?view=sql-server-ver16)を有効にし、可能な限り小さいファイルをストレージに送信します。例えば、3:1 の圧縮率は、ディスクスペースを約 66% 節約することを示しています。これらの列に対してクエリを実行するには、次の Transact-SQL ステートメントを使用できます: `SELECT backup_size/compressed_backup_size FROM msdb..backupset;`。
+ S3 バケットにバックアップする場合は、[Amazon S3 Intelligent-Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) ストレージクラスを有効にして、ストレージコストを 30% 削減します。
+ FSx for Windows File Server または FSx for ONTAP にバックアップする場合は、単一のアベイラビリティーゾーンを使用すると、複数のアベイラビリティーゾーンを使用する場合と比較して 50% のコスト削減になります。料金については、「[Amazon FSx for Windows File Server の料金](https://aws.amazon.com/fsx/windows/pricing/)」と「[Amazon FSx for NetApp ONTAP の料金](https://aws.amazon.com/fsx/netapp-ontap/pricing/)」を参照してください。
+ SQL Server 2022 の最も効率的なオプションは、Amazon S3 への直接バックアップです。Storage Gateway を回避することで、追加コストを節約できます。
### バックアップのベンチマークテスト結果
このセクションでは、本ガイドで説明するバックアップソリューションのパフォーマンスベンチマークテストの結果に基づいて、サンプル 1 TB データベースのコストとパフォーマンスの観点から次のオプションを比較します。
+ **EC2 インスタンス仕様 **– Windows Server 2019 および SQL Server 2019 Developer Edition を使用した r5d.8xlarge
+ **データベース仕様** – TDE が無効になっている 1 TB のサイズ
これらのテストは、r5d.8xlarge インスタンスと、1 TB の SQL Server データベースをソースとして使用して実行されました。ソースシステムはベストプラクティスに沿って構成され、ソースデータベースには、個別の gp3 ボリュームに分散された 4 つのデータファイル (各 250 GB) と 1 つのログファイル (50 GB) が含まれていました。SQL Server ネイティブの `BACKUP` コマンドには、圧縮を使ってバックアップパフォーマンスを最適化し、ネットワーク経由で送信されターゲットに書き込まれるデータの量を減らすため、10 のバックアップファイルへの書き込みが含まれています。すべてのテストケースで、ストレージのパフォーマンスがボトルネックでした。
この種のテストの考えられる構成は、無限に近いバリエーションがあります。このテストでは、パフォーマンス、コスト、スケーラビリティ、実際のユースケースの最適化に焦点を当てました。次の表は、バックアップターゲットオプションでキャプチャされたパフォーマンスメトリクスを示しています。
****
| バックアップオプション | レベル | 実行時間 (近似値) | バックアップレート | 1 か月あたりのコスト (USD)\$1 |
| --- | --- | --- | --- | --- |
| ローカル EBS st1 HDD へのネイティブバックアップ、2 TB | データベース | 00:30:46 分 | 554.7 Mbps | 92.16 USD |
| ローカル EBS SSD gp3 へのネイティブバックアップ、2 TB | データベース | 00:22:00 分 | 512 Mbps | 193.84 USD |
| FSx for Windows File Server HDD へのネイティブバックアップ、2 TB @512 Mbps スループット | データベース | 00:20:58 分 | 814.0 Mbps | [1,146 USD](https://calculator.aws/#/estimate?id=e13d8a385d25b2d4f1320c5b1156b953355b7c13) |
| FSx for Windows File Server SSD へのネイティブバックアップ、2 TB @512 Mbps スループット | データベース | 00:20:00 分 | 814.0 Mbps | [1,326 USD](https://calculator.aws/#/estimate?id=e13d8a385d25b2d4f1320c5b1156b953355b7c13) |
| S3 ファイルゲートウェイ m6i.4xlarge (16 vCPU、64 GB) へのネイティブバックアップ、2 TB gp3 | データベース | 00:23:20 分 | 731.5 Mbps | 470.42 USD |
| EBS VSS スナップショット | EBS ボリューム | 00:00:02 秒00:00:53 秒 | スナップショットなし | [51 USD](https://calculator.aws/#/estimate?id=e13d8a385d25b2d4f1320c5b1156b953355b7c13) |
| AWS Backup (AMI バックアップ) | AMI | 00:00:04 秒00:08:00 分 | スナップショットなし | [75 USD](https://calculator.aws/#/estimate?id=e13d8a385d25b2d4f1320c5b1156b953355b7c13) |
| Amazon S3 への SQL Server の直接ネイティブバックアップ (SQL Server 2022) | データベース | 00:12:00 分 | 731.5 Mbps | [最初の 50 TB/月、1 GB あたり 0.023 USD、1 か月あたり 23.55 USD](https://calculator.aws/#/estimate?id=e13d8a385d25b2d4f1320c5b1156b953355b7c13) |
| FSx for ONTAP へのネイティブバックアップ (SnapCenter を使用) | データベース | – | – | [440.20 USD](https://calculator.aws/#/estimate?id=8c9a0b2c296f9839f3ca16bdc2dcd9a6f52f1faf) |
上記の表は、次のことを前提としています。
+ データ転送と Amazon S3 のコストは含まれません。
+ ストレージ料金はインスタンス料金に含まれます。
+ コストは `us-east-1` リージョンに基づいています。
+ 1 か月間の全体的な変化率が 10% である複数のバックアップにより、スループットと IOPS が 10% 増加します。
テスト結果は、最速のオプションが FSx for Windows File Server へのネイティブ SQL Server データベースバックアップであることを示しています。Storage Gateway とローカルにアタッチされた EBS ボリュームへのバックアップは、コスト効率の高いオプションですが、パフォーマンスが低下します。サーバーレベルのバックアップ (AMI) では、最適なパフォーマンス、コスト、管理性 AWS Backup を実現するために を使用することをお勧めします。
## コスト最適化の推奨事項
Amazon EC2 における SQL Server のバックアップ用ソリューションについて理解しておくことは、データを保護し、バックアップのニーズを満たし、重大事象から回復するための計画を立てる上で鍵となります。このセクションで説明する、SQL Server インスタンスとデータベースをバックアップおよび復元するさまざまな方法は、データを保護し、組織の要件を満たすバックアップおよび復元戦略を考案するのに役立ちます。
このセクションでは、次のバックアップオプションについて説明します。
+ Compression
+ Amazon S3 の新しいストレージクラス、S3 Intelligent-Tiering を発表
+ 単一のアベイラビリティーゾーン
+ URL へのバックアップ
これらのオプションごとに提供されるガイダンスは高レベルです。組織でこれらの推奨事項のいずれかを実装する場合は、アカウントチームに連絡することをお勧めします。その後、チームは Microsoft スペシャリスト SA と連携して会話を主導することができます。optimize-microsoft@amazon.com に E メールを送信して連絡をとることもできます。
要約すると、次のことをお勧めします。
+ SQL Server 2022 を使用している場合は、Amazon S3 へのバックアップが最もコスト効率の高いオプションです。
+ SQL Server 2019 以前の SQL Server エディションを使用している場合は、最もコスト効率の高いオプションとして、Amazon S3 によって支援された Storage Gateway へのバックアップを検討してください。
### Compression
圧縮の目的は、バックアップごとに消費されるストレージを減らすことです。これは、さまざまなストレージオプションにとって有益です。[SQL Server インスタンス](https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/view-or-configure-the-backup-compression-default-server-configuration-option?view=sql-server-ver16)のレベルで SQL Server バックアップの圧縮を有効にする必要があります。次の例は、バックアップデータベースで圧縮キーワードを追加する方法を示しています。
`BACKUP DATABASE TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE)`
### Amazon S3 の新しいストレージクラス、S3 Intelligent-Tiering を発表
Amazon S3 バケットへのバックアップの場合、[Amazon S3 Intelligent-Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) を Amazon S3 ファイルゲートウェイ[ストレージクラス](https://docs.aws.amazon.com/filegateway/latest/files3/storage-classes.html#ia-file-gateway)として有効にできます。これにより、ストレージコストを最大 30% 削減できます。次に、[Active Directory ドメイン](https://docs.aws.amazon.com/filegateway/latest/files3/CreatingAnSMBFileShare.html#configure-SMB-settings)と統合できる SMB ファイル共有を使用して、S3 ファイルゲートウェイを SQL サーバーにマウントします。これにより、共有のアクセスコントロール、既存のサービスアカウントを活用する機能、一般的な Microsoft 向けファイルプロトコルを使用した Amazon S3 へのアクセスが可能になります。ドメインコントローラーに直接接続できない可能性があるアカウントでは、[Active Directory Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) を使用して、オンプレミスまたはクラウドでの Active Directory との通信を容易にすることができます。ゲートウェイで Active Directory 設定を構成するには、ドメインコントローラーが Active Directory へのリクエストをプロキシするための Active Directory Connector IP を指定する必要があります。
次の図は、S3 Intelligent-Tiering に基づくソリューションのアーキテクチャを示しています。
![\[S3 Intelligent-Tiering のアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/ad_connector_arch.png)
デフォルトでは、S3 バケットに書き込まれたバックアップファイルは標準階層を使用します。バックアップファイルを標準階層から S3 Intelligent-Tiering に変換するには、[ライフサイクルルールを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html)必要があります。[AWS マネジメントコンソール](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-intelligent-tiering.html#enable-auto-archiving-int-tiering) を使用して S3 Intelligent-Tiering を有効にすることもできます。詳細については、 AWS ドキュメントの「[Amazon S3 Intelligent-Tiering の使用を開始する](https://aws.amazon.com/getting-started/hands-on/getting-started-using-amazon-s3-intelligent-tiering/)」を参照してください。
### 単一のアベイラビリティーゾーン
単一のアベイラビリティーゾーンのファイルシステムを作成するには、[FSx for Windows File Server ファイルシステムを作成する](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/getting-started.html)ときにシングル AZ オプションを選択します。Amazon FSx は、Windows ボリュームシャドウコピーサービスを使用して、ファイルシステムの耐久性の高いバックアップ (Amazon S3 に保存) を毎日取得し、ユーザーはいつでも追加のバックアップを取ることができます。単一のアベイラビリティーゾーンの使用に関するいくつかの問題に注意してください。例えば、ファイルシステムがプロビジョニングされる、影響を受けるアベイラビリティーゾーンが一度に数時間ダウンすると、SMB ファイル共有にアクセスできなくなります。データへのアクセスが必要な場合は、ソースリージョン内の使用可能なアベイラビリティーゾーンのバックアップから復元する必要があります。詳細については、このガイドの「[Use a single Availability Zone](storage-fsx-single-az.md)」セクションを参照してください。
### URL へのバックアップ
SQL Server 2022 の場合、[URL へのバックアップ](https://www.microsoft.com/en-us/sql-server/blog/2022/09/29/backup-and-restore-to-url-for-s3-compatible-object-storage/)機能を使用すると、Amazon S3 への直接バックアップが可能になります。これは、 で実行されている SQL Server 2022 の理想的なバックアップアプローチです。ストレージレイヤーで Amazon S3 の全機能を取得し、この機能を容易にするために以前のバージョンで必要なアプライアンスの AWS Storage Gateway コストを排除 AWS できます。この機能を実装する際に考慮すべき主なコストは、データ転送コストと、選択した S3 ストレージクラスの 2 つです。Amazon S3 のネイティブディザスタリカバリ機能が必要な場合は、[クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario)によってクロスリージョンの[データエグレスコスト](https://aws.amazon.com/s3/pricing/?p=pm&c=s3&z=4)が発生することを考慮する必要があります。このオプションの設定方法の詳細については、Microsoft Workloads on AWS ブログの記事「[Backup SQL Server databases to Amazon S3](https://aws.amazon.com/blogs/modernizing-with-aws/backup-sql-server-to-amazon-s3/)」を参照してください。
## その他のリソース
+ [Amazon EC2 での SQL Server のバックアップと復元のオプション](https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-managing-on-aws/welcome.html) (AWS 規範ガイダンス)
+ [を使用した Amazon RDS Point-in-timeリカバリと継続的バックアップ AWS Backup](https://aws.amazon.com/blogs/storage/point-in-time-recovery-and-continuous-backup-for-amazon-rds-with-aws-backup/) (AWS ストレージブログ)
+ [Amazon FSx for NetApp ONTAP で NetApp SnapCenter を使用して SQL Server ワークロードを保護する](https://aws.amazon.com/blogs/storage/using-netapp-snapcenter-with-amazon-fsx-for-netapp-ontap-to-protect-your-sql-server-workloads/) (AWS ストレージブログ)
+ [Amazon S3 Intelligent-Tiering の使用開始](https://aws.amazon.com/getting-started/hands-on/getting-started-using-amazon-s3-intelligent-tiering/) (AWS 入門リソースセンター)
+ [Amazon RDS for SQL Server のバックアップおよび復元戦略](https://aws.amazon.com/blogs/database/backup-and-restore-strategies-for-amazon-rds-for-sql-server/) (AWS データベースブログ)
+ [オンプレミスの Microsoft SQL Server データベースを Amazon EC2 に移行する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-on-premises-microsoft-sql-server-database-to-amazon-ec2.html) (AWS 規範ガイダンス)
+ [Amazon EC2 に Microsoft SQL Server をデプロイするためのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/best-practices-for-deploying-microsoft-sql-server/best-practices-for-deploying-microsoft-sql-server.html) (AWS ホワイトペーパー)
# SQL Server データベースをモダナイズする
## 概要:
スケーラビリティ、パフォーマンス、コスト最適化のためにレガシーデータベースをモダナイズするジャーニーを開始する場合、SQL Server などの商用データベースで課題に直面する可能性があります。商用データベースは高価で、顧客を閉じ込め、厳しいライセンス条項を課します。このセクションでは、SQL Server からオープンソースデータベースへの移行とモダナイズのオプションの概要を示し、ワークロードに最適なオプションの選択について説明します。
SQL Server データベースを Amazon Aurora PostgreSQL などのオープンソースデータベースにリファクタリングして、Windows および SQL Server のライセンスコストを節約できます。Aurora のようなクラウドネイティブの最新のデータベースは、オープンソースデータベースの柔軟性と低コストを、商用データベースの堅牢なエンタープライズグレードの機能と融合させます。可変ワークロードまたはマルチテナントワークロードがある場合は、[Aurora Serverless V2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html) に移行することもできます。これにより、ワークロードの特性に応じてコストを最大 90% 削減できます。さらに、 AWS は [Babelfish for Aurora PostgreSQL](https://aws.amazon.com/rds/aurora/babelfish/) などの機能、 [AWS Schema Conversion Tool (AWS SCT)](https://aws.amazon.com/dms/schema-conversion-tool/) などのツール、 [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/) などのサービスを提供し、SQL Server データベースの移行とモダナイゼーションを簡素化します AWS。
## データベースサービス
Windows 上の SQL Server から、Amazon Aurora、Amazon RDS for MySQL、Amazon RDS for PostgreSQL などのオープンソースデータベースに移行すると、パフォーマンスや機能を損なうことなく大幅なコスト削減を実現できます。以下の点を考慮してください。
+ Amazon EC2 上の SQL Server Enterprise Edition から Amazon RDS for PostgreSQL または Amazon RDS for MySQL に切り替えると、最大 80% のコスト削減につながります。
+ Amazon EC2 上の SQL Server Enterprise Edition から Amazon Aurora PostgreSQL 互換エディションまたは Amazon Aurora MySQL 互換エディションに切り替えると、最大 70% のコスト削減につながります。
従来のデータベースワークロードの場合、Amazon RDS for PostgreSQL と Amazon RDS for MySQL は要件に対応し、リレーショナルデータベースにコスト効率の高いソリューションを提供します。Aurora は、これまで高価な商用ベンダーに限定されていた多数の可用性およびパフォーマンス機能を追加します。Aurora の耐障害性機能は追加コストがかかります。ただし、他の商用ベンダーの同様の機能と比較すると、Aurora の耐障害性コストは、同じタイプの機能に対して商用ソフトウェアが請求するコストよりも依然として安価です。Aurora アーキテクチャは、標準の MySQL および PostgreSQL デプロイと比較してパフォーマンスが大幅に向上するように最適化されています。
Aurora はオープンソースの PostgreSQL および MySQL データベースと互換性があるため、移植性という追加の利点があります。最適なオプションが Amazon RDS for PostgreSQL、Amazon RDS for MySQL、または Aurora のいずれであっても、ビジネス要件を理解し、必要な機能を最適なオプションにマッピングする必要があります。
## Amazon RDS と Aurora の比較
次の表は、Amazon RDS と Amazon Aurora の主な違いをまとめたものです。
****
| Category | Amazon RDS for PostgreSQL または Amazon RDS for MySQL | Aurora PostgreSQL または Aurora MySQL |
| --- | --- | --- |
| パフォーマンス | 良いパフォーマンス | 3 倍以上優れたパフォーマンス |
| フェイルオーバー | 通常 60～120 秒\$1 | 通常 30 秒 |
| スケーラビリティ | 最大 5 個のリードレプリカ秒単位の遅延 | 最大 15 個のリードレプリカミリ秒単位の遅延 |
| Storage | 最大 64 TB | 最大 128 TB |
| ストレージ HA | 1 つまたは 2 つのスタンバイを備えたマルチ AZ、それぞれデータベースコピーあり | デフォルトで 3 つのアベイラビリティーゾーンにまたがる 6 つのデータコピー |
| バックアップ | 日次スナップショットとログのバックアップ | Amazon S3 への継続的な非同期バックアップ |
| Aurora でのイノベーション | NA | 100 GBデータベースの高速クローン作成 |
| | リードレプリカの自動スケーリング | |
| | クエリプラン管理 | |
| | Aurora Serverless | |
| | グローバルデータベースによるクロスリージョンレプリカ | |
| | クラスターキャッシュ管理\$1\$1 | |
| | パラレルクエリ | |
| | データベースアクティビティストリーミング | |
\$1大量のトランザクションがあると、フェイルオーバー時間が長くなる可能性があります。
\$1\$1Aurora PostgreSQL で利用可能です。
次の表は、このセクションで説明するさまざまなデータベースサービスの推定月額コストを示しています。
****
| データベースサービス | 1 か月あたりのコスト (USD)\$1 | AWS 料金見積りツール (必須 AWS アカウント) |
| --- | --- | --- |
| Amazon RDS for SQL Server Enterprise Edition | 3,750 USD | [Estimate](https://calculator.aws/#/estimate?id=16f190d818045bb99fb59659cecca80f92db4bbc) |
| Amazon RDS for SQL Server Standard Edition | 2,318 USD | [Estimate](https://calculator.aws/#/estimate?id=5a5e9832ae80fd9ad9e8010c9a17f57d5a0415ca) |
| Amazon EC2 の SQL Server Enterprise Edition | 2,835 USD | [Estimate](https://calculator.aws/#/estimate?id=0976f53e9b1b55d5475dc394c8caae9d5581183b) |
| Amazon EC2 の SQL Server Standard Edition | 1,345 USD | [Estimate](https://calculator.aws/#/estimate?id=3cada8ab6d72b68a2eb3bc92927990c9f7e264ca) |
| Amazon RDS for PostgreSQL | 742 USD | [Estimate](https://calculator.aws/#/estimate?id=bd825d40c79c0df8f0cf053d55ca39acc8a927fe) |
| Amazon RDS for MySQL | 712 USD | [Estimate](https://calculator.aws/#/estimate?id=c0f61d7b67652e58df5bf6cb244e9455ff4a8558) |
| Aurora PostgreSQL | 1,032 USD | [Estimate](https://calculator.aws/#/estimate?id=a557d7d740e5d87c9764bd369de81a5873dad053) |
| Aurora MySQL | 1,031 USD | [Estimate](https://calculator.aws/#/estimate?id=5924d827c98beadda65368c8e64eb249c001afd6) |
\$1 ストレージ料金はインスタンス料金に含まれます。コストは `us-east-1` リージョンに基づいています。スループットと IOPS は想定です。計算は r6i.2xlarge インスタンスと r6g.2xlarge インスタンスに対して行われます。
## コスト最適化の推奨事項
通常、異種のデータベース間の移行では、データベーススキーマをソースからターゲットデータベースエンジンに変換し、ソースからターゲットデータベースにデータを移行する必要があります。移行の最初のステップは、SQL Server スキーマとコードオブジェクトを評価して、ターゲットデータベースエンジンに変換することです。
[AWS Schema Conversion Tool (AWS SCT)](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html) を使用して、Amazon RDS for MySQL や Amazon RDS for PostgreSQL、Aurora MySQL、PostgreSQL などのさまざまなターゲットオープンソースデータベースオプションとの互換性についてデータベースを評価できます。Babelfish for Aurora PostgreSQL との互換性を評価するには、Babelfish Compass ツールを使用することもできます。これにより、 AWS SCT と Compass は、移行戦略を決定する前に、関連する先行作業を理解するための強力なツールになります。続行する場合は、 AWS SCT がスキーマに必要な変更を自動化します。Babelfish Compass の中核となる哲学は、SQL データベースをまったく変更せずに、またはほとんど変更せずに Aurora に移行できるようにすることです。Compass は既存の SQL データベースを評価して、これを実現できるかどうかを判断します。これにより、SQL Server から Aurora へのデータの移行に労力を費やす前に、結果が明らかになります。
AWS SCT は、データベーススキーマとコードのターゲットデータベースエンジンへの変換と移行を自動化します。Babelfish for Aurora PostgreSQL を使用すると、スキーマの変更なしで、または最小限のスキーマ変更で、データベースとアプリケーションを SQL Server から Aurora PostgreSQL に移行できます。これにより、移行が加速されます。
スキーマが移行されたら、 AWS DMS を使用してデータを移行できます。 AWS DMS は、完全なデータロードを実行し、変更をレプリケートして最小限のダウンタイムで移行を実行できます。
このセクションでは、次のツールについて詳しく説明します。
+ AWS Schema Conversion Tool
+ Babelfish for Aurora PostgreSQL
+ Babelfish Compass
+ AWS Database Migration Service
### AWS Schema Conversion Tool
AWS SCT を使用して既存の SQL Server データベースを評価し、Amazon RDS または Aurora との互換性を評価できます。移行プロセスを簡素化するために、 AWS SCT を使用して、異種データベース移行でスキーマをあるデータベースエンジンから別のデータベースエンジンに変換することもできます。 AWS SCT を使用してアプリケーションを評価し、C\$1、C\$1\$1、Java、およびその他の言語で記述されたアプリケーションの埋め込みアプリケーションコードを変換できます。詳細については、 AWS SCT ドキュメントの「[AWS SCTを使用したアプリケーション SQL の変換](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Converting.App.html)」を参照してください。
AWS SCT は、多くのデータベース[ソース](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Source.html)をサポートする無料の AWS ツールです。を使用するには AWS SCT、ソースデータベースをポイントし、評価を実行します。次に、[AWS SCT](https://aws.amazon.com/blogs/database/convert-database-schemas-and-application-sql-using-the-aws-schema-conversion-tool-cli/) がスキーマを評価し、評価レポートを生成します。評価レポートには、エグゼクティブサマリー、複雑さと移行作業、適したターゲットデータベースエンジン、変換に関する推奨事項が含まれます。ダウンロードするには AWS SCT、 ドキュメントの[「インストール、検証、更新 AWS SCT](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Installing.html)」を参照してください。 AWS SCT
次の表は、データベースを異なるターゲットプラットフォームに変更する際の複雑さを示すために AWS SCT によって生成されるエグゼクティブサマリーの例を示しています。
| | | |
| --- |--- |--- |
| **ターゲットプラットフォーム** | **自動または最小限の変更** | **複雑なアクション** |
| | **ストレージオブジェクト** | **コードオブジェクト** | **変換アクション** | **ストレージオブジェクト** | **コードオブジェクト** |
| Amazon RDS for MySQL | 60 (98%) | 8 (35%) | 42 | 1 (2%) | 1 | 15 (65%) | 56 |
| Amazon Aurora MySQL 互換エディション | 60 (98%) | 8 (35%) | 42 | 1 (2%) | 1 | 15 (65%) | 56 |
| Amazon RDS for PostgreSQL | 60 (98%) | 12 (52%) | 54 | 1 (2%) | 1 | 11 (48%) | 26 |
| Amazon Aurora PostgreSQL 互換エディション | 60 (98%) | 12 (52%) | 54 | 1 (2%) | 1 | 11 (48%) | 26 |
| Amazon RDS for MariaDB | 60 (98%) | 7 (30%) | 42 | 1 (2%) | 1 | 16 (70%) | 58 |
| Amazon Redshift | 61 (100%) | 9 (39%) | 124 | 0 (0%) | 0 | 14 (61%) | 25 |
| AWS Glue | 0 (0%) | 17 (100%) | 0 | 0 (0%) | 0 | 0 (0%) | 0 |
| Babelfish | 59 (97%) | 10 (45%) | 20 | 2 (3%) | 2 | 12 (55%) | 30 |
AWS SCT レポートには、自動的に変換できないスキーマ要素の詳細も表示されます。[AWS 移行プレイブック](https://aws.amazon.com/blogs/database/the-database-migration-playbook-has-landed/)を参照して、 AWS SCT 変換ギャップを埋め、ターゲットスキーマを最適化できます。異種移行を支援するデータベース移行プレイブックは多数あります。
### Babelfish for Aurora PostgreSQL
Babelfish for Aurora PostgreSQL は、SQL Server クライアントからデータベース接続を受け入れる機能を使用して Aurora PostgreSQL を拡張します。Babelfish により、少ないコード変更で、またデータベースドライバを変更せずに、元々 SQL Server 用に構築されているアプリケーションを直接 Aurora PostgreSQL で利用できるようになります。Babelfish は Aurora PostgreSQL をバイリンガルに変換して、Aurora PostgreSQL が T-SQL 言語と PL/pgSQL 言語の両方を操作できるようにします。Babelfish は、SQL Server から Aurora PostgreSQL への移行作業を最小限に抑えます。これにより、移行が加速され、リスクが最小限に抑えられ、移行コストが大幅に削減されます。移行後も T-SQL を引き続き使用できますが、開発に [PostgreSQL ネイティブツールを使用するオプション](https://aws.amazon.com/blogs/database/category/database/amazon-aurora/babelfish-for-aurora-postgresql/)もあります。
次の図は、T-SQL を使用するアプリケーションが SQL Server のデフォルトポート 1433 に接続し、Babelfish トランスレーターを使用して Aurora PostgreSQL データベースと通信する方法を示しています。一方、PL/pgSQL を使用するアプリケーションは、Aurora PostgreSQL のデフォルトポート 5432 を使用して Aurora PostgreSQL データベースに直接および同時に接続できます。
![\[Babelfish for Aurora PostgreSQL\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/babelfish_tsql.png)
Babelfish は、特定の SQL Server T-SQL 機能をサポートしていません。このため、Amazon は、SQL ステートメントを 1 行ずつ分析し、Babelfish でサポートされていないものがあるかどうかを判断するための評価ツールを提供しています。
Babelfish の評価には 2 つのオプションがあります。 は、SQL Server データベースと Babelfish の互換性を評価 AWS SCT できます。もう 1 つのオプションは Babelfish Compass ツールです。Compass ツールは Babelfish for Aurora PostgreSQL の新しいリリースに合わせて更新されるため、これが推奨されるソリューションです。
### Babelfish Compass
[Babelfish Compass](https://github.com/babelfish-for-postgresql/babelfish_compass) は、Babelfish for Aurora PostgreSQL の最新リリースに対応した無料のダウンロード可能なツールです。対照的に、 AWS SCT はしばらくすると新しい Babelfish バージョンをサポートします。[Babelfish Compass](https://github.com/babelfish-for-postgresql/babelfish_compass/blob/main/README.md) は、SQL Server データベーススキーマに対して実行されます。SQL Server Management Studio (SSMS) などのツールを使用して、ソース SQL Server データベーススキーマを抽出することもできます。その後、Babelfish Compass を使用してスキーマを実行できます。これにより、SQL Server スキーマと Babelfish の互換性、および移行前に変更が必要かどうかを詳述するレポートが生成されます。Babelfish Compass ツールは、これらの変更の多くを自動化し、最終的に移行を加速させることもできます。
評価と変更が完了したら、SSMS や sqlcmd などの SQL Server ネイティブツールを使用して、スキーマを Aurora PostgreSQL に移行できます。手順については、 AWS データベースブログの記事「[Migrate from SQL Server to Amazon Aurora using Babelfish](https://aws.amazon.com/blogs/database/migrate-from-sql-server-to-amazon-aurora-using-babelfish/)」を参照してください。
### AWS Database Migration Service
スキーマの移行後、 AWS Database Migration Service (AWS DMS) を使用して最小限のダウンタイム AWS でデータを に移行できます。 は完全なデータロードを行う AWS DMS だけでなく、ソースシステムの稼働中にソースから宛先への変更をレプリケートします。ソースデータベースとターゲットデータベースの両方が同期された後、アプリケーションが移行を完了するターゲットデータベースを指す場合にカットオーバーアクティビティを実行できます。 AWS DMS は現在、Aurora PostgreSQL ターゲットに対して Babelfish で完全なデータロードのみを実行し、変更をレプリケートしません。詳細については、 AWS DMS ドキュメントの「 [のターゲットとして Babelfish を使用する AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Babelfish.html)」を参照してください。
AWS DMS は、同種 (同じデータベースエンジン間) 移行と異種 (異なるデータベースエンジン間) 移行の両方を実行できます。 は、多くのソースデータベースエンジンと宛先データベースエンジン AWS DMS をサポートしています。詳細については、 AWS データベースブログの投稿[を使用して SQL Server データベースを Amazon RDS for SQL Server に移行する AWS DMS](https://aws.amazon.com/blogs/database/migrating-your-sql-server-database-to-amazon-rds-for-sql-server-using-aws-dms/)を参照してください。
## その他のリソース
+ [Microsoft SQL Server、Hello Babelfish](https://aws.amazon.com/blogs/aws/goodbye-microsoft-sql-server-hello-babelfish/) (AWS ニュースブログ)
+ [CLI を使用したデータベーススキーマとアプリケーション SQL の AWS Schema Conversion Tool 変換](https://aws.amazon.com/blogs/database/convert-database-schemas-and-application-sql-using-the-aws-schema-conversion-tool-cli/) (AWS データベースブログ)
+ [ベストプラクティスと フィールドから学んだ教訓を使用して SQL Server を Amazon Aurora PostgreSQL に移行する](https://aws.amazon.com/blogs/database/migrate-sql-server-to-amazon-aurora-postgresql-using-best-practices-and-lessons-learned-from-the-field/) (AWS データベースブログ)
+ [Microsoft SQL Server から Amazon RDS for PostgreSQL および Amazon Aurora PostgreSQL への移行後のデータベースオブジェクトの検証](https://aws.amazon.com/blogs/database/validate-database-objects-post-migration-from-microsoft-sql-server-to-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/) (AWS データベースブログ)
# SQL Server のストレージを最適化する
## 概要:
このセクションでは、EC2 ワークロード上の SQL Server 用 Amazon Elastic Block Store (Amazon EBS) SSD ストレージのコスト最適化に焦点を当てます。
SQL Server ワークロードをデプロイして実行するためのさまざまなストレージオプションがあります AWS。適切なストレージの選択は、目的、アーキテクチャ、耐久性、パフォーマンス、容量、コストに基づいて行う必要があります。SQL Server ワークロードを実行する AWS お客様は、通常、Amazon EBS、NVMe、Amazon FSx、Amazon Simple Storage Service (Amazon S3) ストレージの組み合わせを使用します。
Amazon EBS は、EC2 コンピューティングインスタンスに接続されたネットワークアタッチドストレージであり、一般的なオペレーティングシステム、アプリケーション、データベース、バックアップファイルの保存と処理に使用されます。Amazon EBS ソリッドステートドライブ (SSD) ストレージには、汎用 SSD (gp2 および gp3) とプロビジョンド IOPS SSD (io1、io2、io2BX) が含まれています。以下の点を考慮してください。
+ r5d などの一部の EC2 インスタンスには、ホストインスタンスに物理的にアタッチされたローカル NVMe SSD があります。これらのボリュームは、一般的に SQL Server tempdb またはバッファプール拡張機能に使用されるブロックレベルストレージを提供します。
+ Amazon FSx for Windows File Server はフルマネージド型のファイルストレージサービスであり、Amazon FSx for NetApp ONTAP は、NetApp の一般的な ONTAP ファイルシステム上に構築されたフルマネージド型の共有ストレージです。Amazon FSx は、高可用性の SQL Server フェイルオーバークラスターインスタンス (FCI) 設定で SQL Server ワークロードを実行するためによく使用されます。このソリューションは SQL Server のデータおよびログファイルをホストするため、EC2 インスタンスの EBS パフォーマンス要件が軽減されます。
+ Amazon S3 は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。SQL Server のネイティブバックアップファイル、AMI、EBS スナップショット、アプリケーションログなどを Amazon S3 に保存できます。
## Amazon EBS の SSD ストレージタイプ、パフォーマンス、コスト
Amazon EBS の SSD ストレージコストは、一般的に耐久性とパフォーマンスの向上に伴って増加します。現在、ストレージには 5 つのボリュームタイプがあり、それぞれに[独自のパフォーマンスメトリクス](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)があります。SSD ベースのボリュームのユースケースと特性の概要については、Amazon EBS ドキュメントの「[Solid state drive (SSD) volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html#vol-type-ssd)」セクションの表を参照してください。
Amazon CloudWatch を使用して、SSD のパフォーマンスのモニタリング、トレンドデータのキャプチャ、特定のしきい値に達したときのアラームの設定を行うことができます。 AWSで SQL Server ワークロードを実行している場合は、[詳細なモニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-basic-detailed.html)を有効にして [CloudWatch カスタムメトリクス](https://aws.amazon.com/blogs/database/monitor-your-microsoft-sql-server-using-custom-metrics-with-amazon-cloudwatch-and-aws-systems-manager/)をデプロイし、ディスクレイテンシー、IOPS、スループット、ディスクキューの長さ、使用済みキャパシティと空きキャパシティなどの詳細なボリュームパフォーマンスメトリクスをキャプチャすることを検討してください。これらの CloudWatch パフォーマンスメトリクスを使用して、プロビジョニング不足およびプロビジョニング過剰のストレージを特定し、履歴データポイントを提供してストレージ要件を正確に定義できます。
Amazon EBS の SSD ストレージコストも、割り当てられたキャパシティによって異なります。次の表は、さまざまなボリュームタイプの比較を示しています。すべてのボリュームタイプに、1 TB のキャパシティと同様のパフォーマンス設定があります。
****
| ボリュームタイプ | 最大 IOPS (16 KiB I/O) | 最大スループット (128 KiB I/O) | 1TB あたりの料金 | コスト削減率 |
| --- | --- | --- | --- | --- |
| gp2 | 3,000 | 250 | 102.40 USD | |
| gp3 | 3,000 | 250 | 86.92 USD | 15% |
| io1 | 16,000 | 500 | 1,168 USD | |
| io2 | 16,000 | 500 | 1,168 USD | |
| gp3 | 16,000 | 500 | 146.92 USD | 87% |
| io2bx | 16,000 | 4,000 | 1,168 USD | |
| gp3 | 16,000 | 1,000 | 181.92 USD | 84% |
**注記**
上記の表のパフォーマンスとコストのメトリクスは、 AWS 料金見積りツールからの[見積もり](https://calculator.aws/#/estimate?id=b637bb9c21ae8ad62f440e349dd2067de80e76b2)に基づいたボリュームあたりのメトリクスです。の見積りにアクセスするには、 AWS アカウント が必要です AWS 料金見積りツール。
Amazon EBS SSD gp3 ボリュームは、低コストで優れたパフォーマンスを提供します。16,000 未満の IOPS、500 MiBps 未満のスループットを必要とするワークロードで、io1 または io2 ボリュームよりも gp3 ボリュームを選択した場合、最大 87% 節約できます。
io2 Block Express (io2BX) ボリュームは、通常の io2 ボリュームよりも優れたパフォーマンスを提供します。16,000 IOPS では、io1 または io2 ボリュームは 500 MiBps のスループットしか対応できませんが、io2BX ボリュームには最大 4,000 MiBps のスループットを設定できます。io1 および io2 ボリュームと比較すると、io2BX ボリュームは、まったく同じ料金で 16,000～64,000 IOPS で 4 倍を超えるスループットを提供します。通常の io2 ボリュームは、io2BX 対応の EC2 インスタンスにアタッチすることで、io2BX ボリュームに変換できます。io2BX 対応 EC2 インスタンスのリストについては、Amazon EBS ドキュメントの「[Provisioned IOPS SSD ボリューム](https://docs.aws.amazon.com/ebs/latest/userguide/provisioned-iops.html#io2-block-express)」を参照してください。新しいストレージをデプロイする前に、[AWS 料金見積りツール](https://calculator.aws/) を使用して毎月のコストを見積もり、耐久性、パフォーマンス、キャパシティのトレードオフに基づいてコストへの影響を理解することができます。
## Amazon EBS の一般的な SSD コスト最適化
保存する内容を評価し、適切なストレージタイプとクラスを使用していることを確認することをお勧めします。例えば、Amazon S3 は、SQL Server バックアップに最適な優れたプライスポイント、組み込みライフサイクルポリシー、レプリケーションオプションを提供します。SQL Server 2022 は Amazon S3 に直接バックアップできますが、以前のバージョンの SQL Server はネイティブローカルバックアップに依存しています。古いバージョンの SQL Server を実行している場合は、Amazon EBS HDD ボリュームにバックアップしてから、そのバックアップを Amazon S3 にコピーすることを検討してください。このソリューションでは、バックアップに gp3 ボリュームを使用する場合と対照的に、53% 節約できます。
次の表は、Amazon EBS gp3、Amazon EBS HDD st1、および Amazon S3 上の 1 TB のストレージの料金差を示しています。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/storage-sql-server.html)
**注記**
上記の表のコストのメトリクスは、 AWS 料金見積りツールの[見積もり](https://calculator.aws/#/estimate?id=ba6032e10a5f8a82807c1e3b7d5a64ceb2cdcbde)に基づいています。の見積りにアクセスするには、 AWS アカウント が必要です AWS 料金見積りツール。
以下を検討することをお勧めします。
+ 詳細なモニタリングを有効にし、CloudWatch カスタムメトリクスをデプロイして、ストレージのパフォーマンス要件を正確にキャプチャします。
+ Amazon EBS ストレージを gp2 から gp3 にアップグレードして、コストを削減し、柔軟性を高め、パフォーマンスを向上させます。
+ Amazon EBS ストレージを io1 から io2 にアップグレードして、耐久性とパフォーマンスの柔軟性を高めます。
+ 耐久性とパフォーマンスを向上させるために、可能であれば io1 または io2 の代わりに io2BX を使用します。
+ キャパシティ要件と高パフォーマンスボリュームのコストを削減するために、ストレージを選択するときは種々の組み合わせを検討してください。例えば、ルートボリューム (オペレーティングシステム)、SQL Server のインストール、システムデータベース (tempdb を除く)、およびパフォーマンスの低いユーザーデータベースには低コストの gp3 ボリュームを使用できます。これにより、io2 ボリュームのキャパシティとコストを削減できます。io2 ボリュームは、高パフォーマンスユーザーデータベース専用にすることができます。
+ SQL Server データベースを でホストする場合は AWS、データベースごとに複数の SQL Server データファイルを使用することをお勧めします。これにより、読み取り/書き込みワークロードを複数のボリュームに分散できるため、ボリュームあたりのパフォーマンスとキャパシティの要件が軽減され、結果としてコストを削減できます。
+ 本番ワークロードが io1 や io2/io2BX などの高パフォーマンスストレージを必要とする場合でも、コストを削減するために非本番ワークロードには gp3 ボリュームの使用を検討してください。
+ ストレージ使用率を経時的に追跡および傾向分析して、使用量の急増や予期しないコストを容易に特定します。
+ 実際の使用率に基づいて EBS ボリュームをスケールアップまたはスケールダウンするための推奨事項を取得するには [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用します。
+ の伸縮性を使用して AWS 、Amazon EBS の SSD ボリュームのパフォーマンスと容量のニーズを調整します。オンプレミス環境とは異なり、将来のワークロード用にストレージのパフォーマンスとキャパシティを過剰にプロビジョニングする必要はありません。データベースをオンラインに保ちながら、既存の SQL Server ワークロードを に移行 AWS し、必要に応じてパフォーマンスや容量を調整できます。
## その他のリソース
+ 「[Amazon EBS volume types](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)」(Amazon EBS ドキュメント)
+ 「[Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html)」(Amazon EBS ドキュメント)
+ 「[Provisioned IOPS SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/provisioned-iops.html)」(Amazon EBS ドキュメント)
+ 「[EC2 インスタンスの SSD インスタンスストアボリューム](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html)」 (Amazon EC2 ドキュメント)
+ 「[Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html)」(Amazon EBS ドキュメント)
+ 「[Specifications for Amazon EC2 storage optimized instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/so.html)」(Amazon EC2 ドキュメント)
+ [Amazon FSx for NetApp ONTAP で NetApp SnapCenter を使用して SQL Server ワークロードを保護する](https://aws.amazon.com/blogs/storage/using-netapp-snapcenter-with-amazon-fsx-for-netapp-ontap-to-protect-your-sql-server-workloads/) (AWS ストレージブログ)
+ [Amazon EC2 に関するよくある質問](https://aws.amazon.com/ec2/faqs/) (AWS 製品ページ)
# Compute Optimizer を使用して SQL Server ライセンスを最適化する
を使用して SQL Server のライセンスを最適化する方法に関するガイダンス AWS Compute Optimizer。
## 概要:
[AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html) は、Amazon Elastic Compute Cloud (Amazon EC2) 上の Microsoft SQL Server ワークロードのライセンス最適化の機会を推奨できます。Compute Optimizer は、ライセンスコストを削減するための自動推奨事項を提供できます。Compute Optimizer からの推奨事項は、Microsoft SQL Server ライセンスを持つ各 EC2 インスタンスの横に表示されます。提供される情報には、推奨される節約の機会、EC2 インスタンスのオンデマンド料金、時間単位のライセンス持ち込み (BYOL) 料金が含まれます。この情報は、ライセンスエディションをダウングレードすべきかどうかを判断するのに役立ちます。
Compute Optimizer は、推論されるワークロードタイプによって Amazon EC2 上の SQL Server インスタンスを自動的に検出します。ライセンスの推奨事項を表示するには、Compute Optimizer で SQL Server インスタンスを選択し、読み取り専用データベース認証情報を使用して [Amazon CloudWatch Application Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html) で認証します。Compute Optimizer は、SQL Server Enterprise Edition の機能を使用しているかどうかを分析します。Enterprise Edition の機能が使用されていない場合、Compute Optimizer は、ライセンスコストを削減するために Standard Edition にダウングレードすることを推奨します。
Compute Optimizer を使用して、SQL Server ワークロードを実行する Amazon EC2 インスタンスのサイズ設定に関する推奨事項を示すこともできます。詳細については、このガイドの「[Compute Optimizer を使用して SQL Server のサイズ設定を最適化する](sql-server-sizing-compute-optimizer.md)」を参照してください。
## コスト最適化の推奨事項
Compute Optimizer のライセンス推奨事項は、Microsoft SQL Server で使用している機能を評価し、ワークロードに対して最もコスト効率が高いエディションを選択するのに役立ちます。SQL Server Enterprise Edition は、Standard Edition よりかなり高額です。詳細については、このガイドの「[SQL Server エディションの比較](sql-server-editions.md)」および Microsoft ウェブサイトの「[SQL Server 2022 pricing](https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing)」を参照してください。時間をかけて、SQL Server フリートを評価して推奨事項を提供するように Compute Optimizer を設定すれば、ライセンスコストを大幅に削減できます。
**[ライセンスの詳細]** ページには、次の情報が表示されます。
+ この表を使用して、現在のライセンス設定 (エディション、モデル、インスタンスコア数など) を Compute Optimizer の推奨事項と比較します。
+ 使用率グラフを使用して、分析期間中に使用された Enterprise Edition の機能の数を確認します。
詳細については、Compute Optimizer ドキュメントの「[Viewing details of a commercial software license recommendation](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-license-recommendations.html#license-viewing-details)」を参照してください。
## Compute Optimizer を設定する
Compute Optimizer は、`mssql_enterprise_features_used` メトリクスを使用して商用ソフトウェアライセンスを分析します。このメトリクスの詳細については、「[Metrics for commercial software licenses](https://docs.aws.amazon.com/compute-optimizer/latest/ug/metrics.html#license-metrics-analyzed)」を参照してください。
1. Compute Optimizer にオプトインするための適切なアクセス許可があることを確認します。詳細については次を参照してください:
+ [Compute Optimizer にオプトインするポリシー](https://docs.aws.amazon.com/compute-optimizer/latest/ug/security-iam.html#opting-in-access)
+ [スタンドアロン AWS アカウントに Compute Optimizer へのアクセス権を付与するポリシー](https://docs.aws.amazon.com/compute-optimizer/latest/ug/security-iam.html#standalone-account-access)
+ [組織の管理アカウントに Compute Optimizer へのアクセスを許可するポリシー](https://docs.aws.amazon.com/compute-optimizer/latest/ug/security-iam.html#organization-account-access)
1. CloudWatch アプリケーションインサイトに必要なインスタンスロールとポリシーをアタッチします。手順については、「[商用ソフトウェアライセンス推奨を有効にするポリシー](https://docs.aws.amazon.com/compute-optimizer/latest/ug/security-iam.html#license-access)」を参照してください。
1. Microsoft SQL Server データベースの認証情報を使用して CloudWatch アプリケーションインサイトを有効にします。手順については、CloudWatch ドキュメントの「[AWS Management Console を使用してモニタリングするようにアプリケーションを設定する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/appinsights-setting-up.html)」を参照してください。
**注記**
商用ソフトウェアライセンスの推奨事項を生成するには、連続して 30 時間以上の CloudWatch のメトリクスデータが必要です。詳細については、「[CloudWatch metric requirements](https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html#requirements-metrics)」を参照してください。
1. 次の SQL クエリを使用して、CloudWatch Application Insights の最小特権アクセスを設定します。
```
GRANT VIEW SERVER STATE TO [LOGIN];
GRANT VIEW ANY DEFINITION TO [LOGIN];
```
これにより、新しいサービス、PrometheusSqlExporterSQL が有効になります。
1. ターゲット AWS アカウント または組織管理アカウントから、Compute Optimizer にオプトインします。手順については、「[アカウントにオプトインする](https://docs.aws.amazon.com/compute-optimizer/latest/ug/getting-started.html#account-opt-in)」を参照してください。
**注記**
オプトイン後の検出結果と最適化のレコメンデーションの生成には、最大 24 時間かかることがあります。
1. [Compute Optimizer コンソール](https://console.aws.amazon.com/compute-optimizer/)のナビゲーションペインで、**[ライセンス]** を選択します。
1. **[検出結果]** 列で、検出結果が **[メトリクスが不十分]** であるインスタンスを検索します。Compute Optimizer は、CloudWatch Application Insights が有効になっていない、または権限が不十分であることを検出した場合、この検出結果を返します。詳細については、「[Finding reasons](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-license-recommendations.html#license-finding-reasons)」を参照してください。これらの検出結果を解決するには、以下を実行します。
1. インスタンスを選択します。
1. シークレットを追加します。
1. インスタンスロールとポリシーがアタッチされていることを確認します。
1. **[ライセンスのレコメンデーションを有効にする]** を選択します。
1. **[検出結果]** 列で、検出結果が **[最適化されていません]** であるインスタンスを検索します。Compute Optimizer は、お客様の Amazon EC2 インフラストラクチャが支払い対象の Microsoft SQL Server ライセンス機能をまったく使用していないことを検出した場合、この検出結果を返します。詳細については、「[Finding reasons](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-license-recommendations.html#license-finding-reasons)」を参照してください。これらの検出結果を解決するには、以下を実行します。
1. インスタンスを選択します。
1. 現在のライセンスエディションと推奨エディションを比較します。
1. 現在のライセンス使用率グラフを確認します。
1. ライセンスをダウングレードする場合は、**[推奨事項の導入]** を選択します。
1. 要件を確認し、手順に従ってライセンスをダウングレードします。プロセスを自動化する場合は、[「ドキュメントを使用した AWS Systems Manager SQL Server Enterprise Edition のダウングレード」を参照してコストを削減します](https://aws.amazon.com/blogs/mt/downgrade-sql-server-enterprise-edition-using-aws-systems-manager-document-to-reduce-cost/) (AWS ブログ）。
## その他のリソース
+ [による Microsoft SQL Server ライセンスコストの削減 AWS Compute Optimizer](https://aws.amazon.com/blogs/modernizing-with-aws/reduce-microsoft-sql-server-licensing-costs-with-aws-compute-optimizer/) (AWS ブログ)
+ [とは AWS Compute Optimizer(](https://docs.aws.amazon.com/compute-optimizer/index.html)AWS ドキュメント)
+ 「[Viewing commercial software license recommendations](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-license-recommendations.html)」(AWS ドキュメント)
+ 「[Downgrade your Microsoft SQL Server edition](https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/downgrade-sql-server-on-ec2.html)」(AWS ドキュメント)
+ 「[Microsoft SQL Server on AWS](https://aws.amazon.com/sql/)」(AWS)
+ 「[AWSでの Microsoft ライセンシング](https://aws.amazon.com/windows/resources/licensing/)」(AWS)
+ 「[Microsoft SQL Server 2019 Pricing](https://www.microsoft.com/en-us/sql-server/sql-server-2019-pricing)」(Microsoft)
+ 「[Microsoft SQL Server 2022 Pricing](https://www.microsoft.com/en-us/sql-server/sql-server-2022-pricing)」(Microsoft)
# Compute Optimizer を使用して SQL Server のサイズ設定を最適化する
## 概要:
[AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html) は、データベース管理者 (DBA) が Amazon Elastic Compute Cloud (Amazon EC2) で Microsoft SQL Server ワークロードを検出し、EC2 インスタンスのサイズを適正化してライセンスコストを最大 25% 削減するのに役立ちます。Compute Optimizer の[推定ワークロードタイプ](https://docs.aws.amazon.com/compute-optimizer/latest/ug/inferred-workload-type.html)機能は、機械学習 (ML) を使用し、 AWS リソースで実行されている可能性のあるアプリケーションを自動的に検出します。Compute Optimizer には、推論されるワークロードタイプとしての SQL Server のサポートが含まれています。推論されるワークロードタイプ機能を使用すると、Amazon EC2 インスタンスで実行されている特定のワークロードに基づいてコスト削減の機会を正確に特定できます。
この機能により、SQL Server など、サポートされている推論されるワークロードタイプ別にコスト削減の機会を分類できます。Compute Optimizer は、過剰にプロビジョニングされた SQL Server EC2 インスタンスを自動的に検出できます。EC2 コンソールに切り替えてインスタンスをダウンサイズすることで、ライセンスとインフラストラクチャのコストを削減できます。
Compute Optimizer を使用して、SQL Server ライセンスの推奨事項を示すこともできます。詳細については、このガイドの「[Compute Optimizer を使用して SQL Server ライセンスを最適化する](sql-server-compute-optimizer.md)」を参照してください。
## Compute Optimizer を設定する
SQL Server の推定ワークロードで Compute Optimizer を使用する手順については、[「パフォーマンスの最適化とライセンスコストの削減: Amazon EC2 SQL Server インスタンス AWS Compute Optimizer の活用](https://aws.amazon.com/blogs/modernizing-with-aws/optimizing-performance-and-reducing-licensing-costs-leveraging-aws-compute-optimizer-for-ec2-sql-server-instances/)」(AWS ブログ) を参照してください。スタンドアロンアカウント、組織のメンバーであるアカウント、組織の管理アカウントに対してオプトインできます。スタンドアロンアカウントとメンバーアカウントの場合は、オプトインすると、そのアカウントに対してのみ Compute Optimizer が有効になります。組織の管理アカウントの場合は、そのアカウントでのみ Compute Optimizer を有効にするか、組織内のすべてのメンバーアカウントに対して有効にするかを選択できます。
Compute Optimizer のオプトインプロセスでは、 AWS Identity and Access Management (IAM) サービスにリンクされたロールが自動的に作成されます。詳細については、「[AWS Compute Optimizerのサービスにリンクされたロールの使用](https://docs.aws.amazon.com/compute-optimizer/latest/ug/using-service-linked-roles.html)」を参照してください。
Compute Optimizer は、CPU、I/O、ネットワーク、Amazon Elastic Block Store (Amazon EBS) の使用状況などの Amazon CloudWatch メトリクスに基づいてリソースを分析します。推奨事項を生成するには、過去 14 日間における連続した 30 時間以上の CloudWatch メトリクスデータが必要です。拡張インフラストラクチャメトリクス機能を有効にすると、使用率メトリクスが 93 日に延長されます。詳細については、Compute Optimizer ドキュメントの「[CloudWatch metric requirements](https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html#requirements-metrics)」と「[Enhanced infrastructure metrics](https://docs.aws.amazon.com/compute-optimizer/latest/ug/enhanced-infrastructure-metrics.html)」を参照してください。
Compute Optimizer は、vCPU、メモリ、ストレージ、ネットワーク、リスク、移行の労力に基づいて、オプションと各オプションに関連する節約を提供します。CloudWatch メトリクスダッシュボードを使用して、推奨事項の作成に使用されているデータを分析できます。このデータを使用すると、SQL Server ワークロードを実行している EC2 インスタンスのサイズを適正化できます。インスタンスタイプの変更方法の詳細については、Amazon EC2 ドキュメントの「[Amazon EC2 インスタンスタイプの変更](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html)」を参照してください。
## その他のリソース
+ [AWS Compute Optimizer Microsoft SQL Server ワークロードを識別してフィルタリング](https://aws.amazon.com/about-aws/whats-new/2023/05/aws-compute-optimizer-identifies-filters-sql-server-workloads/)する (AWS)
+ [パフォーマンスの最適化とライセンスコストの削減: Amazon EC2 SQL Server インスタンス AWS Compute Optimizer の活用](https://aws.amazon.com/blogs/modernizing-with-aws/optimizing-performance-and-reducing-licensing-costs-leveraging-aws-compute-optimizer-for-ec2-sql-server-instances/) (AWS ブログ)
+ [とは AWS Compute Optimizer(](https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html)AWS ドキュメント)
+ [EC2 インスタンスのレコメンデーションの表示](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ec2-recommendations.html) (AWS ドキュメント)
# SQL Server ワークロードの Trusted Advisor レコメンデーションを確認する
## 概要:
[AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) は、 AWS ベストプラクティスに従うのに役立つ推奨事項を提供します。は、使用状況、設定、支出を分析することで、コスト削減、システムの可用性とパフォーマンスの向上、セキュリティギャップの解消に役立つ実用的な推奨事項 Trusted Advisor を提供します。このセクションでは、 での SQL Server ワークロードの運用コストを削減するのに役立つ Trusted Advisor チェックに焦点を当てます AWS クラウド。
## コスト最適化の推奨事項
Trusted Advisor は、Amazon Elastic Compute Cloud (Amazon EC2) で SQL Server ワークロードを最適化するのに役立つ推奨事項を提供します。このチェックでは、SQL Server ワークロードを検査し、最適化が必要なインスタンスを自動的に一覧表示します。 Trusted Advisor レコメンデーションを運用することで、コストを削減し、組織のセキュリティ体制を向上させることができます。
Microsoft SQL Server に焦点を当てた Trusted Advisor チェックを次に示します。
+ [過剰にプロビジョニングされた Amazon EC2 インスタンス (Microsoft SQL Server 向け)](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html#ec2-instance-over-provisioned-microsoft-sql-server) – このチェックでは、SQL Server を実行している Amazon EC2 インスタンスを分析し、インスタンスが SQL Server ソフトウェアの vCPU 制限を超えた場合に警告します。例えば、SQL Server Standard Edition を使用するインスタンスでは、最大 48 個の vCPU を使用できます。SQL Server Web を使用するインスタンスでは、最大 32 個の vCPU を使用できます。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/sql-server-trusted-advisor.html)
+ [Amazon EC2 インスタンスの統合 (Microsoft SQL Server 向け)](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html#ec2-instances-consolidation-sql-server) – このチェックでは、Amazon EC2 インスタンスを分析し、インスタンスが SQL Server ライセンスの最小数より少ない場合に警告します。小さめの SQL Server インスタンスを統合して、コストの削減に役立てることができます。ライセンス込みの小さな SQL Server インスタンスが多数ある場合は、統合することを検討してください。「[Microsoft SQL Server 2019 licensing guide](https://download.microsoft.com/download/e/2/9/e29a9331-965d-4faa-bd2e-7c1db7cd8348/SQL_Server_2019_Licensing_guide.pdf)」によると、SQL Server ではインスタンスごとに最低 4 つの vCPU ライセンスが必要です。これらのデータベースを統合すると、ライセンスコストを節約できます。インスタンス上のデータベースの数、データベースの最大サイズ、データベースの合計サイズに基づいて決定できます。統合は、SQL Server の Web、Standard、Enterprise の各エディションでサポートされています。詳細については、「[Consolidating SQL Server Databases](https://learn.microsoft.com/en-us/archive/blogs/mvpawardprogram/consolidating-sql-server-databases)」(Microsoft ブログ記事) を参照してください。
AWS では、大規模な本番稼働用データベースを 1 つのサーバーにのみ配置することはお勧めしません。ただし、開発、テスト、ステージングなど、非本番環境に使用される小規模なデータベースを統合することは可能です。これは現在の SQL Server の使用状況によって異なります。使用量の少ないデータベースがある場合は、1 つのサーバーに統合できます。
## 設定 Trusted Advisor
SQL Server に焦点を当てたチェックを評価するには、以下を実行します Trusted Advisor。
1. AWS マネジメントコンソールにサインインします。
1. [AWS Trusted Advisor コンソール](https://console.aws.amazon.com/trustedadvisor/home)を開きます。
1. ナビゲーションペインの **[推奨事項]** の下で、**[コスト最適化]** を選択します。
1. **[コスト最適化チェック]** リストで、**[Amazon EC2 インスタンスの統合 (Microsoft SQL Server 向け)]** のチェックと **[過剰にプロビジョニングされた Amazon EC2 インスタンス (Microsoft SQL Server 向け)]** のチェックのステータスを確認します。
+ 緑色のチェック記号は、Amazon EC2 インスタンスが最適に設定されていることを示します。
+ オレンジ色のアラート記号は、改善の機会があることを示します。
1. チェックを選択すると、詳細と推奨事項が表示されます。
1. SQL Server ワークロードを実行している Amazon EC2 インスタンスを最適化するには、チェックで提供された指示に従います。
1. インスタンスを定期的にモニタリングし、チェックを定期的に更新します。
## その他のリソース
+ [Trusted Advisor チェックリファレンス](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) (AWS ドキュメント)
+ 「[Microsoft SQL Server on AWS](https://aws.amazon.com/sql/)」(AWS)
+ 「[AWSでの Microsoft ライセンシング](https://aws.amazon.com/windows/resources/licensing/)」(AWS)
+ 「[SQL Server 2019 pricing](https://www.microsoft.com/en-us/sql-server/sql-server-2019-pricing)」(Microsoft)
+ [AWS Launch Wizard for SQL Server](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sql.html) (AWS ドキュメント)