AWS DB本番運用Vol4｜Aurora DSQL×Limitless×DynamoDB強整合性

§1 なぜ Database Vol4 か — 2024-2025最新機能 + Database四部作ナビ

Database本番運用シリーズは、AWS 上でデータベースを本番運用するエンジニアが「今日から実装できる」状態を目標に積み上げてきた実践集だ。Vol1 で RDS / Aurora / DynamoDB の基礎運用を固め、Vol2 で DMS による移行と Aurora Global Database / DynamoDB Streams / AWS Backup を使ったグローバル展開戦略を学び、Vol3 で ElastiCache / DAX / MemoryDB を用いたキャッシュ三本柱を習得した。各巻は単体でも読めるが、特に Vol2 で学んだ Aurora Global Database と DynamoDB Global Tables の理解があると、Vol4 で解説する新機能との差分が明確になり、習得が速い。

Vol1〜3 が対象としてきたのは「既存サービスをいかに安定・効率的に運用するか」という問いだ。しかし、ユーザー規模がグローバル展開する段階や、トランザクション量が急増する局面では、Vol1〜3 で習得した運用パターンだけでは乗り越えられない「壁」がある。その壁を打ち砕くために AWS が 2024〜2025 年にかけて投入したのが、今回 Vol4 で扱う三つの最新機能だ。三機能はいずれも 2024〜2025 年に GA となったばかりであり、先進的な本番事例はまだ蓄積途上だ。本記事は公式ドキュメントを土台に、実装可能な設計パターンを凝縮して提供する。

1.1 Vol1〜3 で残ってきた三つの壁

壁1: Aurora の Active-Passive 書き込み制約

Vol2 で学んだ Aurora Global Database は、プライマリリージョンのみが書き込みを受け付ける Active-Passive 構成だ。セカンダリリージョンへの書き込みはフェイルオーバー後にしか実現しない。グローバルユーザーが同時に書き込みを行う EC サイトや SaaS では、書き込みリクエストをプライマリリージョンに集中させる必要があり、リージョン間レイテンシがボトルネックになる。また、フェイルオーバーは手動または自動であっても数十秒〜数分の切り替え時間がかかり、その間は書き込み不可状態が続く。

具体的な影響として、欧州から us-east-1（プライマリ）への書き込みでは 100ms 以上のレイテンシが加算される。ユーザーの体感応答時間が 200ms を超えると ECサイトでのコンバージョン率が低下するという研究知見があり、グローバル展開するサービスにとってリージョン間書き込みレイテンシは事業リスクだ。さらに「Managed Planned Failover」で RTO を数十秒程度に短縮できるが、フェイルオーバー中の書き込み停止は避けられない。

壁2: Aurora PostgreSQL の垂直スケール限界

Aurora PostgreSQL は強力なサービスだが、書き込みを処理するライターインスタンスは垂直スケール（インスタンスサイズ増強）に依存する。最大の db.r8g.48xlarge（公式ドキュメント参照）でも、ピーク時の書き込みスループットは物理的な上限がある。水平スケールを実現しようとすると、アプリケーション層に Sharding ロジックを自前実装する必要があり、設計・運用コストが膨大になる。

自前 Sharding 実装には「Sharding key 選定ミスによるデータ偏り」「クロスシャードトランザクションの複雑化」「スキーマ変更時の全シャード同期作業」「シャード追加時のデータリバランス」など多くの落とし穴がある。Sharding ロジックをアプリに埋め込むと、その後の機能追加ごとに Sharding 制約との整合性検証が必要になり、開発速度が著しく低下する。

壁3: DynamoDB Global Tables の Eventually Consistent 読み取り

Vol2 で扱った DynamoDB Global Tables は、リージョン間レプリケーション遅延（通常は数百ミリ秒〜数秒）の間、読み取った値が最新でない「Eventually Consistent」状態が発生する。在庫管理や金融残高など「読み取り値の正確性が収益に直結する」ユースケースでは、このレプリケーション遅延が致命的なデータ不整合を引き起こす可能性があった。

典型的な失敗パターンは「在庫カウント」だ。us-east-1 で残数 1 の商品を eu-west-1 から読んだ場合、レプリケーション遅延中は残数 2 が返り、複数注文が通ってしまう可能性がある。この問題を回避するためにアプリ側で「書き込みリージョンへの強制ルーティング」を実装するケースもあるが、それでは Global Tables の「読み取りを近いリージョンから行う」メリットが失われる。

1.2 AWS が 2024-2025 年に投入した三大最新機能

① Aurora DSQL — Active-Active Multi-Region 分散 SQL（2024 re:Invent 発表 / 2025 GA）

Aurora DSQL は PostgreSQL 16 互換のサーバーレス分散リレーショナルデータベースだ。壁1 を根本的に解決する機能として設計されており、両リージョンのエンドポイントから同時に読み書きが可能な Active-Active 構成を提供する。OCC（楽観的同時実行制御）で書き込み競合を自動解決し、ACID トランザクションと Strong Consistency を維持する。サーバーレスのため、コンピューティング・I/O・ストレージのすべてが自動スケールし、インフラ管理が不要だ。公式 SLA はシングルリージョン 99.99%、マルチリージョン 99.999% で、フェイルオーバーは完全自動化されている。

② Aurora Limitless — 自動水平スケール（GA 済み）

Aurora PostgreSQL Limitless Database は壁2 を解決する水平スケール機能だ。内部はトランザクションルーター層（SQL 解析・ルーティング担当）と DB シャード層（実データ保存担当）の二層構成で、SQL のルーティングキー列に基づいて適切なシャードへ自動ルーティングする。Shard group と Routing table の自動管理により、アプリケーションは既存の PostgreSQL 接続エンドポイントへ接続するだけで Limitless の恩恵を受けられる。Routing key を適切に設計することで書き込みが均等に分散し、垂直スケールの限界を超えたスループットを実現できる。

③ DynamoDB Multi-Region Strong Consistency — Global Tables v2 強整合性読み取り（GA 済み）

壁3 を解決する機能として Global Tables v2 に追加されたのが Multi-Region Strong Consistency だ。クロスリージョン Strong Read を有効にすることで、どのリージョンのエンドポイントからの読み取りも常に最新の書き込み結果を返す。従来の Eventually Consistent と比較して追加コストが発生するが、整合性要件が厳しいユースケースでは欠かせない選択肢になった。Strong Consistency の有効化は既存の Global Tables v2 テーブルに対して設定変更で行え、テーブル再作成を必要としない（詳細は公式ドキュメント参照）。

1.3 Vol1〜3 の積み上げと Vol4 の対象範囲

Database本番運用シリーズが積み上げてきた知識体系を、以下の表で整理する。

Vol1〜3 で構築した基盤（マルチ AZ / Global Database / キャッシュ）は引き続き有効だ。Vol4 の三機能は「その上にグローバルスケール特性を追加する」レイヤーと捉えると理解しやすい。例えば「Aurora DSQL で Active-Active 書き込みを実現しつつ、前段に ElastiCache（Vol3）を配置してキャッシュ層でレイテンシを最小化する」という組み合わせは実用的な本番設計だ。

1.4 Vol1〜3 で培ったパターンと Vol4 機能の関係性

Vol1〜3 で習得してきた設計パターンは Vol4 導入後も有効だ。Vol4 は「既存パターンの代替」ではなく「グローバルスケール要件が加わった際の拡張レイヤー」として位置付けると混乱が少ない。

具体的な組み合わせ例を挙げる。

パターン A: Aurora DSQL + ElastiCache (Vol3)

Aurora DSQL はトランザクション書き込みを Active-Active で処理し、頻繁に読み取られるデータ（商品マスタ / ユーザーセッション等）は ElastiCache (Valkey) でキャッシュする。DSQL の Active-Active でどのリージョンからも最新を書き込め、読み取りはキャッシュで高速化するハイブリッド構成。

パターン B: Aurora Limitless + DAX (Vol3)

Aurora Limitless で大規模書き込みをシャード分散処理し、DynamoDB の参照系データは DAX でキャッシュする。OLTP 書き込み量が多いゲームや EC でよく使われる構成。

パターン C: DynamoDB Multi-Region Strong + Streams (Vol2)

DynamoDB Global Tables v2 で Strong Consistency を有効にし、書き込み変更を DynamoDB Streams で検知してイベント駆動処理（Lambda）へ接続する。在庫管理 → 注文確定 → 請求処理の連鎖をリアルタイムに処理できる。

このように Vol1〜3 の知識を土台にして Vol4 の新機能を組み合わせることで、既存のアーキテクチャへ段階的にグローバルスケール特性を追加できる。

1.5 三機能の位置付けと適用レイヤー

三つの最新機能は、それぞれ独立した課題を解決するものであり、組み合わせて使うことも可能だ。以下の表で、どの技術が「どのレイヤーの課題」に対処するかを整理する。

3 機能は排他ではない。例えば「Aurora DSQL でトランザクション処理」しつつ「DynamoDB Multi-Region Strong でセッションデータを管理」するハイブリッド構成も実用的な選択肢だ。

1.6 なぜ今（2025年）が採用の転換点か

2024 年末〜2025 年にかけて三機能が GA となった意味は大きい。GA 以前のプレビュー段階では本番ワークロードへの適用は推奨されなかった。GA 到達により、AWS の SLA 保証（99.99%〜99.999% 可用性）が適用され、サポート契約の対象となり、Terraform / CDK / CloudFormation でのインフラコード管理が可能になった。

また、これらの機能は 2023 年以前の「先行する業界標準」に対する AWS 独自実装だ。CockroachDB や Google Spanner が先行して実装してきた分散 SQL や Active-Active トポロジーを、AWS マネージドサービスの文脈で利用できるようになったことを意味する。既存の AWS インフラ（IAM / VPC / CloudWatch / Organizations）とシームレスに統合できる点が、サードパーティ分散 SQL との最大の差別化要因だ。

実際の採用判断においては「GA から数ヶ月〜1 年程度」の時点が適切なタイミングになることが多い。GA 直後はドキュメント不足やエコシステム未整備が残るが、2025 年時点では Terraform Provider / AWS CDK 対応も進み、コミュニティの実績情報も蓄積されてきた。本記事で紹介する実装パターンは、公式ドキュメントと GA 後のベストプラクティスに基づいている。

1.7 本記事が対象とする読者

本記事は以下のいずれかの状況にあるチームを対象とする。

前提知識として Vol1 の基礎（RDS/Aurora/DynamoDB 基礎設計）の習得を推奨する。Vol2〜Vol3 の通読は有益だが必須ではない。

1.8 本記事の章立てと学習ロードマップ

Vol4 の三つの機能はそれぞれ独立したチャプターで解説するが、§5 の比較・選択基準を先に読んでから自分に関連するチャプターへ飛んでも構わない。急いでいる場合は §5 の判断フローを参照し、自分の課題に最も近い章（§2〜§4）を優先して読んだ後、§6〜§7 の演習で理解を定着させることを推奨する。

Vol4 習得後の期待成果

本記事を通読した後、以下のことができるようになることを目標とする。

• Aurora DSQL のピアクラスターを構成し、Python / boto3 で IAM トークンを生成して接続できる
• OCC コンフリクトを想定した Exponential Backoff 付きリトライロジックを実装できる
• Aurora Limitless の Shard group を設計し、Routing key を選定してシャード分散を最適化できる
• DynamoDB Global Tables v2 で Strong Consistency を有効化し、Cross-Region Strong Read を実装できる
• §5 の比較表を参照して「DSQL / Limitless / DDB Strong / 既存サービス」のうち最適な選択を行える
• §6 の詰まりポイント 7 選を参照し、本番トラブル発生時に迅速に根本原因を特定できる

Vol4 を読む前に確認しておきたいこと

本記事で扱う三機能はいずれも最新サービスであるため、実装時には以下を必ず確認すること。

1. 公式ドキュメントのバージョン確認: Aurora DSQL / Aurora Limitless / DynamoDB Multi-Region Strong はいずれも活発にアップデートされる。本記事執筆時点（2025年）の情報を基にしているが、新機能や仕様変更が加わっている可能性がある。
2. AWS リージョン対応確認: Aurora DSQL のマルチリージョンクラスターは特定のリージョンセット内でのみ利用可能。自社で使用するリージョンが対応範囲に含まれるか確認する。
3. Terraform プロバイダーバージョン確認: 新サービスのリソースは Terraform AWS プロバイダーの特定バージョン以降で対応する。実装前に必要なプロバイダーバージョンを確認する。

§2 からは三大テーマの筆頭、Aurora DSQL を詳解する。2024 re:Invent 発表・2025 GA の最新サービスであり、公式ドキュメント（Aurora DSQL User Guide）を随時参照しながら読み進めてほしい。

§2 Aurora DSQL 本番運用 — サーバーレス分散SQL × Active-Active Multi-Region × PostgreSQL互換

2.1 Aurora DSQL とは何か

Amazon Aurora DSQL は、2024 年 re:Invent で発表され 2025 年に一般提供（GA）されたサーバーレス分散リレーショナルデータベースサービスだ。トランザクションワークロードに最適化されており、ACID トランザクション・強整合性・スナップショット分離を保ちながら、従来の Aurora が抱えていた「シングルリージョン書き込み」の制約を根本から取り除いた。

公式の定義を引用すると、Aurora DSQL は “virtually unlimited scale” を実現するとともに、99.99% のシングルリージョン可用性と 99.999% のマルチリージョン可用性を提供する。インフラ管理が不要なサーバーレス構成のため、プロビジョニング・パッチ・メンテナンスウィンドウの設定を一切行わなくてよい。

従来の Aurora との主な違い

Aurora DSQL は Active-Active 書き込みと完全サーバーレスという点で従来の Aurora とは別物のサービスだ。既存の Aurora PostgreSQL クラスターをそのまま DSQL に移行できるわけではなく、新規クラスターを作成して移行する必要がある。アプリケーションの PostgreSQL 依存機能の互換性確認と OCC リトライ実装が移行の主な作業となる。

2.2 分散アーキテクチャの内部構造

Aurora DSQL の内部は、以下の四レイヤーで構成されるマルチテナント分散システムだ（公式ドキュメント参照）。

各レイヤーは 3 つの AZ にまたがって冗長化されており、コンポーネント障害が発生した場合も自動的にヘルシーなインフラへリクエストをリルートする。コントロールプレーンが四レイヤーを統括し、クラスター全体のスケーリングと自己修復を担う。

2.3 Active-Active Multi-Region 構成

Aurora DSQL のマルチリージョンは「ピアクラスター（Peered Clusters）」と呼ばれる構成を取る。2 つのリージョンにクラスターを配置してペアリングすると、両リージョンのエンドポイントが同一の論理データベースを提示し、両方のエンドポイントから同時に読み書きができる。

• 読み取り: どちらのリージョンエンドポイントからの読み取りも常に最新データを返す（Strong Consistency）
• 書き込み: 両リージョンへの書き込みが可能。書き込み競合は OCC で自動解決
• フェイルオーバー: 片方のリージョンが障害になった場合、もう一方のエンドポイントが自動的に引き継ぐ

マルチリージョンクラスターは同一リージョンセット内でのみ作成可能だ（例: us-east-1 + us-east-2 + us-west-2 の US セット、ap-northeast-1 + ap-northeast-2 + ap-northeast-3 の東アジアセット）。大陸をまたぐマルチリージョンクラスターは 2025 年時点では非対応なので注意が必要だ。

Aurora DSQL のエンドポイントは VPC 内部には存在しない。<cluster-id>.dsql.<region>.api.aws 形式の HTTPS エンドポイントに対して TLS で接続する。VPC から接続する際は VPC エンドポイントを利用する場合があるが、詳細は公式ドキュメントの Network access を参照のこと。これは従来の Aurora（VPC 内のプライベート IP で接続）とは異なるネットワークモデルだ。既存のセキュリティグループルールやネットワーク ACL の設計を見直す必要がある点に留意する。

ピアクラスター作成例（AWS CLI）

# リージョン1 にシングルクラスター作成
aws dsql create-cluster \
  --deletion-protection-enabled \
  --region us-east-1

# リージョン2 にシングルクラスター作成
aws dsql create-cluster \
  --deletion-protection-enabled \
  --region us-east-2

# 2クラスターをペアリングしてマルチリージョンクラスターを構成
aws dsql create-multi-region-clusters \
  --linked-region-list us-east-1 us-east-2 \
  --cluster-properties '{"us-east-1": {"deletionProtectionEnabled": true}, "us-east-2": {"deletionProtectionEnabled": true}}'

2.4 OCC（楽観的同時実行制御）の仕組みとコンフリクト対策

Aurora DSQL は書き込み競合の解決に OCC（Optimistic Concurrency Control）を採用している。OCC の基本原理は「ロックを取得せずにトランザクションを実行し、コミット時に競合を検出する」だ。

OCC のトランザクションフロー

1. Read Phase  : データを読み取り、変更内容をローカルに保持（ロック取得なし）
2. Commit Phase: 書き込みセットをコミット試行
3. Validation  : 他トランザクションが同一データをコミット済みかを検証
- 競合なし → コミット成功
- 競合あり → ロールバック（OCC conflict エラー）

Active-Active 環境で 2 リージョンから同一行に対して同時書き込みが発生した場合、どちらか一方がコミットに成功し、もう一方は OCC コンフリクトエラーを受け取る。アプリケーション側でリトライロジックを実装することが必須だ。

Python によるリトライ実装例

import psycopg2
import time

def execute_with_retry(conn_str, query, params, max_retries=5):
 for attempt in range(max_retries):
  try:
conn = psycopg2.connect(conn_str)
conn.autocommit = False
cur = conn.cursor()
cur.execute(query, params)
conn.commit()
return
  except psycopg2.errors.SerializationFailure:
conn.rollback()
if attempt < max_retries - 1:
 time.sleep(0.1 * (2 ** attempt))  # exponential backoff
else:
 raise
  finally:
conn.close()

OCC コンフリクトは書き込み競合率が高いワークロード（多数のクライアントが同一行を頻繁に更新）では発生頻度が上がる。リトライコストが問題になる場合はテーブル設計を見直し、書き込みが集中する Hot partition を分散させることが先決だ。

2.5 Terraform による Aurora DSQL クラスター構成

Aurora DSQL のシングルリージョンクラスターは、AWS CLI または Terraform の aws_dsql_cluster リソースで作成する。2025 年時点では Terraform の aws プロバイダー（v5.x 以降）に Aurora DSQL リソースが追加されている。詳細は 公式ドキュメント を確認のこと。

シングルリージョンクラスター（Terraform）

resource "aws_dsql_cluster" "primary" {
  deletion_protection_enabled = true

  tags = {
 Env = "production"
  }
}

output "cluster_endpoint" {
  value = aws_dsql_cluster.primary.endpoint
}

マルチリージョン（ピアクラスター）構成

マルチリージョンは aws_dsql_cluster_peering リソース（または aws dsql create-multi-region-clusters CLI）で構成する。Terraform リソース名は AWS プロバイダーのバージョンによって変わる可能性があるため、実装時は Terraform Registry — aws_dsql_cluster を参照のこと。

# マルチリージョンクラスターの作成（AWS CLI）
aws dsql create-multi-region-clusters \
  --linked-region-list us-east-1 us-east-2 \
  --cluster-properties '{
 "us-east-1": {"deletionProtectionEnabled": true},
 "us-east-2": {"deletionProtectionEnabled": true}
  }'

上記コマンドは両リージョンのクラスターを同時に作成してピアリングする。クラスター ID と各リージョンのエンドポイントが JSON で返されるので、アプリケーションの接続先として設定する。

2.6 PostgreSQL 互換 — 既存ライブラリをそのまま利用

Aurora DSQL は PostgreSQL 16 互換の Wire Protocol を採用している。psql / DBeaver / JetBrains DataGrip など標準 PostgreSQL ツールで接続でき、Python の psycopg2 / Java の JDBC / Go の pgx などのドライバーもそのまま利用可能だ。

接続パラメータのマッピングは以下の通り（公式ドキュメントより）。

ただし、PostgreSQL の全機能が利用可能なわけではない。分散アーキテクチャの制約により一部 DDL や機能に制限がある。主な非互換点は以下の通り（詳細は SQL feature compatibility 参照）。

• SEQUENCE: 分散環境でのシーケンス整合性に制約がある
• FOREIGN KEY: クロスシャードの外部キー制約は非対応（2025 年時点）
• 拡張機能（Extension）: すべての PostgreSQL Extension が利用可能なわけではない
• 一部の DDL: 分散トランザクション内での一部の DDL 操作に制限あり

既存の Aurora PostgreSQL アプリケーションを DSQL に移行する場合は、上記の非互換点を事前に洗い出し、影響範囲を確認することが必須だ。

2.7 接続・認証 — IAM 認証トークンの生成

Aurora DSQL は長期パスワードを受け付けない。代わりに IAM 認証トークン（AWS Signature Version 4 で署名された一時トークン）を使用する。

Python + boto3 でのトークン生成と接続

import boto3
import psycopg2

def get_dsql_token(cluster_endpoint, region):
 client = boto3.client("dsql", region_name=region)
 # デフォルト有効期間: 900秒(15分) / 最大: 7日
 token = client.generate_db_connect_admin_auth_token(
  hostname=cluster_endpoint,
  region=region,
  expiresIn=900
 )
 return token

cluster_endpoint = "<cluster-id>.dsql.us-east-1.api.aws"
region = "us-east-1"
token = get_dsql_token(cluster_endpoint, region)

conn = psycopg2.connect(
 host=cluster_endpoint,
 port=5432,
 dbname="postgres",
 user="admin",
 password=token,
 sslmode="require"
)

トークンの有効期間は最大 7 日まで設定できるが、セキュリティ上は短い有効期間（15〜60 分程度）を推奨する。既存セッションはトークン有効期間が切れても継続するが、新規接続時には新しいトークンが必要だ。

接続プールと IAM トークン更新の注意点

Aurora DSQL は長期パスワードを持たないため、接続プール（PgBouncer / RDS Proxy 等）との組み合わせは注意が必要だ。接続プールが内部で保持する接続は既存セッションとして継続するが、プールを再起動したり新規接続を追加する際にはその時点で有効なトークンが必要になる。

実装上は「接続プールの設定ファイルに IAM トークンを直書き」するのではなく、起動スクリプトまたは環境変数でトークンを動的に生成する設計を取ることを推奨する。有効期間 15 分のトークンを使う場合、プールの接続確立タイミングとトークン生成タイミングを合わせるスクリプトが必要になる。Lambda や ECS Task のような短命なコンピューティングでは、起動ごとにトークンを取得する設計が最もシンプルだ。

2.8 DPU 課金モデル

Aurora DSQL はサーバーレスのため、DPU（Database Processing Unit）ベースの従量課金だ。コンピューティング（DPU 時間）、ストレージ、ネットワーク（クロスリージョン転送）が独立して課金される。アイドル状態ではコンピューティング料金が発生しないため、リクエストが散発的なマイクロサービスや Event-Driven アーキテクチャとの相性が良い。

最新の料金は Aurora DSQL 料金ページ を参照すること（価格は変動するため本記事では具体的な数値を記載しない）。

DPU 課金の注意点

DPU はトランザクション処理量に応じて消費される。アイドル時のコスト最小化は容易だが、OCC コンフリクト発生時にリトライを繰り返すと DPU 消費が想定以上に増える。コンフリクト率が高い場合は単純にリトライを増やすのではなく、テーブル設計を見直してコンフリクト自体を減らすことがコスト最適化の近道だ。マルチリージョン構成ではクロスリージョンネットワーク転送料金が別途発生する点にも注意する。

2.9 CloudWatch による DSQL 監視

Aurora DSQL の本番運用では、以下のメトリクスを CloudWatch で監視することを推奨する（利用可能なメトリクスは公式ドキュメント Aurora DSQL Monitoring を参照）。

CloudWatch Alarm 設定例（AWS CLI）

aws cloudwatch put-metric-alarm \
  --alarm-name "dsql-occ-conflict-high" \
  --metric-name "OCCConflicts" \
  --namespace "AWS/DSQL" \
  --statistic Sum \
  --period 60 \
  --threshold 100 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 2 \
  --alarm-actions "arn:aws:sns:us-east-1:123456789012:dsql-alerts"

メトリクス名や名前空間は Aurora DSQL の GA 以降、公式ドキュメントで更新される可能性があるため、実装前に CloudWatch メトリクス一覧 を確認すること。

§3 では Aurora Limitless へ移る。巨大なシングル Aurora インスタンスの書き込みスループット限界に直面したチームが、アプリ改修なしで水平スケールを実現する手法を解説する。

§3 Aurora Limitless 本番運用 — Shard group × Routing table × 自動水平スケール ★山場1

Aurora PostgreSQL Limitless Database は Aurora PostgreSQL の書き込みスループット制約を取り除く水平スケール拡張機能で、2024 年に GA となった。従来の Aurora PostgreSQL では単一の Writer インスタンスが書き込みのボトルネックになっていたが、Limitless は分散 SQL エンジンを採用し、複数の Aurora インスタンス（シャード）へ透過的に書き込みを分散する。アプリケーションは既存の PostgreSQL 接続ライブラリ（libpq / psql / ORM）をそのまま利用でき、DB クラスターエンドポイントへの接続だけで Limitless の恩恵を受けられる。

3.1 Aurora Limitless の基本アーキテクチャ

Aurora Limitless Database はルーター層とシャード層の二層構成をとる。

クライアントは DB クラスターエンドポイントへ接続する。Route 53 がルーターへ振り分け、ルーターが SQL のシャードキー列を解析して適切なシャードへクエリを転送する。個々のシャードやルーターは AWS アカウント上には表示されず、DB shard group として一括管理される。

ルーターへの接続分散を改善するには AWS JDBC Driver の Limitless Connection Plugin を導入する。Route 53 のみでは接続が偏る場合があるため、高トラフィック本番環境では必須の設定だ。

シャードとルーターの分布は次の SQL で確認できる。

SELECT * FROM rds_aurora.limitless_subclusters;

3.2 DB Shard Group — 構成と Capacity 設計

DB Shard Group はシャードとルーターの集合体を管理する論理単位だ。作成時に指定する max-acu (Aurora Capacity Units) がシャード数とルーター数を決定する。

max-acu の有効範囲は 16〜6,144 ACU で、シャードグループ作成後は変更不可だ。本番投入前に十分な余裕を持った値を設定すること。compute-redundancy を 1 または 2 に設定すると各シャードにスタンバイが追加され、コストとシャード数が 2〜3 倍になる点に注意する。

CLI でのクラスターおよびシャードグループ作成例:

# Aurora PostgreSQL Limitless クラスターを作成
aws rds create-db-cluster \
  --db-cluster-identifier my-limitless-cluster \
  --engine aurora-postgresql \
  --engine-version 16.6-limitless \
  --storage-type aurora-iopt1 \
  --cluster-scalability-type limitless \
  --master-username admin \
  --master-user-password 'YourPassword!' \
  --enable-performance-insights \
  --performance-insights-retention-period 31 \
  --monitoring-interval 5 \
  --monitoring-role-arn arn:aws:iam::123456789012:role/rds-monitoring-role \
  --enable-cloudwatch-logs-exports postgresql \
  --region ap-northeast-1

# DB Shard Group を作成 (max-acu は作成後変更不可)
aws rds create-db-shard-group \
  --db-shard-group-identifier my-shard-group \
  --db-cluster-identifier my-limitless-cluster \
  --max-acu 1000 \
  --compute-redundancy 1 \
  --region ap-northeast-1

作成が完了するとエンドポイントが払い出される。デフォルトデータベース名は postgres_limitless だ。

# 接続確認
psql -h my-limitless-cluster.limitless-ckifp.ap-northeast-1.rds.amazonaws.com \
  -p 5432 -U admin -d postgres_limitless

エンジンバージョン要件: 16.4-limitless または 16.6-limitless を指定する。通常の 16.6 は使用不可。また --storage-type aurora-iopt1 (Aurora I/O-Optimized) が必須で、これ以外のストレージタイプは指定できない。

3.3 テーブル種別とルーティングの仕組み

Aurora Limitless には 4 種類のテーブルがある。

Reference table は全シャードへ複製されるためシャード増加に伴いストレージが増加する。頻繁に更新される大きなテーブルを Reference table にすることは避ける。

ルーターは SQL の WHERE 句のシャードキー列を解析し、対象シャードを特定して転送する。クロスシャードクエリ（複数シャードにまたがる JOIN や集計）は全シャードを走査するため、OLTP 用途では設計上なるべく避けるのが原則だ。

3.4 シャードキー設計 — 偏りを防ぐ選定基準

シャードキーは Limitless 設計の最重要判断だ。一度決定したシャードキーは変更不可であり、変更する場合はテーブルの再作成とデータ移行が必要になる。

良いシャードキーの三条件:

シャードキーが偏っていると、ホットシャード（特定シャードへの負荷集中）が発生する。Limitless はシャードを自動分割できるが、シャードキーのカーディナリティ不足が原因の偏りは分割しても解消されない。シャード分布は次のクエリで監視する。

-- シャードごとの行数を確認 (3倍以上の偏りは要対処)
SELECT
  _rds_shard_idAS shard_id,
  count(*)  AS row_count
FROM orders
GROUP BY 1
ORDER BY 2 DESC;

3.5 スケーリング動作 — ノードレベルのスケールアップ/ダウン

Aurora Limitless のスケーリングはシャードやルーターのノード単位で行われる。シャードの追加（Split）は自動または手動で実施できるが、シャードのマージ（削減）はサポートされていない。

スケーリングオプションは DB クラスターパラメータ rds_aurora.limitless_auto_scale_options で制御し、add_router / split_shard / 両方を指定できる。

容量変更 CLI (min-acu / max-acu のみ変更可、ノード数は変わらない):

aws rds modify-db-shard-group \
  --db-shard-group-identifier my-shard-group \
  --min-acu 100 \
  --max-acu 2000

3.6 既存 Aurora から Limitless への移行パス

既存の Aurora PostgreSQL を Limitless へ段階移行する場合、新しい Limitless クラスターをサイドカーとして構築し、データをロードしてから切り替える方式が標準だ。Aurora Global Database は Limitless ではサポートされていないため、グローバル展開中のクラスターは移行計画を別途設計すること。

移行の全体フロー:

フェーズ1: 事前分析
  - 大テーブルと書き込み多発テーブルを洗い出す
  - シャードキー候補を絞り込む (COUNT(DISTINCT col) で分布確認)
  - RDS Proxy を使用中の場合は別の接続プールに切り替える計画を立てる
 (Limitless は RDS Proxy 非対応)

フェーズ2: Limitless クラスター構築
  - 新規 Aurora PostgreSQL Limitless クラスターを作成
  - DB Shard Group を作成 (max-acu は余裕を持って設定)
  - ターゲットスキーマ・テーブルを Limitless クラスター側に作成

フェーズ3: データロード
  - pg_dump / aws_s3 拡張 / AWS DMS 等でソースから Limitless へ初期データ投入
  - 差分は Logical Replication または変更キャプチャで追従
  - レプリケーション遅延が 0 秒近くになるまで同期を継続

フェーズ4: 切り替え
  - アプリのメンテナンスウィンドウを設け、旧クラスターへの書き込みを停止
  - アプリの接続先を Limitless エンドポイントへ切り替え
  - 接続・書き込みを確認後、メンテナンスウィンドウを解除

フェーズ5: クリーンアップ
  - 数日間問題がなければ旧クラスターを縮小または削除

注意: AWS Backup は Limitless ではサポートされていない。バックアップは Aurora 自動バックアップ（RTO は Shard Group 単位）に依存する。バックアップ戦略を移行前に確認すること。

3.7 IaC 対応状況 (2025 年時点)

Terraform については aws プロバイダーで対応が進んでいるが、一部のパラメータが CLI と乖離している場合があるため、Console または CLI で動作を確認してから IaC 化する運用が安全だ。

CloudFormation での Shard Group 定義例:

LimitlessCluster:
  Type: AWS::RDS::DBCluster
  Properties:
 Engine: aurora-postgresql
 EngineVersion: "16.6-limitless"
 StorageType: aurora-iopt1
 ScalabilityType: limitless
 MasterUsername: !Ref MasterUsername
 MasterUserPassword: !Ref MasterUserPassword
 EnableCloudwatchLogsExports:
- postgresql
 MonitoringInterval: 5
 MonitoringRoleArn: !GetAtt RDSMonitoringRole.Arn
 EnablePerformanceInsights: true
 PerformanceInsightsRetentionPeriod: 31

LimitlessShardGroup:
  Type: AWS::RDS::DBShardGroup
  Properties:
 DBShardGroupIdentifier: my-shard-group
 DBClusterIdentifier: !Ref LimitlessCluster
 MaxACU: 1000
 ComputeRedundancy: 1

3.8 主要 CloudWatch メトリクスと監視設計

Aurora Limitless は Enhanced Monitoring と Performance Insights の有効化が必須要件だ。本番運用で監視すべき主要メトリクスを整理する。

Performance Insights では rds_aurora.limitless_subclusters の View を活用し、シャードごとのスロット占有率と遅延を可視化できる。

§3 では Aurora Limitless の Shard group 設計から Routing 動作、テーブル種別の使い分け、スケーリング動作、既存 Aurora からの移行パスまで体系的に解説した。次の §4 では、DynamoDB の Multi-Region Strong Consistency — Global Table v2 のクロスリージョン Strong reads と Write routing を取り上げ、NoSQL 領域での強整合性本番運用パターンに踏み込む。

§4 DynamoDB Multi-Region Strong Consistency 本番運用 — Strong reads cross-region × Global Table v2 × Write routing ★山場2

DynamoDB Global Tables v2 (Version 2019.11.21) は複数 AWS リージョンにわたる Active-Active レプリケーションを提供するマネージドサービスだ。2024年に正式 GA となった Multi-Region Strong Consistency 対応により、クロスリージョン読み取りでも強整合性が保証できるようになった。従来の Eventually Consistent モデルでは「書込み後のレプリカ伝播に数秒かかる」前提のアプリ設計が必要だったが、Strong Consistency 対応により金融トランザクション・グローバル在庫管理など整合性優先ワークロードにも Global Tables が本番適用可能となった。

Global Tables v2 が旧バージョン v1 (Version 2017.11.29) と異なる主な点は次のとおりだ。DynamoDB Streams / PITR / On-Demand Backup / Contributor Insights が全レプリカで利用可能になり、コンフリクト解決の精度も向上している。さらに v2 では Terraform や CloudFormation で宣言的に管理できる専用リソースタイプが提供されており、IaC による再現性が担保される。本番環境では必ず Version 2019.11.21 で作成すること。

4.1 Global Tables v2 の仕組み — Multi-region レプリケーション + 書込ルーティング

DynamoDB Global Tables v2 のレプリケーション基盤は DynamoDB Streams を内部的に使用する。各リージョンのレプリカテーブルに書込まれた変更が Streams に乗り、非同期で全レプリカへ伝播する。このプロセスはフルマネージドで提供されるため、Lambda によるカスタムレプリケーション実装や Streams 管理は不要だ。

レプリカ間レイテンシは通常 1〜2 秒程度で、CloudWatch メトリクス ReplicationLatency で定量的に監視できる。このレイテンシが経過する前に他リージョンから読み取りを行うと書込み前の古い値が返る — これが Eventually Consistent の動作だ。Strong Consistency を有効にする場合、このレプリカ間レイテンシの存在を考慮した書込ルーティング設計が最も重要なポイントとなる。

書込ルーティングはアーキテクチャの整合性要件に応じて次の2パターンから選択する:

パターン A — Write-One / Read-Any (Primary 集中書込):
  すべての書込み → Primary リージョン (例: us-east-1) に集中
  各リージョンから ConsistentRead=true で読み取り
  コンフリクト発生ゼロ / Strong Consistency が最も安定
  推奨: 金融残高・在庫カウント・整合性優先データ

パターン B — Active-Active (全リージョン書込):
  各リージョンが独立して書込み / 読み取りは Eventually Consistent が基本
  コンフリクトは last-writer-wins で解決 (同一アイテム同時書込み時)
  最高スループット / 整合性より可用性・速度を優先するワークロード向け
  推奨: SNS タイムライン・セッションデータ・キャッシュ用途

Conflict Resolution — last-writer-wins の本番的意味:
複数リージョンが同一パーティションキーのアイテムを同時に書込んだ場合、DynamoDB はタイムスタンプが最新の書込みを最終値として採用する。ただしタイムスタンプ比較は各リージョンのローカルクロックを基準とするため、クロック同期のわずかなズレが原因で予期しない値が確定するリスクがある。残高管理・在庫減算など競合が業務上許容できないデータでは必ずパターン A を採用し、書込みを1つのリージョンに集約すること。

4.2 Strong Consistency Reads — ConsistentRead=true の制約と設計指針

DynamoDB の ConsistentRead=true パラメーターを指定すると、読み取りリクエストを受けたリージョンのローカルレプリカが最新の確定済み書込みを返すことを保証する。Global Tables v2 では全レプリカリージョンで ConsistentRead=true が利用可能だ。ただし以下の重要な制約を理解した上で使用すること。

制約1 — RCU コスト 2倍:
Eventually Consistent 読み取りが 1 RCU / 4KB であるのに対し、Strong Consistency 読み取りは 2 RCU / 4KB を消費する。毎秒10万件の読み取りが発生するテーブルに全面適用すると読み取りコストが倍増する。DAX (DynamoDB Accelerator) と組み合わせ、Strong Consistency 読み取りの対象を業務上必須のデータのみに絞るコスト最適化設計が重要だ。

制約2 — TransactGetItems / TransactWriteItems はシングルリージョン:
TransactGetItems / TransactWriteItems は単一リージョン内での ACID トランザクションを保証する API だ。クロスリージョントランザクションは DynamoDB では非サポートであり、複数リージョンにまたがる分散トランザクションが必要な場合は、アプリケーション層で Saga パターンを実装するか、書込みを Primary リージョンに集約して単一リージョンの Transactions API を活用すること。

制約3 — Global Table v2 が前提:
Strong Consistency reads は Version 2019.11.21 で作成された Global Table にのみ適用可能。旧バージョン (Version 2017.11.29) は非対応。既存の v1 テーブルを使用している場合は、データ移行を伴う v2 テーブルへの再作成が必要となる。AWS Console の移行ウィザード、または AWS DMS を用いた段階移行を計画すること。

制約4 — Conditional Writes のクロスリージョン制限:
ConditionExpression (例: attribute_not_exists(pk)) を使った条件付き書込みは、ローカルリージョン内の整合性のみを保証する。他リージョンで同時発生した書込みに対して Condition が適用されないため、競合排除が必要なデータは Primary リージョンへの書込み集中が必須となる。

4.3 書込制約と本番設計パターン — ユースケース別配線

以下に、業務ケース別の書込・読取パターンを示す:

ケース1: グローバル金融残高 (整合性最優先)
  書込: us-east-1 (Primary) に集中
  UpdateItem + ConditionExpression で残高チェック + 原子的更新
  読取: 全リージョンで ConsistentRead=true
  効果: どのリージョンのユーザーも最新残高を参照 / コンフリクトゼロ

ケース2: グローバル EC 在庫管理 (在庫減算)
  書込: ap-northeast-1 (Primary) に集中
  UpdateItem + ConditionExpression (quantity > :zero)
  読取: 各リージョンで ConsistentRead=true
  注意: 在庫ゼロ判定は Primary のみで実施 / レプリカは参照専用に限定

ケース3: グローバル機能フラグ / 設定ストア (read-heavy)
  書込: us-east-1 (Primary) / 更新は稀 (1日数回)
  読取: 全リージョンで ConsistentRead=true / DAX を前段に配置
  メリット: 書込みが稀なためレプリカ伝播待ちが問題にならない
  Strong Consistency × DAX でコストを抑えながら整合性確保

4.4 CloudFormation / Terraform 対応状況と IaC 設計

Terraform での Global Tables v2 設定例:

resource "aws_dynamodb_table" "global_table" {
  name  = "GlobalInventory"
  billing_mode= "PAY_PER_REQUEST"
  hash_key = "pk"
  range_key= "sk"

  attribute {
 name = "pk"
 type = "S"
  }

  attribute {
 name = "sk"
 type = "S"
  }

  stream_enabled= true
  stream_view_type = "NEW_AND_OLD_IMAGES"

  replica {
 region_name= "us-west-2"
 point_in_time_recovery = true
  }

  replica {
 region_name= "ap-northeast-1"
 point_in_time_recovery = true
  }

  point_in_time_recovery {
 enabled = true
  }

  server_side_encryption {
 enabled  = true
 kms_key_arn = aws_kms_key.dynamodb_global.arn
  }

  tags = {
 Environment = "production"
 DataClass= "critical"
  }
}

CloudFormation での Global Table 設定例:

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  GlobalInventoryTable:
 Type: AWS::DynamoDB::GlobalTable
 Properties:
TableName: GlobalInventory
BillingMode: PAY_PER_REQUEST
AttributeDefinitions:
  - AttributeName: pk
 AttributeType: S
  - AttributeName: sk
 AttributeType: S
KeySchema:
  - AttributeName: pk
 KeyType: HASH
  - AttributeName: sk
 KeyType: RANGE
StreamSpecification:
  StreamViewType: NEW_AND_OLD_IMAGES
Replicas:
  - Region: us-east-1
 PointInTimeRecoverySpecification:
PointInTimeRecoveryEnabled: true
 ContributorInsightsSpecification:
Enabled: true
  - Region: ap-northeast-1
 PointInTimeRecoverySpecification:
PointInTimeRecoveryEnabled: true
  - Region: eu-west-1
 PointInTimeRecoverySpecification:
PointInTimeRecoveryEnabled: true

IaC で管理可能な項目 (Terraform / CloudFormation 両対応):
– Global Table 作成 + レプリカリージョンの追加・削除
– Billing Mode (PAY_PER_REQUEST / PROVISIONED)
– Auto Scaling (Provisioned モード時の ReadCapacityUnits / WriteCapacityUnits)
– Point-in-Time Recovery (PITR) 有効化
– DynamoDB Streams 設定 (NEW_AND_OLD_IMAGES)
– KMS 暗号化キー指定 / Tags / TTL 設定

手動設定が必要な項目 (IaC 外):
– テーブルバージョンの移行 (v1 → v2): コンソールまたは CLI の専用ウィザードを使用。インプレース変換は不可。データ移行を伴う再作成が必要
– CloudFormation スタック作成リージョン制約: AWS::DynamoDB::GlobalTable はスタックをデプロイするリージョンが Replicas リストに含まれていなければならない
– 既存 Global Table への新規リージョン追加後の初期同期確認: apply 後に AWS Console で同期ステータスを確認すること

AWS CLI でのレプリカ追加と Strong Consistency 読み取り確認例:

# レプリカリージョンの追加
aws dynamodb update-table \
  --table-name GlobalInventory \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]' \
  --region us-east-1

# Strong Consistency での読み取り動作確認
aws dynamodb get-item \
  --table-name GlobalInventory \
  --key '{"pk": {"S": "inv#001"}, "sk": {"S": "stock"}}' \
  --consistent-read \
  --region ap-northeast-1

# ReplicationLatency のモニタリング (CloudWatch)
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ReplicationLatency \
  --dimensions Name=TableName,Value=GlobalInventory \
Name=ReceivingRegion,Value=ap-northeast-1 \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-01T01:00:00Z \
  --period 300 \
  --statistics Average \
  --region us-east-1

4.5 ユースケース — 整合性優先 + グローバル展開の本番シナリオ

金融サービス (決済 / 残高管理):
グローバル決済プラットフォームでは、残高更新後に同リージョンの別プロセスが残高を参照する際、古い値が読み取られると二重払いや残高誤表示のリスクが生じる。Strong Consistency 対応により書込み直後でも正確な最新残高を全リージョンから参照できる。書込みは Primary リージョン (例: us-east-1) に集中させ、各リージョンの読み取りに ConsistentRead=true を指定する構成が標準パターンだ。

グローバル在庫管理 (EC / 倉庫管理):
多地域のユーザーが同じ在庫データを参照する EC プラットフォームでは、在庫減算の競合回避が売り過ぎ防止に直結する。在庫更新は Primary リージョンへの Conditional Write (ConditionExpression: quantity > :zero) で実装し、在庫参照には ConsistentRead=true を使用する。注文確定時の在庫引当ロジックを Primary に集中させることで、世界中からの同時注文に対して正確な在庫管理が実現できる。

整合性優先 read-heavy ワークロード (機能フラグ / 設定ストア):
全リージョンのアプリが参照するグローバル設定ストアや Feature Flag は「更新は稀、読み取りは高頻度」のパターンを持つ。書込みが少ないためレプリカ伝播の待機問題が発生しにくく、Strong Consistency によって全リージョンのアプリが常に最新の設定値を取得できる。DAX を前段に配置してキャッシュすることでさらに RCU コストを削減可能だ。機能フラグの即時反映が求められるカナリアリリースやブルーグリーンデプロイでも有効なパターンとなる。

DynamoDB Global Tables v2 公式ドキュメント

4.6 監視・アラート設計 — ReplicationLatency 基点の本番体制

DynamoDB Global Tables v2 を本番運用するにあたり、監視の中心となるのは ReplicationLatency メトリクスだ。このメトリクスがベースラインを超え始めると、Strong Consistency 読み取りの前提 (「書込みはレプリカに伝播済み」) が崩れるリスクが高まる。以下の CloudWatch アラーム設計を出発点として本番監視体制を構築すること。

監視すべき主要メトリクス:

CloudFormation での CloudWatch アラーム定義例:

ReplicationLatencyAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
 AlarmName: GlobalTable-ReplicationLatency-High
 AlarmDescription: DynamoDB Global Table replication latency exceeded threshold
 Namespace: AWS/DynamoDB
 MetricName: ReplicationLatency
 Dimensions:
- Name: TableName
  Value: GlobalInventory
- Name: ReceivingRegion
  Value: ap-northeast-1
 Statistic: p99
 Period: 60
 EvaluationPeriods: 3
 Threshold: 5000
 ComparisonOperator: GreaterThanThreshold
 TreatMissingData: notBreaching
 AlarmActions:
- !Ref AlertSNSTopic

コスト試算の具体例 — Strong Consistency 適用前後の比較:

前提: グローバル EC 在庫管理テーブル
  - 月間読み取り: 10億リクエスト (アイテムサイズ 4KB)
  - 月間書込み: 5,000万リクエスト
  - リージョン: us-east-1 (Primary) + ap-northeast-1 + eu-west-1

Eventually Consistent 読み取りのコスト:
  RCU = 10億 × 1 RCU = 10億 RCU
  → us-east-1: $0.25/100万 RCU × 1,000 = $250/月

Strong Consistency 読み取りのコスト:
  RCU = 10億 × 2 RCU = 20億 RCU
  → us-east-1: $0.25/100万 RCU × 2,000 = $500/月
  → 差額: +$250/月

DAX 活用で Strong Consistency を Read-Through キャッシュ化した場合:
  キャッシュヒット率 80% → Strong Consistency 読み取りは 20% のみ
  実効 RCU = 10億 × 0.2 × 2 RCU = 4億 RCU = $100/月
  DAX インスタンスコスト: dax.r6g.large × 3ノード ≈ $300/月
  合計: $400/月 (Eventually Consistent の $250 より +$150 だが、整合性保証付き)

このコスト試算を基に、Strong Consistency が業務価値 (売り過ぎ防止・残高誤表示ゼロ) に対して ROI が取れるかを評価してから採用判断すること。

§4 では DynamoDB Global Tables v2 の Strong Consistency 本番設計パターンと IaC 実装を解説した。続く §5 では Aurora Global / Aurora DSQL / Aurora Limitless / DynamoDB Global の4機能を横断比較し、ユースケース別選択基準をフレームワーク化する。

§5 比較・選択基準 — Aurora Global vs DSQL / Limitless vs Sharding / DynamoDB Global vs Strong

Vol4 で扱った三つの最新機能 (Aurora DSQL / Aurora Limitless / DynamoDB Multi-Region Strong Consistency) は、それぞれ異なる課題領域を解決する。本章では既存技術 (Aurora Global Database / 手動シャーディング / DynamoDB Eventually Consistent Global Tables) との比較を軸にユースケース別の選択フレームワークを提示する。

5.1 比較1: Aurora Global Database vs Aurora DSQL — Active-Passive vs Active-Active

Aurora Global Database (既存技術)は Primary クラスター (読み書き可) に対して最大5つの Secondary クラスター (読み取り専用) を持つ構成だ。Primary リージョン障害時のフェイルオーバーは通常 1分以内 (RPO は通常 1秒未満) だが、フェイルオーバー後の Secondary への昇格は手動操作または Managed Planned Failover API が必要だ。書込みは常に Primary に集中し、Secondary はリードレプリカとして機能する。

Aurora DSQLは全リージョンが Active となる Active-Active 構成を採用し、すべてのリージョンから書き込みと読み取りが可能だ。Optimistic Concurrency Control (OCC) によるコンフリクト解決機能が内蔵されており、同一データへの同時書込みが発生した場合はトランザクションの再試行で対処する。サーバーレス課金 (DPU 従量) のため固定インスタンスコストが不要だ。

使い分け判断軸:
– 既存 Aurora MySQL / PostgreSQL から移行 + DR 強化が主目的 → Aurora Global Database を維持するのがコスト・工数最小
– RTO=0 の真の Active-Active が絶対要件 + PostgreSQL 互換 + 新規設計 → Aurora DSQL
– 書込みを Primary に集中できる + コスト予測可能性が重要 → Aurora Global Database

5.2 比較2: Aurora Limitless vs 手動シャーディング — 自動化 vs カスタム制御

手動シャーディング (既存アプローチ)は、アプリケーション層でシャードキーを計算し複数の Aurora クラスターにデータを分散する方式だ。シャードルーティングロジックを自社実装するため完全な制御が可能だが、シャード追加時のリバランス手順・クロスシャード JOIN の実装・シャード障害時の対応など運用コストが高い。

Aurora Limitlessは Shard group (内部的な物理シャード) + Routing table (クエリルーティング) をマネージドで提供する。アプリケーションは通常の Aurora PostgreSQL エンドポイントに接続するだけでよく、シャードルーティングロジックの実装は不要だ。負荷に応じて Shard group が自動的に追加されるため、トラフィックの急増に対して自動で対応できる。

使い分け判断軸:
– 新規設計で急成長が見込まれる + 運用チームの DBA リソースが限られている → Aurora Limitless
– 既存シャーディングロジックが複雑 + クロスシャード SQL が多い → 手動シャーディングを維持
– 既存 Aurora の垂直スケール上限に到達 + 運用コスト削減が優先 → Aurora Limitless 移行検討

5.3 比較3: DynamoDB Eventually Consistent Global vs Strong Consistency — 整合性 vs スループット / コスト

DynamoDB Global Tables (Eventually Consistent)は全リージョンが Active-Active で書き込みを受け付け、変更は1〜2秒以内に全レプリカへ伝播する。読み取り RCU が最安 (1 RCU / 4KB) で、高スループットが必要なワークロードに最適だ。書込み後の古い値が読み取られる可能性を許容できるユースケースに向いている。

DynamoDB Multi-Region Strong Consistencyは書込み後即座に最新値の読み取りを全リージョンで保証する。読み取り RCU は 2 RCU / 4KB (Eventually Consistent の2倍) で、クロスリージョン読み取りのレイテンシも若干増加する。整合性が業務上クリティカルなデータ (金融残高 / 在庫 / 設定値) に適用する。

5.4 選択マトリクス — ユースケース × 機能 × コスト の3軸

5.5 コスト比較試算 — 3機能の月次コスト比較

3機能はそれぞれ課金モデルが異なる。導入判断時に月次コスト概算を把握しておくことで、ビジネスケースの説得力が高まる。

Aurora Global Database vs Aurora DSQL — 同規模ワークロードでの比較:

前提: グローバル金融決済 DB (中規模)
  - 書込み: 1,000 TPS / 読み取り: 10,000 TPS
  - データ量: 1TB / リージョン: us-east-1 + ap-northeast-1

Aurora Global Database (db.r6g.2xlarge Writer + 2 Reader):
  Writer インスタンス: $0.48/h × 720h = $345/月
  Reader インスタンス × 2 × 2リージョン: $0.24/h × 720h × 4 = $691/月
  ストレージ: $0.10/GB × 1,000GB × 2リージョン = $200/月
  合計概算: ~$1,236/月

Aurora DSQL (サーバーレス DPU 従量):
  書込み DPU: ~500 DPU × $0.0003/DPU × 720h = $108/月
  読み取り DPU: ~100 DPU × $0.0003/DPU × 720h = $21.6/月
  ストレージ: $0.02/GB × 1,000GB × 2リージョン = $40/月
  合計概算: ~$170/月 (ただし急増時は DPU 増加)

注: DSQL はアイドル時のコストがゼロ。ピーク時の DPU 上限設定が重要。

Aurora Limitless vs 手動シャーディング (10 シャード構成) のコスト比較:

前提: 急成長 SaaS (マルチテナント) / 10億行 / 書込み 5,000 TPS

手動シャーディング (Aurora 10クラスター × db.r6g.xlarge):
  インスタンス: $0.24/h × 720h × 10 = $1,728/月
  ストレージ: $0.10/GB × 2,000GB = $200/月
  運用工数 (シャード管理 DBA): ~40h/月 × $150/h = $6,000/月
  合計: ~$7,928/月 (運用工数含む)

Aurora Limitless (ACU 従量):
  消費 ACU 平均: 200 ACU × $0.12/ACU-h × 720h = $17,280/月
  ストレージ: $0.10/GB × 2,000GB = $200/月
  運用工数削減: ~5h/月 × $150/h = $750/月
  合計: ~$18,230/月 (運用工数含む)

判断: 10シャード規模では手動シャーディングの方が安価。
  急成長で 50+ シャードになると Limitless の運用工数メリットが逆転。

DynamoDB Eventually Consistent vs Strong Consistency コスト比較:

参考として §4 の試算を再掲する。月間10億読み取りリクエスト (4KB アイテム) での比較:

5.6 移行計画フレームワーク — 段階移行のチェックポイント

3機能への移行は一夜にして完了しない。以下のフレームワークで段階的な移行計画を立案すること。

Phase 1: 現状評価 (1〜2週間):
– 現在の DB 構成・スキーマ・アクセスパターンを文書化する
– ボトルネックを定量化する (書込み TPS / 整合性違反件数 / シャード偏り)
– 対象技術の前提条件を確認する (PostgreSQL 互換性 / シャードキー候補 / 整合性要件)

Phase 2: PoC 実装 (2〜4週間):
– Dev/Staging 環境で対象機能を構築する
– 代表的なワークロードでベンチマークを実施する
– コスト見積を実測値で更新する

Phase 3: 段階移行 (4〜12週間):
– Blue-Green 戦略で新機能クラスターと並行稼働させる
– 非クリティカルなテーブルから順に移行する
– 各ステップで整合性検証とロールバック計画を確認する

Phase 4: 本番切替 (1〜2週間):
– メンテナンスウィンドウを設定し、トラフィックを切り替える
– 切替後 24〜72 時間は旧環境を待機状態で維持する
– メトリクス正常化を確認後、旧環境をクリーンアップする

5-6. 既存DB→新機能 移行の意思決定表

各機能への移行判断を「移行コスト」「期待効果」「リスク」の3軸で整理する。

「移行コスト 大 / 期待効果 ★」のセルは慎重判断、「移行コスト 小 / 期待効果 ★★以上」は優先着手対象。DynamoDB Strong Consistency は機能フラグ切替に近いため、最も着手障壁が低い (Vol4 で扱う3機能のうち最も導入しやすい)。

§5 でユースケース別の選択基準を整理した。§6 では DynamoDB / Aurora DSQL / Aurora Limitless の本番運用で直面する詰まりポイント7選を具体的な解決策とともに解説する。

§6 詰まりポイント7選 図解 (Mermaid01 判断ツリー)

Aurora DSQL × Aurora Limitless × DynamoDB Multi-Region Strong Consistency を本番導入した現場で頻出する7つの詰まりポイントを体系化する。各パターンに症状・原因・対処法を記載し、以下の判断ツリーで迷ったときの入口を一本化した。

flowchart TD
 A[DB問題発生] --> B{DSQL書込競合?}
 B -->|Yes| C[OCC/コンフリクト監視設定確認]
 B -->|No| D{Limitless shard移行?}
 D -->|Yes| E[Logical Replication手順確認]
 D -->|No| F{DynamoDB Strong書込制限?}
 F -->|Yes| G[Global Table v2 制約確認]
 F -->|No| H{Global vs DSQL選択?}
 H -->|Yes| I[Active-Passive vs Active-Active判断]
 H -->|No| J{コスト見積ズレ?}
 J -->|Yes| K[DPU/shard請求単位再確認]
 J -->|No| L{フェイルオーバー挙動?}
 L -->|Yes| M[各機能フェイルオーバー比較]
 L -->|No| N[移行戦略パターン確認]

詰まり1: Aurora DSQL レイテンシ罠 — Active-Active 書込競合と OCC

症状: 書込レイテンシが通常の3〜5倍に達し、PostgreSQL エラーコード 40001 (serialization failure) が散発する。トラフィックピーク時に顕著で、リトライなしではエラー多発状態になる。

原因: Aurora DSQL の Active-Active Multi-Region 構成では Optimistic Concurrency Control (OCC) を採用している。各トランザクション開始時にバージョンスタンプを取得し、コミット時に他リージョンの書込と競合していないかを検証する。複数リージョンが同一行へ同時書込するほど OCC コンフリクト率が増加する。

対処法:

1. Write locality 設計: 同一ユーザー/テナントのデータは同一リージョンへ書き込む (例: us-east-1 ユーザーは us-east-1 エンドポイントへ)
2. Retry with exponential backoff: 40001 受信時は指数バックオフで再試行 (最大5回 / 初期 50ms)
3. トランザクション短縮: 長大なトランザクションをバッチ分割してコンフリクト窓口を狭める
4. コンフリクト率監視: pg_stat_activity と CloudWatch (OCC conflicts) で定常監視

-- OCC コンフリクト発生状況の確認 (Aurora DSQL / PostgreSQL 互換)
SELECT
 pid,
 state,
 wait_event_type,
 wait_event,
 query_start,
 left(query, 80) AS query_head
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY query_start ASC;

# OCC retry パターン (psycopg2)
import psycopg2
import time
import random

def execute_with_occ_retry(conn_str, query, params, max_retries=5):
 for attempt in range(max_retries):
  try:
with psycopg2.connect(conn_str) as conn:
 with conn.cursor() as cur:
  cur.execute(query, params)
 conn.commit()
 return
  except psycopg2.errors.SerializationFailure:
if attempt == max_retries - 1:
 raise
wait = (2 ** attempt) * 0.05 + random.uniform(0, 0.01)
time.sleep(wait)

詰まり2: Aurora Limitless shard 移行 — 既存 Aurora からの Logical Replication 移行

症状: 既存 Aurora クラスターから Limitless へ切り替え後、特定クエリが極端に遅い。Shard に偏りが生じ、一部 Shard の CPU/I/O が過負荷になる。

原因: Routing key の選定ミスが最大原因。低カーディナリティカラム (status / country_code) を Routing key に指定すると、特定 Shard にデータが集中するホットスポットが発生する。

対処法:

1. Routing key 選定: 高カーディナリティカラム (user_id / uuid / order_id) を Routing key に指定
2. Logical Replication 移行: AWS DMS の Full Load + CDC で無停止移行
3. 移行前シミュレーション: EXPLAIN DISTRIBUTE で Shard 分布をプレビュー
4. 段階的カットオーバー: 読込先行移行 → 書込移行 → 旧クラスター停止

-- Aurora Limitless: Routing key (user_id) でテーブル作成
CREATE TABLE orders (
 order_id UUIDNOT NULL,
 user_id  UUIDNOT NULL,
 amountDECIMAL(10,2),
 created_at  TIMESTAMPTZ  DEFAULT NOW(),
 PRIMARY KEY (order_id, user_id)
) DISTRIBUTE BY (user_id);

-- EXPLAIN DISTRIBUTE でシャード分布確認
EXPLAIN DISTRIBUTE
SELECT * FROM orders WHERE user_id = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee';

# AWS DMS: Limitless への移行タスク作成
aws dms create-replication-task \
 --replication-task-identifier aurora-to-limitless \
 --source-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:source \
 --target-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:limitless \
 --replication-instance-arn arn:aws:dms:us-east-1:123456789012:rep:instance \
 --migration-type full-load-and-cdc \
 --table-mappings file://table-mapping.json

詰まり3: DynamoDB Multi-Region 書込制約 — Strong Consistency 有効時の Write 制限

症状: DynamoDB Global Tables v2 で Strong Consistency を有効化後、Secondary リージョン (us-west-2) からの書込スループットが急低下し WCU を大幅超過する。

原因: DynamoDB Multi-Region Strong Consistency は Strong reads を全リージョンで保証するため、書込は Primary リージョンへのルーティングが必要。また Strong write の WCU は通常 write の 2 倍消費する。

対処法:

1. Write routing 設計: アプリ層で Primary リージョン (us-east-1) エンドポイントへ書込をルーティング
2. Read/Write 分離: 読込は各リージョンローカルエンドポイント + ConsistentRead: true
3. WCU 再見積: Strong write = 通常の 2× WCU。プロビジョンド上限を調整

# Strong Consistency reads + Write routing パターン (boto3)
import boto3

dynamodb_primary = boto3.client('dynamodb', region_name='us-east-1')

def write_item(table_name, item):
 dynamodb_primary.put_item(TableName=table_name, Item=item)

dynamodb_local = boto3.client('dynamodb', region_name='us-west-2')

def read_item_strong(table_name, key):
 response = dynamodb_local.get_item(
  TableName=table_name,
  Key=key,
  ConsistentRead=True
 )
 return response.get('Item')

詰まり4: Aurora Global vs DSQL 選択基準 — Active-Passive vs Active-Active

症状: DR / グローバル展開の設計フェーズで Aurora Global Database と Aurora DSQL のどちらを採用すべきか判断が止まる。

原因: Aurora Global は Active-Passive (Secondary は読込専用)、Aurora DSQL は Active-Active (全リージョンで読写可能) と根本的に設計が異なる。

選択基準マトリクス:

詰まり5: コスト見積の罠 — DSQL DPU / Limitless shard 請求単位理解

症状: テスト環境での試算を元に本番コストを算出したところ、実際の請求額が2〜4倍になった。

原因: Aurora DSQL と Limitless の課金モデルは従来の ACU × 時間とは異なる複合課金体系を持つ。

Aurora DSQL の課金構造:
– DPU (Database Processing Unit): クエリ処理に消費した計算リソース (従量)
– I/O: データ読書き量に応じた追加課金
– Storage: データ保存容量 / バックアップ
– Cross-region Replication: Active-Active リージョン間データ転送料

Aurora Limitless の課金構造:
– ACU: 各 Shard が消費する Aurora Capacity Unit (Shard 数 × ACU が請求ベース)
– Shard group storage: 全 Shard の合算ストレージ

# CloudWatch で DPU 消費量確認 (Aurora DSQL)
aws cloudwatch get-metric-statistics \
 --namespace AWS/RDS \
 --metric-name DatabaseProcessingUnits \
 --dimensions Name=DBClusterIdentifier,Value=my-dsql-cluster \
 --start-time 2025-01-01T00:00:00Z \
 --end-time 2025-01-02T00:00:00Z \
 --period 3600 \
 --statistics Sum

詰まり6: 障害時挙動差異 — 各機能のフェイルオーバー挙動

症状: 障害訓練でどのフェイルオーバーメカニズムが動作するか混乱する。手動操作が必要なのか自動なのかが不明確で、障害対応手順書が各機能で共通化できない。

# Aurora Limitless: クラスター手動フェイルオーバー
aws rds failover-db-cluster \
 --db-cluster-identifier my-limitless-cluster \
 --target-db-instance-identifier my-limitless-cluster-instance-1

# DynamoDB Global Table v2: Primary リージョン変更 (Lambda 半自動化例)
import boto3

def switch_dynamodb_primary(table_name, new_primary_region, old_primary_region):
 client = boto3.client('dynamodb', region_name=old_primary_region)
 client.update_table(
  TableName=table_name,
  ReplicaUpdates=[{
'Update': {
 'RegionName': new_primary_region,
 'ProvisionedThroughputOverride': {'ReadCapacityUnits': 1000}
}
  }]
 )

詰まり7: 移行戦略失敗パターン — 既存 DB → 新機能移行の落とし穴

症状: 既存 Aurora / DynamoDB から新機能への移行後、データ欠落 / 整合性不整合が発覚。ロールバックが不可能になる。

原因: 段階移行計画の欠如 / データ整合性検証ステップの省略 / ロールバック手順の未テスト が三大原因。

主要な失敗パターン:
– Big Bang 切替: 全トラフィックを一斉切替 → 問題発覚時にロールバック不可
– 整合性検証省略: 移行後の行数 / チェックサム比較をスキップ → データ欠落が後から発覚
– 旧クラスターの早期停止: 検証完了前に停止 → ロールバック手段を失う

Phase 1: 新クラスター構築 + 読込専用テスト (旧クラスター継続稼働)
Phase 2: DMS Full Load + CDC で継続同期 (デュアルライト期間)
Phase 3: 読込トラフィック 10% → 50% → 100% を段階的移行
Phase 4: 書込トラフィック移行 (旧クラスターを読込専用で維持)
Phase 5: 整合性検証 (行数 / チェックサム / 主要クエリ結果比較)
Phase 6: 旧クラスター停止 (検証完了後 72 時間以上経過してから)

# 行数整合性チェック例 (移行前後の比較)
psql -h old-cluster.endpoint -U admin \
 -c "SELECT COUNT(*) FROM orders WHERE created_at >= '2025-01-01';"
psql -h new-cluster.endpoint -U admin \
 -c "SELECT COUNT(*) FROM orders WHERE created_at >= '2025-01-01';"

§7 アンチパターン → 正解パターン変換演習 (5問)

本番設計の判断力を養うため、現場で実際に起きたアンチパターンと、推奨される正解パターンを Terraform 構成とコードで対比する。各問の「なぜそれがアンチパターンか」を理解することが設計力向上の核心である。

Q1: Single-Region Aurora → Aurora DSQL Active-Active (RTO短縮 / 書込継続性)

シナリオ: 決済システムが us-east-1 単一リージョンの Aurora PostgreSQL で稼働。DR 要件として RTO 5分以内 + リージョン障害時の書込継続性が必須となった。

アンチパターン (Aurora Global / Active-Passive — 書込停止リスクあり):

# アンチパターン: Aurora Global Database (Secondary は読込専用)
# フェイルオーバー時に書込停止 + 手動プロモーションが必要
resource "aws_rds_cluster" "primary" {
  cluster_identifier = "payment-primary"
  engine = "aurora-postgresql"
  engine_version  = "15.4"
  master_username = "admin"
  master_password = var.db_password
}

resource "aws_rds_global_cluster" "global" {
  global_cluster_identifier = "payment-global"
  source_db_cluster_identifier = aws_rds_cluster.primary.arn
}

# Secondary は読込専用 — フェイルオーバー時は手動プロモーションが必要
resource "aws_rds_cluster" "secondary" {
  cluster_identifier= "payment-secondary"
  engine= "aurora-postgresql"
  global_cluster_identifier  = aws_rds_global_cluster.global.id
  replication_source_identifier = aws_rds_cluster.primary.arn
  provider = aws.us_west_2
}

正解パターン (Aurora DSQL / Active-Active — フェイルオーバー不要):

# 正解パターン: Aurora DSQL Active-Active Multi-Region
# 両リージョンで同時書込可能 → フェイルオーバー不要 / RTO = 0
resource "aws_dsql_cluster" "primary" {
  deletion_protection_enabled = true
  tags = { Name = "payment-dsql-us-east-1", Environment = "production" }
}

resource "aws_dsql_cluster" "secondary" {
  deletion_protection_enabled = true
  tags = { Name = "payment-dsql-us-west-2", Environment = "production" }
  provider = aws.us_west_2
}

resource "aws_dsql_multi_region_cluster" "payment" {
  linked_cluster_arns = [
 aws_dsql_cluster.primary.arn,
 aws_dsql_cluster.secondary.arn
  ]
}

解説: Aurora Global は Secondary が読込専用のため、Primary 障害時は Secondary を手動プロモーションする必要があり書込が一時停止する。Aurora DSQL は Active-Active なので両リージョンで常時書込可能。フェイルオーバー所要時間ゼロで RTO 要件を満たせる。ただし OCC コンフリクト設計が必要。

Q2: 手動Shard設計 → Aurora Limitless (自動分散/管理コスト削減)

シナリオ: ECサイトの注文DBが単一 Aurora クラスターの垂直スケール限界に達した。アプリケーション層での手動 Sharding を実装済みだが、Shard 追加のたびにアプリ改修が必要で管理コストが膨大になっている。

アンチパターン (アプリケーション層での手動 Shard ルーティング):

# アンチパターン: アプリ層の手動 Shard ルーティング
# Shard 追加のたびにコード修正が必要 → 管理コスト爆発
SHARD_ENDPOINTS = {
 0: "shard-0.cluster.us-east-1.rds.amazonaws.com",
 1: "shard-1.cluster.us-east-1.rds.amazonaws.com",
 2: "shard-2.cluster.us-east-1.rds.amazonaws.com",
}
SHARD_COUNT = 3

def get_shard(user_id: str) -> str:
 shard_index = hash(user_id) % SHARD_COUNT
 return SHARD_ENDPOINTS[shard_index]
# 問題: Shard 追加時にハッシュ再配置 + アプリ改修 + データ再分散が必要

正解パターン (Aurora Limitless / アプリ改修ゼロ):

# 正解パターン: Aurora Limitless (アプリ改修ゼロ / 自動水平スケール)
resource "aws_rds_cluster" "limitless" {
  cluster_identifier = "ecommerce-limitless"
  engine = "aurora-postgresql"
  engine_version  = "16.4"
  cluster_mode = "limitless"
  master_username = "admin"
  master_password = var.db_password

  serverlessv2_scaling_configuration {
 min_capacity = 2
 max_capacity = 256
  }
}

-- アプリ側: 既存の PostgreSQL 接続文字列のまま利用可能
-- DISTRIBUTE BY を追加するだけ → Shard 追加はLimitlessが自動処理
CREATE TABLE orders (
 order_id UUID NOT NULL,
 user_id  UUID NOT NULL,
 amountDECIMAL(10,2),
 PRIMARY KEY (order_id, user_id)
) DISTRIBUTE BY (user_id);

解説: 手動 Sharding はアプリ層の複雑度増大・Shard 追加時のダウンタイム・データ再配置コストが三大欠点。Aurora Limitless は Routing table を内部自動管理し、アプリは既存の PostgreSQL エンドポイントをそのまま使用できる。Shard 追加はサービス無停止で行われる。

Q3: Eventually Consistent Global Table → DynamoDB Strong Consistency (整合性保証/金融系)

シナリオ: 銀行の口座残高チェックで DynamoDB Global Tables (Eventually Consistent) を使用。残高読込と書込の間に数百ミリ秒のラグがあり、二重送金の可能性が指摘された。

アンチパターン (Eventually Consistent 読込 / 金融系には危険):

# アンチパターン: Eventually Consistent 読込 (金融系には危険)
import boto3

dynamodb = boto3.client('dynamodb', region_name='us-west-2')

def check_balance_unsafe(account_id: str) -> int:
 response = dynamodb.get_item(
  TableName='accounts',
  Key={'account_id': {'S': account_id}},
  # ConsistentRead 未指定 → Eventually Consistent (デフォルト)
  # 他リージョンの最新書込が反映されていない可能性あり
 )
 return int(response['Item']['balance']['N'])

正解パターン (Strong Consistency / Global Tables v2):

# 正解パターン: Strong Consistency reads (Global Tables v2)
import boto3

# 読込: Strong Consistency (ConsistentRead=True)
dynamodb_read = boto3.client('dynamodb', region_name='us-west-2')

def check_balance_safe(account_id: str) -> int:
 response = dynamodb_read.get_item(
  TableName='accounts',
  Key={'account_id': {'S': account_id}},
  ConsistentRead=True  # Strong Consistency → 最新値を保証
 )
 return int(response['Item']['balance']['N'])

# 書込: Primary リージョン (us-east-1) 集中
dynamodb_write = boto3.client('dynamodb', region_name='us-east-1')

def deduct_balance(account_id: str, amount: int):
 dynamodb_write.update_item(
  TableName='accounts',
  Key={'account_id': {'S': account_id}},
  UpdateExpression='SET balance = balance - :amount',
  ConditionExpression='balance >= :amount',
  ExpressionAttributeValues={':amount': {'N': str(amount)}}
 )

解説: 金融系の残高チェックに Eventually Consistent 読込を使うと、他リージョンの最新書込が見えない「古いデータ」を読む可能性がある。Global Tables v2 の ConsistentRead: true は全レプリカ間の最新値を保証するため、二重送金リスクを排除できる。Strong read は通常 read の 2 倍 RCU を消費する点に注意。

Q4: Active-Passive DR → Active-Active DSQL (RTO短縮/可用性向上)

シナリオ: グローバル SaaS で DR 目標 RTO 1分以内。現行は Aurora Global Database (Active-Passive) でフェイルオーバー時に手動プロモーションが必要。夜間障害時のオペレーター対応が問題になっている。

アンチパターン (Aurora Global / 手動フェイルオーバー — 夜間対応が必要):

# アンチパターン: 手動フェイルオーバー (RTO が人的対応速度に依存)
# プロモーション中は書込停止 (1〜2分) + 夜間オンコール対応が必要
aws rds failover-global-cluster  --global-cluster-identifier payment-global  --target-db-cluster-identifier arn:aws:rds:us-west-2:123456789012:cluster:payment-secondary

正解パターン (Aurora DSQL / 自動継続 — フェイルオーバー不要):

# 正解パターン: Aurora DSQL Active-Active (フェイルオーバー不要)
# us-east-1 が障害になっても us-west-2 へクライアント側で自動切替
import psycopg2
from psycopg2 import OperationalError
import time

DSQL_ENDPOINTS = [
 "us-east-1.dsql-cluster.amazonaws.com",
 "us-west-2.dsql-cluster.amazonaws.com",
]

def get_connection(retry=0):
 endpoint = DSQL_ENDPOINTS[retry % len(DSQL_ENDPOINTS)]
 try:
  return psycopg2.connect(
host=endpoint,
dbname="saas_db",
user="admin",
password="...",
sslmode="require"
  )
 except OperationalError:
  if retry < len(DSQL_ENDPOINTS) - 1:
time.sleep(0.5)
return get_connection(retry + 1)
  raise

解説: Active-Passive DR は人的フェイルオーバー操作が必須で RTO が「人の反応速度」に依存する。Aurora DSQL の Active-Active では両エンドポイントが常時稼働しているため、クライアント側のエンドポイント切替だけで継続稼働できる。夜間オンコール不要・RTO 秒以内が達成可能。

Q5: 単一DB型選択 → 用途別DB選択マトリクス (DSQL/Limitless/Global最適配置)

シナリオ: 大規模 SaaS が全データを Aurora PostgreSQL に集約。ユーザープロファイル (高読込/低書込)・注文データ (高書込/水平スケール必要)・残高チェック (Strong Consistency必須/グローバル) が混在し、スケール要件の違いから単一クラスターで限界に達している。

アンチパターン (全社統一 Aurora / 用途無視):

# アンチパターン: 全データを単一 Aurora クラスターへ
# 垂直スケール限界 + コスト最適化不可 + 整合性要件混在
resource "aws_rds_cluster" "monolith" {
  cluster_identifier = "company-all-in-one"
  engine = "aurora-postgresql"
  engine_version  = "15.4"
  # ユーザープロファイル / 注文 / 残高が全て同一クラスター
  # → スケール要件が異なるデータが混在 → 最適化不可
}

正解パターン (用途別DB分離):

# 正解パターン: 用途別DB分離

# 1. 注文データ (高書込 / 水平スケール) → Aurora Limitless
resource "aws_rds_cluster" "orders" {
  cluster_identifier = "orders-limitless"
  engine = "aurora-postgresql"
  engine_version  = "16.4"
  cluster_mode = "limitless"
}

# 2. ユーザープロファイル (グローバル読込 / Active-Active書込) → Aurora DSQL
resource "aws_dsql_cluster" "profiles" {
  deletion_protection_enabled = true
  tags = { Name = "profiles-dsql" }
}

# 3. 残高チェック (グローバル / Strong Consistency / NoSQL) → DynamoDB Global v2
resource "aws_dynamodb_table" "balances" {
  name= "account-balances"
  billing_mode = "PAY_PER_REQUEST"
  hash_key  = "account_id"

  attribute { name = "account_id"; type = "S" }

  replica { region_name = "us-west-2" }
  replica { region_name = "eu-west-1" }
}

用途別DB選択マトリクス:

解説: 全データを単一 Aurora に集約するとスケール上限・コスト最適化・整合性要件の3つで限界が来る。用途特性 (スケール要件 / 整合性要件 / SQL互換性) を軸に DSQL / Limitless / DynamoDB Global v2 を選択することで、各軸の最適化が可能になる。

§8 まとめ + Database四部作完成 + 47記事化告知 + 全軸クロスリンクナビ

Aurora DSQL × Aurora Limitless × DynamoDB Multi-Region Strong Consistency の本番運用パターンを §1〜§7 で体系化した。最後に Database 四部作の完成と、AWS 本番運用シリーズの全体像をまとめる。

3機能 本番運用まとめ

3機能の選択は「①RDB か NoSQL か」「②Active-Active か Active-Passive か」「③Strong Consistency か Eventually か」の3軸で決まる。それぞれの設計思想と制約を理解することで、本番運用の落とし穴を事前に回避できる。

graph LR
 DB[Database Vol4 四部作完成] --> CONT[Container Vol1-3]
 DB --> SEC[Security Vol1-3]
 DB --> AI[AI/ML Vol1-3]
 DB --> DEV[DevOps Vol1-3]
 DB --> OBS[Observability Vol1-2]
 DB --> SRV[Serverless Vol1-2]
 DB --> NET[Network Vol1-2]

全軸クロスリンクナビ

本記事と関連する主要シリーズへのリンクを掲載する。Database Vol4 で扱った DSQL / Limitless / DynamoDB Strong は、Container (EKS上のDB接続)・Security (KMS Multi-Region)・AI/ML (Feature Store DynamoDB連携)・DevOps (CDK Pipelines DBデプロイ) と密接に連携する。

Database Vol1 — RDS × Aurora × DynamoDB 基礎運用

Database Vol2 — DMS × Aurora Global × Streams × Backup

Database Vol3 — ElastiCache × DAX × MemoryDB キャッシュ三本柱

次のステップ

Database 四部作を完読した読者は、以下のシリーズで学習を深めることを推奨する。

• DB × Container 連携: EKS 上での Aurora DSQL / Limitless 接続パターン → Container Vol3 へ
• DB × AI/ML 連携: SageMaker Feature Store と DynamoDB Online Store の統合 → AI/ML Vol3 へ
• DB × DevOps 連携: CDK Pipelines による Aurora / DynamoDB スキーマデプロイ自動化 → DevOps Vol3 へ
• DB × Observability: Aurora Performance Insights / DynamoDB Contributor Insights の本番活用 → Observability Vol2 へ

Aurora DSQL の Active-Active 設計・Aurora Limitless の Shard 設計・DynamoDB Strong Consistency の Write routing 設計を習得し、グローバルスケールの DB 本番運用力を獲得されたい。

8-2. グローバル DB 本番運用 5原則

Vol1 (基礎) → Vol2 (移行+グローバル) → Vol3 (キャッシュ) → Vol4 (2024-2025最新) を通読すると、AWS Database 本番運用には共通する5つの原則が浮かび上がる。これらは技術スタックを超えて適用できる普遍的な指針である。

これら5原則は Vol1 の RDS/Aurora/DynamoDB 基礎から、Vol2 の移行+グローバル、Vol3 のキャッシュ層、Vol4 の最新分散DB まで一貫して通底する設計思想である。技術スタックが変わっても、この5原則が DB 本番運用の北極星となる。

8-3. Database 四部作 読者ペルソナ別 読み順ガイド

本シリーズはあなたの現状と目標に応じて読む順番を変えることで効率的に学習できる。

四部作は「Vol1 = 基礎」「Vol2 = 移行+グローバル」「Vol3 = キャッシュ」「Vol4 = 2024-2025最新」と段階構造になっており、後ろの巻ほど深く具体的な最新機能に踏み込む。あなたが詰まっている領域に応じて優先する巻を選ぶことで、最短で課題を解決できる。

8-4. Database Vol4 読了後 想定質問 FAQ

読了後によく聞かれる質問に答える。

Q1. Aurora DSQL と Aurora Global Database、どちらを選ぶべきか?
書込ローカリティと RTO 要件で決める。Active-Active 同時書込が必要で RTO 秒単位なら DSQL、既存 Aurora 資産が大きく Active-Passive で十分なら Aurora Global。DSQL は PostgreSQL互換のみ、Aurora Global は MySQL/PostgreSQL 両対応の点も考慮する。

Q2. Aurora Limitless はいつ採用すべきか?
垂直スケール (db.r7g.16xlarge等) の壁にぶつかり、かつ Routing key として高カーディナリティな列 (user_id等) が存在する場合に採用する。データ量 < 5TB or Routing key 設計困難なら、Vol3 のキャッシュ層 (ElastiCache/DAX) で読込負荷を逃がす方が安価。

Q3. DynamoDB Global Tables v2 の Strong Consistency と、従来の Eventually Consistency はどう使い分ける?
業務影響度で決める。金融 (残高/取引)・在庫管理・予約システム等の「整合性が業務影響に直結する」用途は Strong、ソーシャル (いいね数等)・ログ集計等の「秒単位の遅延が許容される」用途は Eventually。コスト差 (Strong は約2倍) も考慮要素。

Q4. 既存 Aurora から DSQL/Limitless への移行はどう進める?
段階移行を推奨。(1) PoC でアプリ互換性検証、(2) Read replica として並走運用、(3) Read traffic を段階的に切替、(4) Write を最終切替。並走期間に Aurora Global → DSQL のレプリケーションは AWS DMS で実装可能。

Q5. 4本柱を全部一度に導入するべきか?
非推奨。1機能ずつ段階導入する。優先順位は §8-2 の5原則と照らし合わせて決定する。Active-Active 必要 → DSQL から、水平スケール壁 → Limitless から、整合性問題 → DynamoDB Strong から。同時導入は運用負荷が爆発する。

8-5. 戦略総括 + 後続シリーズ予告

次に予定している DB 関連縦深化軸:
– Database Vol5 (構想中): Aurora Serverless v3 / Aurora Zero-ETL with Redshift / DynamoDB Streams to S3 (Iceberg連携)
– Network Vol3 (構想中): Cross-Region VPC Peering × Transit Gateway Inter-Region Peering × Cloud WAN — DSQL/Limitless の Multi-Region 通信基盤
– Observability Vol3 (構想中): Aurora Performance Insights × DynamoDB Contributor Insights × CloudWatch Database Insights — DB 本番監視の縦深化

シリーズ全体は AWS 本番運用に必要な全ドメインを縦深化していく方針だ。あなたの本番運用で詰まっている領域があれば、シリーズの各巻を参照することで実装パターンと詰まりポイントの対処法が得られる。Database 四部作を起点に、ぜひ他ドメインのシリーズもご活用いただきたい。