ご注意

本ドキュメントは 2019/12 時点の状況での検証結果をまとめています。
コメントに頂きましたが 2020/9 に CloudSQL がレプリ元をFQDNで指定可能となった (ref) ようで、Aurora -> CloudSQL へ MySQL レプリケーションができるようになった可能性がありますのでご注意ください。

はじめに

ZOZOテクノロジーズでSREチームに所属している@hkameです
普段はZOZOTOWNのオンプレ基盤を運用しております

ZOZOTOWNはレガシーなシステムから徐々にパブリッククラウドへのリプレイスを実施していまして
そのプロジェクトに関わりながら、日々クラウドやk8s・CICDのスキルを吸収している人です

マルチクラウドでサービスを構築するための検証として
Aurora->CloudSQLの2サービスのみで、MySQLのレプリケーションができるか
を試したのでそちらを記事にします

レプリ要件

Aurora


https://aws.amazon.com/jp/rds/aurora/
AWSのフルマネージド型RDSで、saasと言われるサービスです
DBエンジンはMySQL, PostgreSQLが選択できます

外部へレプリするためには下記が求められます
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html

• レプリ先のMySQLバージョン5.5以降
• InnoDBストレージエンジンを使用しているテーブルであること

CloudSQL

https://cloud.google.com/sql/?hl=ja
GCP版のフルマネージド型RDS saasです
DBエンジンはMySQL, PostgreSQL、さらにSQLServerが選択できます

外部からレプリを受けるためには、レプリ元データベースサーバに下記が求められます
https://cloud.google.com/sql/docs/mysql/replication/replication-from-external?hl=ja#server-requirements
ポイントは下記になります

• バイナリログが行ベースのロギングであること
• GTID が有効にされていて、GTID 整合性が強制されること
• MySQL ユーザー アカウントに REPLICATION_SLAVE 権限が割り当てられていて、どこからの接続でも受け入れるように構成していること（ホスト = %）
• IPv4 アドレスと TCP ポートに外部からアクセスできること

こちらの要件からAuroraはGTIDを設定する必要があり、IPv4でアクセスできる必要が出てきます

※GTID（グローバルトランザクション識別子）
個々のトランザクションに対してつけられた世界でユニークなIDのこと
それがバイナリログに記載されることで、マスターポジションを指定しないレプリケーションができる
https://dev.mysql.com/doc/refman/5.6/ja/replication-gtids-concepts.html

Aurora->CloudSQLへレプリしてみる

イメージ図

このようなものを作りました
Auroraはマルチリージョンで作成し、書き込みインスタンスからCloudSQLへレプリ
レプリカはマルチゾーンで複数作成

手順

前提

• 検証できるAWS・GCP環境、アカウント、権限
• AuroraのMySQLエンジンクラスタが作成されている
  CloudSQLへインターネット越しにレプリするのでパブリックアクセス許可
• 検証用のデータベース・テーブルが作成されている
• 下記ができる作業用の環境
  • mysqlコマンドで作成したAuroraクラスタの書き込みエンドポイントに接続
  • gcloud、gsutilコマンドでGCPへ接続

Auroraの準備

クラスタのパラメータグループを変更

パラメータグループでクラスタのMySQLパラメータを変更できます
下記を変更します

• binlog_formatをROWに設定
  Aurora内のクラスタはバイナリログでなく、同一ストレージを参照することでレプリが実現されます
  それもありバイナリログはデフォルト無効なので、ROWに設定し行ベースでのbinlogを有効にします
  
• gtid-modeをONに設定
  GTIDはデフォルトOFFなので、ONに設定することで有効になります
• enforce_gtid_consistencyをONに設定
  GTID整合性を強制します

変更後、クラスタの再起動をします

バイナリログの保持期間を設定する

バイナリログの保持期間を1週間に設定します
短いと、レプリ設定が完了する前にバイナリログが削除されてしまう可能性があるためです
Auroraの書き込みエンドポイントに、rootユーザでMySQLログインし下記を実行します

変更
CALL mysql.rds_set_configuration('binlog retention hours', 168);

確認
CALL mysql.rds_show_configuration;

レプリ用ユーザを作成する

作成
CREATE USER '[レプリ用ユーザ名]'@'%' IDENTIFIED BY '[パスワード]';
GRANT REPLICATION SLAVE ON *.* TO  '[レプリ用ユーザ名]'@'%';

確認
SHOW GRANTS FOR '[レプリ用ユーザ名]'@'%';

CloudSQLの準備

CloudStorageでバケット作成

CloudSQLレプリカはAuroraのmysqldumpデータをインポートします
その際、GCPのクラウドストレージであるCloudStorageにデータを設置しておく必要があるため
バケットを作成しておきます

レプリケーション設定

AuroraのMySQLdumpを取得

mysqldump -u admin -p -h [Aurora書き込みエンドポイント] -P3306 \
--databases [データベース] \
--single-transaction \
--order-by-primary | gzip > dump.sql.gz

GTIDを利用した環境ではデータベースを指定した部分dump時に下記の警告がでます
データ自体は取得できていて、今回の検証では無視して進めてOKです

Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.

CloudStorageにdumpを設置

gsutil cp dump.sql.gz gs://[バケット名]/.

CloudSQLのレプリカを作成

GCPのコンソール画面のMIGRATE DATA 機能で
Auroraの書き込みエンドポイントをソースにレプリカを作成します

ここでひと工夫必要になりました
CloudSQLの外部からレプリケーションを受けるための、レプリ元サーバの要件

• IPv4 アドレスと TCP ポートに外部からアクセスできること

レプリ元をIPv4でしか指定できなかったのです！

AuroraはIPv4のエンドポイントを提供していません
仕方ないので、暫定的に書き込みエンドポイントをAWS外部から名前解決した際に確認できる
Auroraインスタンスの実態であるEC2インスタンスのIPv4アドレスを使用します
確認方法は下記になります

dig [書き込みエンドポイント] +noall +answer

結果例
[書き込みエンドポイント] 5   IN CNAME [書き込みインスタンスのエンドポイント]
[書き込みインスタンスのエンドポイント] 5 IN CNAME [EC2インスタンスのエンドポイント]
[EC2インスタンスのエンドポイント] 86400   IN A xx.xx.xx.xx

AuroraでCloudSQLレプリカからの通信許可

レプリカを作成すると、送信IPアドレスが払い出されます
Auroraのセキュリティグループのインバウンドルールで
送信IPアドレスからの3306通信を許可します

レプリ完了をまつ

レプリカのステータスアイコンがロード中から
緑のチェックに変わるとレプリ完了です

SHOW SLAVE STATUS¥Gで確認すると
このような状態でレプリケーションがされていました

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

slaveIO、SQLどちらも正常

Seconds_Behind_Master: 0

スナップショットから最新バイナリログまで追いついている

Replicate_Wild_Ignore_Table: mysql.%

mysqlデータベース以外がレプリケーション対象

また、レプリカインスタンスはread_onlyがONでした

複数のレプリカを作成する

1つ目はコンソール画面から作成する必要があるのですが
2つ目以降はgcloudコマンドでのみ作成ができます

gcloud beta sql instances create [レプリカインスタンス名] \
--master-instance-name=[外部プライマリインスタンス名] \
--master-username=[レプリユーザ名] --prompt-for-master-password \
--master-dump-file-path=gs://[バケット名]/[dumpファイル名] \
--tier=[インスタンススペック/例:db-n1-highmem-2] --storage-size=[DISKサイズ/例:10G]

同様に、AuroraでCloudSQLレプリカからの通信許可をしレプリ完了を待ちます

完了

以上でAurora->CloudSQLへレプリケーションができました

検証は成功なの？

レプリケーションをすることはできましたが
今回の構成ではAuroraの書き込みインスタンスがフェイルオーバーなどで変更した場合
レプリケーションが止まってしまうため、失敗です

レプリ元をIPv4で指定せざるを得ないため
フェイルオーバーでレプリ元が降格したレプリカを指定する状態になってしまい

Slave_IO_Running: No
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Binary log is not open'

とレプリが止まってしまいました

各クラウドのエンジニアにも確認しましたが

• AuroraがIPv4のエンドポイントを提供
• CloudSQLがレプリ元をFQDNで指定可能

現在はどちらもサービス提供はしていないとのことで
どちらかが可能になれば2サービスのみで
Aurora->CloudSQLができるのではないかと思っております！

最後に

まだまだ知識不足で、文言など間違いあったらすいません
マルチクラウドでシステム構築したい！
という方がどのくらいいるのか疑問ではありますが、少しでも興味を持って頂けたら幸いです