Microsoft SQL Server を AWS にデプロイするためのベストプラクティスを紹介 !

AWS が提唱している AWS Well-Architected フレームワークの 5 つの柱をベースに、下記5つの項目で構成されています。

それでは、Microsoft SQL Server を AWS クラウドにデプロイして運用するにあたり、どのようなベストプラクティスが活用できるのか見ていきましょう。

ビジネスにおいてサービスが提供できなくなる事態の発生頻度が少ないに越したことはありませんが、いつ何時災害が発生するかは誰にもわかりません。

ここでは、災害が発生してもビジネスが継続できるようにするために目標復旧時間 (RTO) と目標復旧時点 (RPO) を考慮した災害対策を事前に講じておき、お使いのシステムやアプリケーションのデータを守るうえで、Microsoft SQL Server のどの Edition が最適なのかを確認していただけるようになっています。詳しくは、このホワイトペーパー内の「表 1: Microsoft SQL Server の HA/DR オプション」を参照してください。

これに加えて、次の 4 つの点に関する推奨事項について紹介されています。

AWS のアベイラビリティーゾーンは、別々の障害ドメインを提供してワークロードを低レイテンシーで通信するために比較的近接するように設計されているため、ミラーリング、Always On 可用性グループ、基本可用性グループ、またはフェイルオーバークラスターインスタンスを使用したデータベースの同期レプリケーションに適しています。

ここでは、アベイラビリティーゾーンの性能とMicrosoft SQL Server を組み合わせて使用することで、データ損失をゼロにし、より高いパフォーマンスを実現することについて、下記 2 つの例で説明しています。

Amazon FSx については、「パフォーマンス最適化」と「コストの最適化」も合わせてご一読ください。

ここでは、可用性が高くなるとパフォーマンスが低下するため、クラスタープレイスメントグループと拡張ネットワーキングを用いて、AWS でこの差異を軽減する次の方法を紹介しています。

サーバーに近接すると同時に障害が発生する可能性が高くなるため、高可用性の要件と競合しているように見えますが、マルチ AZ と組み合わせることで、より高いレベルの可用性を得ることができます。

また、クラスタープレイスメントグループ内に Always On フェイルオーバークラスターインスタンス (FCI) を作成した場合の例や 2 つの EC2 インスタンスを同じ物理ホストで実行する場合の例についても触れています。

Amazon Virtual Private Cloud (Amazon VPC) はデフォルトで単一のリージョン内に限定されているため、マルチリージョンでデプロイするには、異なるリージョンにデプロイされている Microsoft SQL Server インスタンス間で接続を確立する必要があるため、その方法として、下記 4 つを紹介しています。(各機能の詳細はリンク先を見ていただくか、ホワイトペーパー(本体) でご確認ください)

また、複数のリージョンにまたがるケースについても、次のように紹介されています。

分散可用性グループに関しては活用例が紹介されていますので、ホワイトペーパー (本体) の該当セクションもご一読ください。

災害対策では、サーバーはプライマリサイトから遠く離れたリモートサイトに設置されていることが多く、同期レプリケーションを使用する高可用性要件のソリューションを適用している場合は高レイテンシーになり、パフォーマンスが低下します。そのため、災害対策要件のソリューションでは、コスト、RPO、RTO、複雑さ、各ソリューションを実装するための取り組みなどの要件に基づいて選択されています。

AWSでは、ログシッピングや Windows 記憶域レプリカなどの一般的な Microsoft SQL Server の災害対策要件のソリューションに加えて、CloudEndure Disaster Recovery の使用も推奨しています。この機能を使用すると、ダウンタイムを数分に短縮し、1 秒未満の RPO でデータ損失を防ぎ、実装を簡素化して、信頼性を高め、総所有コストを削減できます。また、復旧するワークロードに必要とされる適切なサイズのコンピューティングや高性能なストレージを備えたプロビジョニング済みの完全な災害対策環境のみを災害演習のときに起動させることができます。(AWS では、移行プロジェクトの場合に追加コストなしで CloudEndure Migration をご利用いただけます。詳細は、CloudEndure Migration のページをご覧ください)

お使いのシステム構成によっては、パフォーマンスを最大限に高めることが最適化に繋がる場合があります。Microsoft SQL Server および AWS のワークロードのパフォーマンスを大幅に向上させるベストプラクティスとして下記を紹介しています。

次のセクションでは、AWS クラウドで Microsoft SQL Server のパフォーマンスを最大限に高めるためのインフラストラクチャ設計部分に焦点を当てたベストプラクティスを紹介します。

Amazon EBS (単一 AZ のブロックストレージサービス) での EBS ボリュームはシンプルで使いやすく、様々なケースで効果的に使用できます。ここでは、EBS ボリュームを使用する場合のベストプラクティスについて紹介します。

EC2 インスタンスではインスタンスストレージが最速ですが、物理ディスクの速度にパフォーマンスの上限があります。そのため、複数のディスクにまたがってストライピングすることで、単一ディスクの最大値を超えて使用することが可能になります。記憶域スペース (単一の Windows インスタンスの場合) および記憶域スペースダイレクト (Windows Server フェイルオーバークラスターの場合) のストレージプールのキャッシュレイヤーとしても、このインスタンスストレージをご利用いただけます。ここでは、インスタンスストレージのパフォーマンスを最大限に高めるベストプラクティスについてご紹介します。

注) インスタンスストレージは、関連付けられた EC2 インスタンスが存在している間のみ利用できます。EC2 インスタンスに障害が発生してインスタンスが停止/終了した場合は、そのインスタンスストアボリューム内のデータはすべて消去されます。EBS ボリュームとは異なり、インスタンスストアボリュームのスナップショットを使用してバックアップできないため、永続性が求められるデータに インスタンスストレージを使用する場合は、耐久性を考慮する必要があります。

ワークロードに適したパフォーマンスを実現できるよう、スループットレベルをファイルシステムのサイズとは別に選択できる Amazon FSx for Windows ファイルサーバー を推奨しています。スループット容量のレベルが高いほど、接続する SQL Server インスタンスに対して処理できる IOPS レベルも高くなるため、Microsoft SQL Server のストレージオプションのひとつになっています。このベストプラクティスは、次のようなケースに適しています。

パフォーマンスを最適化するにはレイテンシーと帯域幅について考慮し、ネットワークのレイテンシーと可用性のバランスを取る必要があります。ここでは、次のベストプラクティスを紹介しています。

Microsoft SQL Server でもリードレプリカを利用できるようになり、読み取り頻度の高いデータベースワークロードに対してリードレプリカの作成が推奨されています。Microsoft SQL Server でリードレプリカを使用する際のベストプラクティスをご紹介します。

クラウド上のセキュリティ強化は、AWS の最優先事項です。AWS で提供しているセキュリティーサービスと Microsoft SQL Server の組み込みセキュリティ機能を組み合わせることで、さらにセキュリティの強化を行うことができます。

転送中のデータ保護に役立つ機能がたくさん用意されている Amazon VPC では、ベストプラクティスとして SQL Server インスタンスを Amazon VPC 内のプライベートサブネットにデプロイし、Amazon VPC で NAT ゲートウェイまたはカスタム NAT インスタンスを介するインターネットアクセスのみを許可することを推奨しています。

保管時にデータファイルを暗号化して保存する方法のベストプラクティスとして、下記を推奨しています。

＜EBS 暗号化と TDE のトレードオフとその違いについて＞

EBS 暗号化と TDE には下記の違いがあります。

• EBS 暗号化はブロックレベルで行われます。この場合、データは保存時に暗号化され、取得時に復号化されます。
• TDE では暗号化はファイルレベルで行われます。この場合、データファイルは保存時に暗号化されますが、復号化には該当の証明書が必要です。

EBS 暗号化と TDEの使用例がホワイトペーパー (本体) に紹介されていますので、合わせてご一読ください。

転送時の暗号化には、次のベストプラクティスが推奨されています。

使用中の暗号化には、Microsoft SQL Server で提供している Always Encrypted の使用を推奨しています。この機能は、クライアント証明書を使用して機密データを保護するために用意されていますが、ユーザー権限を分離して管理することができます。(Amazon RDS for SQL Server および Amazon EC2 の SQL Server ワークロードで利用可)

暗号化/復号化キーの管理には、AWS KMS の利用を推奨しています。AWS KMS で生成されたキーまたは独自のキーのいずれを使用しても、AWS KMS からキーが送信されることはないので、不正なアクセスから保護できます。SQL Server バックアップファイルを Amazon S3、Amazon S3 Glacier、その他のストレージサービスに保存する際にも AWS KMS のキーを使用して暗号化できます。

AWS では、AWS Systems Manager Patch Manager を使用して、セキュリティパッチとアップデートの定期的なデプロイを自動化して管理することを推奨しています。Patch Manager のユースケースは、セキュリティパッチに限定されないことに注意してください。この記事の「運用上の優秀性」トピックの「パッチ管理」も参考にしてください。

ライセンス料金はコスト最適化を行う上では重要なポイントです。AWS では、お客様の状況に合わせて、下記 2 つのライセンスモデルが利用可能です。

次のセクションで、他にもどのようなコスト最適化ができるのか見ていきましょう。

ビジネス要件により Microsoft SQL Server のデプロイに、コンピューティング集約型またはメモリやストレージなどのリソースに特化した EC2 インスタンスタイプが必要な場合があります。このような特定の要件に特化した EC2 インスタンスタイプでは、必要とする要件以上の CPU コア数が提供されているため、全く使用していない CPU コアにもライセンスコストが発生してしまいます。

これを防ぐ方法として、EC2 インスタンスの起動時に CPU オプションを指定することによるライセンスコストの最適化を推奨しています。(CPU オプションは EC2 インスタンスの起動時のみに利用可能です。起動後は利用できませんので、ご注意ください)

Microsoft SQL Server 2019 より Standard Edition でも利用可能になっている機能があります。下記などの機能を使用するために Enterprise Edition を利用していた場合は、Standard Edition に切り替えてライセンスコストを抑えることができます。

お使いの Microsoft SQL Server がより高速なシーケンシャル処理を必要とするワークロードである場合は、z1d インスタンスの利用を検討することを推奨しています。このインスタンスで実行できる CPU コア数は少ないですが、ライセンスコストが高いワークロード向けに最適化されているインスタンスなので、CPU コアを多く持つインスタンスを実行するのと同等またはそれ以上のパフォーマンスで運用することができます。

LI モデルと BYOL モデルを組み合わせてアクティブレプリカのコスト最適化を行うことができます。よくあるソリューションとして、アクティブレプリカを持つ Microsoft SQL Server Always On 可用性グループの使用があります。これは、アクティブレプリカのジョブが下記のケースで実行される場合に最適です。

上記のような場合に、AWS ではセカンダリインスタンスをアクティブレプリカからパッシブレプリカに切り替えることで、このアーキテクチャを最適化することができます。高可用性の維持はパッシブレプリカが引き続き行い、その他のジョブは、LI モデルを使用して作成された別のインスタンス上で実行します。(ジョブを数時間実行してからインスタンスを停止できます)

継続的または高頻度で実行されるジョブのためのレプリカが必要な場合は、AWS Database Migration Service (AWS DMS) を使用して、プライマリインスタンスからセカンダリインスタンスにデータを継続的にレプリケートすることを検討してください。この方法は、Standard Edition を使用して実行できるので、Enterprise Edition を利用する必要がなく、ライセンスコストを抑えることができます。

AWS でのライセンスコストを最適化する方法の詳細については、AWS での Microsoft ライセンシングページを参照してください。

ここでは、AWS クラウドに Microsoft SQL Server をデプロイした後で、障害やインシデントが常に発生することを想定し、それらに対応できるよう準備しておくことの重要性についてふれています。このセクションでは、次の 3 つについて推奨しています。

Microsoft SQL Server ワークロードに対する異常の観察と検出を行うために、Amazon CloudWatch Application Insights の利用を推奨しています。この機能を有効にすると、アプリケーションのリソース全体とテクノロジースタックで主要なメトリクスやログを特定して設定します。エラーが検出されると CloudWatch Events が作成され、通知の設定やアクションの実行に使用でき、トラブルシューティングを円滑に行うことができます。

Amazon CloudWatch Application Insights を有効にすると自動でダッシュボードが生成されることに加えて、AWS リソースに関連する運用作業項目 (OpsItems) も作成されます。この運用作業項目 (OpsItems) は、AWS Systems Manager の OpsCenter で管理されるため、この機能の利用が推奨されています。この OpsCenter は、問題を解決するまでの平均時間を短縮するように設計されています。

パッチ管理には、AWS Systems Manager Patch Manager の利用を推奨しています。このパッチマネージャーでは、Microsoft SQL Server を含む Microsoft アプリケーションがサポートされています。また、メンテナンスウィンドウと統合されているので、パッチを含む定期的なスケジュールを定義して管理することができます。

今回は「Microsoft SQL Server を AWS にデプロイするためのベストプラクティス」でどのようなベストプラクティスが紹介されているのか要点をざっとまとめてみましたが、いかがでしたでしょうか ?

皆さんが運用しているシステムのコスト最適化にご活用いただけますと幸いです。