Amazon Web Services ブログ

分散型可用性グループを使用して、ハイブリッドMicrosoft SQL Serverソリューションを設計する方法

モノリシックでミッションクリティカルなMicrosoft SQL ServerデータベースをオンプレミスからAWS（Amazon EC2ベースのSQL Server）に移行することは、しばしば困難な作業です。主な課題は次の通りです：

  • 継続的なダウンタイム – ビジネスに悪影響を及ぼす可能性のあるカットオーバー中の継続的なダウンタイムウィンドウが発生する課題
  • データ同期の課題 – オンプレミスに配置されたデータベースとAWS上のデータベースを同期した状態に維持するための課題
  • 柔軟性の欠如 – 移行のための段階的なアプローチを計画・実行する為の柔軟性を確保する課題

この記事では、重要なSQL ServerデータベースをAWSにリフト＆シフト（またはリフト＆トランスフォーム）するためのハイブリッドソリューションの構築方法について詳しく説明します。このソリューションでは、SQL Server 2016で導入された新しい機能である分散型可用性グループを使用します。この記事では、分散型可用性グループを使用して移行を制御し、柔軟性を高める段階的アプローチについても説明します。

分散型可用性グループの概要

分散型可用性グループは、2つの個別の可用性グループにまたがる特別なタイプの可用性グループ（AG）です。分散型可用性グループは複数の可用性グループの1つ（または複数のAGの中の1つ）と考えることができます。基礎となる可用性グループは、2つの異なるWindows Server Failover Cluster（WSFC）で構成されます。

分散型可用性グループアーキテクチャは、既存のオンプレミスWindows Server Failover Cluster（WSFC）をAWSに拡張するよりも効率的です。データは、オンプレミスのプライマリからAWS上の1つのレプリカ（フォワーダ）にのみ転送されます。フォワーダは、AWS上の他のリードレプリカにデータを送信する役割を担います。このアーキテクチャにより、オンプレミスとAWSの間のトラフィックフローが削減されます。

アーキテクチャ概要

次の図は、ソリューションの全体的なアーキテクチャを示しています。

図に示されているように、最初のWSFCクラスタ（WSFC1）はオンプレミスでホストされています。オンプレミス可用性グループ（AG1）はこのWSFCクラスタに配置されます。 2番目のWSFCクラスタ（WSFC2）はAWSでホストされます。 AWS可用性グループ（AG2）はこのWSFCクラスタに配置されます。

このユースケースでは、オンプレミスのSQL Serverインスタンスとデータベースは、従来の物理サーバーまたは仮想マシン（VM）によってホストされています。 AWSのSQL ServerインスタンスはAmazon EC2でホストされ、SQL ServerデータベースはAmazon EBSボリュームで構成されます。 AWS Direct Connectによって、オンプレミスからAWSへの専用ネットワーク接続を確立しています。

前述のアーキテクチャ図に示すように、オンプレミス可用性グループ（AG1）には2つのレプリカ（ノード）があります。これらの間のデータ転送は、自動フェイルオーバーを使用して同期します。オンプレミスレプリカの1つに障害が発生すると、AGは2番目のレプリカにフェールオーバーすることで、アプリケーションとユーザーはDBを使用できます。各可用性グループは、1つのプライマリレプリカと最大8つのセカンダリレプリカをサポートしています。高可用性の要件と拡張性のニーズに基づいて追加のレプリカを同期または非同期にする必要があるかどうかを判断します。

AWS可用性グループ（AG2）にも2つのレプリカがあり、それらの間のデータ転送は自動フェールオーバーで同期しています。 EC2インスタンスまたは1つのアベイラビリティゾーンに障害が発生すると、AGは別のアベイラビリティゾーンにある2番目のEC2インスタンスにフェールオーバーします。

このソリューションの一環として、分散型可用性グループを構成します。このグループには、オンプレミス可用性グループ（AG1）とAWS可用性グループ（AG2）の両方が含まれます。分散型可用性グループは、前述の図において赤い点線で示すように、データベースを非同期で同期させます。

フォワーダ（前述の図で緑文字で表されている）は、AWS内の他のリードレプリカにデータを送信する役割を担います。このデータ転送により、オンプレミスとAWS間のトラフィックフローが減少します。オンプレミスからAWSへのデータ転送はプライマリレプリカから一度だけ実施され、フォワーダは残りの伝播を処理します。

どの時点でも、書き込みに使用できるデータベースは1つだけです。残りのセカンダリレプリカデータベースは読み取り用に使用できます。前述のサンプルアーキテクチャ図では、社内のプライマリデータベースを読み取り/書き込み可能にし、AWSセカンダリデータベースを読み取りに使用できます。

AWSでリードレプリカを追加できることが重要なメリットです。この能力があれば、AWSへの移行に際して、読取り専用アプリをAWSに最初に移行することができます。また、データベースは、AWS上のアプリケーションとそのユーザーにも近くなります。

読み込みのワークロードをスケールアウトする場合は、AWSにさらに多くのリードレプリカを追加できますし、複数のアベイラビリティゾーンに配置することも可能です。このアプローチは、以下のアーキテクチャ図で表されます。この図では3つの異なるアベイラビリティゾーンに、それぞれリードレプリカを配置しています。

段階的な移行方法

分散型可用性アーキテクチャを使用することで、段階的な移行が可能となり、移行における柔軟性を高めることができます。

フェーズ1

この段階では、ほとんどの読取り専用アプリケーションをAWSに移行して、AWS上の読取り専用セカンダリデータベースにアクセスします。読み取り/書き込みを行うアプリケーションは、引き続きオンプレミスのプライマリ・データベースにアクセスします。

クラウド移行のこのフェーズでは、ストレステスト、機能テスト、およびデータベース作業負荷の回帰テストが重要な要素です。読取りワークロードをサポートするためにEC2インスタンスを正しくサイジングすることもこのフェーズの重要なステップです。

考慮すべきもう1つの重要な点は、AWS側の読み取り専用アプリケーションが非同期に複製されたデータを読み取ることです。データのレプリケーションにはラグがあり、データの鮮度に影響します。このソリューションではDirect Connect接続が使用されるため、ラグは最小限に抑えられますが、レイテンシやデータの古さを許容できないアプリケーションについては、この点を考慮する必要があります。

以下にこのアーキテクチャを図示します。

フェーズ2

フェーズ2では、分散型可用性グループをAWSにフェイルオーバし、AWS上のデータベースがプライマリになります。読取り/書込みアプリケーションは、AWSのプライマリデータベースにアクセスするようになります。

AWSへ移行されない特定の読み取り専用アプリケーションは、引き続きオンプレミスのセカンダリデータベースにアクセスします。移行しないアプリケーションは、特定の時点以降に廃止する予定のアプリケーションのはずですが、しばらくは稼働する必要があり、遅延を避ける為にデータベースの近くに配置する必要があるものです。

フェールオーバーは手動で実行します。分散型可用性グループの同期状態(可用性モードの設定に依存)を同期に設定します。状態が同期されると、フェールオーバーを開始できます。フェイルオーバーは比較的迅速で、ダウンタイムを削減します。

以下にこのアーキテクチャを図示します。

セットアップと構成

分散型可用性グループを作成するための高度な手順は、次のとおりです。

  1. オンプレミス可用性グループを作成し、セカンダリレプリカを追加します。
  2. オンプレミス可用性グループ用のAGリスナーを作成します。
  3. AWS可用性グループを作成し、セカンダリレプリカをAWS可用性グループに追加します。
  4. AWS可用性グループ用のAGリスナーを作成します。
  5. オンプレミス側で可用性モードをAsynchronous_Commitに設定した分散型可用性グループを作成します。
  6. AWS側で分散型可用性グループに参加します。
  7. AWS可用性グループのデータベースを使用します。

構成スクリプトと手順の詳細については、分散型可用性グループに関するMicrosoftのドキュメントを参照してください。

まとめ

分散型可用性グループアーキテクチャにより、ミッションクリティカルなSQL ServerインスタンスまたはデータベースをAWSにリフト＆シフトする際の柔軟性がもたらされます。段階的なアプローチでは、移行手順をよりよく管理し、移行の道のりの一部であるストレステスト、回帰テスト、機能テストを十分に行うことができます。

次回の記事では、2つ以上のAWSリージョンに分散された可用性グループを構築する方法について議論する予定です。また、分散型可用性グループを設計する際に取り入れることのできるベストプラクティスとスタンダードについて議論する予定です。

最後まで読んで頂きありがとうございます、次回も引き続きお読み頂ければ幸いです。

About the Author


Anup Sivadasは、Amazon Web Servicesのソリューションアーキテクトです。

お客様と共に、AWSを使用する際にソリューションの価値を向上させるため、AWSサービスに関するアーキテクチャガイダンスと技術支援を提供するために活動しています。