Auroraカスタムエンドポイントのフェイルオーバー時の制御

Auroraカスタムエンドポイントを設定して、フェイルオーバーが発生した場合の挙動について調べました。

はじめに

上記の図のようにカスタムエンドポイントを複数使用して、読み取り先のDBを制御したい場合があると思います。

カスタムエンドポイントを使用すれば、簡単に制御できるのですが、実運用するにはフェイルオーバー時の挙動も知っておく必要があると考えました。

フェイルオーバー時にカスタムエンドポイントで指定しているリーダーインスタンスが昇格した場合、代わりにプライマリが降格してカスタムエンドポイントで指定されるようになるのでしょうか？それともカスタムエンドポイントに紐づくインスタンスは無くなるのでしょうか？
その辺りを調査していきます！

⭐️今回やりたいこと

カスタムエンドポイントを使って、通常はdb-2のリーダーインスタンスで読み取りを行い、フェイルオーバー発生後はプライマリから降格したdb-1をカスタムエンドポイントのリーダーインスタンスとして使うように制御したいです。

フェイルオーバー時の挙動の調査をしていく中では、上記の図にあるカスタムエンドポイント2を考える必要はないので省略します。赤枠の部分だけを使用して調査をしていきます。

前提

DBの構成は以下のようになっています。

db-cluster
- db-1（ライターインスタンス）
- db-2（リーダーインスタンス）

調査１（失敗）

予測

コンソール上からカスタムエンドポイントを作成して、リーダーインスタンスをエンドポイントメンバーに設定すれば実現できそうな気がします。やってみます。（☜失敗します）

カスタムエンドポイント設定

リーダーインスタンスにカスタムエンドポイントを設定します。

エンドポイント名：reader
エンドポイントメンバー：db-2（リーダーインスタンス）
今後追加されるインスタンスをこのクラスターにアタッチする：ON

新たにreaderのプレフィックスで始まるエンドポイントが作成されたことが分かります。
こちらの設定を再度確認するとリーダーであるdb-2が、メンバーとして設定されています。

フェイルオーバー

この設定でフェイルオーバーすると、以下のようにdb-2がライターインスタンスに変更されていることが分かります。

私の予測では、このカスタムエンドポイントのメンバーにはリーダーインスタンスしか入らない想定でした。なので、ライターに昇格したdb-2がメンバーに入ってきて大混乱しました。（アホでした）

考察

冷静に考えると当然でして、
カスタムエンドポイントの設定で、メンバーをどのタイプのインスタンスでも許可するような設定になっているためこのようになります。カスタムエンドポイントはコンソールからではANYタイプしか指定できないようです。リーダー用のカスタムエンドポイントの検証をしたいのでCLIを実行してREADERタイプを指定して作成します。

調査2（失敗）

予測

CLIでエンドポイントタイプをREADER`としたカスタムエンドポイントを作成して、メンバーにリーダーインスタンスを設定しておけばできそうです。やってみます。（☜失敗します）

カスタムエンドポイント設定

CloudShellで以下を実行します。

[cloudshell-user@ip-10-134-31-199 ~]$ aws rds create-db-cluster-endpoint --db-cluster-identifier db-cluster --db-cluster-endpoint-identifier reader --endpoint-type READER --static-members db-2
{
    "DBClusterEndpointIdentifier": "reader",
    "DBClusterIdentifier": "db-cluster",
    "DBClusterEndpointResourceIdentifier": "cluster-endpoint-K5MKRNUCXO6HNTBN454T4O4B6E",
    "Endpoint": "reader.cluster-custom-ckdq7op2mrv4.ap-northeast-1.rds.amazonaws.com",
    "Status": "creating",
    "EndpointType": "CUSTOM",
    "CustomEndpointType": "READER",
    "StaticMembers": [
        "db-2"
    ],
    "ExcludedMembers": [],
    "DBClusterEndpointArn": "arn:aws:rds:ap-northeast-1:722015880532:cluster-endpoint:reader"
}

このCLIコマンドによって

• エンドポイント名：reader
• エンドポイントメンバー：db-2（リーダーインスタンス）
• エンドポイントのタイプ：リーダー
  が設定されたことになります。
  
  CLIを実行してカスタムエンドポイントは出来上がったのですが、コンソール上では特に変化がないため、リーダータイプなのかどうかは分かりませんでした。設定を確認するにはCLIを実行するしかないようです。

フェイルオーバー実行

今回はCLIで実行してエンドポイントのタイプをリーダーに設定したので、フェイルオーバーすれば、プライマリだったdb-1がリーダーインスタンスとして、カスタムエンドポイントのメンバーに入ってくると思います。

...と思っていた時代もありました。失敗です。カスタムエンドポイントのエンドポイントメンバーは無しになりました。降格したプライマリが設定されて欲しいのですが。。

考察

ここでようやく気づいたのですが、カスタムエンドポイントに設定しているインスタンスがdb-2のみだったのが、良くなかったようです。db-1も設定しなければいけないようですね。CLIからのエンドポイントのRead設定とエンドポイントメンバーとしてdb-1もdb-2も入れておくということがポイントのようです。やってみます。

調査3（成功）

予測

CLIを実行してReadインスタンスのみ許可をするカスタムエンドポイントを作成して、リーダーインスタンスとフェイルオーバー時に設定されるライターエンドポイントを設定する。

カスタムエンドポイント設定

CloudShellで以下を実行します。

[cloudshell-user@ip-10-134-21-193 ~]$ aws rds create-db-cluster-endpoint --db-cluster-identifier db-cluster --db-cluster-endpoint-identifier reader --endpoint-type READER --static-members db-1 db-2{
    "DBClusterEndpointIdentifier": "reader",
    "DBClusterIdentifier": "db-cluster",
    "DBClusterEndpointResourceIdentifier": "cluster-endpoint-WB4VIKXCDXGULD722BFPXFWSV4",
    "Endpoint": "reader.cluster-custom-ckdq7op2mrv4.ap-northeast-1.rds.amazonaws.com",
    "Status": "creating",
    "EndpointType": "CUSTOM",
    "CustomEndpointType": "READER",
    "StaticMembers": [
        "db-1",
        "db-2"
    ],
    "ExcludedMembers": [],
    "DBClusterEndpointArn": "arn:aws:rds:ap-northeast-1:722015880532:cluster-endpoint:reader"
}

CLI実行時のカスタムエンドポイントの設定はこのようになっています。想定通り、db-2がリーダーとして設定されています。

フェイルオーバー実行

フェイルオーバーを実行しました。

プライマリから降格したdb-1がリーダーインスタンスとして設定されていました。
やりたい制御ができました！

まとめ

カスタムエンドポイントを読み取り専用のインスタンスのみを許可するには
=> CLIでエンドポイントのタイプ：リーダーの設定が必要である

更にフェイルオーバー時にプライマリから降格したリーダーインスタンスをカスタムエンドポイントに設定するには
=>ライター（プライマリ）インスタンスをカスタムエンドポイントのエンドポイントメンバーに入れておく必要がある