はじめに
クラウドインフラにおいて、システムの「止まらない設計」は最重要テーマの1つです。AWSでは、Multi-AZ / Multi-Region構成や、DNSレベルのフェイルオーバー、レイヤーごとの冗長化によって、堅牢な高可用性アーキテクチャを実現できます。
本記事では、以下の4つの観点から、実用的な高可用性設計を解説します。
- Multi-AZ・Multi-Region構成の考え方
- RDSのクロスリージョンレプリケーション
- Route 53を使った地理的ルーティングとフェイルオーバー構成
- ALB/NLBの構成と運用最適化
1. Multi-AZ・Multi-Region構成
Multi-AZ（アベイラビリティゾーン）構成
同一リージョン内での可用性向上を目的とした構成です。以下のAWSリソースがMulti-AZに対応しています：
- RDS（スタンバイフェイルオーバー）
- ALB（自動的に複数AZに展開）
- ECSサービス（複数AZにTaskを配置）
- Auto Scaling Group（複数サブネットへのインスタンス分散）
Multi-AZ設計は、リージョン単位の障害には弱いという点に注意が必要です。
Multi-Region構成
災害対策（DR：Disaster Recovery）や、レイテンシの最適化を目的にリージョンをまたいで構成を分散します。
一般的なアーキテクチャ例：
- 東京リージョン（ap-northeast-1）⇔ バックアップ：大阪リージョン（ap-northeast-3）
- グローバル配信：米国東部（us-east-1）＋アジア（ap-northeast-1）構成
Multi-Region構成では、DNS切替戦略、データレプリケーション、コストが重要な設計ポイントとなります。
2. RDSのクロスリージョンレプリケーション
RDSはリージョン内のマルチAZ構成だけでなく、リージョン間でのクロスリージョンリードレプリカにも対応しています（一部エンジンのみ）。
対応エンジン：
- MySQL
- MariaDB
- PostgreSQL
# クロスリージョンリードレプリカ作成例（MySQL） aws rds create-db-instance-read-replica \ --db-instance-identifier replica-db \ --source-db-instance-identifier my-db \ --region ap-northeast-3 ユースケース：
- 災害時のDR環境の即時立ち上げ
- 海外からの読み取りパフォーマンス向上
- リージョン別レポーティング
注意点として、リードレプリカは読み取り専用であり、プライマリ切替には手動作業や追加設計が必要です。
3. Route 53での地理的ルーティングとFailover設定
地理的ルーティング（Geolocation Routing）
Route 53では、ユーザーの地理的位置に応じて異なるリソースに振り分けることが可能です。たとえば：
- 日本からのアクセス → 東京リージョン
- 米国からのアクセス → バージニアリージョン
# Route 53の地理的ルーティング例（JSON） { "Name": "example.com", "Type": "A", "SetIdentifier": "Japan users", "GeoLocation": { "CountryCode": "JP" }, "ResourceRecords": [ {"Value": "1.2.3.4"} ] } フェイルオーバールーティング
Route 53では、ヘルスチェック結果に基づいてフェイルオーバーが可能です。
例：
- プライマリ：東京リージョン
- セカンダリ：大阪リージョン
東京リージョンのELBがヘルスチェック失敗 → 自動的に大阪リージョンへトラフィックを切り替え。
# フェイルオーバー設定に必要な項目 { "Failover": "PRIMARY", "HealthCheckId": "xxxxxxx" } DNS TTLの設定も重要で、短くしすぎるとルックアップコスト増、長いと切替遅延になります。推奨：30〜60秒。
4. ALB/NLB構成の最適化
ALB（Application Load Balancer）
- L7ロードバランシング（HTTP/HTTPS）
- URLパスやホスト名ベースのルーティング
- Lambda、ECS、EKSなどとの統合
ベストプラクティス：
- 複数AZにターゲットグループを分散
- ヘルスチェック間隔は短く（10秒〜）
- WAF、Shield Standardを併用してセキュリティ強化
NLB（Network Load Balancer）
- L4ロードバランサー（TCP/UDP）
- 極めて高速な処理性能、低レイテンシ
- 静的IPアドレス割当やElastic IP連携が可能
EKSやデータベースプロキシ用途、またはオンプレと統合する構成ではNLBが有効です。
ALB vs NLBの使い分け
| ユースケース | 推奨LB |
|---|---|
| Webアプリ（HTTPS, パスベース振り分け） | ALB |
| リアルタイム処理（TCP, UDP） | NLB |
| 固定IPが必要なエンドポイント | NLB |
| Lambdaとの連携 | ALB |
まとめ
AWSでの高可用性アーキテクチャは、単なる冗長化ではなく、AZ・リージョン・DNS・ネットワークレイヤーをまたぐ多層的な設計が求められます。
- Multi-AZ構成はデフォルト、災害対策にはMulti-Regionを
- RDSのリードレプリカでDRやグローバル配信に備える
- Route 53でトラフィック制御とフェイルオーバーを自動化
- ALB/NLBは用途に応じて正しく選定・最適化
次章では、これら高可用性設計をTerraformなどのIaCでコード化し、再現性のある構成管理を行う方法を解説します。
