【マルチクラウド】AWS⇔Azureでデータベース連携して実現する超高可用性【Azure × AWS】

最近、個人経営の美味しい定食屋さんを見つけることにハマっているoyuchanです！

さて、今回はよく巷で耳にする「マルチクラウド」をテーマとして書いていこうと思います。

マルチクラウドのメリットは、DWS二人目の大島さんの記事から引用しますと、以下のようなことが挙げられます。

マルチクラウドを選択する理由としては、ベンダーロックインを回避する目的や、ミッションクリティカルな環境において高可用性を求めるため、クラウド独自の強みとなるサービスを活用するためなど、さまざまな理由があります。

今回は上述のマルチクラウドのメリットを活かして、
1つのクラウドに依存せず、リスク分散が可能なAWS ・Azure間 での「データベースの連携」を実現します！

クラウド間のデータベース連携のメリット

複数のクラウドベンダー間でデータベースを連携することで、広域災害によるクラウドベンダーの障害によるサービス停止のリスクを下げ、高い可用性や耐障害性を実現できます！

絶対に落としたくないサービスに向いていますね。

また、データベースが必要となるような各クラウドのサービスを選択することが可能になるため、ビジネスに合わせた最適なサービス選択の範囲が広がります。

全体像

具体的には、「Azure SQL Managed Instance」で運用しているデータベースを、「AWS Database Migration Service」（以降、DMS）を使用して、「Amazon Aurora MySQL」に移行し、さらに常にデータベースの内容を同期する継続的レプリケーションを行います。

継続的レプリケーションを行うことで、クラウド間で冗長化され、高可用性が実現できます。

AWS Database Migration Serviceとは

DMSは、データベースの移行・レプリケーションを行うマネージドサービスです。

AWS内のデータベースは勿論、他クラウドサービスやオンプレミスのデータベースと組み合わせ可能です。

また、DMS Schema Conversion というスキーマ変換機能が組み込まれているので、OracleからPostgreSQLなど異なるデータベース間でもDMSを使用する事が出来ます。

DMSで対象となっているAzureのデータベースサービスはこちらをご確認ください。
Microsoft SQL Server データベースの AWS DMS のソースとしての使用

継続的レプリケーションが可能なのは、Azure SQL Managed Instanceのみなので、今回はこちらを使用します。（2023年5月現在）

Amazon Aurora MySQLを準備

まずは接続先となるAurora MySQLを作成します。

DMSからアクセスできる場所にあれば、その他の設定はお好みで大丈夫です。

作成が完了すると、データベースも同時に作成されます。

Azure SQL Managed Instanceの準備

※作成完了までに数時間かかる可能性があります。

次は接続元となるAzure SQL Managed Instanceを作成します。

SQL認証を使用し、ユーザー・パスワードを設定します。

DMSのエンドポイントとして接続するために、インターネット接続を有効にします。

※今回は検証のため直接アクセス出来るようにしていますが、DMSのIPアドレスからのアクセス許可したVnet経由でSQL Managed Instanceに接続する方法をおすすめします。

起動後、ポータル上からデータベースを作成します。

AWS Database Migration Serviceの作成

次にDMSの作成を行います。

DMSでは以下の4つを作成します。

DMSの全体像としては図のように、予め決められた「タスク」の内容を元に、「レプリケーションインスタンス」で「データベースのエンドポイント」に接続し、移行・継続レプリケーションを行います。

まずはレプリケーションインスタンス・それぞれのエンドポイント・タスクを設定していきます。

レプリケーションインスタンスの構築

Azureと連携をするため、パブリックアクセス可能な設定にします。

エンドポイントの設定

SourceエンドポイントとTargetエンドポイントをそれぞれ設定していきます。

Sourceエンドポイント設定

Azure SQL Managed Instanceは TCP/1433 のポートでアクセスできます。

接続テストをして「successful」となれば成功です！

Targetエンドポイント設定

データベースへの書き込みを行えるよう、Aurora MySQLのライターインスタンスのエンドポイントを使用します。

※Auroraはクラスタで構成されており、それぞれ読み書き可能なライターインスタンスと、読み込み可能なリーダインスタンスが存在します。

こちらも、接続テストをして「successful」となれば成功です！

タスクを作成

移行タイプは、「既存のデータを移行して、継続的な変更をレプリケートする」を選択します。

これで、DMSの準備は完了です！

移行するデータの準備

Azure SQL Managed Instanceで移行用のデータを用意します。

今回は、SQL Server Management Studioを使用しました。
Azure Data Studio のダウンロードとインストール

簡単に、IDとフルーツの名前をテーブルにいれました。

データベース移行を実行

タスクを実行します。

ステータスがロード完了となれば成功です！

データも少なかったので、5分以内に実行完了しました。

そして、Auroraを確認したところ無事移行できていました！！

継続レプリケーションを確認

Azure SQL Managed Instanceで、「もも」を追加しました。

5分後にAuroraを確認したところ、データが同期されていました！

ちなみに、レプリケーションを行う間隔はデフォルトでは5秒です。

対象のデータベースは限られる可能性がありますがSourceエンドポイントで設定が可能です。
ソースとして SQL Server を使用する場合のエンドポイントの設定AWS DMS

これでクラウド間のデータベース移行・継続レプリケーションが実現しました！

【余談】Azure ArcでAWSのデータベースを管理

AWSとAzureのデータベースを同期している状態で、2つのデータベースを管理するには、各クラウドのコンソールを行き来する必要があり、非常に手間です。

そこで、「Azure Arc」というサービスを使用すれば、Azure ポータル上からマシンに対して、さまざまなオペレーションを実行することが可能です。

DWS二人目の大島さんの記事で、実際にEC2の管理を行っています！

※Azure ArcにAWSのデータベースを登録する場合、SQLサーバーのみが対象になります（2023年5月現在）

まとめ

AzureとAWSのデータベース移行・継続的レプリケーションのご紹介でした。

リアルタイムに近い形でデータが同期されるので、クラウド間の冗長化による高い可用性が確保されます。

そのため冒頭でもお伝えした通り、クラウドの障害による長時間のサービス停止を予防したり、各クラウドの強みを生かした柔軟な設計が可能となります！

もしマルチクラウドの使い方にお困りであれば、お気軽に当社へのご相談もお待ちしております。

お気軽にお問い合わせください。

お問い合わせ - クラウド・AWSのデロイト トーマツ ウェブサービス株式会社

oyuchan