AWS SaaSマルチテナントVol3｜データ層スケーリング実践

1. データ層スケーリングの概要と前提

1-1. なぜデータ層スケーリングが課題になるか

SaaSアーキテクチャにおいて、テナント数とトラフィックが増加するにつれて、データ層は最初にボトルネックが顕在化するレイヤーのひとつです。

接続枯渇問題

Vol1で解説したPool型テナント分離では、複数テナントが単一のRDSインスタンスを共有します。アプリケーション層にLambda等のサーバーレス関数を採用した構成では、各関数インスタンスが起動のたびに新規DB接続を確立し、終了時に破棄します。同時リクエスト数の増加に比例してDB接続数がRDSのmax_connections上限に到達し、「too many connections」エラーが頻発します。スケールアウトするほどDB接続数が増えるという逆説が生じるため、アプリケーション層の横スケールだけでは解消できず、データ層への専用対策が不可欠となります。

noisy neighbor問題

特定テナントが突発的な高トラフィックを発生させると、同じデータ層を共有する他テナントのパフォーマンス劣化を招くnoisy neighbor問題を引き起こします。リレーショナルDBでは接続競合やCPU過負荷として、DynamoDBでは特定パーティションへの集中アクセス(ホットパーティション)として発現します。テナント数が増加するほど一部テナントのスパイクが他テナントに波及する確率は高まり、SaaSの信頼性・SLA達成に直結する課題となります。

読み取り負荷の集中

レポーティングやダッシュボードなど読み取り集約ワークロードが加わると、単一ライターへのアクセス集中が書き込みレイテンシを圧迫します。読み取り負荷をライターから分離するread replicaの活用が、本番SaaSにおける基本的な対策となります。

課題が顕在化するタイミング

一般的に、テナント数が数十〜100を超えたあたりで接続枯渇とnoisy neighborの問題が本番環境で顕在化し始めます。スタートアップ初期はシンプルな共有DBで問題なくても、テナント数増加とともに設計の見直しが必要な臨界点に達します。本記事で扱うデータ層対策はこの臨界点を先延ばしにしながら、スケールに追従できるアーキテクチャを実現します。

早期にデータ層のスケーリング設計を組み込んでおくことで、後からの大規模リアーキテクチャを回避できます。

1-2. 本記事の守備範囲

本記事はVol1(テナント分離・セル・課金・オンボーディング)・Vol2(エンタープライズ認証連携・認可・M2M)の基盤が整った続編として、データ層の負荷対策に特化して解説します。

扱わない範囲(Vol1/Vol2との境界)

以下はVol1/Vol2で確立済みのため、本記事では再掲しません。

• テナント分離モデル(Silo/Pool/Bridge)の概念・選定基準 → Vol1
• セルベースアーキテクチャ・課金・オンボーディング → Vol1
• エンタープライズ認証連携(SAML/OIDC federation)・Verified Permissions(ABAC/RBAC) → Vol2
• M2Mクレデンシャル管理 → Vol2

データ層がテナント増・トラフィック増に耐える設計の核心に絞って解説します。

▶ Vol1: テナント分離・セル・課金・オンボーディング編

2. RDS Proxy接続プーリング

2-1. 接続多重化の仕組み

RDS Proxyはクライアントとデータベースの間に配置されるAWSマネージドの接続プールサービスです。クライアント(Lambda関数・アプリケーションサーバー等)はRDS ProxyのエンドポイントへMySQLまたはPostgreSQLプロトコルで接続します。図2で示すように、RDS Proxy側では受け取った多数のクライアント接続を、DB側ではより少数のDB接続にまとめる多重化(multiplexing)を実施します。クライアント接続数がスパイクしても、Proxy→DBの接続数は一定の範囲内に抑えられます。

多重化により得られる主な効果を以下に示します。

対応サービスと東京リージョン

RDS ProxyはAurora(MySQL/PostgreSQL互換)・RDS(MySQL/PostgreSQL/SQL Server)に対応し、東京リージョン(ap-northeast-1)で長期GA提供中です。

• Auroraクラスター: ライターエンドポイントまたはReaderエンドポイントをターゲットに設定
• RDSインスタンス: 個別エンドポイントをターゲットに設定

RDS Proxy作成時の主要設定項目

エンジン互換性: MySQL / PostgreSQL
ターゲット : 対象RDS/Auroraクラスター
IAM認証 : 有効/無効 (詳細は§2-4)
Secrets Manager  : DB接続資格情報を登録
VPC  : RDS/Auroraと同一VPC内に配置

Secrets ManagerへのアクセスにはProxyが引き受けるIAMロールにsecretsmanager:GetSecretValue権限が必要です。

2-2. pool-per-tenant vs shared pool

RDS Proxyによる接続プールには2つの基本モードがあります。

shared pool(基本モード)

全テナントのクライアント接続が単一のRDS Proxyを共有し、Proxy→DBの接続プールも共有されます。RDS Proxyのデフォルト動作で、設定・運用コストが最も低い構成です。

• 設定: 単一RDS Proxyと1つのターゲットグループ
• 適用場面: Pool型マルチテナントアーキテクチャ全般
• 利点: 設定シンプル、全テナントの接続を集約してDB負荷を最小化
• 制約: テナント間でDB接続が共有されるため、接続面の論理隔離はない

pool-per-tenant(テナント別隔離)

テナントごと(またはテナントグループごと)に専用のRDS Proxyまたはターゲットグループを割り当てる構成です。各テナントのProxy→DB接続が分離され、接続面のnoisy neighborリスクを軽減します。

• 設定: Proxy数またはターゲットグループ数がテナント数に比例
• 適用場面: 接続面の強隔離が必要な重要テナント・上位ティア
• 利点: テナント間での接続占有リスクを低減
• 制約: Proxyのプロビジョニング・管理コストがテナント数に比例して増大

実践的な組み合わせ

大多数のテナントをshared poolで扱い、接続レベルの隔離が必要な重要テナントのみpool-per-tenantに昇格させるハイブリッド構成が現実解です。Vol1で解説したPool→Silo移行判断と連動させ、接続面の隔離をSilo化の一要素として位置づけると設計の一貫性が保たれます。

2-3. 接続ピン留め(pinning)の落とし穴（重要な前提）

RDS Proxyの多重化が機能しないケースとして接続ピン留め(pinning)があります。接続プーリング設計において正確な理解が重要です。

ピン留めとは

RDS Proxyがあるクライアントセッションを特定のDB接続に固定し、そのセッションが終了するまで同じDB接続を他のクライアントへ再割り当てできない状態を指します。ピン留めが頻発すると、Proxyを経由していても実質的に接続が専有され、接続多重化の効果が大幅に低下します。

ピン留めが発生する主な操作

以下の操作ではProxyが接続再利用の安全性を保証できないと判断し、ピン留めが発生します。

ピン留め最小化のベストプラクティス

ピン留め状況の監視

DatabaseConnections: Proxy→DBの実際の接続数
ClientConnections  : クライアント→Proxyの接続数

ClientConnectionsに対してDatabaseConnectionsが近い値になっている場合、多重化が効いていない(ピン留め多発の疑い)です。両者の比率を定期的に確認し、過剰なピン留めが発生していないかチェックします。ピン留め率が高い場合は、アプリケーションコードのSET文使用箇所や大きなクエリを見直します。

2-4. IAM認証と接続上限

IAM認証の仕組み

RDS ProxyではIAM認証を有効化できます。有効時の接続フローは以下のとおりです。

クライアント → RDS Proxy : IAM DB認証(generate-db-auth-tokenで生成した一時トークンをパスワードとして使用)
RDS Proxy → DB : IAM認証またはSecrets Manager格納の資格情報で接続

クライアントはIAMロールに付与された権限を使ってaws rds generate-db-auth-tokenで一時トークン(15分有効)を取得し、DB接続のパスワードとして使用します。Lambda等のサーバーレス関数はIAMロールでデプロイされるため、IAM DB認証との相性がよく、パスワードのローテーションをSecrets Managerで自動管理できます。

MaxConnectionsPercentによる接続上限制御

MaxConnectionsPercentパラメータは、RDS ProxyがDB(RDS/Aurora)に確立できる最大接続数を、そのDBのmax_connectionsに対するパーセンテージで指定します。

Proxy→DBの最大接続数 = max_connections × MaxConnectionsPercent / 100

例: max_connections=1000、MaxConnectionsPercent=80の場合
– Proxy→DBの最大接続数=800に制限
– 残り20%(200接続)は管理・緊急接続用に確保

pool-per-tenant構成での注意点

pool-per-tenantで複数のProxyが同一DBをターゲットとする場合、各ProxyのMaxConnectionsPercentの合計がDBのmax_connectionsの100%を超えないよう設計する必要があります。超過するとDBへの接続要求が拒否されます。

例: max_connections=1000に4台のProxyが接続する場合、各ProxyにMaxConnectionsPercent=18(合計72%)を設定することで、DB接続の28%(280接続)を管理・緊急用として確保できます。MaxConnectionsPercentは100%に設定せず、管理接続用の余裕を残すことで接続圧迫時でも運用操作を維持できます。

3. テナント別シャーディング戦略

3-1. シャーディングの概念とマルチテナントへの適用

SaaSのPoolモデルで複数テナントが1つのDynamoDBテーブルを共有する場合、テナント数とトラフィックの増加に伴いパーティション設計が最重要課題になります。

DynamoDBパーティションの基本制約

DynamoDBはデータを内部的に複数のパーティションへ分散して格納します。各パーティションには明確なスループット上限があります。

• 読み取り上限: 1パーティションあたり最大3,000 RCU/s
• 書き込み上限: 1パーティションあたり最大1,000 WCU/s

この上限を超えるリクエストはスロットリング(ProvisionedThroughputExceededException)を引き起こします。プロビジョンドスループットをいくら増やしても、同じパーティションにリクエストが集中する限りスロットリングは発生します。

ナイーブなtenant-id設計の落とし穴

# NG例: tenant-idをそのままパーティションキーに使う
item = {
 "PK": "TENANT#tenant-1",# パーティションキー
 "SK": "ORDER#order-456",# ソートキー
}

この設計では、tenant-1のすべてのデータが同一パーティションに集中します。テナントAが急増トラフィックを発生させると次の問題が連鎖します。

1. パーティション書き込みが1,000 WCU/s上限に到達
2. テナントAの書き込みがスロットリング
3. 同じノードを共有する他テナントまでレイテンシが悪化（noisy neighbor問題）

SaaSのPool設計ではこのnoisy neighbor問題がサービス品質(SLA)の根本的な脅威になります。

シャーディングで解決できる理由

シャーディングの本質は「1つの論理テナントのデータを複数の物理パーティションに分散すること」です。パーティションキーに識別子を付与することで、DynamoDBのデータ配置アルゴリズムを利用して書き込み負荷を自然に分散できます。シャード数を増やすほど1パーティションあたりの書き込み量が減り、上限超過のリスクを低下させられます。

3-2. write sharding: TENANT#ID-N 複合キー設計

write shardingの正しい実装パターンは、テナントIDにシャードサフィックス(-0, -1, …)を付与してパーティションキーを生成することです。

シャードサフィックス付与の設計

import random

SHARD_COUNT_DEFAULT = 1
SHARD_COUNT_HIGH_VOLUME = 4  # 高トラフィックテナントのシャード数

def get_shard_count(tenant_id: str) -> int:
 """テナント設定テーブルまたはSSMからシャード数を取得"""
 config = tenant_config_table.get_item(Key={"PK": f"TENANT#{tenant_id}"})
 return config["Item"].get("shard_count", SHARD_COUNT_DEFAULT)

def get_partition_key(tenant_id: str) -> str:
 shard_count = get_shard_count(tenant_id)
 if shard_count <= 1:
  # 通常テナント: サフィックスなし
  return f"TENANT#{tenant_id}"
 # write sharding: ランダムサフィックスで書き込みを分散
 suffix = random.randint(0, shard_count - 1)
 return f"TENANT#{tenant_id}-{suffix}"

これにより生成されるパーティションキーの例を以下に示します。

複合パーティションキーによる負荷分散

別のアプローチとして、tenantIdとエンティティIDを連結した複合パーティションキーも有効です。

# 複合パーティションキーの例
item = {
 "PK": "TENANT#tenant-1|TICKET#T-1234",  # テナント+エンティティIDの複合キー
 "SK": "v0",
 "status": "open",
 "tenant_id": "tenant-1",  # GSI用属性
}

この設計の特徴は次のとおりです。

• エンティティ単位にパーティションが分散 — 書き込み集中を構造的に防ぐ
• テナント横断クエリはGSIで対応 — GSI-PK: TENANT#tenant-1 で同一テナントの全エンティティを効率的に取得
• スケールに比例した自然な分散 — テナントのデータ量が増えるほどパーティションも自動的に分散

シャード数の決め方

シャード数は過剰設定すると読み取りコスト(scatter-gather)が増大するため、ピーク書き込み予測を基に決定します。

パーティション上限の80%を設計目標とし、バーストに備えて20%のマージンを確保します。

3-3. ルーティング層の設計

write shardingを導入すると、書き込み時と読み取り時でルーティングロジックが分かれます。

書き込みルーティング

書き込みはランダムなシャードサフィックスを付与することで自動的に分散されます。

def write_item(tenant_id: str, sk: str, data: dict) -> None:
 pk = get_partition_key(tenant_id)  # ランダムサフィックス付与
 table.put_item(Item={"PK": pk, "SK": sk, **data})

読み取りルーティング: scatter-gather

単一テナントのデータを列挙する場合、全シャードに対して並列でクエリを発行します(scatter-gather)。

import asyncio
import aioboto3

async def query_tenant_items(
 tenant_id: str,
 shard_count: int,
 limit: int = 100,
) -> list:
 """全シャードに並列クエリを投げてマージ (scatter-gather)"""
 session = aioboto3.Session()
 async with session.resource("dynamodb") as dynamodb:
  table = await dynamodb.Table("saas-data")
  tasks = []
  for i in range(shard_count):
pk = f"TENANT#{tenant_id}-{i}" if shard_count > 1 else f"TENANT#{tenant_id}"
tasks.append(
 table.query(
  KeyConditionExpression="PK = :pk",
  ExpressionAttributeValues={":pk": pk},
  Limit=limit,
 )
)
  results = await asyncio.gather(*tasks)

 all_items = [item for res in results for item in res.get("Items", [])]
 # 時刻順ソートで一貫した結果を返す
 return sorted(all_items, key=lambda x: x["created_at"], reverse=True)

scatter-gatherの考慮点を以下に整理します。

GSIによる読み取り補完

テナント横断の集約クエリにはGSI(Global Secondary Index)を使い、scatter-gatherを回避します。

# GSI設計例: テナントIDを属性として保持し、GSIで集約
item = {
 "PK": f"TENANT#{tenant_id}-{shard_suffix}",  # シャードキー
 "SK": f"ORDER#{order_id}",
 "tenant_id": tenant_id,# GSI-1のPK用属性
 "created_at": timestamp,  # GSI-1のSK用属性
}

# GSI-1の設定
# GSI-PK: tenant_id
# GSI-SK: created_at
# → tenant_id="tenant-1" のクエリでシャードを意識せず全注文が取得できる

書き込み時にGSI用の属性を同時に設定することで、scatter-gatherなしの効率的な読み取りが実現します。

3-4. シャード追加・リバランスの運用

トラフィック増加に伴いシャード数を増やす場合、データ移行を伴うリバランスが必要です。

シャード追加の4ステップ手順

シャード数をNからMに増やす例(4→8シャード)を示します。

1. DynamoDB Streams + Lambda で新シャードへデータ複製

# Lambda関数: DynamoDB Streamsのイベントを受け取り
# 旧キー(shard 0-3)のデータを新シャード(4-7)に複製
def handler(event, context):
 for record in event["Records"]:
  if record["eventName"] in ("INSERT", "MODIFY"):
old_item = record["dynamodb"]["NewImage"]
tenant_id = extract_tenant_id(old_item["PK"]["S"])
new_pk = f"TENANT#{tenant_id}-{random.randint(4, 7)}"
table.put_item(Item={**old_item, "PK": new_pk})

1. 二重書き込み期間の設定: アプリケーションが旧シャード(0〜3)と新シャード(4〜7)の両方へ書き込む期間を設ける。
2. 読み取り切り替え: 全データ複製完了後、scatter-gather対象を全シャード(0〜7)に変更。
3. 旧シャードキーのクリーンアップ: TTL属性の設定またはバッチ削除で旧シャードのデータを削除。

シャード設定のSSM Parameter Store管理

テナントごとにシャード数が異なるため、設定を集中管理します。

import boto3

ssm = boto3.client("ssm")

def get_shard_count(tenant_id: str) -> int:
 """SSM Parameter Storeからシャード数をホットリロード"""
 try:
  param = ssm.get_parameter(
Name=f"/saas/sharding/{tenant_id}/shard_count"
  )
  return int(param["Parameter"]["Value"])
 except ssm.exceptions.ParameterNotFound:
  return 1  # デフォルト: シャードなし

SSM Parameter StoreはParameterStoreキャッシュSDKと組み合わせることで、Lambda/ECSを再デプロイせずにシャード数を動的に変更できます。

Pool→Silo移行との判断基準

シャード増設で対応できない重テナントは、Vol1で解説したPool→Silo移行を検討します。

まずシャード増設で吸収し、コスト・運用コスト・スロットリングが改善しない場合にSilo移行を判断するのが実践的なアプローチです。

ホットシャードの監視

シャード設計が適切でも、ビジネス的な事情でアクセスが特定シャードに偏ることがあります。CloudWatchカスタムメトリクスでシャード別のスロットリングを継続監視します。

cloudwatch = boto3.client("cloudwatch")

def record_throttle_event(tenant_id: str, shard_id: int) -> None:
 cloudwatch.put_metric_data(
  Namespace="SaaS/DynamoDB",
  MetricData=[{
"MetricName": "ShardThrottleCount",
"Dimensions": [
 {"Name": "TenantId", "Value": tenant_id},
 {"Name": "ShardId","Value": str(shard_id)},
],
"Value": 1,
"Unit": "Count",
  }]
 )

このメトリクスに対してCloudWatchアラームを設定し、特定シャードのスロットリングが継続する場合はシャード増設を自動で通知する仕組みを作ると、運用の抜け漏れを防げます。

4. read replicaスケーリング

4-1. Auroraクラスター構成とread replica上限

Auroraクラスターは共有分散ストレージを核としたアーキテクチャを採用しています。writerインスタンス(プライマリ)とread replica(Auroraレプリカ)は同一のクラスターストレージを参照し、データは3つのAZにまたがる6ストレージノードへ自動複製されます。

この構造の最大の特性は、read replicaがストレージを共有しているため物理的なデータコピーを必要としない点です。writerがページを更新すると、そのログレコードのみがreplicaへ伝達されます。ストレージ全体のデータ転送が不要であるため、replicaラグが極めて小さく保たれます。

Auroraクラスターの主要エンドポイント:

Aurora vs RDS リードレプリカ上限:

テナント数の増加に伴う読み取り需要の急増には、Aurora Auto ScalingでCPU使用率やreplicaラグを指標にread replicaを自動スケールアウト/インします。

resource "aws_appautoscaling_target" "aurora_replicas" {
  max_capacity = 15
  min_capacity = 2
  resource_id  = "cluster:${aws_rds_cluster.saas_db.cluster_identifier}"
  scalable_dimension = "rds:cluster:ReadReplicaCount"
  service_namespace  = "rds"
}

resource "aws_appautoscaling_policy" "aurora_replica_cpu_policy" {
  name= "saas-aurora-replica-cpu-tracking"
  policy_type  = "TargetTrackingScaling"
  resource_id  = aws_appautoscaling_target.aurora_replicas.resource_id
  scalable_dimension = aws_appautoscaling_target.aurora_replicas.scalable_dimension
  service_namespace  = aws_appautoscaling_target.aurora_replicas.service_namespace

  target_tracking_scaling_policy_configuration {
 predefined_metric_specification {
predefined_metric_type = "RDSReaderAverageCPUUtilization"
 }
 target_value = 70.0
 scale_in_cooldown  = 300
 scale_out_cooldown = 60
  }
}

4-2. reader endpointとカスタムエンドポイント

Auroraは読み取りトラフィックを制御するための2種類のエンドポイントを提供します。

reader endpoint(クラスター読み取りエンドポイント):

reader endpointは単一のDNS名で全Auroraレplicaへ読み取り接続をラウンドロビン分散します。アプリケーションは1つのエンドポイントを参照するだけで、Aurora側がreplicaの増減に応じて自動的に負荷分散先を調整します。レプリカが追加・削除されてもアプリケーション側の接続設定変更は不要です。

# reader endpoint: 単一エンドポイントで全replicaへ自動ラウンドロビン分散
READER_ENDPOINT = "saas-cluster.cluster-ro-xxxx.ap-northeast-1.rds.amazonaws.com"

conn = psycopg2.connect(
 host=READER_ENDPOINT,
 port=5432,
 dbname="saas_db",
 user="app_reader",
 password=get_secret("saas/db/reader_password")
)

カスタムエンドポイント:

カスタムエンドポイントは特定のreplicaグループに向けた専用エンドポイントを定義する仕組みです。SaaSマルチテナント環境では、テナントのティアに応じてエンドポイントを分割することで、上位ティアテナントが高スペックreplicaを優先的に利用できます。

Auroraクラスター構成例(テナントティア別エンドポイント分割):
 ├── writerエンドポイント→ primary(書き込み専用)
 ├── readerエンドポイント→ 全replica(デフォルト読み取り・ラウンドロビン)
 ├── カスタム: premium-ep  → replica-1, replica-2, replica-3 (大メモリインスタンス)
 └── カスタム: standard-ep → replica-4, replica-5 (標準インスタンス)

# Premiumティア専用カスタムエンドポイント(高スペックreplica指定)
resource "aws_rds_cluster_endpoint" "premium_readers" {
  cluster_identifier = aws_rds_cluster.saas_db.id
  cluster_endpoint_identifier = "premium-readers"
  custom_endpoint_type  = "READER"

  # static_members: 指定replicaのみに接続(意図しないreplica追加を防止)
  static_members = [
 aws_rds_cluster_instance.replica_1.id,
 aws_rds_cluster_instance.replica_2.id,
 aws_rds_cluster_instance.replica_3.id,
  ]
}

# Standardティア用カスタムエンドポイント
resource "aws_rds_cluster_endpoint" "standard_readers" {
  cluster_identifier = aws_rds_cluster.saas_db.id
  cluster_endpoint_identifier = "standard-readers"
  custom_endpoint_type  = "READER"

  static_members = [
 aws_rds_cluster_instance.replica_4.id,
 aws_rds_cluster_instance.replica_5.id,
  ]
}

カスタムエンドポイントには static_members(指定replicaのみ) と excluded_members(指定replica以外すべて) の2方式があります。上位ティア専用グループには static_members で高スペックインスタンスを明示指定する設計が、Auto Scalingで追加されたreplicaが意図せずPremiumグループへ混入するのを防止できます。

4-3. テナント別読み取りルーティング

テナントのティア・トラフィック規模に応じて読み取り接続先のreplicaを動的に切り替えることで、ヘビーテナントの読み取り負荷が他テナントへ波及するnoisy neighborを抑制します。

ルーティングパターン比較:

アプリケーション側のルーティング実装例:

READER_ENDPOINTS = {
 "premium":  "premium-readers.cluster-custom-xxxx.ap-northeast-1.rds.amazonaws.com",
 "standard": "standard-readers.cluster-custom-xxxx.ap-northeast-1.rds.amazonaws.com",
 "free":  "saas-cluster.cluster-ro-xxxx.ap-northeast-1.rds.amazonaws.com",
}

def get_read_conn(tenant_context: dict):
 tier = tenant_context.get("tier", "free")
 endpoint = READER_ENDPOINTS.get(tier, READER_ENDPOINTS["free"])
 return psycopg2.connect(host=endpoint, dbname="saas_db",
 user="app_reader", password=get_secret("saas/db/reader_password"))

replicaラグへの対処:

Auroraのreplicaラグは通常数十ms以下と低く、大多数の読み取りユースケースに適合します。ただし次の状況では読み取り先を明示的に制御する必要があります。

• 書き込み直後に同一データを読み取る場合 → writerエンドポイントを使用、またはセッション変数 aurora_replica_read_consistency で整合性レベルを上げる
• 財務・在庫など厳密な整合性が必要な操作 → 常にwriterエンドポイントへ誘導
• セッション変数やトランザクション中のステートに依存する操作 → replicaでは反映されない可能性がある

def query_with_consistency(tenant_id: str, sql: str, require_strong: bool = False):
 """整合性要件に応じてwriter/readerを自動選択する。"""
 if require_strong:
  conn = get_write_conn()# 財務・決済など強整合性ケースはwriter
 else:
  tier = get_tenant_tier(tenant_id)
  conn = get_read_conn({"tier": tier})
 return execute(conn, sql)

CloudWatchメトリクス AuroraReplicaLag をreplicaグループ別に監視し、閾値(例: 100ms)超過時にアラームを発報することで、SLAへの影響を早期検知します。

4-4. RDS read replicaとの比較

Auroraを採用しない構成では、Amazon RDS(非Aurora)のread replicaでも読み取りスケールアウトを実現できます。しかしAuroraとRDS(非Aurora)では根本的なアーキテクチャが異なり、SaaSマルチテナントの要件に与える影響も大きく違います。

アーキテクチャの根本的差異:

Auroraのread replicaはクラスターストレージ共有のため、writerがデータを更新してもreplicaは同一ストレージを参照するだけで最新状態を取得できます。物理的なデータ転送が不要であるため、ラグが通常数十ms以下に収まります。

RDS(非Aurora)のread replicaは物理レプリケーション(MySQLではbinlog、PostgreSQLではWAL)によりプライマリからreplicaへデータを転送します。ネットワーク帯域・ディスクI/O・replicationスレッドの処理速度に依存するため、書き込み負荷が高い環境ではラグが数百ms〜数秒に達します。

詳細比較:

SaaSマルチテナント環境での選択指針:

テナント数が多く読み取り需要の急増が見込まれる本番SaaS環境では、次の理由からAuroraを優先します。

• 最大15台 + Auto Scalingでテナント増に追随したread scaleoutが可能
• カスタムエンドポイントによるティア別QoS保証がネイティブに使える
• フェイルオーバー約30秒以内でマルチテナントのSLAを守りやすい

RDS(非Aurora)を採用するのは、コスト最優先でテナント数が少なく、アプリケーション設計でreplicaラグを許容できる場合に限定されます。

5. DynamoDBマルチテナントデータ層設計

DynamoDBはスキーマレスかつサーバーレスで自動スケールする特性から、マルチテナントSaaSのデータ層に採用されるケースが増えています。しかし、マルチテナント特有の偏ったアクセスパターンを考慮しないキー設計はスロットリングとnoisy neighborを招きます。本節では、パーティションキー戦略・write sharding・ホットパーティション上限の仕組み、そしてGlobal Tablesを用いたマルチリージョン設計を解説します。

5-1. パーティションキー戦略(TENANT#プレフィックス・GSI活用)

マルチテナントDynamoDBのキー設計でまず決めるのがパーティションキー(PK)の粒度です。Pool型テナントでは複数テナントが同一テーブルを共有するため、アイテムをテナント単位で確実に識別しつつ書き込みが特定パーティションに偏らない設計が求められます。

TENANT#プレフィックスによる名前空間分離

最も一般的なアプローチは、PKに TENANT#<tenantId> というプレフィックスを付与し、ソートキー(SK)にエンティティ種別と識別子を持たせるシングルテーブル設計です。

PK: TENANT#tenant-001  SK: ORDER#order-9001
PK: TENANT#tenant-001  SK: TICKET#ticket-5555
PK: TENANT#tenant-002  SK: ORDER#order-0042

このプレフィックス規則により、TENANT#tenant-001 のデータが誤って別テナントから参照されるアクセス漏えいリスクを低減できます。IAMポリシーの dynamodb:LeadingKeys 条件キーと組み合わせることで、テナントが自身のPKプレフィックス以外にアクセスできないよう強制できます。

{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:PutItem"],
  "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/SaaSAppTable",
  "Condition": {
 "ForAllValues:StringLike": {
"dynamodb:LeadingKeys": ["TENANT#${aws:PrincipalTag/tenantId}*"]
 }
  }
}

Cognitoのカスタム属性に tenantId を設定し、IdP発行のJWTから aws:PrincipalTag/tenantId を引き継ぐことで、テナントごとに独立したデータアクセス制御をIAMレイヤーで実現できます。

GSIを用いたクロステナントクエリ

管理者ダッシュボードや課金集計では、全テナントを横断してデータを集計したいケースがあります。テナントPKでデータが分散しているため、単純なScanは全パーティションを走査しコスト・レイテンシが増大します。GSI(Global Secondary Index)を活用することでこの課題を緩和できます。

例えば、テナントのティア(tier)をGSI-PKに設定した tier-createdAt-index を作成すると、ENTERPRISE ティアの全テナントを日付範囲で効率よくクエリできます。

メインテーブル:
PK: TENANT#tenant-001 SK: ORDER#2026-06-01#order-9001
GSI-PK: TIER#enterprise  GSI-SK: 2026-06-01T09:00:00Z

ただしGSI-PKのカーディナリティが低い(例: tier=3種類)場合、GSI内でもパーティション偏りを生じさせます。GSI-PKにシャードサフィックスを付与してカーディナリティを上げるか、GSIへのアクセスをバッチ用途に限定する設計を推奨します。

ソートキーによる範囲クエリの最適化

begins_with や between などのSK条件式を使うことで、テナント内の特定エンティティ・期間・IDレンジを効率的に取得できます。

KeyConditionExpression: PK = "TENANT#tenant-001"
  AND begins_with(SK, "ORDER#2026-06")
ScanIndexForward: false

SKに日付プレフィックス(ORDER#YYYY-MM-)を含めることで、月次・年次の範囲クエリも単一QueryAPIで完結し、Scan不要でコストを抑えられます。

5-2. write shardingとDynamoDB

テナント数が増えると、特定の大テナントが単一パーティションへ書き込みを集中させスロットリングが発生します。write shardingはこの問題を解決するための設計パターンです。

サフィックスによるwrite sharding(TRAP④)

write shardingでは、tenant-idにランダムまたは決定論的なサフィックスを付与し、書き込みを複数パーティションに分散させます。

PK: TENANT#tenant-001-0 # シャード0
PK: TENANT#tenant-001-1 # シャード1
PK: TENANT#tenant-001-2 # シャード2
PK: TENANT#tenant-001-3 # シャード3

書き込み時はアイテムIDのハッシュでシャード番号を決定し、読み取り時は全シャードをParallel Queryで集約します。

import hashlib
import concurrent.futures
import boto3
from boto3.dynamodb.conditions import Key

N_SHARDS = 4
table = boto3.resource('dynamodb').Table('SaaSAppTable')

def write_item(tenant_id, item_id, data):
 shard_id = int(hashlib.md5(item_id.encode()).hexdigest(), 16) % N_SHARDS
 pk = f"TENANT#{tenant_id}-{shard_id}"
 table.put_item(Item={"PK": pk, "SK": f"ORDER#{item_id}", **data})

def read_all_shards(tenant_id):
 def query_shard(shard_id):
  return table.query(
KeyConditionExpression=Key('PK').eq(f'TENANT#{tenant_id}-{shard_id}')
  )['Items']
 with concurrent.futures.ThreadPoolExecutor(max_workers=N_SHARDS) as ex:
  results = list(ex.map(query_shard, range(N_SHARDS)))
 return [item for sublist in results for item in sublist]

設計上の注意: シャード数は後から変更しにくい点に注意してください(既存アイテムのPKハッシュ変更に伴う移行コスト増大のため)。大テナントの最大書き込みスループットを初期設計で見積もり、シャード数を決定してください。1,000 WCU/s以内のテナントであればshardingは不要です。

複合パーティションキーによる自然な負荷分散

サフィックスによるshardingの代わりに、PKをより細かい粒度のエンティティに分解することで自然に負荷を分散させる方法もあります。

# 変更前: 大テナントの全Orderが同一パーティションに集中
PK: TENANT#tenant-001 SK: ORDER#order-9001

# 変更後: テナント×カテゴリでパーティション分散
PK: TENANT#tenant-001|CAT#electronics SK: ORDER#order-9001
PK: TENANT#tenant-001|CAT#apparel  SK: ORDER#order-0042

カテゴリ・日付・地域など業務的に意味のある次元をPKに組み込むことで、アクセスパターンと分散が自然に一致したshardingを実現できます。

on-demandキャパシティモードの活用

テナントごとのトラフィックパターンが予測困難な場合は、on-demandキャパシティモードの採用を検討してください。on-demandはアクセス量に応じて自動でキャパシティをスケールし、事前見積もりが不要です。ただしコストがprovisionedより高くなる傾向があるため、安定したトラフィックが見込めるテーブルはprovisionedへの移行を検討します。

5-3. パーティション上限とnoisy neighborの関係

DynamoDBのスケーリング機構を正しく理解することは、マルチテナントアーキテクチャの安定運用に不可欠です。

パーティション上限の正確な理解(TRAP③)

DynamoDBテーブルのデータは内部的に複数パーティションに分散して保存されます。1パーティションが提供できるスループット上限は3,000 RCU/s・1,000 WCU/sです。テーブル全体のスループットはパーティション数に比例して増加しますが、特定パーティションへのアクセスがこの上限を超えると ProvisionedThroughputExceededException によるスロットリングが発生します。

DynamoDBテーブル
┌──────────────────────────────────────────────────────────────┐
│  パーティション A │  パーティション B│
│  TENANT#tenant-001 〜 100  │  TENANT#tenant-101 〜 200 │
│  上限: 3,000 RCU/s, 1,000 WCU/s │  上限: 3,000 RCU/s, 1,000 WCU/s│
│ ││
│  ⚠️ tenant-001が急増  │  問題なし  │
│  → 上限超過 → スロットリング││
│  → 同パーティションの ││
│ tenant-002〜100も巻き込まれる│  │
└──────────────────────────────────────────────────────────────┘

ナイーブに TENANT#<tenantId> をPKとすると、大テナントのデータが単一パーティションに集中し、そのテナントが上限を超えた瞬間に同パーティション上の全テナントがスロットリングの影響を受けるのがnoisy neighbor問題の本質です。

adaptive capacityとsplit for heat — 自動対応の限界(TRAP⑤)

DynamoDBにはホットパーティション問題を緩和する自動機能があります。

adaptive capacityは、テーブル全体のプロビジョンドスループットに余裕がある場合に、高トラフィックパーティションへのキャパシティを自動的にブーストします。例えばテーブル全体10,000 WCU/sをプロビジョンし利用が6,000 WCU/sの状態で特定パーティションへ書き込みが急増した場合、adaptive capacityが一時的にそのパーティションへのキャパシティを増やします。

split for heatは、持続的な高スループットが検出されたパーティションを2分割し、各々にキャパシティを配分します。パーティション分割はバックグラウンドで自動実行されます。

CloudWatchによるホットパーティション検知

ThrottledRequests メトリクスがスパイクしたらホットパーティションの兆候です。ConsumedWriteCapacityUnits と ProvisionedWriteCapacityUnits の比率を継続的に監視し、特定テナントの書き込み急増をいち早く検知します。

推奨CloudWatchアラーム:
- ThrottledRequests > 0 (5分間合計)→ アラーム(即時調査)
- ConsumedWCU/ProvisionedWCU > 0.80 (15分平均) → 警告(容量見直し)
- SystemErrors > 0 (5分間合計)→ アラーム(内部障害)

5-4. Global Tablesとマルチリージョンテナント

グローバル展開するSaaSでは、テナントのデータをそのテナントが所在するリージョンに物理的に近い場所に置くことでレイテンシを削減できます。DynamoDB Global Tablesはこれを実現するマネージドなマルチリージョンレプリケーション機能です。

Global Tablesの仕組み

Global Tablesを有効化すると、指定した複数リージョン間でテーブルデータが自動的にレプリケーションされます。各リージョンのレプリカは完全な読み書き権限を持ち、どのリージョンからも書き込めます。同一アイテムへの同時書き込みが競合した場合はlast-writer-wins(タイムスタンプベース)方式で自動解決されます。

東京リージョン (ap-northeast-1) バージニア (us-east-1)
┌───────────────────────────────┐ ┌───────────────────────────────┐
│  Global Table レプリカ│ ◀──────▶ │  Global Table レプリカ│
│  (読み書き可能)  │  双方向│  (読み書き可能)  │
└───────────────────────────────┘  レプリカ  └───────────────────────────────┘
▲  ▲
│ アジアテナントが書き込み │ 北米テナントが書き込み

レプリケーションの伝播遅延(通常数百ミリ秒〜数秒)があるため、強整合性が必要な読み取りには ConsistentRead: true を設定し、ローカルレプリカから最新データを取得してください。

テナント別リージョン割り当て設計

マルチリージョン構成で重要なのは、テナントが常にホームリージョンへ読み書きする設計です。全リージョンへの書き込み混在はlast-writer-wins競合を頻発させ、データ不整合リスクを高めます。

推奨する設計フロー:

1. テナントオンボーディング時にホームリージョン(最寄りリージョン)を決定し、Control Planeのテナントメタデータ(例: Cognitoカスタム属性・Control Plane専用DynamoDBテーブル)に記録します。
2. リクエストルーティングはRoute 53のレイテンシルーティングポリシーまたはCloudFront + Lambda@Edgeで、テナントのリクエストを常にホームリージョンのAPIエンドポイントへ誘導します。
3. 読み取り整合性は原則ホームリージョンからの結果整合性読み取りとし、金融系操作など厳密な整合性が必要な場面では ConsistentRead: true を使います。

データレジデンシーとGlobal Tables

欧州テナント(GDPR対象)が「データをEUリージョン外に保管しない」と要求する場合、Global TablesでEU以外のリージョン(例: 東京・バージニア)にもレプリカを作成するとデータレジデンシー要件に違反します。

対策として:
– EU専用テーブル: EUリージョン(eu-west-1等)のみにレプリカを持つGlobal Tablesグループを別途作成し、EUテナントを分離します。
– Silo化: コンプライアンス要件の厳しいテナントはPool型からSilo型へ移行し、EU専用AWSアカウント・リージョンに完全分離します。

Global Tablesの使用と各国データローカライゼーション法の適合関係は、法務・コンプライアンスチームと連携して設計段階で確認してください。

6. データ層のnoisy neighbor対策

6-1. noisy neighborのデータ層パターン

noisy neighbor問題とは、マルチテナント環境において一部の高負荷テナントが共有リソース(DB接続・DynamoDBパーティション・ストレージIOPS)を占有し、他テナントのレイテンシ増加・スロットリング・接続エラーを引き起こすパターンです。

データ層での主なnoisy neighborパターンを整理します。

対策は2方向あります。ガバナンス(リミット設定)でテナントごとのリソース上限を設け、設計(データモデル・ストレージ選定)でそもそも競合が起きにくい構造にすることです。6-2〜6-4でそれぞれを具体的に説明します。

noisy neighborの早期検知と対処フロー

noisy neighbor問題は発生してから対処するよりも、閾値アラームで早期に検知し、段階的に対処することが重要です。以下の3段階エスカレーションが実践的です。

テナント分類とリソース制限の事前設計

noisy neighbor問題の発生確率を下げるには、テナント登録時から利用量の分類(ティア)を設け、各ティアに対してリソース上限を事前設定しておくことが重要です。

6-2. RDS Proxyのリミット(MaxConnectionsPercent per tenant)

RDS Proxyは接続多重化でテナント増に耐えますが、noisy neighborテナントが大量接続を占有するリスクは残ります。これを抑制するのがMaxConnectionsPercentパラメータです。

MaxConnectionsPercentの仕組み

MaxConnectionsPercentは、プロキシがDBに対して確立できる最大接続数を、DBのmax_connectionsに対するパーセンテージで制限するパラメータです。

# 例: DBのmax_connections=1,000の場合
MaxConnectionsPercent=100 → プロキシの最大接続数=1,000
MaxConnectionsPercent=50  → プロキシの最大接続数=500

pool-per-tenant構成(テナントごとに専用Proxyを用意する方式)では、各Proxyに異なるMaxConnectionsPercentを設定することで、テナントNがDB接続の何%まで使えるかを制御できます。

pinningとnoisy neighborの関係

接続ピン留め(pinning)もnoisy neighborの文脈で重要です。テキストサイズ16KB超のステートメントやSET文・一時テーブル操作など、接続の再利用が安全でない操作ではRDS Proxyがセッションを特定接続にピン留め(pinning)し、セッション終了まで多重化が行われません。

ピン留めが多発するテナントは接続プーリング効果を享受できず、実質的に接続を占有し続ける状態になります。アプリケーション設計でセッション固有のステートを排除し、ピン留めを最小化することがnoisy neighbor対策としても有効です。

MaxConnectionsPercent適用後の監視

MaxConnectionsPercentを設定した後は、以下のCloudWatchメトリクスで設定効果を確認します。

また、pool-per-tenant構成では複数ProxyのMaxConnectionsPercent合計がDBのmax_connectionsを超えないよう、テナントオンボーディング時に計算するプロビジョニングチェックを自動化することを推奨します。

6-3. DynamoDBのadaptive capacity(限界を含む)

DynamoDBのadaptive capacityはnoisy neighborに対する自動緩和機能ですが、その限界を正しく把握することが重要です。

adaptive capacityとsplit for heatの動作

adaptive capacityの限界

adaptive capacityとsplit for heatはあくまで自動緩和機能であり、良いキー設計の代替にはなりません。

• adaptive capacityはパーティション上限(3,000 RCU/s・1,000 WCU/s)を恒常的に超えるアクセスには対応できません
• split for heatは分割後も同じパーティション範囲にアクセスが集中すると、繰り返しスロットリングが発生します
• on-demand課金モードでもパーティション単位の上限制約は同様に存在します

根本対策はデータモデル設計です。write sharding(TENANT#1-0/TENANT#1-1)や複合パーティションキー(TENANT#1|TICKET#4)で高ボリュームテナントのアクセスを複数パーティションに分散させることが必須です。adaptive capacityへの過度な依存はスロットリングと見えにくいレイテンシ悪化を招きます。

6-4. プロビジョンドIOPS分離

RDS/Auroraのストレージ層では、テナント間のI/O競合もnoisy neighbor問題として顕在化します。

ストレージタイプとIOPS特性

重テナントのI/O集中が問題になる場合の対策オプションです。

1. gp3へのアップグレード: gp2のバーストクレジット依存を解消し、安定したベースラインIOPSを確保します。コスト効率も改善する場合があります。
2. io1/io2への移行: SLAが厳しいテナント群に対してIOPS保証ストレージを適用し、予測可能なパフォーマンスを提供します。
3. Pool→Silo移行: I/O集中テナントを専用DBインスタンスに移行することで物理的にI/Oを分離します(Vol1のPool/Silo選定ロジックとの接続点)。
4. Auroraへの移行: Auroraは分散ストレージ(6コピー)でI/O特性がRDSと異なります。特定テナントのI/Oが他に波及しにくい構造のため、多数の中小テナントが混在する構成に適します。

必要IOPSの見積もり

ストレージタイプを決定する前に、必要IOPSを以下の手順で見積もります。

1. 現状把握: CloudWatchのWriteIOPS・ReadIOPS・BurstBalance(gp2のみ)を1週間分確認
2. ピーク算出: 最大テナント数×テナントあたり最大IOPS = 必要最大IOPS
3. タイプ選定判断:

BurstBalance が繰り返し 0% に近づく  → gp3またはio1/io2に移行
ピーク IOPS > 16,000  → io1/io2(高IOPS特化)を検討
ストレージ料金を抑えつつ安定化  → gp3(コストバランス最良)
IOPS SLA保証が必須 → io2 Block Express

gp3の場合、追加IOPSをプロビジョニングする際のコスト計算: 3,000 IOPS(標準)を超えるIOPS = (追加IOPS) × $0.02/IOPS-month(東京リージョン参考値)。必要IOPSを正確に見積もることでコストの無駄なオーバープロビジョニングを防ぎます。

noisy neighbor対策の全体まとめ

7. 運用監視とコスト最適化

7-1. データ層メトリクスの監視

SaaSマルチテナント環境では、テナント単位でのメトリクス可視化が運用品質の鍵です。CloudWatchを中心に監視すべき指標を整理します。

RDS Proxy / RDS / Aurora 監視メトリクス

DynamoDB 監視メトリクス

per-tenant観測の実現方法

CloudWatchのデフォルトメトリクスはインスタンス・テーブル単位であり、テナント単位の可視化は行えません。テナントごとのメトリクスにはCloudWatch Custom Metricsへの書き込みが有効です。

import boto3, time

cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-1')
cloudwatch.put_metric_data(
 Namespace='SaaS/TenantMetrics',
 MetricData=[{
  'MetricName': 'DBQueryDuration',
  'Dimensions': [{'Name': 'TenantId', 'Value': tenant_id}],
  'Value': duration_ms,
  'Unit': 'Milliseconds',
  'Timestamp': time.time()
 }]
)

アプリケーション層でテナントIDをディメンションとしてメトリクスを送信することで、CloudWatchダッシュボードにてテナントごとのクエリ時間・エラー率・接続数を可視化できます。CloudWatch Logs Insightsでテナントフィールドを持つログをクエリすることも有効です。

DynamoDB Contributor Insightsによるホットテナント検知

DynamoDB Contributor Insightsを有効化すると、最もアクセスが集中しているパーティションキーをリアルタイムで特定できます。

aws dynamodb update-contributor-insights \
  --table-name TenantData \
  --contributor-insights-action ENABLE

Contributor Insightsの「Most accessed items」ビューでnoisy neighborテナントのパーティションキーが上位に現れた場合、write shardingへの移行またはSilo化を優先的に検討します。なお、Contributor Insightsはデータ量に応じた追加コストが発生するため、問題解決後は無効化することも選択肢の一つです。

CloudWatch Logs Insightsでは以下のクエリでテナントごとの遅いクエリを特定できます。

fields @timestamp, tenant_id, query_duration_ms
| filter query_duration_ms > 500
| stats count(*) as slow_count, avg(query_duration_ms) as avg_ms by tenant_id
| sort slow_count desc
| limit 20

アラーム設計のベストプラクティス

CloudWatch AlarmではANOMALY_DETECTION_BAND(異常検知バンド)を活用すると、静的閾値では捉えにくいトラフィックパターンの異常を検知できます。SaaSでは曜日・時間帯によるアクセス量の変動が大きいため、静的閾値よりも機械学習ベースの異常検知を優先することを推奨します。

CloudWatch Dashboardの推奨構成

SaaSデータ層の運用ダッシュボードは、以下の3ペインで構成することを推奨します。

ダッシュボードはAWS CDKでコード管理し、テナント増加に伴うカスタムディメンション追加を自動化することが理想的です。

7-2. コスト最適化

データ層のスケールアウトはパフォーマンス向上と同時にコスト増を招きます。以下の施策を組み合わせてコストとパフォーマンスのバランスをとります。

RDS / Aurora コスト最適化

Aurora Application Auto Scalingでリードレプリカ数を自動調整する設定例です。

import boto3

autoscaling = boto3.client('application-autoscaling')
autoscaling.register_scalable_target(
 ServiceNamespace='rds',
 ResourceId='cluster:my-aurora-cluster',
 ScalableDimension='rds:cluster:ReadReplicaCount',
 MinCapacity=1,
 MaxCapacity=5
)
autoscaling.put_scaling_policy(
 ServiceNamespace='rds',
 ResourceId='cluster:my-aurora-cluster',
 ScalableDimension='rds:cluster:ReadReplicaCount',
 PolicyName='aurora-reader-scaling',
 PolicyType='TargetTrackingScaling',
 TargetTrackingScalingPolicyConfiguration={
  'TargetValue': 70.0,
  'PredefinedMetricSpecification': {
'PredefinedMetricType': 'RDSReaderAverageCPUUtilization'
  },
  'ScaleOutCooldown': 300,
  'ScaleInCooldown': 300
 }
)

スケールアウト時は新規レプリカが読み取りトラフィックを受け入れられるまでのウォームアップ時間(通常数分)を考慮した閾値設定が重要です。

DynamoDB コスト最適化

on-demand/provisionedの選択基準として、テナントティア別に使い分けることも有効です。エンタープライズティアはトラフィックが予測しやすいためprovisionedで最適化し、スタータープランはon-demandで低コストを維持するというパターンが実践されます。

8. まとめとVol1/Vol2との連携

8-1. 本記事のまとめ

本記事では、SaaSマルチテナントのデータ層がテナント増加・トラフィック増に耐える設計を解説しました。重要な技術ポイントを整理します。

RDS Proxy接続プーリング
– 多数のクライアント接続を多重化しDB側接続数を削減。「too many connections」とメモリ過負荷を防ぎます
– pool-per-tenantはProxy/ターゲットグループ分離で実現。大多数のテナントはshared poolを基本とします
– pinning(16KB超ステートメント・セッション固有ステート)はプーリング効果を低下させるため、設計で最小化します

テナント別シャーディング
– 高成長テナントを水平シャーディングで分散。シャードキー設計と将来のリバランスを事前に考慮します
– Pool→Silo移行の判断軸(Vol1参照)と連携し、重テナントは専用DBインスタンスへ移行します

read replicaスケーリング
– Aurora: writer + 最大15リードレプリカ、reader endpointで読み取りを負荷分散
– テナント/ティア別ルーティングで重テナントを専用レプリカへ。レプリカラグのSLA設定を忘れずに

DynamoDB設計
– パーティション上限(3,000 RCU/s・1,000 WCU/s)を超えるテナントにはwrite shardingまたは複合パーティションキーが必須
– adaptive capacity/split for heatは自動緩和機能であり、良いキー設計の代替ではありません

noisy neighbor対策
– MaxConnectionsPercentでテナントごとの接続上限を設定し、接続占有リスクを抑制します
– DynamoDB Contributor Insightsでホットテナントを早期に検知します
– 繰り返しnoisy neighborになるテナントはSilo化を検討します

運用監視とコスト最適化
– per-tenant Custom MetricsとContributor Insightsで問題テナントを可視化します
– RDS Proxy導入でインスタンスサイズを抑制し、Aurora Serverless v2でACUを自動スケールします
– DynamoDB: on-demand/provisioned選択とAuto Scalingでコストとパフォーマンスのバランスをとります
– CloudWatch Logs InsightsとANOMALY_DETECTION_BANDの組み合わせで、曜日・時間帯の変動を考慮した動的閾値監視を実現します

設計判断のクイックリファレンス

8-2. シリーズ連携

本シリーズ3巻でSaaS本番運用の主要レイヤーを網羅しました。

3つのレイヤー(分離基盤→認証認可→データ層スケーリング)を重ね合わせることで、エンタープライズ対応のSaaS基盤が完成します。データ層のnoisy neighbor問題が発生した際はVol1のPool/Silo移行判断と組み合わせ、根本的な分離強化を検討してください。

各Volumeの判断軸との連携

3巻の内容は独立していますが、実務では以下のように連携して意思決定します。

今後のデータ層拡張ポイント

本記事の設計が定着したあと、さらにスケールさせる場合の検討事項を以下に示します。

• グローバル展開: Amazon Aurora Global Databaseを活用し、ホームリージョンでの書き込みと海外リージョンでの読み取りを分離。テナントごとのデータレジデンシー要件に対応
• 分析基盤の分離: 重いレポート・集計クエリはAmazon Redshift Serverlessまたはゼロ-ETL連携でOLTPから切り離し、運用DBへの影響を排除
• イベント駆動アーキテクチャ: DynamoDB StreamsとLambdaを活用し、テナントデータの変更イベントを下流サービスへファンアウト。データ層スケーリングとイベントバスの統合が次の拡張テーマです

▶ SaaS Vol1: マルチテナント分離基盤（サイロ・プール・ブリッジ設計）

▶ SaaS Vol2: エンタープライズ認証連携・Verified Permissions・M2M