この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
アノテーション、テクニカルサポートチームの村上です。
先日、検証の為にライター 1 台構成の Aurora クラスターを作成したところ、エンドポイントにリーダーエンドポイントも作成されていることに気づきました。
普段、検証で Aurora クラスターを作成する場合、リードレプリカも 1 台加えて作成することがほとんどだったので、リードレプリカを作成しない場合でもリーダーエンドポイントが作成されていることに少し驚きました。
リードレプリカを追加した場合に備えて前もって準備してあると考えると自然なことですが、良い機会なので以前から試してみたかったリードレプリカが無い状態のリーダーエンドポイントへ接続しての書き込みを試してみることにしました。（読み込みではありません）
「リーダーエンドポイント接続での書き込み？」と驚いた方は、ぜひご一読ください！
ライター 1 台構成で Aurora クラスターを作成してみた
EC2 作成
Aurora クラスターを作成する前に Aurora へ接続する EC2 を作成します。
RDS を作成する前に EC2 を作成することで、RDS 作成時にセキュリグループによる接続元の指定が楽になります。
名前：Aurora-Test
インスタンスタイプ：t2.micro
パブリック IP の自動割り当て：有効化
セキュリティグループのインバウンドルール：自分の IP を許可（SSH 接続）
ストレージサイズ：8GiB(gp2)
Aurora クラスター作成
Aurora MySQL クラスターをライター 1 台構成で作成します。
DB クラスター識別子：test
DB インスタンス ID：test-instance-1
エンジンバージョン：5.7.mysql_aurora.2.10.2
インスタンスクラス：db.t3.small
マルチ AZ 配置：Aurora レプリカを作成しない
接続：EC2 コンピューティングリソースに接続（先に作成した EC2 Aurora-Test を指定）
パブリックアクセス：なし
データベース認証：パスワード認証
拡張モニタリングの有効化：無効
暗号化：無効
マイナーバージョン自動アップグレードの有効化：無効
ライター 1 台構成でも、リーダーエンドポイントが作成されていることが確認できました。
エンドポイント名は、クラスターエンドポイントとリーダーエンドポイントで以下のように作成されました。
クラスターエンドポイント
test.cluster-cvkbczufdw7g.ap-northeast-1.rds.amazonaws.com
リーダーエンドポイント
test.cluster-ro-cvkbczufdw7g.ap-northeast-1.rds.amazonaws.com
クラスターエンドポイントへ接続してデータベースとテーブルを作成
リーダーエンドポイントへの接続を試す前に、事前にクラスターエンドポイントへ接続して、データベースとテーブルを作成しました。
レコードも 2 つ追加しておきました。
リーダーエンドポイントへ接続して書き込みしてみた
EC2 から接続するエンドポイントを、クラスターエンドポイントからリーダーエンドポイントへ変更して接続できるか試してみます。
Aurora クラスターにリードレプリカが無い構成の場合でも、リーダーエンドポイントから Aurora クラスターへ接続することができました！
試しに SELECT 文を実行してみます。football テーブルを表示することができました。
では、INSERT 文を実行してレコードを追加できるか試してみます。
リーダーエンドポイントからの接続でも、レコードの追加（書き込み）に成功しました！
種明かし
もうお気づきかと思いますが、リードレプリカが無い状態のリーダーエンドポイントの接続先はライターインスタンスとなります。クラスター構成がライターインスタンス 1 台なので、当たり前と言えば当たり前なのですが。
クラスターにプライマリインスタンスのみが含まれていて、Aurora レプリカが含まれていない場合、リーダーエンドポイントはプライマリインスタンスに接続します。その場合は、エンドポイントを介して書き込みオペレ―ションを実行できます。
実際にリーダーエンドポイントの FQDN に対して dig コマンドを実行して接続先を確認してみます。
リーダーエンドポイントの接続先が CNAME レコードでtest-instance-1.cvkbczufdw7g.ap-northeast-1.rds.amazonaws.comとなっていることが確認できました。
ライターインスタンスのインスタンスエンドポイントをマネジメントコンソール上で確認したところ、dig コマンドの実行結果で得られた接続先test-instance-1.cvkbczufdw7g.ap-northeast-1.rds.amazonaws.comと一致していることが確認できました。
テクサポからの運用上の注意点
リードレプリカに何らかの障害が発生しリーダーエンドポイントから接続できるリードレプリカが無くなった場合、本記事でご紹介したようにリーダーエンドポイントへの接続もライターインスタンスへ向かうのですが、注意する点があります。
注意する点とは、接続元のアプリケーションにおいて長時間の DNS キャッシュを設定しないことです。
接続元のアプリケーションにおいて DNS キャッシュをしている場合、DNS レコード上で接続先が変更されても接続元のアプリケーションは DNS キャッシュの TTL が切れるまで、障害があったリードレプリカへの接続を試みることとなります。
以下の AWS ナレッジにもアプリ側の DNS キャッシュが起こす問題について分かりやすい説明があるので、ぜひご一読ください。
Amazon Aurora ライターエンドポイントに接続する際、接続がリーダーインスタンスにリダイレクトされるのはなぜですか?
まとめ
ずっと試してみたかったリーダーエンドポイントからのライターインスタンスへの接続をブログ化できて良かったです。
この記事がどなたかのお役に立てば幸いです。
4
