SOA信頼性とビジネス継続性
あるECサイトのバックエンドはRDS MySQL(Multi-AZ構成)を使用しています。定期メンテナンス時のフェイルオーバーで、スタンバイへの昇格中にアプリケーションサーバーが旧プライマリのDNSキャッシュを参照し続け、約40秒間に渡り接続エラーが発生しました。アプリケーションコードの大幅な変更は避けつつ、次回のフェイルオーバーで接続断を数秒以内に収めるために最も効果的な対策はどれですか?
AアプリケーションサーバーのJVM・OSのDNSキャッシュTTLを5秒以下に設定し、フェイルオーバー後のエンドポイント切り替えを高速化する
JVMやOSのDNSキャッシュTTLを短縮しても、アプリケーションフレームワークやコネクションプールが独自のキャッシュを保持する場合があり、すべてのレイヤーを制御することは困難です。フェイルオーバー時の接続断を確実になくす解決策にはなりません。
BRDS Multi-AZをやめて同一リージョンの別AZにリードレプリカを2台作成し、フェイルオーバー時はRunbook手順に従い手動プロモートする
Multi-AZの自動フェイルオーバーをやめて手動プロモートに変更すると、フェイルオーバーに数分かかり接続断はむしろ延長されます。またリードレプリカは書き込みを受け付けないため、昇格完了まで書き込み系トランザクションが停止します。
CAmazon RDS Proxyをデータベース前段に配置し、接続先をProxyエンドポイントに切り替えてフェイルオーバー時の接続プールを引き継ぐ
✓ 正解
RDS Proxyはフェイルオーバー時に既存の接続プールを維持しつつ新しいプライマリDBへ内部で再接続するため、アプリケーション側のDNSキャッシュ問題を回避し接続断を数秒以内に抑えられます。接続先をProxyエンドポイントに変えるだけで導入でき、アプリケーションの大幅な変更は不要です。
DCloudWatchアラームでRDSの接続エラーを検知し、Lambda関数で設定ファイルを書き換えてアプリケーションを再起動する自動修復フローを構築する
CloudWatch + Lambdaによる自動修復はアラーム評価・Lambda起動・再起動処理で数十秒〜数分かかり、数秒以内の回復要件を満たせません。またアプリケーション再起動は進行中のリクエストを強制中断させるリスクがあります。
解説
RDS Proxyはアプリケーションとデータベースの間に位置するフルマネージドのデータベースプロキシです。Multi-AZフェイルオーバーが発生すると、Proxyは既存のアプリケーション接続をプールに保持したまま内部で新しいプライマリDBへ再接続します。アプリケーション側のエンドポイントはProxyエンドポイントで固定されるため、DNSキャッシュの影響を回避でき、接続断を通常数秒以内に短縮できます。アプリケーション側の変更は接続先をProxyエンドポイントに切り替えるのみです。
選択肢AのDNS TTL短縮は、JVMやアプリケーションフレームワークが独自のDNSキャッシュを持つため全レイヤーを制御できず、確実な解決策にはなりません。
選択肢BのリードレプリカへのDRはMulti-AZの自動昇格をやめて手動プロモートに頼るため、復旧時間が大幅に増加し可用性が低下します。
選択肢DのLambdaによる自動修復は、アラーム評価・Lambda実行・アプリケーション再起動の各ステップに時間がかかり、数秒以内の回復という要件を満たせません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →