AWS RDSで大きいインスタンス1台と小さいインスタンス複数台に分ける場合の違い

この文書の適用条件

そのまま実行できるコマンド

# 対象: Amazon RDS（AWS CLI v2）
# 権限: rds:DescribeDBInstances
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws rds describe-db-instances \
  --query "DBInstances[].{Id:DBInstanceIdentifier,Class:DBInstanceClass,Engine:Engine,\
MultiAZ:MultiAZ,Storage:AllocatedStorage,StorageType:StorageType,Iops:Iops,\
StorageThroughput:StorageThroughput,License:LicenseModel,ReadReplicas:ReadReplicaDBInstanceIdentifiers}" \
  --output table

# 対象: Amazon CloudWatch（名前空間 AWS/RDS）
# 権限: cloudwatch:GetMetricStatistics
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=db-sample-instance \
  --start-time 2026-08-06T00:00:00Z \
  --end-time   2026-08-13T00:00:00Z \
  --period 300 \
  --statistics Average Maximum \
  --extended-statistics p95 p99 \
  --output table

# 対象: Amazon CloudWatch（名前空間 AWS/RDS）
# 権限: cloudwatch:GetMetricStatistics
# 変更作業: なし（参照のみ）
# Production 実行: 可能
for M in ReadIOPS WriteIOPS ReadThroughput WriteThroughput FreeableMemory DatabaseConnections
do
  echo "===== $M ====="
  aws cloudwatch get-metric-statistics \
    --namespace AWS/RDS \
    --metric-name "$M" \
    --dimensions Name=DBInstanceIdentifier,Value=db-sample-instance \
    --start-time 2026-08-06T00:00:00Z \
    --end-time   2026-08-13T00:00:00Z \
    --period 300 \
    --statistics Average Maximum \
    --output text
done

# 対象: Amazon RDS（AWS CLI v2）
# 権限: rds:ModifyDBInstance
# 変更作業: あり（インスタンスクラス変更 → 再起動 / Multi-AZ ではフェイルオーバー）
# Production 実行: 可能だが接続断が発生する。メンテナンス枠内で実施すること
aws rds modify-db-instance \
  --db-instance-identifier db-sample-instance \
  --db-instance-class db.r6i.4xlarge \
  --no-apply-immediately

結果の読み方

こういう状況で使います

• ピーク時にCPU使用率が高止まりし、増設すべきか統合すべきか判断できない
• 「8xlarge×3台」と「12xlarge×2台」のような案が並び、比較の軸が決まっていない
• インスタンスを大きくしたのに期待したほど速くならなかった
• 1台に集約した結果、1回の障害で全システムが同時に止まる構成になっている
• SQL ServerのRDSで、インスタンスサイズを上げた際の総額が想定より大きく増えた

考えられる原因（可能性の高い順）

1. 01

   ライターは水平分割できないという前提が共有されていない

   RDSのリードレプリカが増やせるのは読み取り処理だけです。1つの書き込みワークロードを複数インスタンスへ自動的に分散する仕組みはRDSにはありません。したがって「小さい複数台」にする場合、必ずデータベース単位・機能単位でワークロードを分ける設計判断が伴います。

2. 02

   ボトルネックがCPUではない

   CPU以外（IOPS上限、EBSスループット上限、ロック競合、シングルスレッドで走るバッチ）が律速の場合、インスタンスクラスを上げてもvCPUが余るだけです。何が律速かを測らずにサイズを決めると、この状態になります。

3. 03

   インスタンスサイズに比例する資源とそうでない資源が混在している

   vCPU・メモリ・ネットワーク帯域・EBS帯域は概ねインスタンスサイズとともに増えますが、増え方は同一ではありません。またストレージのプロビジョニングIOPSはインスタンスクラスとは別に設定する値で、クラスを上げただけでは増えません。

4. 04

   ライセンス費用の課金体系が考慮されていない

   SQL Serverのライセンス込みモデルでは、ライセンス費用はvCPU数に連動します。合計vCPU数が同じでも、台数構成が変わると1台あたりの最小構成や冗長構成の取り方が変わり、総額の比較が単純な足し算にならないことがあります。金額は必ずAWS Pricing Calculatorと自社の契約条件で算出してください。

5. 05

   障害の影響範囲（ブラストラディウス）が設計項目になっていない

   1台に集約するほど、その1台の障害・メンテナンス・パラメータ変更ミスが影響する範囲が広がります。逆に台数を増やすと、影響範囲は狭まる代わりに障害の発生機会そのものは増えます。可用性要件が業務ごとに違う場合、分割の判断軸はコストではなく影響範囲になります。

確認手順

1. 1

   現在の構成を一覧化する

   参照のみ

   `aws rds describe-db-instances` でクラス・ストレージ種別・プロビジョニングIOPS・Multi-AZ・リードレプリカの有無を確認します。

2. 2

   CPUをパーセンタイルで測る

   参照のみ

   CPUUtilization の p95・p99・Maximum を、繁忙期を含む期間で取得します。平均値だけでは判断できません。

3. 3

   メモリの充足を測る

   参照のみ

   FreeableMemory の推移と、エンジン側のバッファキャッシュヒット率を併せて見ます。ヒット率が低くFreeableMemoryも小さいなら、メモリが律速です。

4. 4

   I/Oが上限に当たっているか確認する

   参照のみ

   ReadIOPS+WriteIOPS をプロビジョニングIOPSと、ReadThroughput+WriteThroughput をインスタンスクラスのEBS帯域上限と比較します。上限値は現行のAWSドキュメントを参照します。

5. 5

   ワークロードが分離可能かを棚卸しする

   参照のみ

   データベース間をまたぐクエリ、共通のマスタテーブル、分散トランザクションの有無を洗い出します。またぐ処理が多いほど分割コストは上がります。

6. 6

   候補構成で試験する

   低

   スナップショットから復元した検証インスタンスに本番相当のワークロードを流し、候補クラスで指標がどう変わるかを測ります。本番での試行錯誤は避けます。

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• エンジン内部の待機事象を確認する

  CPUもI/Oも上限に達していないのに遅い場合、ロック待ち・ラッチ待ち・ネットワーク待ちが支配的である可能性があります。インスタンスサイズの問題ではありません。

• 単一クエリがシングルスレッドで律速していないか

  巨大なバッチ処理が並列化されていない場合、vCPUを増やしても1本の処理時間は縮みません。クエリ側の並列度設定を先に確認します。

• コネクションプールの設定を確認する

  DatabaseConnectionsが上限付近なら、インスタンスサイズよりアプリケーション側のプール設定が原因である場合があります。

• ストレージのプロビジョニング値と実測値を突き合わせる

  プロビジョニングIOPSに対して実測が常に低い場合、律速はストレージではありません。逆に張り付いているならクラス変更では解決しません。

• 分割後に必要になる横断処理を洗い出す

  夜間バッチや集計処理がDBをまたいでいないかを、実行中のクエリとジョブ定義から確認します。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• RDS SQL Serverのスループットを決める要素
• 8xlarge×3台と12xlarge×2台のどちらがよいか
• RDSはインスタンスを増やせば書き込みも速くなるのか
• データベースを分けるべきか1台に統合すべきか

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

サイジングの判断そのものは、実測値さえ揃えば一度の作業で終わります。難しいのはその後です。ワークロードは業務の成長とともに変わり、半年前に妥当だった構成が今も妥当である保証はありません。GIIPではAWSとAzure上の複数データベースおよび約30のWebサービスについて、CPU・メモリ・I/Oの指標をAIエージェントが継続的に収集し、上限に近づく傾向が出た時点で人間の専門家が構成見直しの要否を判断しています。サイジングを「その都度の相談」ではなく、傾向監視から始まる定常業務として扱う形です。

関連サービス

• データベース性能チューニング
• AWSマネージド運用の範囲を確認する
• クラウドコスト最適化