※本稿は、米国サイオスの友人であるSteve Rezhener氏によるコラムを和訳したものです。
AWS RDSサービスの代わりに、複数のAWS EC2を使用してコストを抑えつつSQL Serverの高可用性、災害復旧を実現する方法をご紹介します。なぜAWS RDSをつかわないのか？その理由も合わせて解説してゆきます。
はじめに
AWSパブリッククラウドにSQL Serverの高可用性災害復旧（HADR）ソリューションを実装するには、複数の方法があります。一番簡単なのは、AWS RDSと呼ばれるAWS Database as a Service（DBaaS）製品を使用し、AWSコントロールパネルを用いてマルチAZオプションを有効にする方法です（図1参照）。
<図1>
これだけで展開や既存のインスタンスへの追加が完了し、あとはAWSが内部で残りの処理を行ってくれます（SQL Serverのバージョンによっては、ミラーリングやAlways On可用性グループを使用する場合もあります）。自動フェールオーバーに必要なすべてのもの（監視、ネットワーク、ストレージなど）をプロビジョニングし、プライマリーノードがダウンすると、セカンダリーノードに置き換えます。
このブログ記事では、マネージドAWS RDSサービスの代わりに、複数のAWS EC2を使用して独自のHADRソリューションを構築する方法について説明します。
この方法ではより多くの作業が必要となりますが、自分でコントロールしながら、費用を多少節約することができます。このオプションでは、AWS EC2を利用して独自のHADRソリューションを構築します。具体的には、複数のゾーン、複数の仮想サーバー（EC2）、SMBが必要で、すべてをインストールして設定する必要があります。
AWS RDSのデメリット
一番の疑問は、なぜわざわざやるのか、ということです。SQL Serverクラスターの構築は、誰にでもできることではありません。AWS RDSがすべてのプロビジョニングを行ってくれて、HADRの実装が数クリックで済むのであれば、なぜわざわざAWS EC2を使ってHADRを構築する必要があるのでしょうか？
ここでは、AWS RDSのデメリットをいくつかご紹介します。
コスト
- AWS RDSは一般に高価であり（図2）、「数クリックで済む」HADRソリューションでは、時間当たりのコストが高くなります。
<図2> – 2つのEC2 AMIクラスター構成の価格は、マルチAZを使用したRDS 1つの価格の2/3
- ライセンス – AWS RDSはBYOL（Bring Your Own License）をサポートしていないため、既存のライセンスを使用することができません。
機能
- サービスレベルアグリーメント（SLA）が最適とは言えない – AWS RDSのサービスレベルは99.95%。
- 目標復旧時間（RTO）が長い – AWS RDSがリカバリー/フェールオーバーするのにかかる時間は60〜90秒。
- 管理者による制御ができない – AWS RDSではHADRの実装やファイルシステムへのアクセスができません。
- 機能– AWS RDSは、SQL Serverスタンドアロンバージョンと100％の互換性がありません。たとえば、CLR関数を使用することができません。
- 実装 – AWS RDS for SQL Serverはミラーリング/可用性グループを同期モードで使用しており（SQL Serverのバージョンに依存）、可用性を犠牲にしてデータの一貫性を保証しています（プライマリーノードはセカンダリーノードに依存しています）。つまり、AWS RDSがセカンダリーノードに接続できない場合、プライマリーノードは失われます。
問題点
AWS RDS マルチAZは、SQL Serverの最適なソリューションではないようです。そして、より少ない費用でより多くのものを得ることができる、AWS EC2への置き換え方法を説明しましょう。ただし、独自のHADRソリューションを構築するには、導入作業が必要になります。
価格
まずは価格から見てみましょう。AWS EC2はAWS RDSよりも時間当たりの料金は安いですが（図2）、SQL Serverのライセンスについてはどうでしょうか？SQL Serverの中で最も廉価なバージョンは、Standard Edition（SE）です。Windows上のSEでは、フェールオーバークラスター（FCI）やAlways On可用性グループ、またはその両方を組み合わせてHADRを実現することができます。
SQL Server 2017以降、SEにはAlways Onの基本的な可用性グループ（Always On Basic Availability Group、AG）が搭載されていますが、その設定や利用は非常に面倒なので（1つのデータベースに1つのグループというのは管理しやすいとは言えません）、スケールアウトした読み取りが必要ないのであれば、FCIを構築してその日のうちに終了してしまいます。SEのFCIは2ノードが上限ですが、ノード数が少ないと必要な費用も少なくて済むといえます。
機能
次に、機能について説明しましょう。AWS EC2は事実上100%のサーバーでの管理制御が可能ですが、FCIを実装することで、SLA（99.99%）、SQL Serverとの100%の互換性、数秒のRTOを実現します。さらにFCIは、純粋な可用性ソリューション（セカンダリーノードの損失はプライマリーノードに影響を与えない）を実現します。
そしてFCIの要件である共有ストレージについてですが、ストレージはローカルでありながら、ノード間で共有する必要があります。独自のプライベートクラウド/データセンター/ガレージでは、ストレージソリューションはお金と時間にのみ制限されますが、パブリッククラウドでは、ストレージ構成オプションは限られています。新しいSSDブレードストレージ/SANの電源を以前のように簡単にオンにすることはできませんし、予算を抑えることもできません。ただし、必要なのはストレージレプリケーションソリューションのみで済みます。
ソリューション
以下のソリューションでは、AWSの「バブル」を離れずにBYOC SQL Serverを実装する方法をご紹介します。
オーバーヘッド用に最小限のEBSボリュームを備えた同じサイズのEC2サーバー2台、自動フェールオーバーをサポートするための安価な監視用EC2を1台、データ用にEBSボリュームを2つ用意し、ストレージレプリケーション（共有ストレージの提供用）にはSIOS DataKeeper Cluster Editionを使用し、FCIはWindows Server Failover Cluster（WSFC）をベースに構築します。
前提条件
- 2つのクラスターノード用に2つのEC2インスタンス（同じOSとインスタンスサイズ）を作成します。
- EC2を1つ作成します（安価なt1.microインスタンスで十分です）。
- EBSボリュームを作成して両方のノードにアタッチします。
- クラスターノードとして追加したい3台のサーバーすべてが同じActive Directoryドメインに参加しているようにします。 （オプション）組織単位（OU）を作成し、クラスターノードとして追加するサーバーのコンピューターアカウントをOUに移動します。ベストプラクティスとして、フェールオーバークラスターをAD DS内の独自のOUに配置することをお勧めします。これにより、どのグループポリシー設定やセキュリティテンプレート設定がクラスターノードに影響を与えるかをより適切にコントロールすることができます。また、クラスターを独自のOUに隔離することで、クラスターのコンピューターオブジェクトが誤って削除されるのを防ぐこともできます。
- クラスターの作成に使用するアカウントが、クラスターノードとして追加するすべてのサーバーの管理者権限を持つドメインユーザーであることを確認します。
- 以下のいずれかを実施します。 クラスター用のOUを別途作成します。Domain\Clusterアカウントに「フルコントロール」を付与し、クラスターオブジェクト（コンピューターアカウント、クラスターオブジェクト、Domain\Clusterユーザー）をこのOUに移動します。 Domain\Clusterにコンピューターオブジェクトの作成と、ドメインのコンピューターオブジェクトを含むデフォルトのコンテナに対するすべてのプロパティの読み取りアクセス権限を付与します。オブジェクトがクラスターOUに移動されたら、それらを削除します。詳細については、「Active Directory Domain Services でクラスター コンピューター アカウントを事前設定する」を参照してください。
- 3つのサーバーすべてを同じドメインに参加させます。
- Domain\Clusterをローカル管理者として両方のサーバーに追加します。
- EC2 node1およびnode2からSQL Server 2017 Standard Editionをアンインストールします。
- 両方のノードにホストファイルエントリを追加します。
- ADでのKerberos委任について、すべてのコンピューターとユーザーを信頼します。
- SPNを追加します。
ここからは、こちらの手順「 SQL Server Failover Cluster インスタンスを手動でデプロイする 」を参照して、以下を実行してください。
フェールオーバークラスタリング機能の追加 クラスター構成の検証 Windows Serverフェールオーバー クラスター（WSFC）の作成 Quorum/Witnessの設定 SIOS DataKeeperのインストールと設定 MSDTCの設定 最初のSQLインスタンスへのSQLのインストール
重要 – SQL Serverフェールオーバー クラスターをインストールする際には、Analysis Servicesを有効にしないでください（図3）。
<図3>
2番目のSQLインスタンスにSQLをインストール TTLを1分未満に調整
謝辞
このブログ記事で紹介したソリューションは、以下の方々の協力なしには実現できませんでした（アルファベット順、敬称略）。この場を借りてお礼申し上げます。
Allan Hirt、David Bermingham、Nick Rubtsov、Vadim Kulikov
参考：
Always On Failover Cluster Instances (SQL Server)
Error during installation of an SQL server Failover Cluster Instance
SQL Server Native Client Support for High Availability, Disaster Recovery
Prestage cluster computer objects in Active Directory Domain Services
Deploying DataKeeper Cluster Edition in AWS
Multi-AZ deployments for Amazon RDS for Microsoft SQL Server
お問い合わせ
AWSの冗長化構成をご検討の方は、お気軽にお問い合わせください。
もちろんSQL Server以外のDBやアプリケーションの保護も可能です。
