AWS RDSでのAutoScaling設定を行うための基礎知識

最終更新日:2025/11/16 公開日:2025/11/13

はじめに

AWS が提供するオートスケーリングは、インスタンスの CPU 利用率などをトリガとして台数を自動的に調整する仕組みです。インスタンスの起動には一定の時間を要するため、突発的なピークに即時対応できるわけではありませんが、長期的な運用では負荷に応じたインスタンス数の確保が可能となり、リソース利用とコストの最適化を行うことができます。

この技術は特に EC2 インスタンスにおいて広く利用されています。しかし、アプリケーションサーバーの台数が増えると同時にデータベース側も増加したアクセスに耐えられるだけのリソースを確保しなければ、システム全体として正常に動作しません。そのため、AWS ではデータベースサービスである RDS においても、スケーリングに関する仕組みが提供されています。

ただし、RDS のスケーリングは EC2 のオートスケーリングと比べて制限や前提条件が多く、設定方法も異なります。本記事では、その違いと設定の考え方を解説します。

RDSオートスケーリングを利用するための前提

RDS を複数台で運用する場合は、書き込みが可能な Writer インスタンスと、読み取り専用の Reader インスタンスを組み合わせたクラスター構成を取ります。オートスケーリングで増減できるのは Reader インスタンスのみであり、Writer インスタンスを自動的に増やすことはできません。RDS は複数ノードで同時に書き込みを処理する方式を採用しておらず、書き込み先は常に一台に限定されるという設計によるものです。

そのため、短時間に大量の書き込みが集中するようなワークロードでは、Reader を増やしても根本的な解決にはなりません。Writer インスタンスのスペックを引き上げるか、もしくはそもそも書き込み量が多い用途に適した別のデータベースサービスを選択する必要があります。たとえば、DynamoDB のようなスケールアウト可能なシステムを利用することで、大量書き込みへの耐性を高めることができます。

また、アプリケーション側が適切に Reader へ読み取り処理を振り分ける仕組みを持っていることも重要です。多くのウェブフレームワークには複数のデータベース接続を扱う機能が用意されているため、Reader を利用する設定を正しく構成しておく必要があります。

これらの前提を満たしていない状態でインスタンス数だけを増やしても、構成上のボトルネックは解消されず、結果としてコストが増えるだけになってしまいます。オートスケーリングを導入する前に、アプリケーションとデータベースの役割分担を見直し、適切なサービス選択と設計を整えておくことが重要です。

RDS Aurora を利用する必要がある

RDS のオートスケーリング機能を利用するには、Aurora を選択する必要があります。RDS for MySQL などの通常の RDS サービスでもリードレプリカの作成は可能ですが、インスタンス数を自動で増減させる仕組みには対応していません。

RDS for MySQL のリードレプリカにはそれぞれ固有のエンドポイントが割り当てられます。アプリケーション側は、接続先のレプリカを自ら選び、読み取り処理を分散させるための処理を実装しなければなりません。

一方で、Aurora では読み取り専用の共通エンドポイントが１つだけ提供されます。アプリケーションはそのエンドポイントにアクセスするだけで、Aurora クラスター内部で稼働中の Reader インスタンスに自動的に振り分けられます。これにより、アプリケーション側で複雑な分散処理を実装する必要がなくなり、インスタンスの増減にも自動で対応できます。

このように、動的スケーリングを前提とした運用を行う場合は、Aurora の機能が必須となります。

Management Console でできることが限定される

Management Console では、CPU 使用率や接続数をトリガとしたオートスケーリングルールの設定や、リードレプリカの最小数・最大数の指定が可能です。しかし、特定の日時にあわせてスケールアウト・スケールインを行うような、いわゆるスケジュールベースの調整はコンソールから確認や編集を行うことができません。たとえば、月初に負荷が集中することが分かっているため、毎月末日から翌月初めにかけてリードレプリカの最小台数を増やしたいといった需要に対して、2025年11月現在はコンソールでは設定ができません。

このようなスケジュール設定を扱うには、awscli の application-autoscaling を利用する必要があります。CloudShell 上でも利用できますので、環境を用意せずに実行したい場合はそちらを使うと便利です。

以下は、現在登録されているスケジュールアクションの確認と、キャパシティ変更のスケジュールを登録する例です。利用している cron 式は AWS cron 式であり、明確なタイムゾーンを指定しない場合はUTCタイムゾーンとして取り扱われます。通常の cron 式とは異なる点に注意してください。

CLUSTER_NAME="<自身のクラスタ名を設定してください>"

# 現在登録されているスケジュールアクションを確認
$ aws application-autoscaling describe-scheduled-actions \
    --service-namespace rds \
    --resource-id cluster:${CLUSTER_NAME}

# コンソールでAutoScalingルールを設定していない場合は必要
$ aws application-autoscaling register-scalable-target \
    --service-namespace rds \ 
    --resource-id cluster:${CLUSTER_NAME} \ 
    --scalable-dimension rds:cluster:ReadReplicaCount \ 
    --min-capacity 1 \
    --max-capacity 6

# キャパシティの変更スケジュールを予約
$ aws application-autoscaling put-scheduled-action \
    --service-namespace rds \
    --resource-id cluster:${CLUSTER_NAME} \ 
    --scalable-dimension rds:cluster:ReadReplicaCount \
    --scheduled-action-name test-scale-down \ 
    --schedule "cron(0 6 12 11 ? *)" \ 
    --scalable-target-action MinCapacity=1,MaxCapacity=6

スケジュールベースでのスケーリングを活用することで、予測可能な負荷イベントを事前に吸収でき、より安定した運用が可能になります。

まとめ

Aurora のオートスケーリングを利用するには、アプリケーション側の読み取り分離や Writer の制約など、構成とサービス選定に前提条件があります。一部のスケーリング機能は CLI 操作が必須で、Management Console だけでは完結しない点にも注意が必要です。
また、レプリカ追加には数分単位の初期化時間がかかるため、即時応答は期待できず、この遅延を前提にした運用設計が必要です。

こうした特徴を理解したうえで適切に活用すれば、Aurora は安定性と拡張性を両立した運用に大きく貢献します。