0Pricing
Cloud & IT Cert Prep · レッスン

Global TablesとRoute 53によるマルチサイト・アクティブ-アクティブ

DynamoDB Global Tables、Aurora Global Database、Route 53のレイテンシーベースルーティングを使用して、2つ以上のリージョンで本番環境を同時にフル稼働させます。

「Global TablesとRoute 53によるマルチサイト・アクティブ-アクティブ」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。

マルチサイト・アクティブ-アクティブの定義

Multi-Site Active-Activeは、ディザスタリカバリの最上位の構成です。アプリケーションを2つ以上のAWSリージョンで同時に本番と同等のキャパシティで稼働させます。スタンバイ側が引き継ぐのを待つactive-passiveとは異なり、active-activeでは常に両方のリージョンが実際のユーザートラフィックを処理します。一方のリージョンに障害が発生すると、もう一方のリージョンが直ちにトラフィックの100%を引き受けるため、フェイルオーバーによる遅延はありません。また、世界中に分散したユーザーに対して最寄りのリージョンから応答することで、レイテンシーも低減できます。

# Active-Active traffic split (normal operation):
# us-east-1: serving ~50% of users (North America)
# eu-west-1: serving ~50% of users (Europe)

# Active-Active traffic split (us-east-1 failure):
# us-east-1: 0% (health check failed)
# eu-west-1: 100% (ASG scales up automatically)

# RTO: near-zero (DNS TTL propagation only)
# RPO: near-zero (with DynamoDB Global Tables)

DynamoDB Global Tablesのアーキテクチャ

DynamoDB Global Tablesは、active-activeアーキテクチャのデータ基盤です。Global Tablesではマルチマスター・マルチリージョンレプリケーションが可能です。どのリージョンのアプリケーションからでも、ローカルのDynamoDBテーブルに対して読み取りと書き込みを実行でき、変更は約1秒以内に他のすべてのリージョンへレプリケートされます。Global Tablesは、テーブルを配置するリージョンを指定して有効化します。すべてのレプリケーション、競合解決(last-writer-wins)、フェイルオーバーはAWSが自動的に処理します。

# Create DynamoDB table and add global regions
aws dynamodb create-table \
  --table-name UserSessions \
  --attribute-definitions AttributeName=userId,AttributeType=S \
  --key-schema AttributeName=userId,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

# Add replica regions for Global Table
aws dynamodb update-table \
  --table-name UserSessions \
  --replica-updates '[{"Create":{"RegionName":"eu-west-1"}},{"Create":{"RegionName":"ap-southeast-1"}}]' \
  --region us-east-1

書き込みアクティブ・読み取り対応のAurora Global Database

Aurora Global Databaseは、読み取りについてはactive-active、書き込みについてはactive-passiveを提供します。すべてのセカンダリリージョンが1秒未満のレプリケーション遅延で読み取りを処理しますが、書き込みを受け付けるのはプライマリリージョンだけです。これは、書き込みのプライマリを明確にしつつ、世界中で低レイテンシーの読み取りを実現したい、読み取り負荷の高いアプリケーションに適しています。プライマリでリージョン障害が発生した場合は、1分未満でセカンダリをプライマリに昇格できるため、書き込み層のRTOを短くできます。すべてのリージョンでactive-activeの書き込みをサポートするDynamoDB Global Tablesと比較してください。

# Aurora Global Database read configuration
# Primary region (us-east-1): reads + writes
# Secondary region (eu-west-1): reads only
#   ~100ms replication lag, serves EU users low-latency reads

# Application reads from local Aurora endpoint
# Application writes to primary region Aurora endpoint

# Java connection string with region routing:
# readEndpoint=eu-west-1.cluster-ro-xxx.aurora.amazonaws.com
# writeEndpoint=us-east-1.cluster-xxx.aurora.amazonaws.com

Active-ActiveのためのRoute 53ルーティング

Route 53は、マルチサイトactive-activeアーキテクチャのトラフィックを制御します。レイテンシーベースルーティングを使用して、各ユーザーを所在地からネットワークレイテンシーが最も低いリージョンへ送ります。各リージョンのレコードにヘルスチェックを関連付けます。リージョンのヘルスチェックが失敗すると、Route 53はそのリージョンをDNS応答から自動的に除外し、すべてのトラフィックを残りの正常なリージョンへ送ります。正常なリージョンへのフェイルオーバーにかかる時間を最小限にするため、DNSのTTLは60秒以下に設定してください。

# Route 53 latency routing with health checks
aws route53 change-resource-record-sets \
  --hosted-zone-id ZXXX \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "Region": "us-east-1",
          "SetIdentifier": "us-east-1",
          "HealthCheckId": "hc-us-east-1",
          "AliasTarget": {"DNSName": "alb-us-east-1.amazonaws.com", "EvaluateTargetHealth": false}
        }
      }
    ]
  }'

トラフィック吸収のためのAuto Scaling

active-active構成で一方のリージョンに障害が発生すると、残存するリージョンは通常の2倍以上のトラフィックを処理する必要があります。Auto Scaling Groupには、十分な最大キャパシティと、迅速に反応するスケールアウトポリシーを設定する必要があります。ALBのターゲットあたりのリクエスト数に基づくターゲット追跡スケーリングを設定し、トラフィックが倍増したときにASGが自動的にインスタンスを追加できるようにします。また、事前ウォームアップも検討してください。フェイルオーバー訓練中にASGのスケールアウト速度を確認し、RTOの目標時間内に必要なキャパシティへ到達できることを確認します。

# ASG target tracking for request count
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name app-asg-eu-west-1 \
  --policy-name scale-on-requests \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 1000,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/my-alb/xxx/targetgroup/my-tg/yyy"
    },
    "ScaleInCooldown": 60,
    "ScaleOutCooldown": 30
  }'

Active-Activeにおけるセッション管理

単一リージョンのアーキテクチャでは、ユーザーセッションをアプリケーションサーバー上にローカル保存できます。active-activeのマルチリージョン構成では、後続のリクエストが別のリージョンへ振り分けられる可能性があり、サーバー側のセッションが機能しなくなります。解決策は次のとおりです。1) ステートレスセッション — 署名付きJWTまたはCookieにセッションデータを保存し、どのリージョンのサーバーでも検証できるようにします。2) セッション用のDynamoDB Global Tables — セッションを一元的に保存し、どのリージョンからでもミリ秒単位でアクセスできるようにします。3) Global Datastoreを備えたElastiCache — セッション保存用にリージョン間でRedisをレプリケーションします。

# DynamoDB Global Table for session storage
# Session item structure:
{
  'sessionId': 'sess-abc123',
  'userId': 'usr-456',
  'data': {'cart': [...], 'preferences': {}},
  'expiresAt': 1750000000,
  'lastUpdatedRegion': 'us-east-1'
}

# Application reads from local region DynamoDB
# Writes replicate to all regions within ~1 second
# No sticky sessions needed on the ALB

書き込みの競合と解決

マルチマスター書き込みを使用するactive-active構成で最大の課題となるのは書き込みの競合です。異なるリージョンの2人のユーザーが同じレコードを同時に更新した場合、どちらの更新を採用すべきでしょうか。DynamoDB Global Tablesは、書き込みのタイムスタンプに基づくlast-writer-winsを使用します。これは多くのユースケースで適切に機能しますが、競合する更新(たとえば、2人のユーザーが同時にカウンターをインクリメントする場合)でデータが失われる可能性があります。条件付き書き込みを使用するか、リージョンごとにデータの所有権を分割し、異なるリージョンが同じ項目へ同時に書き込まないようにデータモデルを設計してください。

# Avoid conflicts with conditional writes
aws dynamodb update-item \
  --table-name UserProfiles \
  --key '{"userId":{"S":"usr-123"}}' \
  --update-expression 'SET profileVersion = profileVersion + :inc, username = :name' \
  --condition-expression 'profileVersion = :expectedVersion' \
  --expression-attribute-values '{
    ":inc":{"N":"1"},
    ":name":{"S":"newname"},
    ":expectedVersion":{"N":"5"}
  }'
# If another region already updated version, this fails gracefully

Active-ActiveにおけるS3レプリケーション

active-active構成でオブジェクトストレージを使用する場合は、双方向レプリケーションを備えたS3 Cross-Region Replication(バージョニングを有効にしたバケットで利用可能)を使用します。一方向のCRRとは異なり、双方向レプリケーションでは両リージョンのバケットが同期され、どちらかのリージョンに書き込まれたオブジェクトがもう一方へ自動的にレプリケートされます。これは、ユーザーがアップロードしたファイルをローカルリージョンのS3バケットに書き込みつつ、そのファイルをグローバルに利用できるようにする必要があるアプリケーションで重要です。Replication Time Control (RTC)を有効にすると、オブジェクトの99.99%が15分以内にレプリケートされることを保証できます。

# Bidirectional S3 replication
# Bucket A (us-east-1) replicates to Bucket B (eu-west-1)
# Bucket B (eu-west-1) replicates to Bucket A (us-east-1)

# Enable S3 RTC for guaranteed replication time
aws s3api put-bucket-replication \
  --bucket us-east-1-uploads \
  --replication-configuration '{
    "Rules": [{
      "Status": "Enabled",
      "ReplicationTime": {"Status": "Enabled", "Time": {"Minutes": 15}},
      "Metrics": {"Status": "Enabled", "EventThreshold": {"Minutes": 15}},
      "Destination": {"Bucket": "arn:aws:s3:::eu-west-1-uploads"}
    }]
  }'

マルチリージョンオリジンでのCloudFront

オリジングループを使用するCloudFrontで、自動フェイルオーバーに対応したactive-active CDNを構築できます。プライマリオリジン(us-east-1のALB)とセカンダリオリジン(eu-west-1のALB)を設定します。プライマリが5xxエラーを返すと、CloudFrontは自動的にセカンダリオリジンへフェイルオーバーします。S3から静的アセットを配信する場合は、双方向レプリケーションを設定した複数リージョンのS3バケットを指すオリジングループを構成します。これにより、Route 53のactive-activeルーティングに加えて、CDNレベルの耐障害性が得られます。

# CloudFront origin group for multi-region failover
aws cloudfront create-distribution \
  --distribution-config '{
    "Origins": {
      "Quantity": 2,
      "Items": [
        {"Id": "us-east-1", "DomainName": "alb-us-east-1.amazonaws.com"},
        {"Id": "eu-west-1", "DomainName": "alb-eu-west-1.amazonaws.com"}
      ]
    },
    "OriginGroups": {
      "Items": [{
        "Id": "multi-region-group",
        "FailoverCriteria": {"StatusCodes": {"Items": [500,502,503,504]}},
        "Members": {"Items": [{"OriginId": "us-east-1"},{"OriginId": "eu-west-1"}]}
      }]
    }
  }'

Active-Activeのヘルス監視

active-activeアーキテクチャでは、両方のリージョンが正常で、想定どおりにトラフィックが分散されていることを確認するため、堅牢な監視が必要です。主なメトリクスは、リージョンごとのRoute 53 HealthCheckPercentageHealthy、Global Tablesの遅延を示すDynamoDB ReplicationLatency、トラフィック分散を確認するためのリージョンごとのALB RequestCount、そして統合されたビューを提供するCloudWatchのクロスアカウント/クロスリージョンダッシュボードです。レプリケーション遅延がRPOのしきい値を超えた場合や、トラフィック分散が大きく偏った場合にアラームを設定してください。

# CloudWatch alarm for DynamoDB Global Table replication lag
aws cloudwatch put-metric-alarm \
  --alarm-name 'GlobalTable-ReplicationLag-eu-west-1' \
  --metric-name ReplicationLatency \
  --namespace AWS/DynamoDB \
  --dimensions Name=TableName,Value=UserSessions Name=ReceivingRegion,Value=eu-west-1 \
  --period 60 \
  --evaluation-periods 3 \
  --threshold 5000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123:ops-alerts

Active-Activeを選ぶべきケース

次のような場合、active-activeが適しています。ユーザーが世界中に分散しているため、単一リージョンへのレイテンシーが許容できない場合。RTOをほぼゼロにする必要があるため、ビジネス上、数分間の停止さえ許容できない場合。高い書き込みスループットが必要で、リージョン間で書き込みを分散する場合。規制要件によって国内でのデータ処理が義務付けられている場合です。他のDR層と比べてコストが大幅に高いため、ビジネス要件と経済性によって明確に正当化できる場合にのみactive-activeを選択してください。多くのワークロードでは、Warm Standbyで十分であり、はるかに低コストです。

# Active-Active justification checklist:
# [ ] Users in 2+ continents with latency SLAs
# [ ] RTO requirement < 5 minutes
# [ ] Revenue impact of downtime justifies 2x+ cost
# [ ] Data must remain within specific regions (regulations)
# [ ] Write throughput exceeds single-region capacity

# If fewer than 2-3 boxes checked:
# Consider Warm Standby instead (lower cost, adequate RTO)

クイックチェック

このレッスンで学んだAWS Solutions Architect (SAA-C03)の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、DynamoDB Global Tablesによってリージョン間のマルチマスター書き込みが可能になり、真のactive-activeを実現できること、Route 53のレイテンシールーティングとヘルスチェックによって、ユーザーを最寄りの正常なリージョンへ誘導できること、そしてactive-activeではセッション管理をステートレスにするか、グローバルにレプリケートされたストレージを使用する必要があることを学びました。active-activeはRTOとRPOをほぼゼロにできますが、コストは大幅に高くなります。次は、Well-Architected Frameworkのオペレーショナルエクセレンスとセキュリティの柱について学びます。

よくある質問

「Global TablesとRoute 53によるマルチサイト・アクティブ-アクティブ」レッスンは無料ですか?

はい。「Global TablesとRoute 53によるマルチサイト・アクティブ-アクティブ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Cloud & IT Cert Prepコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。

「Global TablesとRoute 53によるマルチサイト・アクティブ-アクティブ」で何を学びますか?

DynamoDB Global Tables、Aurora Global Database、Route 53のレイテンシーベースルーティングを使用して、2つ以上のリージョンで本番環境を同時にフル稼働させます。 ブラウザで直接実行するハンズオンコードでCloud & IT Cert Prepを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Cloud & IT Cert Prepを始めるのに経験は必要ですか?

事前経験は必要ありません。CoddyKitのCloud & IT Cert Prepは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。

「Global TablesとRoute 53によるマルチサイト・アクティブ-アクティブ」レッスンにはどのくらい時間がかかりますか?

ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このCloud & IT Cert Prepレッスンでコードを書いて実行できますか?

はい。すべてのCloud & IT Cert Prepレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. RTO、RPO、DRティア
  2. バックアップと復元
  3. パイロットライトとウォームスタンバイ
  4. Global TablesとRoute 53によるマルチサイト・アクティブ-アクティブ
← Cloud & IT Cert Prepに戻る