【マルチクラウド】AWS⇔Azureでデータベース連携して実現する超高可用性【Azure × AWS】
![](https://blog.mmmcorp.co.jp/images/2023/05/GettyImages-1167011805_lo.png)
最近、個人経営の美味しい定食屋さんを見つけることにハマっているoyuchanです!
さて、今回はよく巷で耳にする「マルチクラウド」をテーマとして書いていこうと思います。
マルチクラウドのメリットは、DWS二人目の大島さんの記事から引用しますと、以下のようなことが挙げられます。
マルチクラウドを選択する理由としては、ベンダーロックインを回避する目的や、ミッションクリティカルな環境において高可用性を求めるため、クラウド独自の強みとなるサービスを活用するためなど、さまざまな理由があります。
今回は上述のマルチクラウドのメリットを活かして、
1つのクラウドに依存せず、リスク分散が可能なAWS ・Azure間 での「データベースの連携」を実現します!
クラウド間のデータベース連携のメリット
複数のクラウドベンダー間でデータベースを連携することで、広域災害によるクラウドベンダーの障害によるサービス停止のリスクを下げ、高い可用性や耐障害性を実現できます!
絶対に落としたくないサービスに向いていますね。
また、データベースが必要となるような各クラウドのサービスを選択することが可能になるため、ビジネスに合わせた最適なサービス選択の範囲が広がります。
全体像
具体的には、「Azure SQL Managed Instance」で運用しているデータベースを、「AWS Database Migration Service」(以降、DMS)を使用して、「Amazon Aurora MySQL」に移行し、さらに常にデータベースの内容を同期する継続的レプリケーションを行います。
継続的レプリケーションを行うことで、クラウド間で冗長化され、高可用性が実現できます。
![Group 1.png (47.5 kB)](https://img.esa.io/uploads/production/attachments/1854/2023/05/13/130053/409f34fc-eedf-4198-af3b-ae9980837a13.png)
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を作成します。
![スクリーンショット 2023-05-03 10.58.13.png (150.5 kB)](https://img.esa.io/uploads/production/attachments/1854/2023/05/13/130053/b0984c50-28dd-47ca-9f53-33152342b8d7.png)
DMSからアクセスできる場所にあれば、その他の設定はお好みで大丈夫です。
作成が完了すると、データベースも同時に作成されます。
Azure SQL Managed Instanceの準備
※作成完了までに数時間かかる可能性があります。
次は接続元となるAzure SQL Managed Instanceを作成します。
SQL認証を使用し、ユーザー・パスワードを設定します。
![](https://blog.mmmcorp.co.jp/images/2023/05/image-4-1024x511.png)
DMSのエンドポイントとして接続するために、インターネット接続を有効にします。
![](https://blog.mmmcorp.co.jp/images/2023/05/image-5-1024x286.png)
※今回は検証のため直接アクセス出来るようにしていますが、DMSのIPアドレスからのアクセス許可したVnet経由でSQL Managed Instanceに接続する方法をおすすめします。
起動後、ポータル上からデータベースを作成します。
AWS Database Migration Serviceの作成
次にDMSの作成を行います。
DMSでは以下の4つを作成します。
- Sourceエンドポイント:接続元のデータベース情報
- Targetエンドポイント:接続先のデータベース情報
- タスク:処理内容を設定するもの
- レプリケーションインスタンス:タスクを元にSource・Targetエンドポイントに接続し、移行・継続レプリケーションの処理を行うインスタンス
DMSの全体像としては図のように、予め決められた「タスク」の内容を元に、「レプリケーションインスタンス」で「データベースのエンドポイント」に接続し、移行・継続レプリケーションを行います。
![Group 6.png (76.0 kB)](https://img.esa.io/uploads/production/attachments/1854/2023/05/13/130053/2cec5b19-0b40-4563-9f54-5f7678a532cc.png)
まずはレプリケーションインスタンス・それぞれのエンドポイント・タスクを設定していきます。
レプリケーションインスタンスの構築
Azureと連携をするため、パブリックアクセス可能な設定にします。
![スクリーンショット 2023-05-03 9.30.54.png (293.8 kB)](https://img.esa.io/uploads/production/attachments/1854/2023/05/13/130053/0cc0ac30-b360-4984-9680-3582014401d4.png)
エンドポイントの設定
SourceエンドポイントとTargetエンドポイントをそれぞれ設定していきます。
Sourceエンドポイント設定
Azure SQL Managed Instanceは TCP/1433 のポートでアクセスできます。
![](https://blog.mmmcorp.co.jp/images/2023/05/image-6-895x1024.png)
![スクリーンショット 2023-05-03 11.48.40.png (110.8 kB)](https://img.esa.io/uploads/production/attachments/1854/2023/05/03/130053/ab15353a-66e7-4531-bfb3-113cf097ebc4.png)
Targetエンドポイント設定
データベースへの書き込みを行えるよう、Aurora MySQLのライターインスタンスのエンドポイントを使用します。
※Auroraはクラスタで構成されており、それぞれ読み書き可能なライターインスタンスと、読み込み可能なリーダインスタンスが存在します。
![スクリーンショット 2023-05-03 12.17.58.png (286.2 kB)](https://img.esa.io/uploads/production/attachments/1854/2023/05/03/130053/57e67d58-9531-4125-a6b4-6ab2ec3d40b0.png)
こちらも、接続テストをして「successful」となれば成功です!
タスクを作成
移行タイプは、「既存のデータを移行して、継続的な変更をレプリケートする」を選択します。
![](https://blog.mmmcorp.co.jp/images/2023/05/image-7-1024x954.png)
移行するデータの準備
Azure SQL Managed Instanceで移行用のデータを用意します。
今回は、SQL Server Management Studioを使用しました。
Azure Data Studio のダウンロードとインストール
簡単に、IDとフルーツの名前をテーブルにいれました。
![](https://blog.mmmcorp.co.jp/images/2023/05/image-8.png)
データベース移行を実行
タスクを実行します。
![](https://blog.mmmcorp.co.jp/images/2023/05/image-9-1024x171.png)
ステータスがロード完了となれば成功です!
![](https://blog.mmmcorp.co.jp/images/2023/05/image-10.png)
データも少なかったので、5分以内に実行完了しました。
そして、Auroraを確認したところ無事移行できていました!!
![スクリーンショット 2023-05-07 15.02.44.png (27.4 kB)](https://img.esa.io/uploads/production/attachments/1854/2023/05/13/130053/f9d350de-acdd-4d47-afec-cf5fe5f42321.png)
継続レプリケーションを確認
Azure SQL Managed Instanceで、「もも」を追加しました。
![](https://blog.mmmcorp.co.jp/images/2023/05/image-11.png)
5分後にAuroraを確認したところ、データが同期されていました!
![](https://blog.mmmcorp.co.jp/images/2023/05/image-12.png)
ちなみに、レプリケーションを行う間隔はデフォルトでは5秒です。
対象のデータベースは限られる可能性がありますがSourceエンドポイントで設定が可能です。
ソースとして SQL Server を使用する場合のエンドポイントの設定AWS DMS
![](https://blog.mmmcorp.co.jp/images/2023/05/image-13-1024x312.png)
これでクラウド間のデータベース移行・継続レプリケーションが実現しました!
【余談】Azure ArcでAWSのデータベースを管理
AWSとAzureのデータベースを同期している状態で、2つのデータベースを管理するには、各クラウドのコンソールを行き来する必要があり、非常に手間です。
そこで、「Azure Arc」というサービスを使用すれば、Azure ポータル上からマシンに対して、さまざまなオペレーションを実行することが可能です。
DWS二人目の大島さんの記事で、実際にEC2の管理を行っています!
※Azure ArcにAWSのデータベースを登録する場合、SQLサーバーのみが対象になります(2023年5月現在)
まとめ
AzureとAWSのデータベース移行・継続的レプリケーションのご紹介でした。
リアルタイムに近い形でデータが同期されるので、クラウド間の冗長化による高い可用性が確保されます。
そのため冒頭でもお伝えした通り、クラウドの障害による長時間のサービス停止を予防したり、各クラウドの強みを生かした柔軟な設計が可能となります!
もしマルチクラウドの使い方にお困りであれば、お気軽に当社へのご相談もお待ちしております。
お気軽にお問い合わせください。
お問い合わせ - クラウド・AWSのデロイト トーマツ ウェブサービス株式会社