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

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

::: note info
AWSのAuroraにもGlobal Databaseという類似の仕組みがあります。
:::
https://dev.classmethod.jp/articles/amazon-aurora-global-database-failover-between-region/


# 2. 仕組み
- GDNは一つのprimary clusterと複数(最大4つまで)のsecondary clusterから構成されている。
::: note info
- 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へと同期されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/f677e5df-8a6b-2b46-3323-c72988986bec.png)
- 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秒の接続断が発生する可能性があるため、アプリケーションに再接続メカニズムがあることを確認し、アクセスの少ない時間帯に切り替えを行うことを推奨します。
    :::
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/1891a138-4518-c137-2f98-5b6bd01d8b68.png)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/39e275a1-28b1-4ff6-b1d7-7c97db68daea.png)



# 4. 検証手順
1. primary clusterの作成(通常通りにやればいいので、詳細な手順は[こちら](https://qiita.com/dennis_wang/items/6cbd443044ae71b8e5c3#polardb%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%AE%E4%BD%9C%E6%88%90)をご参考ください。)

1. GDNの作成
以下のようにGDNの`Name`、`Primary Region`と上記で作られた`Primary Cluster`を指定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/96a72504-486b-60c0-a737-c791f797c3a9.png)

1. secondary clusterを追加
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/d879ebaa-79b5-10bc-c221-3403d9fee122.png)
    - `Region`: primary regionと別のregionを選択、今回はシンガポールを利用
    - GDN: 上記作られたGDNのIDを選択
    - Compatibility: 基本的にprimary clusterのmysqlバージョンと一致させる必要があります
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/a40bfcf8-2a91-4194-103a-9dc8a358cbc2.png)
:::note warn
現在、各国では国境を越えたデータ転送に対する規制が厳しくなっています。そのため、現在のデフォルトでは、GDNのsecondary clusterはprimary clusterと同じリージョン内にしか配置できません。リージョンを越えてGDNを利用する場合は、サポートチケットにて依頼してください。
:::

1. 出来上がった内容を確認
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/2dcfa166-b44e-3c8b-aa27-7d445ca42fdd.png)
GDNのtopology図も確認できず、一目瞭然で、とてもわかりやすいですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/5258c018-6bf8-941f-2204-8bcf3ce9b986.png)
1. GDNへの接続
    - GDNは統一された接続endpointを持たないため、各クラスターは独自の接続エンドポイントを有しています。そのため、各クラスターにアクセスする際には、それぞれのエンドポイントを利用してください
    - 各クラスターの詳細画面にも接続endpoint確認できますが、GDNの画面にも接続endpoint確認可能
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/a4347126-16ad-c9fc-dfcb-ad7ef998290a.png)

1. primary cluster上でdatabase,tableを新規作成
    ```
    mysql> create database test;
    mysql> use test;
    mysql> create table user (id int, name varchar(10));
    ```
1. secondary cluster上で上記のdatabaseとtableが自動的に作られたこと(つまり同期さていたこと)を確認(レイテンシーは1秒以内)
    ```
    mysql> show databases;
    +--------------------+
    | Database           |
    +--------------------+
    | __recycle_bin__    |
    | information_schema |
    | mysql              |
    | performance_schema |
    | sys                |
    | test               |
    +--------------------+
    ```
1. primary cluster上新規レコードを作成
    ```
    mysql> insert into user values (1, 'dennis');
    ```

1. secondary cluster上で上記のレコードが自動的に同期されていることを確認
    ```
    mysql> select * from user;
    +------+--------+
    | id   | name   |
    +------+--------+
    |    1 | dennis |
    +------+--------+
    ```

# 5. region間の同期レイテンシーについて
以下は北京からアメリカ西regionへの同期レイテンシーをテストした結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/7b4e341a-fc04-df94-324e-9036936778c7.png)

https://www.alibabacloud.com/help/en/polardb/polardb-for-mysql/latest/technical-architecture#section-m5r-r39-hav

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

https://www.alibabacloud.com/help/en/polardb/polardb-for-mysql/billable-items#concept-zbj-4pg-tdb

# 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の間でのデータ転送には料金がかかりますか。
いえ、無料です。