AmazonAurora カスタムエンドポイントのフェールオーバー時の挙動についての検証

こんにちは。インフラエンジニアの永井(shnagai)です。

昨年11月にリリースされたAmazon Auroraのカスタムエンドポイントを運用していて、先日ある検証環境でフェールオーバーが起きた際に考慮していなかった事態が起きたので、仕様を確認するがてらカスタムエンドポイントのタイプ別にフェールオーバー時の挙動をまとめてみました。

カスタムエンドポイントについては下記をご参照ください。自由にAuroraインスタンスを組み合わせて、用途別にAuroraのエンドポイントを管理出来る機能で、これまで泣く泣く続けていたmysqlのbinlogレプリ運用から解放されるようなうれしさがあります。 docs.aws.amazon.com

起きた事象

Auroraクラスタにフェールオーバーが発生した際に、当然リードレプリカがマスター昇格します。その際に、カスタムエンドポイントのノードが0になりカスタムエンドポイントへのDB接続が不可となりました。

これは、下記環境の説明にあるようにREADER TYPEでカスタムエンドポイントを作成していたので、登録していたリーダーインスタンスがREADER TYPEの条件不一致になりメンバから外れたのが原因でした。リーダーエンドポイントだと、よくあるLBのSorry設定のように、ノードが0になればマスターが一時的にメンバに入りノード0を防ぐような挙動をしてくれますがカスタムエンドポイントではそのような挙動はありません。今回の検証では、リードレプリカに降格したインスタンス(旧ライターインスタンス)が、自動的にカスタムエンドポイントに登録するような設定を見つけるのがゴールとなります。

問題が起きたカスタムエンドポイントの環境

Auroraクラスタで、ライターインスタンス1台、リーダーインスタンス1台構成で運用
カスタムエンドポイントは下記条件で作成し運用
- READER TYPE
- メンバシップルール内の[今後追加されたインスタンスをこのクラスターにアタッチ]はDisable ※この設定はAuroraレプリカを追加する際に意図せずエンドポイントに追加されるのを防ぐ意図で入れたのですがこれが仇になりました。。
- 静的リストで、リーダーインスタンス1台を登録

Auroraのカスタムエンドポイントの主な設定値

はじめに前提知識としてAuroraのカスタムエンドポイントに主な設定値の内容を確認しておきます。主な設定値は2つです

タイプ指定

Any or READERでカスタムエンドポイントのルールを指定する

type	説明
READER	読み取り専用の Aurora レプリカである DB インスタンスのみが、READER カスタムエンドポイントの一部となることができる
ANY	読み取り専用の Aurora レプリカと読み取り/書き込みのプライマリインスタンスの両方が ANY カスタムエンドポイントの一部となることができる

メンバーシップルール

静的リストか除外リストを用いて、カスタムエンドポイントに所属するインスタンスを指定する
[今後追加されたインスタンスをこのクラスターにアタッチ]するか否かを選択する ※今回の検証ではここが肝だった

検証

6つのパターンからフェイルオーバー時に降格したマスターノードがカスタムエンドポイントのメンバに自動的に追加される設定を探りました。

検証

テスト用のAuroraクラスターを作成
クラスタには、1台のライターノード(test-custom-endpoint)と1台のリーダーインスタンス(test-custom-endpoint-ap-northeast-1c)を用意
6パターンのカスタムエンドポイントを作成し、フェイルオーバー時の挙動を確認

結果

②の構成でカスタムエンドポイントを作ることで、フェイルオーバー時に降格したインスタンスがカスタムエンドポイントに追加されることが確認出来ました。

また、⑤⑥の構成であれば静的リストの中からレプリカのみがカスタムエンドポイントのメンバーとして管理されることがわかりました。

※はてブでコメントいただき「ライターインスタンスは静的リストに入れておいてもライターのうちはREADER TYPEのメンバにはならないからそれをうまく使うという」気づきを得ました。

No	TYPE	追加インスタンスのアタッチ	静的リストに登録するメンバ	予想	結果
①	READER	Disable	レプリカのみ	メンバいなくなる	メンバいなくなる
②	READER	Enable	レプリカのみ	メンバいなくなる or 降格したインスタンスがメンバイン	降格したインスタンスがメンバイン
③	ANY	Disable	レプリカのみ	そのまま(昇格したライターのみ)	そのまま
④	ANY	Enable	レプリカのみ	そのまま or 降格したインスタンスがメンバイン	そのまま
⑤	READER	Disable	レプリカとライター	降格したインスタンスのみ	降格したインスタンスのみ
⑥	READER	Enable	レプリカとライター	降格したインスタンスのみ	降格したインスタンスのみ

最終的にどんな構成にすればいいのか

カスタムエンドポイントを使いたいよくあるケースは下記のようなパターンかと思います。

マスターにはサービスからの書き込みトラフィックが流れる
複数台あるレプリカを束ねるカスタムエンドポイントにサービスの読み取りトラフィックが流れる
- フェイルオーバー時は、このサービス用のカスタムエンドポイントのいずれかがマスタ昇格
分析用にAuroraのレプリカを作ってそこは分析のSQLだけが流れるような構成

下記のような構成を取ることで、カスタムエンドポイントの本来の良さを生かしてAuroraレプリカへのトラフィック分散が出来るのではないかと思います。(さらばbinlogレプリ)