はじめに

RDS Aurora をそれなりの期間運用していると、
「クラスターエンドポイント、便利なんだけどちょっと融通きかないな…」
と感じる場面が出てきます。（融通とは）

RDS Aurora には、クラスター内の特定のインスタンス（群）に対して、任意の名前で接続できる カスタムエンドポイント という仕組みがあります。

この記事では、実際の運用で直面した課題と、カスタムエンドポイントを使ってどう解決したか、あわせて導入手順をまとめました。

「今すぐ困っている」人だけでなく、「この先たぶん困りそうだな」と感じている人にも、何かの参考になれば嬉しいです。

想定している読者

RDS Aurora のクラスターエンドポイントをそのまま利用している方
binlog レプリカ利用、リアルタイム性の高い利用などで、レプリケーション遅延が気になっている方
サービス利用とは別に、特定用途向けのリーダーインスタンスを切り分けて使いたい方

現在の運用になんらかの課題感がある方や、将来的な運用の柔軟性を高めたい方を想定しています。

3行でまとめると

クラスターエンドポイントでは、用途ごとのインスタンス分離が難しい
カスタムエンドポイントを使うことで、サービスに影響を与えない専用リーダーを用意できる
インスタンスの追加・削除をオンラインで柔軟に行えるようになる

背景

アンドパッドでは、サービスから RDS Aurora インスタンスへの接続に、クラスターエンドポイントを利用しています。

あるマイクロサービスで LIKE 検索の負荷が高まったため、いろいろあって最終的には全文検索システムを導入することになりました。
が、初期同期に問題がありました。

MySQL から全文検索基盤へデータを流し込む過程で、どうしても大量の SELECT が発生します。
しかも一時的とはいえ、そこそこ重たい。

「これ、今のリーダーに投げると普通にサービス影響出そうだな…」
というのが正直な感想でした。

リアルタイム性が必須な処理ではなかったんですが、

サービスとは完全に切り離したい
将来的に類似のオペレーションが発生しそう
レプリケーション遅延はできるだけ少なくしたい

といった点を考えると、 同一クラスター内で、用途を明確に分けられるインスタンス構成 が欲しくなりました。

そこで今回は、カスタムエンドポイントと新規リーダーインスタンスを組み合わせ、専用の読み取り環境を構築しました。

クラスターエンドポイント運用で感じた課題

Aurora のクラスターエンドポイント（特にリーダー）は「とりあえずこれを使っておけば大丈夫」という点では便利です。

一方で、運用していると「全部ひとまとめ」なことが、逆に扱いづらく感じる場面も出てきました。

特に、

お客さまの問い合わせや本番障害などの調査用途
初期同期用途
一時的に重たい処理を流したい

といった サービスとは性質の異なる用途 で、かつ今後も同じことがありそうな状況でリーダーインスタンスを追加したい場合、以下のような点が気になりました。

専用用途のインスタンスを隔離できない
- リーダーを追加すると自動的にクラスターエンドポイントに含まれ、サービスからの接続が流れ込んでしまう
- 高負荷なクエリを流すなどでサービス応答に支障が出る可能性がある
専用インスタンスの性能調整がしづらい
- 一時的な用途やコスト調整で性能を変更したくても、サービスアクセスを遮断できず、扱いづらい
エンドポイントの役割が曖昧になりやすい
- リーダー全てがクラスターエンドポイントに含まれるため、用途別に判別しにくくなる

サービスの安定性を保ちつつ、もう少し柔軟に運用できる仕組みが必要だと感じました。

カスタムエンドポイントでできること

カスタムエンドポイントを利用すると、前述の課題を比較的シンプルに解消できます。

エンドポイントの用途を明確に分離できる
- アプリケーション参照用、全文検索初期同期用など、 用途ごとにエンドポイントを分けられる
サービスへの影響を避けられる
- 用途別のインスタンスを個別に隔離できるため、 高負荷処理をサービスと完全に切り離せる
インスタンスの追加・削除がしやすくなる
- 一時的なインスタンスを、他の用途に影響させずに扱えるため、似たような用途に即応できる
コスト調整がしやすくなる
- なんらかの一時的高負荷用途や、リアルタイム性の高い調査用途など、状況に応じてインスタンス性能を柔軟に調整できる

次に、導入手順の例を紹介します。

導入手順の例

背景で触れた「全文検索初期同期用のカスタムエンドポイント導入」の手順を一般化してみました。

カスタムエンドポイントを使い、リーダーを隔離運用するまでの AWS コンソールでの導入手順の例です。これは一例ですので、読み手のみなさんの環境に合わせて利用いただければと思います。

サービスからのコネクションは既存リーダーに限定しつつ、専用用途のリーダーを安全に追加・提供していきます。

アプリケーション参照用カスタムエンドポイントの作成
- アプリケーション用のリーダーをまず隔離します
- 既存のリーダーインスタンスすべてを含む、アプリケーション参照専用のカスタムエンドポイントを作成します
Route53 の CNAME レコードの向き先変更
- クラスターエンドポイントを CNAME レコード経由で提供しているため、「1.」で作成したカスタムエンドポイントへアプリケーションの接続が向くよう値を更新します
サービスを再起動
- アプリケーションの実装やライブラリ・フレームワークの使い方によっては、コネクションプールを掴んだまま、という場合もありえるため、アプリケーションを再起動して接続をリフレッシュします
専用用途のリーダーインスタンス追加
- アプリケーション参照用エンドポイントには含まれない、専用用途のリーダーインスタンスを追加します
- Tier（フェイルオーバー優先度）は最低値にしておくと、フェイルオーバーが発生してもひとまず安心です
専用リーダーインスタンスに接続が来ていないことを確認
- 意図しない接続がないことを確認します
- audit log や、メトリクスの DatabaseConnections を確認します
専用用途カスタムエンドポイント作成
- 新規リーダーのみを含むカスタムエンドポイントを作成します
- 用途が明確にわかる名称にします
専用用途の CNAME レコードを新規作成
- 用途が明確にわかる CNAME レコード名で作成します
専用用途カスタムエンドポイント接続確認
- 作成した専用用途の CNAME レコード名を指定し、意図したインスタンスに接続できることを確認します
- 踏み台サーバーからの mysql コマンド接続や、利用している GUI ツールなどで「明確に専用用途の CNAME レコード名を指定して接続している」状態で確認します
想定外の接続がないことを最終確認
- 「5.」と同じ確認を行います
- 「8.」のアクセスのみ確認できる前提です
利用チームへ提供
- 利用チームへ CNAME レコード名を共有し、利用開始してもらいます

まとめ

カスタムエンドポイントを使うことで、

サービスとは完全に切り離した専用リーダーインスタンスを用意できる
インスタンスの役割が分かりやすくすることができる
将来の「ちょっと重たいことやりたい」など専用用途に備えられる

という状態を作ることができました。

課題を解決できたこともさることながら、 あとから効いてくる運用の余白を作れた ことも非常に大きかったと考えています。

「当たり前に導入している」環境ももちろんあるかと思うのですが、そうではない環境もあると思っています。

誰かの参考になれたらいいなと思います。

今後の課題

今後は以下にも取り組んでいく予定です。

他クラスターへの横展開
カスタムエンドポイントを含めた IaC 化（Terraform）

課題をひとつ解決すると、また次の課題が見えてきます。
地味ではありますが、こうした積み重ねがあとから効いてくると日々思うので、楽しみながら引き続き改善していこうと思います。