Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
著者:
AWSマルチリージョンアクティブアクティブアーキテクチャは、2つ以上のAWSリージョンが同時に本番トラフィックを処理する分散クラウド設計であり、リージョン間の常時レプリケーションとグローバル自動トラフィックルーティングによって支えられています。
いずれかのリージョンでサービス障害が発生しても、他のリージョンが切り替え遅延なくユーザーにサービスを提供し続けます。残りのリージョンはアプリケーションの全負荷を処理できる規模に構成されており、障害発生時の業務継続性を保証します。Route 53のレイテンシベースルーティングまたはGlobal Acceleratorを通じてユーザーは最寄りのリージョンに誘導され、遅延を抑え快適な利用体験を実現します。
本ガイドではAWSマルチリージョン環境の構築手順を解説し、エンドツーエンドのデプロイ、データレイヤー設計、競合解消、監視、コスト損失につながるミスの回避方法を学べます。
データレプリケーションの費用が発生するため、マルチリージョンAWS構成のコストは単一リージョンの2～3倍になります。実装に着手する前に、自身のシステムが本構成を必要とするか下記のケースを確認しましょう。
インフラの準備は容易です。AWSにはRoute 53、Global Accelerator、CloudFrontが標準で用意されています。しかしマルチリージョンアクティブアクティブ構成ではCAP定理と正面から向き合う必要があります。リージョン間のネットワーク分断が発生した際、以下のいずれかを選択することになります。
以下の手順に沿ってAWS上にマルチリージョンアクティブアクティブ構成を作成できます。
ユーザーを稼働中の最寄りリージョンに誘導する必要があり、AWSには相補的な3つの手法が用意されています。
►Amazon Route 53によるDNSベースルーティング
Route 53をエントリーポイントとし、レイテンシベースルーティングでユーザーを最寄りリージョンに振り分けます。各リージョンのエンドポイントにヘルスチェックを設定し、リージョン障害時は自動的にトラフィックの振り分けを停止します。
主な設定項目
1. 各リージョンのALBに対し、確認間隔10秒、障害閾値2回のヘルスチェックを作成
2. DNSのTTLを60秒に短く設定し、フェイルオーバーを高速化
3. EvaluateTargetHealthをtrueに設定し、ALBの稼働状態をRoute 53が反映
# リージョンALBのヘルスチェック作成コマンド
aws route53 create-health-check \
--caller-reference "us-east-1-health-$(date +%s)" \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "us-east-1-alb.example.com",
"Port": 443,
"ResourcePath": "/health",
"RequestInterval": 10,
"FailureThreshold": 2
}'
►AWS Global Acceleratorによるトラフィック高速化
Global Acceleratorは固定のエニーキャストIPアドレスを提供し、稼働中の最寄りリージョンエンドポイントにトラフィックを誘導します。DNSルーティングと異なりネットワーク層で動作し、AWS専用バックボーンを経由するため、インターネット経由と比較しTCP/UDPの遅延を最大60%削減可能です。
各リスナーに複数のエンドポイントグループ（1リージョンに1グループ）を登録し、稼働中の最寄りグループにトラフィックを分配します。トラフィックダイヤルで各リージョンへの流量割合を調整でき、段階的なフェイルオーバーやカナリーデプロイに活用できます。
►Amazon CloudFrontによるエッジキャッシュ
コンテンツ量の多いアプリケーションにはCloudFrontが適しており、世界のエッジロケーションに静的アセットをキャッシュし、オリジンサーバーの負荷を軽減してユーザー体験を改善します。Route 53のレイテンシルーティングと組み合わせることで最適なパフォーマンスを実現します。
許容可能な整合性保証のもと、マルチリージョンでの書き込みに対応するデータストアが必要です。代表的な4つの選択肢を紹介します。
►選択肢1：DynamoDBグローバルテーブル（完全マルチマスター）
DynamoDBグローバルテーブルはAWSリージョン間の完全マネージドなアクティブアクティブレプリケーション機能です。いずれのレプリカテーブルにも書き込み可能で、変更内容は自動的に全リージョンに伝播されます。内部的にDynamoDBストリームを利用してリージョン間のデータ複製を実行します。
数万事業者が結果整合性モデルのグローバルテーブルを活用していますが、決済システムや金融サービスといった重要業務では、リージョン全体の障害発生時でもRPOをゼロに抑える要件が存在します。
マルチリージョン強整合性（MRSC）：2025年6月にDynamoDBグローバルテーブルに追加された機能で、高可用マルチリージョンシステム向けにRPOゼロを実現します。指定した複数AWSリージョンにテーブルを自動複製し、高速かつ強整合な読み書き処理を提供します。
MRSC対応リージョン：米東（バージニア北部、オハイオ）、米西（オレゴン）、欧州（アイルランド、ロンドン、パリ、フランクフルト）、アジア太平洋（東京、ソウル、大阪）
MRSCのアーキテクチャ要件：クォーラム維持のため3つのAWSリージョンが必須で、2種類の構成方法があります。
(1) 完全レプリカを3箇所配置
(2) 完全レプリカ2箇所＋ウィットネスリージョン
ウィットネスリージョンには変更履歴データのみ複製され、テーブル全体を保持しないため、ストレージコストを抑えつつ可用性要件を満たせます。
競合解消：結果整合性のグローバルテーブルはタイムスタンプによる最終書き込み優先（LWW）方式を採用。MRSCを有効にすると強整合性により書き込み競合自体が発生しません。
コスト：MRSCグローバルテーブルは既存のグローバルテーブル料金体系が適用されます。中規模負荷のアクティブアクティブ構成の場合、グローバルテーブル分の費用は月額約18ドル程度です。
►選択肢2：Auroraグローバルデータベース（リレーショナルワークロード向け）
Auroraグローバルデータベースは最大6つのAWSリージョンにAuroraクラスターを複製します。1つのリージョンがプライマリ（読み書き両方可能）、残りのセカンダリリージョンは読み取り専用となります。
制限事項：複数ライターノードに対応しておらず、全ての書き込みはプライマリリージョンに送信する必要があります。真のアクティブアクティブ書き込みを実現するには、セカンダリからプライマリへの書き込み転送を実装する必要があり、プライマリから遠いリージョンの書き込み処理に遅延が発生します。
レプリケーション遅延：リージョン間複製の遅延は通常1秒未満に抑えられるため、各地域から高速なローカル読み取りが必要な読み込み偏重業務に適しています。
コスト：中規模アプリケーションの場合、AuroraグローバルDBの複製にかかる追加費用は月額約85～100ドルです。
►選択肢3：Aurora DSQL（完全アクティブアクティブSQL）
Amazon Aurora DSQLはサーバーレス分散SQLデータベース（PostgreSQL互換）で、事実上無限のスケーリング、最高水準の可用性、インフラ管理の完全廃止を実現します。主な特徴は以下の通りです。
Aurora DSQLによるマルチリージョン強整合性の仕組み：Aurora DSQLマルチリージョンクラスターは同期型リージョン間レプリケーションを活用し、リージョン（およびウィットネスリージョン）間の強整合性を維持します。いずれのリージョンのエンドポイントからも読み書きを受け付け、リージョンAの書き込みコミット内容はリージョンBの読み取りから即時参照可能です。
最大のメリット：アプリケーション側はマルチリージョンアクティブアクティブ構成を意識する必要がなく、他リージョンとの調整・メッセージング処理を実装する必要もありません。全てDSQL側で処理されるため、アプリ設計の負担が大幅に軽減されます。
可用性SLA：単一リージョン99.99%、マルチリージョン99.999%
マルチリージョンDSQLのエンドポイントルーティング：Aurora DSQLマルチリージョンクラスターを利用するアプリは、Route 53などDNSベースのルーティング機構を導入しリージョン間のトラフィック自動切り替えを実装する必要があります。推奨運用として、アプリケーション層にルーティングロジックを実装し、リージョンフェイルオーバーを統合的に管理します。
►選択肢4：S3クロスリージョンレプリケーション（オブジェクトストレージ向け）
ユーザーアップロードファイルや静的アセットにはS3クロスリージョンレプリケーション（CRR）を有効化します。ソースバケットにアップロードされたオブジェクトは自動的に他リージョンの宛先バケットに複製されます。S3マルチリージョンアクセスポイント（MRAP）を活用すると、複製済みデータへの跨リージョンアクセスが簡素化されます。
►選択肢5：ElastiCache（キャッシュ無効化戦略）
各リージョンに独立したElastiCacheクラスターを配置します。課題は跨リージョンのキャッシュ同期で、1つのリージョンでデータが更新された際、他リージョンのキャッシュエントリを無効化する仕組みが必要です。代表的な実装手法は以下の2通りです。
データレイヤー比較表
| サービス | アクティブアクティブ書き込み対応 | 整合性モデル | RPO | 可用性SLA | 最適なワークロード |
|---|---|---|---|---|---|
| DynamoDBグローバルテーブル（MRSC） | 対応 | 強整合 | ゼロ | 99.999% | NoSQL、キーバリュー、RPOゼロ要件 |
| Auroraグローバルデータベース | 非対応（書き込み転送が必要） | 強整合 | 1秒未満 | 99.99% | リレーショナル、読み込み偏重業務 |
| Aurora DSQL | 対応 | 強整合（ACID準拠） | ゼロ | 99.999% | マルチリージョン書き込みを必要とするリレーショナル |
| S3 CRR | 該当なし | 結果整合 | 数分～数時間 | 99.99% | オブジェクトストレージ、ユーザーアップロード |
CloudFormationまたはTerraformを使用し、全リージョンに同一のインフラストラクチャをデプロイします。フェイルオーバー発生時、単独のリージョンで全グローバルトラフィックを処理できる規模に構成する必要があります。
# 全リージョンにデプロイするCloudFormationテンプレート
AWSTemplateFormatVersion: '2010-09-09'
Description: アクティブアクティブアプリケーションスタック
Parameters:
Region: {Type: String, AllowedValues: [us-east-1, eu-west-1]}
Resources:
AppAutoScalingGroup:
Type: AWS::AutoScaling::AutoScalingGroup
Properties:
MinSize: 2, MaxSize:10, DesiredCapacity:3
VPCZoneIdentifier: [!Ref PrivateSubnet1, !Ref PrivateSubnet2]
LaunchTemplate: {LaunchTemplateId: !Ref AppLaunchTemplate, Version: !GetAtt AppLaunchTemplate.LatestVersionNumber}
TargetGroupARNs: [!Ref AppTargetGroup]
AppLaunchTemplate:
Type: AWS::EC2::LaunchTemplate
Properties:
LaunchTemplateData:
ImageId: !FindInMap [RegionMap, !Ref "AWS::Region", AMI]
InstanceType: c5.xlarge
UserData:
Fn::Base64: !Sub |
#!/bin/bash
aws s3 cp s3://deploy-bucket/app-latest.tar.gz /opt/app/
cd /opt/app && tar xzf app-latest.tar.gz
export AWS_REGION=${AWS::Region}
export APP_ROLE=active
systemctl start myapp
ユーザーがリクエストごとにアクセス先リージョンを切り替える可能性があるため、セッション情報をグローバルに共有する必要があります。TTL24時間のDynamoDBグローバルテーブルを活用します。
import boto3, uuid, time
dynamodb = boto3.resource('dynamodb')
sessions_table = dynamodb.Table('global-sessions')
def create_session(user_id):
session_id = str(uuid.uuid4())
sessions_table.put_item(Item={
'session_id': session_id, 'user_id': user_id,
'created_at': int(time.time()), 'ttl': int(time.time()) + 86400
})
return session_id
def get_session(session_id):
response = sessions_table.get_item(Key={'session_id': session_id}, ConsistentRead=False)
return response.get('Item')
複数リージョンから同時に書き込みが発生するとデータ競合が生じます。実績のある3つの実装パターンを紹介します。
1. 最終書き込み優先（LWW）：DynamoDBグローバルテーブルの標準方式
2. リージョンアフィニティ：各ユーザーに固定のホームリージョンを割り当て、書き込みはホーム、読み取りは任意リージョンで実行
3. CRDT（衝突フリー複製データ型）：複数の更新内容を矛盾なく統合可能
DynamoDBグローバルテーブルやAurora DSQLといったAWSネイティブサービスはAWS環境内で優れたアクティブアクティブ機能を提供しますが、多くの企業ではAWS標準機能だけでは要件を満たせないケースが存在します。
運用負荷を抑えたい、または異種データベース間のレプリケーションが必要な場合は、Info2Softのi2Streamが有力な代替手段となります。
i2Streamはエンタープライズ向けデータベースレプリケーションソフトウェアで、同種・異種データベースに対応したリアルタイムデータ同期、災害復旧、マイグレーション、データ連携機能を提供します。AWSネイティブサービスがAWS環境内に限定されるのに対し、i2Streamはオンプレミス、AWS、他クラウドプロバイダーなど多様な環境に対応するよう設計されています。
i2Streamの主な機能：
AWSマルチリージョンアクティブアクティブアーキテクチャはAWSが提供する最高水準の耐障害性を実現します。キーバリュー型ワークロードにはDynamoDBグローバルテーブル、リレーショナルデータにはAuroraグローバルデータベースを起点に構築しましょう。Route 53で低遅延ルーティングを実装し、IaCで各リージョンに同一アプリスタックをデプロイ、ステートレスなアプリケーションを設計し、堅牢な競合解消ロジックを導入します。
また別の選択肢としてInfo2Softのi2Streamを活用してアクティブアクティブ構成を構築することもできます。リージョン間のデータ複製を簡単に実装でき、異種データベースプラットフォーム間のデータ同期にも対応します。
