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대로 통합한 결과 한 번의 장애로 전체 시스템이 동시에 멈추는 구성이 됨
• SQL Server의 RDS에서 인스턴스 크기를 올렸을 때 총액이 예상보다 크게 늘어남

가능한 원인(가능성이 높은 순)

1. 01

   라이터는 수평 분할할 수 없다는 전제가 공유되지 않음

   RDS의 읽기 전용 복제본(리드 레플리카)으로 늘릴 수 있는 것은 읽기 처리뿐입니다. 하나의 쓰기 워크로드를 여러 인스턴스로 자동 분산하는 구조는 RDS에 없습니다. 따라서 "작은 여러 대"로 할 경우, 반드시 데이터베이스 단위·기능 단위로 워크로드를 나누는 설계 판단이 수반됩니다.

2. 02

   병목이 CPU가 아님

   CPU 이외(IOPS 상한, EBS 처리량 상한, 락 경쟁, 단일 스레드로 실행되는 배치)가 제한 요인인 경우, 인스턴스 클래스를 올려도 vCPU만 남습니다. 무엇이 제한 요인인지 측정하지 않고 크기를 정하면 이런 상태가 됩니다.

3. 03

   인스턴스 크기에 비례하는 자원과 그렇지 않은 자원이 섞여 있음

   vCPU·메모리·네트워크 대역·EBS 대역은 대체로 인스턴스 크기와 함께 늘어나지만 증가 방식은 동일하지 않습니다. 또한 스토리지의 프로비저닝 IOPS는 인스턴스 클래스와 별도로 설정하는 값으로, 클래스를 올리는 것만으로는 늘지 않습니다.

4. 04

   라이선스 비용의 과금 체계가 고려되지 않음

   SQL Server의 라이선스 포함 모델에서는 라이선스 비용이 vCPU 수에 연동됩니다. 총 vCPU 수가 같아도 대수 구성이 바뀌면 대당 최소 구성이나 이중화 방식이 바뀌어 총액 비교가 단순한 합산이 되지 않는 경우가 있습니다. 금액은 반드시 AWS Pricing Calculator와 자사의 계약 조건으로 산출하십시오.

5. 05

   장애의 영향 범위(blast radius)가 설계 항목이 되지 않음

   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를 늘려도 한 처리의 소요 시간은 줄지 않습니다. 쿼리 쪽 병렬도 설정을 먼저 확인합니다.

• 커넥션 풀 설정 확인하기

  DatabaseConnections가 상한 근처라면 인스턴스 크기보다 애플리케이션 쪽 풀 설정이 원인인 경우가 있습니다.

• 스토리지의 프로비저닝 값과 실측값 대조하기

  프로비저닝 IOPS에 비해 실측이 항상 낮다면 제한 요인은 스토리지가 아닙니다. 반대로 딱 붙어 있다면 클래스 변경으로는 해결되지 않습니다.

• 분할 후 필요해지는 횡단 처리 찾아내기

  야간 배치나 집계 처리가 DB를 넘나들고 있지 않은지를 실행 중인 쿼리와 작업 정의에서 확인합니다.

이 문서의 근거와 한계

자주 묻는 질문

이 문서가 다루는 질문

• RDS SQL Server의 처리량을 결정하는 요소
• 8xlarge×3대와 12xlarge×2대 중 어느 쪽이 좋은가
• RDS는 인스턴스를 늘리면 쓰기도 빨라지는가
• 데이터베이스를 나눠야 하는가 1대로 통합해야 하는가

위험도 표시의 의미

• 참조만데이터와 설정을 변경하지 않습니다.
• 낮음영향은 제한적이지만 권한과 부하 확인이 필요합니다.
• 중간성능·락·비용에 영향을 줄 수 있습니다.
• 높음장애·데이터 손실·복구 작업이 발생할 수 있습니다.
• 전문가 검토 필수프로덕션 적용 전 별도 검토가 반드시 필요합니다.

GIIP의 대응 범위

사이징 판단 자체는 실측값만 갖추면 한 번의 작업으로 끝납니다. 어려운 것은 그 이후입니다. 워크로드는 업무의 성장과 함께 변하며, 반년 전에 적절했던 구성이 지금도 적절하다는 보장은 없습니다. GIIP에서는 AWS와 Azure 상의 여러 데이터베이스 및 약 30개의 웹 서비스에 대해 CPU·메모리·I/O 지표를 AI 에이전트가 지속적으로 수집하고, 상한에 근접하는 경향이 나타난 시점에 사람인 전문가가 구성 재검토 필요성을 판단합니다. 사이징을 "그때그때의 상담"이 아니라 추이 모니터링에서 시작되는 정기 업무로 다루는 방식입니다.

관련 서비스

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