SW BBANG J

本番EC2インスタンスが深夜に突然ダウンした経験があるなら、DNSフェイルオーバーの重要性は身に染みているはずだ。Route 53のヘルスチェックとフェイルオーバールーティングを組み合わせれば、EC2が応答しなくなった瞬間にS3の静的サイトへ自動的にトラフィックを切り替えられる。このガイドでは、 Route 53 DNSフェイルオーバー の仕組みから実際の設定手順まで、プロダクション環境で使える形で解説する。 TL;DR：Route 53 DNSフェイルオーバーの全体像 項目 内容 目的 EC2障害時にS3静的サイトへ自動DNS切り替え 主要コンポーネント Route 53ヘルスチェック、フェイルオーバールーティングポリシー、S3静的ウェブサイトホスティング 切り替えの目安 ヘルスチェック失敗判定後、TTL経過で切り替わる（TTL設定値に依存） 必要なレコードタイプ PRIMARY（EC2向け）とSECONDARY（S3向け）の2レコード コスト要因 ヘルスチェック料金、Route 53クエリ料金（最新料金は公式ドキュメント参照） 主な注意点 S3静的ウェブサイトエンドポイントはHTTPSを直接サポートしない Route 53フェイルオーバーの仕組み フェイルオーバールーティングポリシーは、レコードをPRIMARYとSECONDARYの2種類に分類する。Route 53はPRIMARYレコードに紐付けられたヘルスチェックを定期的に実行し、失敗と判定した場合にSECONDARYレコードを返すよう切り替える。ヘルスチェックはRoute 53のグローバルなヘルスチェッカーネットワークから実行されるため、単一リージョンの問題ではなく、広域での到達不能を検知する。 重要なのは、DNS応答の切り替えはTTLに依存するという点だ。ヘルスチェックが失敗を検知してもTTLが長ければ、クライアントはキャッシュされた古いIPアドレスを使い続ける。フェイルオーバーの応答速度を重視するなら、TTLを低く設定する必要がある。ただし、TTLを下げるとRoute 53へのクエリ頻度が上がり、コストに影...

RDS Multi-AZを有効にしたのに「パフォーマンスが上がるはず」と期待して、後から「何も変わっていない」と気づく — これは本番環境でよく見かける誤解だ。Multi-AZはパフォーマンス機能ではなく、 高可用性とフェイルオーバー のための機能であり、その設計思想を正しく理解しないと、コストと効果のバランスを見誤る。 TL;DR — RDS Multi-AZの要点 観点 Multi-AZの動作 目的 高可用性・自動フェイルオーバー スタンバイインスタンス 読み取り/書き込みトラフィックを受け付けない（通常時） レプリケーション 同期レプリケーション（プライマリ → スタンバイ） フェイルオーバー所要時間 通常1〜2分（DNSエンドポイント切り替え） 読み取りスケールアウト 対象外（Read Replicaが別途必要） コスト シングルAZ比でインスタンス料金が約2倍 RDS Multi-AZの仕組み — 有効化する前に理解すべきこと Multi-AZを有効にすると、RDSはプライマリインスタンスとは 別のアベイラビリティゾーン にスタンバイインスタンスを自動的にプロビジョニングする。プライマリへの書き込みはすべて同期的にスタンバイへレプリケートされる。つまり、プライマリがコミットを返す前にスタンバイへの書き込みも完了していることが保証される。 この同期レプリケーションが、Multi-AZがパフォーマンス向上に寄与しない理由でもある。書き込みレイテンシはスタンバイへの往復時間分だけ増加する可能性がある。アプリケーションからは単一のDNSエンドポイントしか見えず、スタンバイインスタンスへの直接アクセスは通常時は不可能だ。 graph TD App["アプリケーション"] -->|"単一DNSエンドポイント"| Primary["プライマリインスタンス (AZ-A)"] Primary -->|"同期レプリケーション (コミット前に完了)"| Standby[...