翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

HA/DR のオプションと考慮事項

AWS アベイラビリティーゾーンまたはリージョンが完全にオフラインになる可能性は非常にまれですが、冗長性を確保し、データ損失を最小限に抑えるため、災害発生時のバックアップとリカバリには多方面からのアプローチを推奨します。バックアップとリカバリのプロセスには、ワークロードの目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たし、ビジネスプロセスをサポートするための適切なレベルの粒度を含める必要があり、多くの場合、これはアプリケーションによって決まります。データベースの場合、AWS は、高可用性とディザスタリカバリ (HA/DR) のための SQL Server のセットアップと構成に関する Microsoft のすべての推奨事項をサポートします。SQL Server のエディションによってさまざまな HA/DR オプションがサポートされているため、超大規模データベース (VLDB) などの特殊なケースはケースバイケースで検討する必要があります。どの DR 構成でもそうですが、各アプリケーションが HA/DR のサービスレベルアグリーメント (SLA) を満たしていることを確認するにはテストが不可欠です。テスト/開発環境では、無料ですが制限付きのSQL Server Developer エディションの使用を検討してください。

15 分の RPO と 4 時間の RTO を必要とするユースケースでは、次の HA/DR オプションの組み合わせを検討できます:

AWS Backup での HA/DR リソースの管理

AWS Backup は、バックアップ計画とスケジュールを作成し、HA/DR 構成に関連する AWS リソース (スナップショットを作成するための Amazon EBS ボリュームや Amazon EC2 AMI など) をこれらのバックアップ計画に割り当てる機能を提供する完全マネージド型サービスです。AWS Backup を使用して、これらの EBS スナップショットのマルチリージョンコピーをスケジュールすることもできます。最適に使用するには、AWS Backup においてリソースを効率的にタグ付けするメカニズムが必要です。AWS Backup はまた、SQL Server で使用できる Windows ボリュームシャドウコピーサービス (VSS) によるアプリケーション整合バックアップもサポートします。ストレージレベルの保護には、EBS スナップショットの使用を推奨します。最初の EBS スナップショットはフルで、それ以降のスナップショットはインクリメンタルになります。EBS スナップショットはストレージレベルの保護を提供しますが、ポイントインタイムリカバリを提供する SQL Server のファイルベースのネイティブバックアップに代わるものではありません。

HA/DR に AWS DMS を使用する

SQL Server Always On オプションに代わるレプリケーションオプションを探している場合や、ハイブリッドセットアップまたは AWS で異種ソースとターゲットデータベースを使用している場合は、以下の方法で AWS Database Migration Service (AWS DMS) を使用することができます。

セルフマネージドコンテキスト (Amazon EC2 またはオンプレミスでホストされているもの) の SQL Server で AWS DMS を使用する場合、MS-REPLICATION (プライマリキーを持つテーブルの変更を取り込む) と MS-CDC (プライマリキーを持たないテーブルの変更を取り込む) の2つのモードで、1 回限りのレプリケーションと継続的なレプリケーションをサポートします。ただし、Amazon Relational Database Service (Amazon RDS) を AWS DMS のソースとして使用する場合は、MS-CDC のみがサポートされます。AWS DMS は、さまざまなソースエンドポイントとターゲットエンドポイントを提供し、異種データベースエンジンをサポートし、レプリケーションプロセスをきめ細かく制御できます。AWS Schema Conversion Tool (AWS SCT) を AWS DMS と組み合わせて使用し、異種データベース移行を行うこともできます。AWS SCT はスキーマレベルの変更を自動化し、移行の準備と計画のためのレポートも作成します。

以下の図に示すように、AWS DMS でソースデータベースとターゲットデータベースをエンドポイントとして追加します。このサービスは、MS-REPLICATION または MS-CDC のいずれかを使用して論理的なレプリケーションプロセスを実装します。ハイブリッドセットアップの場合、オンプレミスと AWS 間の継続的なレプリケーションのために AWS DMS を設定することができます。カットオーバー中は、AWS DMS 移行タスクを停止して、アプリケーションはオンプレミスデータベースと既に同期しているデータベースに遅滞なく接続できます。AWS DMS for SQL Server をソースとして使用することには、AWS DMS ドキュメントで説明されているいくつかの制限があります。

以下のシナリオでは、ネイティブ HA/DR メソッドの代わりに AWS DMS を使用することを検討します:

次の図は、AWS DMS がどのようにレプリケーションサポートを提供するかについての代替アプローチを示しています。この構成では、ソースは SQL Server Always On アベイラビリティーグループクラスターで、AWS DMS は変更データキャプチャ (CDC) オプションを使用して、データを別の AWS リージョンのターゲットに継続的に複製します。最適なパフォーマンスを得るには、レプリケーションインスタンスが適切なサイズで、ソースリージョン内にとどまるようにすることが重要です。

ソースエンジンとターゲットエンジンは一致していなくてもかまいません。この図では、(1) とマークされているプライマリノードとセカンダリノードは、シングル AZ 構成またはマルチ AZ 構成の SQL Server クラスターでもかまいません。または、ソースを MS-CDC または MS-REPLICATION をサポートする単一の SQL Server ノードにすることもできます。

図で (2) とマークされているターゲット DB インスタンスは、Amazon RDS、Amazon EC2、またはその他の異種ターゲット上の SQL Server のどのバージョンでもかまいません。プライマリインスタンスとセカンダリインスタンスが一致していなくても、Always On アベイラビリティーグループをサポートしていなくてもかまいません。たとえば、ソースは SQL Server Always On アベイラビリティーグループクラスターで、ターゲットは Amazon Aurora PostgreSQL 互換エディションであってもかまいません。

DRに AWS Application Migration Service を使用する

AWS へのリフトアンドシフト移行には、AWS Application Migration Service を使用することをおすすめします。Application Migration Service は、マシン (オペレーティングシステム、システム状態設定、データベース、アプリケーション、ファイルを含む) をターゲット AWS アカウントと優先リージョンの低コストのステージングエリアに継続的に複製します。障害が発生した場合、Application Migration Service を使用すると、数千台のマシンを数分で完全にプロビジョニングされた状態で自動的に起動できます。

その他の考慮事項

以下のリストは、HA/DR 戦略を設計する際に考慮すべき、考えられるボトルネックを示しています。