Auroraにはマルチマスターという複数のWriterインスタンスを実行することができる機能があります。
一般的にはシングルマスターでの運用が多いと思いますが、シングルマスターではWriterインスタンスが1台しかないため、このインスタンスに異常が発生すると異常を検知するまでの数分間+フェイルオーバーが行われるまで2分程度の書き込み機能への障害が発生してしまいます。
一方でマルチマスターを利用している場合にはWriterインスタンスを複数実行することになりますので、書き込み機能に対する冗長化が実現できますね。
今回は、既にシングルマスターで実行しているAuroraクラスターをマルチマスターに変更する方法があるのかの調査と、マルチマスターでのメリット、デメリットについて調査しました。
Auroraの仕組み
そもそもAuroraの仕組みってどうなんだっけ？
というところから振り返ってみようと思います。
EC2インスタンスの存在から、Auroraインスタンスごとに個別のボリュームストレージがマウントされていると思ってしまいがちですが、Auroraはこのような構成にはなっていません。
Auroraでは、インスタンス層とボリュームストレージ層が分かれています。
たとえばインスタンスが1台しか実行されていなくても、Auroraでは自動的に3つのAZに2つずつのボリュームを作成します。
これらのボリュームストレージは常に同期されており、インスタンスとボリュームは疎な関係なので、仮に全てのインスタンスが壊れてしまってもデータを守ることができるようになっています。
同様に、ボリュームストレージが破損してしまっても、６つ全てが機能を停止しなければデータを提供し続けることが可能です。
Writeインスタンスはボリューム層のストレージに対して読み書きを提供します。
Readerインスタンスはボリューム層からの読み取りのみを提供します。
ボリューム間のデータ同期は最適化されており非常に高速です。
リードレプリカへの書き込み
シングルマスター構成ではリードレプリカが提供されますが、Readerインスタンスは本当に書き込みができないのでしょうか。
検証のためにクラスターを1台作成して、Readerインスタンスのエンドポイントにアクセスしてみます。
試しにCREATE DATABASEを実行したところ、[the mysql server is running with the –read-only option so it cannot execute this statement]というエラーメッセージが表示されました。
innodb_read_onlyのパラメータを確認すると、ReadOnly設定が有効になっていることが確認できます。
すなわちReaderインスタンスに対しての書き込みは無効になっていることがわかりますね。
マルチマスターへの移行
マルチマスターでは複数のWriterインスタンスを実行することができます。
新規でAuroraクラスターを作成するときは、上記のようにオプションでシングルマスターにするかマルチマスターにするかを選択することができました。
では既にシングルマスターで実行しているクラスターをマルチマスターに変更したい場合にはどうしたら良いでしょうか？
シングルマスターで実行しているクラスターの変更オプションには、マルチへの切り替え項目がありませんでした。
そのため、スナップショットを作成してクラスターを作成し直してみることにします。
しかし、上図のように復元したクラスターではシングルマスターしか選択肢がありません。
その他にもReaderインスタンスのみ全て削除してから[変更]をしてみるなど試してみましたが、マルチマスターへ変更する手段はありませんでした。
どうやらマルチマスターのクラスターを利用したい場合は、新規作成の時点で選択していなければならないようです。
マルチマスターでの制約
後から変更が不可なのであれば、Writerが冗長化できるマルチマスターでクラスターを作った方が良いように思えます。
しかし実際にはさまざまな制約があり、基本的には使わない方が無難な機能という印象を受けました。
たとえば上記の画像から分かるように、サポートされているインスタンスタイプが少ないです。
今となっては2世代ほど古いr4系しか利用できません。
さらにDBのバージョンの低さも気になります。今回はMySQL互換で実行していますが、MySQL5.6しかマルチマスターに対応していませんでした。
ちなみにPostgreSQLは対象外です。
また、せっかく冗長化ができるのに最大で実行できるインスタンスは2台のみと非常に少ないです。
複数のWriterが存在するため、トランザクションにも気を配る必要があります。
ほぼ同時の書き込みでは重複クエリ扱いになってしまうこともあるようです。
結論・まとめ
・シングルマスター構成をマルチマスター構成に変更する方法はない(その逆も然り)
・マルチマスターでは以下のような制約があり、用途が限られる
- 実行可能なインスタンスは2台まで
- MySQL5.6しか対応していない
- 利用可能なインスタンスはr4系のみ
- 同時の書き込み処理が苦手
・公式ドキュメントにも多数の考慮事項が上がっている↓
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-multi-master.html
おわりに
数年前からリリースされていたのにあまり採用事例を聞かないマルチマスター設定ですが、移行難易度の高さ(新規作成してデータ移行しないとダメそう)と制約の多さから、汎用的な用途では採用が難しそうな印象を受けました。
そもそも現在のシングルマスター構成であっても、Writerインスタンスがダウンすれば自然とフェイルオーバーが実行されるためダウンタイムは短くて済みますし、負荷に応じてレプリカを追加していくことでパフォーマンスを改善することもできます。
マルチマスターのようなWriterインスタンスの冗長化は魅力的なので、将来的に制約や考慮事項が自動的に解決するような裏側の仕組みが導入されることに期待をしたいですね。
コメントを残す