Amazon Web Services ブログ
分散型可用性グループを使用したマルチリージョン SQL Server のデプロイ
SQL Server のマルチリージョンアーキテクチャは、多くの場合、お客様と連携する際に関心を集めるトピックです。SQL Server のデプロイにマルチリージョンアーキテクチャアプローチを採用する根本的な理由は次のとおりです。
- ビジネス継続性と災害復旧
- 地理的に分散したお客様の事業所とエンドユーザーのためのレイテンシーの改善
この投稿では、2 つ以上の AWS リージョンにまたがる可用性の高い SQL Server のデプロイを効果的に設計するためのアーキテクチャパターンについて説明します。また、マルチリージョンアプローチを使用して読み取りワークロードをスケールアウトし、グローバルに分散したエンドユーザーのためにレイテンシーを改善する方法についても学びます。
アーキテクチャ: 従来的かつ最適
この投稿では、マルチリージョンの Always On 可用性グループの従来のアプローチと、マルチリージョンの分散型可用性グループの最適なアプローチの 2 つのアーキテクチャについて説明します。
マルチリージョンの Always On 可用性グループ
従来のアプローチでは、リージョン間 VPC ピアリング接続を確立し、単一の Windows Server Failover Cluster (WSFC) が 2 つのリージョンにまたがるようにして、これら 2 つのリージョンのノードで Always On 可用性グループのデプロイを構築できます。次の図は、このアーキテクチャを示しています。
このアーキテクチャでは、リージョン A がプライマリレプリカをホストします。同期セカンダリレプリカもリージョン A でホストされています。プライマリレプリカはリージョン A の AZ1 にあり、同期セカンダリレプリカは AZ2 にあります。データ転送はレプリカ間で同期され、フェイルオーバーモードは自動フェイルオーバーです。AZ1 の接続障害またはその他の障害が発生した場合、自動フェイルオーバーが開始され、AZ2 ノードがプライマリレプリカになります。これは、Always On 可用性グループに参加しているサーバー上の単一のデータベースに障害が発生した場合に発生する動作と同じです。
ベストプラクティスとして、アプリケーションは、Always On 可用性グループリスナーを介して最新のサポートされているドライバーと主要パラメータ (MultiSubNetFailover=True など) を使用して接続し、フェイルオーバーを容易にして、アプリケーションがエラーまたはタイムアウトなしで新しいレプリカにシームレスに接続するようにします。クォーラム関連の設定についても考慮する必要があります。これについては、この投稿の後のセクションで説明します。
このアーキテクチャのリージョン B は、セカンダリリージョンとみなされます。2 番目と 3 番目のセカンダリレプリカはこのリージョンで設定され、リージョン A でホストされているプライマリから非同期に同期されます。データ転送モードが非同期として設定されているため、フェイルオーバーモードは手動として設定されます。非同期転送は、リージョン間通信の場合に推奨されます。リージョン A で壊滅的なリージョン障害が発生した場合、手動フェイルオーバーがトリガーされ、アプリケーションは可用性グループリスナーを介してリージョン B で新しく昇格されたプライマリレプリカに接続できます。
このアプローチの主な欠点の 1 つは、リージョン B のセカンダリレプリカのデータ同期の側面に関連しています。リージョン A のプライマリレプリカは、すべてのセカンダリレプリカにフィードし、リージョン B のすべてのセカンダリレプリカには、プライマリレプリカがネットワーク経由で個別にデータを送信する必要があります。複数のデータ転送を行うと、全体のデータ転送料金が増加する可能性があるため、コスト最適化戦略としては不適切です。
これを緩和する方法の 1 つは、セカンダリリージョン B に単一のノードのみを配置し、リージョンのフェイルオーバーが発生した場合に新しいノードを追加することです。他の欠点はセキュリティに関係しています。WSFC が複数のリージョンにまたがるようにする場合、セキュリティグループ用に多数のポートセットを開く必要があります。これには、クラスターサービスの TCP/UDP ポート、RPC の TCP ポート、クラスターアドミニストレーターの UDP、ICMP、SMB の TCP、およびランダムに割り当てられた高 UDP ポートが含まれます。広範囲のポートを開くことは、多くの場合、内部セキュリティチームに懸念事項として受け止められます。関連するポートの詳細については、Windows サポートのウェブサイトで、Windows のサービス概要およびネットワーク ポート要件を参照してください。
マルチリージョン分散可用性グループ
分散型可用性グループを備えたアーキテクチャは、マルチリージョン SQL Server のデプロイに最適なアプローチです。分散型可用性グループは、2 つの別個の可用性グループにまたがる特殊なタイプの可用性グループです。それを可用性グループの中の 1 つの可用性グループと捉えてもいいでしょう。基礎となる可用性グループは、2 つの異なる WSFC クラスターで構成されます。
分散型可用性グループアプローチを使用して、オンプレミスのデータセンターと AWS に SQL Server ノードをデプロイするハイブリッド SQL Server デプロイアーキテクチャを設計することもできます。詳細については、分散型可用性グループを使用して、ハイブリッドな Microsoft SQL Server ソリューションを設計する方法をご覧ください。
次の図は、マルチリージョンの分散可用性グループアーキテクチャを示しています。
このアーキテクチャでは、リージョン A がプライマリレプリカをホストします。リージョン A には WSFC1 という名前の単体の WSFC クラスターがあり、以前のアーキテクチャのようにリージョンにまたがっていません。同期セカンダリレプリカもリージョン A で、好ましくは 2 番目のアベイラビリティーゾーンで、ホストされます。プライマリレプリカはリージョン A の AZ1 にあり、同期セカンダリレプリカは AZ2 にあります。両方のレプリカは、AG1 という名前の単体の可用性グループの一部です。データ転送はレプリカ間で同期され、フェイルオーバーモードは自動フェイルオーバーです。障害が発生すると、自動フェイルオーバーが開始され、AZ2 ノードがプライマリレプリカになります。
ベストプラクティスとして、アプリケーションは、Always On 可用性グループリスナーを介して最新のサポートされているドライバーと主要パラメータ (MultiSubNetFailover=True など) を使用して接続し、フェイルオーバーを容易にして、アプリケーションがエラーまたはタイムアウトなしで新しいレプリカにシームレスに接続するようにします。考慮すべきクォーラム関連の設定もあります。これについては、この投稿の後のセクションで説明します。
このアーキテクチャのリージョン B は、セカンダリリージョンとみなされます。2 番目のセカンダリレプリカはこのリージョンで設定され、リージョン A でホストされているプライマリから非同期に同期されます。このレプリカはフォワーダーと呼ばれます。フォワーダーの概念は新しく、分散型可用性グループのコア機能の 1 つです。フォワーダーは、リージョン B の他のレプリカの同期を担当します。
フォワーダーは、この最適なアーキテクチャの主要な利点の 1 つです。リージョン A のプライマリレプリカは非同期でデータをフォワーダーにのみ送信し、フォワーダーは同期または非同期でリージョン B の他のレプリカにデータを送信します。これにより、リージョン B に複数のノードがある場合にリージョン A からリージョン B への全体的なデータ転送が削減されます。WSFC1 と WSFC2 は単体の独立したクラスターであるため、多数のポートを開く必要もありません。これにより、セキュリティ上のリスクが軽減されます。
読み取りのスケールアウト
分散可用性グループアーキテクチャをさらに拡張して、リージョン B にリードレプリカを提供できます。このアプローチは、2 つの異なるリージョンにアプリケーションのユーザーがいる場合に便利で、当該ユーザーは近くのリージョンから読み取りを消費できます。これにより、読み取り専用の SQL クエリのレイテンシーが改善します。次の図は、このアーキテクチャを示しています。
このアーキテクチャには、リージョン B 用に設定された 3 つの追加レプリカがあります。フォワーダーは、これら 3 つのレプリカのデータ同期を担当します。追加のレプリカを使用して、読み取りをスケールアウトできます。各可用性グループは、1 つのプライマリレプリカと最大 8 つのセカンダリレプリカをサポートします。基本的に、この構成では最大 18 個のリードレプリカを持つことができます。
SQL Server のよりシンプルで可用性の高い単一リージョンのデプロイに関心がある場合は、AWS Launch Wizard for SQL Server を利用できます。AWS Launch Wizard for SQL Server は、シンプルかつ直感的な無償のウィザードベースであり、可用性の高い SQL Server ソリューションの迅速かつ簡単な AWS へのデプロイを実現します。ウィザードは、手引きとなるガイドブックを使って、Always On 可用性グループのエンドツーエンドのデプロイを段階的に説明します。AWS Launch Wizard を使用すると、SQL Server ノード設定や AMI から Virtual Private Cloud (VPC)、Active Directory (AD)、EC2 インスタンスに至るまで、アプリケーションのコンポーネントを指定して、本番環境に対応したデプロイを簡単に作成できます。
考慮事項
デプロイ戦略を選択するときは、帯域幅、クォーラム設定、および自動シード処理を考慮する必要があります。
帯域幅
帯域幅は、マルチリージョンのデプロイにおける重要な考慮事項です。たとえば、米国東部 (バージニア北部) と米国西部 (オレゴン) に分散型可用性グループを使用してマルチリージョン SQL Server デプロイを設定したと想定します。これら 2 つのリージョンのネットワークレイテンシーは 75〜80 ミリ秒の範囲です。ワークロードが高 OLTP システムである場合は、ストレスとパフォーマンスのベンチマークテストを実行して、他のリージョンのセカンダリレプリカが大きな遅れなく同期されていることを確認する必要があります。セカンダリレプリカを同期するための大幅な遅延は、目標復旧時点 (RPO) の SLA に悪影響を及ぼします。
クォーラム設定
分散型可用性グループでは、2 つの異なる WSFC があるため、クォーラム設定を個別に扱います。ノード数に基づいてクォーラム投票を設定する必要があります。ファイル共有監視は推奨される監視タイプであり、ファイル共有監視の要件を満たすために、フルマネージド型サービスの Amazon FSx for Windows ファイルサーバーを使用できます。
Amazon FSx を使用して、Always On フェイルオーバークラスターインスタンス (FCI) を設計することもできます。詳細については、Amazon FSx for Windows ファイルサーバーを使用して、Microsoft SQL Server の高可用性デプロイメントを簡素化するを参照してください。
自動シード処理
SQL Server 2016 では、可用性グループの自動シード処理が採用されました。自動シード処理を使用して可用性グループを作成すると、SQL Server はグループ内のすべてのデータベースのセカンダリレプリカを自動的に作成します。セカンダリレプリカを手動でバックアップおよび復元する必要がなくなりました。この機能は、比較的小さなデータベースセットを扱う場合に便利です。大規模なデータベースを使用する場合、自動シード処理は推奨されません。自動シードの詳細については、Microsoft ドキュメントウェブサイトの自動シード処理を使用して、Always On 可用性グループを初期化するを参照してください。
まとめ
キーとなるのは、ミッションクリティカルな SQL Server デプロイのマルチリージョン戦略です。この投稿では、分散型可用性グループを使用して、これを最適に達成するための方法に焦点を当てました。また、分散型可用性グループを使用することによる読み取りスケールアウトなどの他の利点についても学びました。
SQL Server のデプロイの最適化に関する今後の投稿をお楽しみに。
著者について
Anup Sivadas は、アマゾン ウェブ サービスのソリューションアーキテクトです。AWS を使用する際にソリューションの価値を向上させるために、お客様と協力して AWS のサービスに関するアーキテクチャガイダンスと技術支援を提供しています。