Amazon Auroraのエンドポイント徹底解説：クラスターエンドポイント・リーダーエンドポイント・インスタンスエンドポイントの使い分け

Auroraリードレプリカを使ったことがある方なら、利用可能なエンドポイントが複数あることに気づいたかもしれません。クラスターエンドポイント、リーダーエンドポイント、そしてインスタンスエンドポイント……これだけの選択肢があると、「どれをいつ使えばいいのか？」と迷うのは当然です。答えは、多くの実務的なシステムと同じく「ケースによる」というものになります。

この記事では、各エンドポイントの特徴、適したユースケース、そしてそれぞれの設計判断に伴うトレードオフについて詳しく解説します。

Amazon Auroraで利用できる3種類のエンドポイント

• クラスターエンドポイント – アプリケーションをDBクラスターの現在のプライマリDBインスタンスに接続します。このインスタンスに対しては、読み取りと書き込みの両方が可能です。

• リーダーエンドポイント – 利用可能なリードレプリカのプール全体に接続を負荷分散します。読み取りクエリをここにオフロードすることで、プライマリDBインスタンスへの負荷を軽減できます。

• インスタンスエンドポイント – クラスター内の特定のインスタンスに直接接続します。接続の振り分けをAmazon Auroraに任せるのではなく、クライアント側でクエリの割り当てを細かく制御できます。

「書き込みはクラスターエンドポイント、読み取りはすべてリーダーエンドポイントに接続すればよくて、特定のインスタンスに接続するなんて組み込みの耐障害性を無視するだけでトラブルのもとだろう」と思うかもしれません。しかし前述のとおり、アプリケーションとAuroraとのやり取りは複雑（少なくとも自明ではない）なシステムを構成します。複雑なシステムにおいて「万能な一手」に頼るのは危険です。……深夜の緊急電話を受けたくないのであれば、なおさらです。

それでは、具体的なシナリオごとに、どのエンドポイントをいつ使うべきかを見ていきましょう。

即時一貫性が必要な場合

一部のアプリケーションは、データが即時に一貫していることを前提としています。こうしたアプリケーションはデータを書き込んだ直後に読み取りを行い、「ローカルのデータではなくモデルを信頼せよ」といった設計パターンに厳密に従います。Amazon AuroraはACID準拠であるため、クラスターエンドポイントへの書き込みコミットが成功した直後に同じエンドポイントから読み取れば、期待どおりのデータが取得できます（後続の読み取り前に別のトランザクションがデータを変更していない場合）。

問題が発生するのは、書き込みをクラスターエンドポイントに送り、読み取りをリーダーエンドポイントに対して行う場合です。これは、データの書き込みからリーダー側で参照可能になるまでのレイテンシが原因です。レプリケーションラグは100ミリ秒未満と短いものの、ゼロではありません。そのため競合状態（レースコンディション）が発生しえます。「書き込んだ直後に必ず読み取る」必要があるシナリオでは、読み取りも書き込みもクラスターエンドポイントを使用してください。なお、その場合により高いパフォーマンスが必要になったら、プライマリインスタンスのサイズをスケールアップするしかない点にも注意しましょう。

一方、結果整合性（イベントualコンシステンシー）で十分であり、アプリケーション側がそれを許容できるのであれば、リーダーエンドポイントの活用はプライマリインスタンスの負荷を下げる優れた手段となります。

読み取りクエリのオフロード

「書き込み直後の読み取りがダメなら、わざわざ別のリーダーエンドポイントを持つ意味はあるのか？」と思うかもしれません。しかし、多少の不整合が問題にならないユースケースは数多く存在します。たとえば日次レポートです。前日のデータからバッチ処理でレポートを生成する場合、100ミリ秒程度のレプリケーションラグはまったく問題になりません。ECサイトの商品説明ページなども同様です。ユーザーのブラウザに残っている古いキャッシュのほうが、レプリケーションラグよりも影響として大きいでしょう。

一般的に、即時一貫性に依存しない読み取り中心のワークロードは、リーダーエンドポイントの利用を検討すべきです。

ワークロードが偏っている場合

インスタンスエンドポイントの使用が合理的になる場面もあります。たとえば、Elastic Load Balancerの背後に多数のステートレスなマイクロサービスが配置されているアプリケーションを考えてみましょう。この場合、クエリはクライアント間に均等に分散され、結果としてリーダーエンドポイント経由でもリードレプリカ間に均等に分散されると想定できます。

ところが、各クライアントのワークロードが均等に分布していない場合はどうでしょうか。たとえばレポーティングサービスが混ざると、特定のリードレプリカだけが他より不釣り合いに高い負荷を抱えます。先ほどのマイクロサービスも同じリードレプリカを使っていると、レポート処理で使われているインスタンスへのクエリ性能が低下する可能性が高くなります。

これを回避する一つの方法は、接続の分散をAuroraに任せるのではなく、クライアント側で管理することです。幸い、これはリーダーエンドポイントの代わりにインスタンスエンドポイントを使うことで簡単に実現できます。Aurora MySQL向けのMariaDB Connector/Jや、Aurora PostgreSQLのFast Failover機能を利用すれば、ドライバーに個々のリードレプリカを認識させ、クエリを各インスタンスへどう配分するかをドライバー自身に直接制御させることができます。

DNSキャッシュの管理

ワークロードの特性を理解することに加えて、Auroraの高可用性（HA）とリーダーエンドポイントの負荷分散がどのように実現されているか――つまり接続がどのように割り当てられるか――を理解することも重要です。

クラスターエンドポイントの自動フェイルオーバーとリーダーエンドポイントの負荷分散は、IP層やTCP層、データベースクライアントプロトコル層ではなく、DNS（Amazon Route 53）によって管理されています。DNS経由で接続を振り分けるということは、アプリケーションは新しい接続要求のたびにDNSルックアップを行う必要があるということです。DNSキャッシュを使用するアプリケーションは、キャッシュのタイムアウト値をAuroraのDNSレコードTTLに合わせて調整してください。TTLより長くDNS応答をキャッシュすると、次のような問題が発生します。

• HAフェイルオーバー時：リードレプリカがプライマリに昇格するフェイルオーバーイベントが発生しても、キャッシュされたDNS応答により、アプリケーションは障害の発生した旧インスタンスへの再接続を試み続けてしまいます。

• リーダーエンドポイント使用時：DNS応答がキャッシュされることで、複数の接続が特定のリードレプリカに集中し、利用可能なリードレプリカ全体に分散されなくなります。

まとめ

見てきたとおり、本番環境の本格的なワークロードに対して「万能の正解」は存在しません。重要なのは、自分のアプリケーションの特性を理解し、それに応じて適切なエンドポイントを選択することです。

• 即時一貫性が必要 → 読み取りも書き込みもクラスターエンドポイントへ

• 多少のレプリケーションラグが許容できる読み取り → リーダーエンドポイントへオフロード

• リードレプリカは使いたいが、クエリがクライアント間で均等に分散されない → インスタンスエンドポイントを使い、クライアント側で接続分散を管理

そして忘れてはならないのがDNSキャッシュです。アプリケーションのキャッシュタイムアウトがDNSレコードのTTLより長い場合、クラスターエンドポイントのHAフェイルオーバー時やリーダーエンドポイントの利用時に、エンドポイントが期待どおりに動作しなくなります。

アプリケーションの性質を理解し、Auroraエンドポイントの挙動を把握し、その知識を正しく適用することで、より堅牢なアプリケーション環境を実現できます。それはあなたにとっても、顧客にとっても非常に重要なことです。誰も、深夜の障害対応電話は受けたくありませんから。