Alibaba CloudのPolarDBの徹底分析(6)_GDN (Global Database Network)による複数のリージョンに跨るデータベースの構築

1. GDNとは

Global Database Network (略語GDN) は、世界中の複数リージョンにわたるPolarDBクラスターで構成されるデータベースネットワークです。これはグローバル分散アプリケーション向けに設計されており、PolarDBデータベースクラスターを複数リージョンに渡って運用することを可能にします。
データベースのパフォーマンスに影響を与えずにデータを別のregionにレプリケートし、region規模の停止からのディザスタリカバリを実現します。

AWSのAuroraにもGlobal Databaseという類似の仕組みがあります。

2. 仕組み

• GDNは一つのprimary clusterと複数(最大4つまで)のsecondary clusterから構成されている。

• 4つ以上が必要な場合はサポートチケットにて依頼できます。
• clusterごとにはデフォルトで２つのノードがあり、最大16個(一つのprimary node + 15個のread-only node)まで追加可能です。

• secondary clusterでは、読み取りリクエストは同一リージョン内のPolarDB clusterに向けられます。一方で、書き込みリクエスト（create, update, delete）はGDN内部のネットワークを通じて自動的にprimary clusterへと転送され、そこでデータが書き込まれます。このプロセスはアプリケーションにとって透明です。primary clusterのDBにデータが書き込まれると、その最新情報はGDN専用のネットワークを介してsecondary clusterへと同期されます。
  
• secondary clusterには、Primary Nodeと呼ばれる書き込み可能なノードがあります。しかし、このノードはユーザーからの直接的な書き込みリクエストを受け取るのではなく、primary clusterから同期されたデータをセカンダリクラスター内に書き込むために使われます。
• アプリケーションのコードを変更することなく、データベースを複数リージョンに迅速に展開することが可能です。
• リージョン間での低レイテンシーによるデータ同期を実現します。物理レプリケーションを複数のチャンネルを通じて実行することで、高負荷時でも全てのノードへ2秒以下でデータをレプリケート可能です（例: 東京リージョンから米国西リージョンへは1秒以内）。

3. 利用シーン

1. cross regionのDR (active-standby)

   • DRによるcross regionの高可用性で、データセキュリティとシステムの可用性を向上できる。
   • primary clusterとsecondary clusterの切り替えは10分以内に完了できる（テストは5分以内）。
   • 切り替え中に最大60秒の接続断が発生する可能性があるため、アプリケーションに再接続メカニズムがあることを確認し、アクセスの少ない時間帯に切り替えを行うことを推奨します。

   

2. cross regionのmulti-site (active-active)
   世界のユーザーに対応し、データは複数リージョンで読み書きされ、お互いに同期が必要です。読み込みリクエストは同一region中のデータベースクラスターに送られ、書き込みリクエストはプライマリクラスターに転送されます。

4. 検証手順

1. primary clusterの作成(通常通りにやればいいので、詳細な手順はこちらをご参考ください。)

2. GDNの作成
   以下のようにGDNのName、Primary Regionと上記で作られたPrimary Clusterを指定
   

3. secondary clusterを追加
   

   • Region: primary regionと別のregionを選択、今回はシンガポールを利用
   • GDN: 上記作られたGDNのIDを選択
   • Compatibility: 基本的にprimary clusterのmysqlバージョンと一致させる必要があります
     

現在、各国では国境を越えたデータ転送に対する規制が厳しくなっています。そのため、現在のデフォルトでは、GDNのsecondary clusterはprimary clusterと同じリージョン内にしか配置できません。リージョンを越えてGDNを利用する場合は、サポートチケットにて依頼してください。

1. 出来上がった内容を確認
   
   GDNのtopology図も確認できず、一目瞭然で、とてもわかりやすいですね。
   

2. GDNへの接続

   • GDNは統一された接続endpointを持たないため、各クラスターは独自の接続エンドポイントを有しています。そのため、各クラスターにアクセスする際には、それぞれのエンドポイントを利用してください
   • 各クラスターの詳細画面にも接続endpoint確認できますが、GDNの画面にも接続endpoint確認可能
     

3. primary cluster上でdatabase,tableを新規作成

   mysql> create database test;
   mysql> use test;
   mysql> create table user (id int, name varchar(10));
   

4. secondary cluster上で上記のdatabaseとtableが自動的に作られたこと(つまり同期さていたこと)を確認(レイテンシーは1秒以内)

   mysql> show databases;
   +--------------------+
   | Database           |
   +--------------------+
   | __recycle_bin__    |
   | information_schema |
   | mysql              |
   | performance_schema |
   | sys                |
   | test               |
   +--------------------+
   

5. primary cluster上新規レコードを作成

   mysql> insert into user values (1, 'dennis');
   

6. secondary cluster上で上記のレコードが自動的に同期されていることを確認

   mysql> select * from user;
   +------+--------+
   | id   | name   |
   +------+--------+
   |    1 | dennis |
   +------+--------+
   

5. region間の同期レイテンシーについて

以下は北京からアメリカ西regionへの同期レイテンシーをテストした結果です。

注意点：

1. レイテンシーはセカンダリクラスターのスペックと関連があります。今回の結果は、16コア/128GBメモリを有するクラスターに基づいています。レイテンシー敏感な利用シーンではプライマリクラスターとセカンダリクラスターのスペックを揃えることがお勧めです。
2. レイテンシーをそこまで重視しないがコスト削減を望む場合、セカンダリクラスターをプライマリクラスターよりも低スペックで設定する方法もあります。
   • セカンダリクラスターとプライマリクラスターはそもそも独立しているため、それぞれのスペックは自由に設定できます。
   • 最初はセカンダリクラスターを低めのスペックで設定し、プライマリクラスターに障害が発生した際、フェイルオーバー後に手動でセカンダリクラスターをスケールアップするという運用方法も可能です。
3. 物理的距離がそれほど影響しないため、日本とアメリカ、または日本とEU（ドイツ）間のレイテンシーも1秒以内であると見込んで良いでしょう。プライマリクラスターへの同時書き込み処理によってデータ転送が100M/S以上となるワークロードでは、レイテンシーを2秒以内に保証できます。
4. ミリ秒レベルで正確なレイテンシーを測定したい場合は、このページを参照してSysBenchスクリプトを用いたテストを行ってみてください。

6. 利用制限

• PolarDB MySQLしか利用できない
• 利用できるMySQLのバージョンリスト：
  • PolarDB MySQL 8.0
  • PolarDB MySQL 5.7
  • PolarDB MySQL 5.6
• primary clusterとsecondary clusterのMySQLのバージョンは一致する必要があります

7. 料金

primary cluster⇔ secodary clusterの間のデータ転送は無料であり、PolarDBクラスタの料金だけを払えばいいです。つまり追加されたsecondary clusterのインスタンスの料金とストレージの料金を支払うだけで、GDNを利用可能になります。

8. Q/A

1. secondary clusterのスペックはprimary clusterより低く設定することが可能ですか。
   primary clusterとsecondary clusterは2つの独立したclusterで、内部はGDNのネットワークで接続されています。そのため、２つのclusterのスペックが自由に設定でき、必ずしも一致する必要はありません。

2. primary clusterが障害発生し、failoverになる場合は、手動でsecondary clusterのスペックを上げることが可能ですか。
   primary clusterとsecondary clusterは2つの独立したclusterなので、手動で個別にスケールアップすることが可能です。

3. データベースには2TBのデータがあります。最小の4CPU 8GBのsecondary clusterは足りますか？
   データの総量が2TBあるとはいえ、毎日2TBのデータを転送するわけではありません。変更されたデータのみが毎日同期されます。もし変更量が特に大きく、頻繁であれば、最小スペックでは不足する可能性もあります。
   最初はこの最小スペックで試してみて、もしデータの変更量が特に大きく、頻繁であるためにデータ転送の遅延が長くなる場合は、スペックを上げることを検討しても可能です。

4. GDNは、単に2つのPolarDBを接続するだけで、元のVPCには影響しません。例えば東京とシンガポールのVPCはCENで接続する必要がなく、VPCのネットワークセグメントが重複していても問題ありませんか。
   その通りです。GDNはPolarDB内部のクロスリージョンネットワークを使用しており、２つのVPCをVPC peeringやCENなど方法で接続する必要はありません。VPCのセグメントが重複しても問題ありません。

5. primary regionに障害が発生し、secondary clusterが新primary clusterに昇格されました。障害が解消された後、新primary clusterに書き込まれたデータは元のprimary clusterに同期されますか。
   はい。元のprimary clusterはsecodary clusterになったため、新primary clusterに書き込まれたデータは元のprimary clusterに自動的に同期されます。

6. primary clusterとsecodary clusterの間でのデータ転送には料金がかかりますか。
   いえ、無料です。