RDS・Aurora - AWS
最終更新日: 2026-07-26
TOP(About this memo)) > 一覧(AWS) > RDS・Aurora
DBへの接続
- Table PlusやSequel Proなどのクライアントで接続する。
- DBは通常、MySQLのポートなどをセキュリティ上外部に解放しないため、SSH経由でAP/WEBサーバーなどのDMZを踏み台にしてアクセスする。
RDS
- マネージドサービスであり、自動パッチ適用、自動バックアップなどの便利機能を備える。
運用上の重要な設定項目
- DBサブネットグループ: DBを配置できるサブネットの候補群。単一AZ構成であっても、後からマルチAZに変更したりフェイルオーバー先を確保したりするため、複数AZにまたがるサブネットで構成しておくのが基本。
- 保管時の暗号化は作成後に有効化できないサービスが多いため、初回作成時に有効にしておく。
- バックアップウィンドウ(自動バックアップの実行時間帯)はUTCで指定するサービスが多い。日本時間からUTCへの変換(-9時間)を間違えると、想定と異なる時間帯にバックアップが走るため注意。
- 削除保護を有効にすると誤操作によるDB削除を防げる。無効化されている場合、削除時に最終スナップショットを作成するかどうかも合わせて検討する。本番環境では削除保護を有効にし、かつ最終スナップショットを残す設定にしておくのが安全。
- 変更の即時反映設定(次のメンテナンスウィンドウまで待たずに即座に反映するか)は、本番環境ではオフにして意図しないタイミングでの再起動・ダウンタイムを避けるのが基本(検証環境ではオンにして即座に変更を反映させると開発効率が良い)。
- マスターパスワードは平文で設定ファイルに書かず、Secrets Manager等に事前登録した値を参照する形にする。
- インスタンスクラス: EC2でいうインスタンスタイプに相当するもの。Amazon RDSは3種類のインスタンスクラス(スタンダード、メモリ最適化、バースト可能なパフォーマンス)をサポートしている。
- 金額は各エンジンごとに料金体系が異なる。
- インスタンスクラスの変更に伴うシステム停止時間
- 起動時に用意されているMultiAZオプションをオンにすると、自動的に2つのRDSを2つのAZに渡って構築してくれる。この仕組みをレプリケーションと呼ぶ。プライマリへの変更後にセカンダリへの反映が完了してから応答するため、これは同期レプリケーションと呼ばれる。
- 災害などでプライマリが属しているデータセンターに異常が発生し、マスターの機能が停止した場合にはセカンダリが働く。これをフェイルオーバーという。
- フェイルオーバーは通常60〜120秒かかる。大規模なトランザクション等によって増加する場合もある。
- MultiAZ構成でフェイルオーバーした際にエンドポイントは変わらないが、必ずDNSの書き換えが発生する。
- フェイルオーバーが自動的に行われる条件
- マスターのAZ機能停止
- マスターのエラー
- DBインスタンスのサーバータイプ変更
- ソフトウェアのパッチ適用中
- 手動で実施する場合
- Amazon RDSコンソールを開く
- ナビゲーションの[インスタンス]から対象のインスタンスを選択
- [インスタンス]の操作から[再起動]を選択
- [フェイルオーバーし再起動しますか?]をチェック
- リードレプリカとは、プライマリからレプリケーションされた読み込み専用のデータベース。リードレプリカを複数台設置することで、読み込みが多いサービスではデータベースにかかる負荷を分散できる。データの削除(DELETE)、更新(UPDATE)、追加(INSERT)に対してはプライマリが処理を行う。
- どのクエリをどのデータベースに処理させるかはAWS側の設定ではなく、アプリケーション側で実装する必要がある点に注意。WordPressではHyperDBというプラグインを使うことで、Readクエリ(SELECT)をリードレプリカへ、Writeクエリ(DELETE、UPDATE、INSERT)をマスターへルーティングできる(?)。
- さらに可用性を向上させるために、複数のリードレプリカへのルーティングをロードバランサーで負荷分散させる方法もある。
CPUクレジットについて(バースト可能なパフォーマンスインスタンス)
| モデル |
vCPU |
CPUクレジット/時間 |
メモリ(GiB) |
ネットワークパフォーマンス |
| db.t2.small |
1 |
12 |
2 |
低〜中 |
| db.t2.medium |
2 |
24 |
4 |
低〜中 |
- ベースラインパフォーマンス
- 各モデルにはベースラインパフォーマンスが設定されている。db.t2.smallは20%。
- db.t2.smallは1つのvCPUで1時間につき12のクレジットを受け取るため、12/60=20%となる(vCPUが2個なら10%)。
- db.t2.mediumは24/60=40%だが、vCPUが2つあるためvCPUごとには20%(CloudWatchに表示されているCPU使用率はvCPUごとの値)。
- クレジット
- CPUクレジットは1時間で12なので、100%のCPU使用率で12分、50%なら24分稼働させられる計算(vCPUが2個なら50%で12分、25%で24分)。
- ベースラインパフォーマンスが20%のため、1時間ずっと20%を維持し続けるとクレジットは増減しない。20%を切るとその分クレジットが蓄積され、20%を超えるとクレジットが消費され続ける。ベースラインパフォーマンスを超えることを「バースト」という。
- クレジットは各インスタンスの最大値までしか貯まらない(インスタンス停止で破棄される)。db.t2.smallの最大は288。
- db.t3について
Aurora
RDSとの違い
- AuroraはRDSの一部である。独立したサービスのように見えるが、実態はOracle DatabaseやMicrosoft SQL Server、MySQLなどと同じくAmazon RDSで利用可能なRDBMSのオプションの一つ。Auroraを利用するにはAmazon RDSを利用する必要があり、自動パッチ適用や自動バックアップなどRDSの基本機能もAuroraへ引き継がれる。
- 作成時にAurora DBクラスターが作成される。RDSとの違いは以下の通り。
- RDS: 1つのAZにインスタンス+EBS2台の構成。EBSがもう1つのEBSへミラーリングすることで耐久性を高めている。レプリカを作成すると、このセット(インスタンス+EBS2台)が別のAZに増える。レプリカ(セカンダリ)はプライマリから連携されるログを使ってストレージデータを更新し、プライマリと同期する。プライマリ/セカンダリの関係はアクティブ/スタンバイであり、プライマリが稼働している間セカンダリは待機しているだけになる。
- Aurora: インスタンス(プライマリ)と複数AZにまたがるストレージ(リードレプリカ)で構成される(リードレプリカは最大15個まで配置可能)。ストレージは1AZあたり2箇所、3AZに渡ってコピーされる(2×3=6箇所)。この6つのストレージボリュームは互いに通信し、いずれかのストレージがデータ消失などした場合は修復し合う仕組みになっている。
- プライマリはデータの読み書きを行い、リードレプリカはデータの読み込みのみ行う。Auroraは複数のリードレプリカで大量の読み込みリクエストを処理できるように最適化されている。
- (IME) 本来リードレプリカは性能向上を目的として配置されるものだが、Auroraの場合はリードレプリカが自動フェイルオーバー機能を備えているため、セカンダリデータベースの役割も兼ねる。そのためプライマリのみでもフェイルオーバーは可能だが、10分程度かかる。より高速にしたい場合はマルチAZ構成にする必要がある(セカンダリを構築するイメージ)。
- 構築の単位としては「クラスター」(エンジン設定・DB名・マスター認証情報などクラスタ全体の設定を持つ)と「クラスターインスタンス」(実際に計算資源を割り当てるインスタンス。クラスターに対して複数作成でき、1台目がライター、以降がリーダーとして扱われることが多い)が分かれている。台数を増減させるだけでリードレプリカのスケールアウト/インができる。
- 比較
- コスト: AuroraはRDSより高くなりやすい(?)。Aurora Serverlessにすると安くなる場合もある。
- 耐久性: Auroraは6つに分散しているぶん耐久性が高い。
- 性能(スループット): AuroraのほうがRDSより性能が出やすい。リードレプリカが多くスループットが良く、それ以外も最適化されている。
- 可用性(フェイルオーバー): RDS、Aurora、Aurora Serverlessいずれも自動フェイルオーバー機能を保有している。Auroraの場合、プライマリインスタンスのみでは10分未満でサービスが回復する。セカンダリインスタンスがある場合は復旧時間が120秒未満(多くの場合60秒未満)になる。10分の停止が許容できない場合は、Auroraでもセカンダリ構成にしたほうがよい。
- メンテナンス: いずれのサービスもハードウェアのプロビジョニングやミドルウェアのパッチ適用、バックアップが自動で行われ、運用負荷を減らせる。
- (参考) https://service.plan-b.co.jp/blog/tech/28232/
- 自動バックアップ機能はS3に保存される(?)。
- その他機能
- Protection Groups: 10GB毎にグループ分けして並列化しているため、クラッシュ時のリカバリも並列で速い。
- BackTrack: オペレーションミス時などのバックアップや、REDOが容易。
- クラスタキャッシュ管理: フェイルオーバー時、通常はプライマリのキャッシュが消失しセカンダリはディスクアクセスが発生して一時的にTPSが下がるが、キャッシュを引き継ぐことができる。
- 並列クエリ、Global databaseなど。
- ストレージのオートスケーリング
- Data API
- Aurora Serverlessに接続する際に、コネクション数を気にせずLambdaなどのサービスと繋ぐためのAPI。
- 従来のProvisioned Aurora向けにはAmazon RDS Proxyとして提供されている。
Aurora Serverless
- (参考) https://dev.classmethod.jp/articles/reinvent-2019-aurora-serverless-scalable-cost-effective-application-deployment-dat382/
- (IME) Auroraの機能が一部制限される点が悩ましく、通常のAuroraとどちらを選ぶべきか判断に迷うことがある。
- Auroraはストレージはオートスケールだが、インスタンス(コンピューティング)はオートスケールではない。これをオートスケールにしたのがAurora Serverless。
- Aurora Serverlessでは、ワークロードに応じたスケールアップ・ダウン、利用していないときのスリープ、利用再開時のインスタンス起動が自動で行われる。
- プロキシレイヤー: リクエストをルーティングする。高分散・マルチテナントのためSPOFにならない。
- データベースインスタンスのプール: インスタンスはウォーム状態にあり、必要なタイミングですぐ利用できる。
- スリープしたインスタンスが起動するまでにはある程度の時間を要する(再起動の場合は20秒〜1分程度)。
- (IME) そのため、開発環境などでない場合はアイドル状態でも一時停止しないように設定したほうがよさそう。
- Auroraには以下2つのタイプがある。
- ユーザーがサーバー構成を明示的に指定する従来のProvisioned(プロビジョン)型(インスタンスタイプを選択する)
- アプリケーションのニーズに応じて自動的に起動・シャットダウン・スケールアップダウンするServerless型
- デメリット
- (参考) https://dev.classmethod.jp/articles/lessons-learned-from-up-and-running-aurora-serverless/
- 再起動できない(「再起動」アクションが定義されていない)。
- パブリックIPアドレスを割り当てて、VPC外からアクセスすることはできない。
- 一度停止したクラスタが再開するには1分程度かかる。
- MySQLは5.6系のみ、PostgreSQLは10.7系のみ対応(執筆時点の情報のため、現在は状況が変わっている可能性がある(?))。
- クエリ処理中はスケーリングできない。継続的にクエリが実行されるアプリケーションでは、スケーリング自体がいつまでも実行されない可能性がある。秒間1回以上リクエストが来るようなシステムでは、Auroraをはじめとした非サーバーレスのDBサービスが向いている。
- Data APIは便利な半面、「1秒間あたり最大1000コール」「レスポンスのサイズが最大1MB」といった制限がある。性能面でリクエストを並列で投げたり、1回のクエリあたりのレスポンスサイズを大きくしたりすると、この制限に引っかかる可能性があるため設計時に考慮が必要。
- 非サーバーレスAuroraの一部機能(Auroraレプリカ、バックトラック、Amazon S3バケットからのデータの読み込み、Amazon S3バケットへのデータ保存、他多数)が使えない。
- フェイルオーバー時間が未定義。Aurora ServerlessのDBクラスターは単一AZに1インスタンスのみ作成され、インスタンスやAZ障害でフェイルオーバーが発生すると別AZにDBインスタンスが作成される。高速フェイルオーバーには対応しておらず処理時間は未定義(非サーバーレスでもセカンダリ無しの場合は10分程度かかる)。
- Aurora ServerlessはAurora Capacity Unit(ACU)という単位でキャパシティを表現する。
- v2について
- Amazon Aurora Serverless v2は2020年のre:Inventでプレビュー公開された(執筆時点の情報のため、その後正式リリースされ機能も変化している可能性がある(?))。
- スパイキーなワークロードにも即座にスケール(v1はスケールが遅かった)。
- 細かい粒度でインクリメンタルにスケール(v1はインスタンスタイプと同様2のべき乗でスペックが上がるが、v2は0.5単位)。
- Amazon Auroraのマルチ AZ、グローバルデータベースなど様々な機能が利用可能に(v1はAuroraの高機能を利用できなかった)。Multi-AZ、Global Database、Read Replica、Backtrack、Cloningに対応。
- ピークロードに合わせてAmazon Aurora Clusterをプロビジョニングした場合より90%程度低コストになる(v1もほぼ同じ)。
- スケーリングに応じてメモリなどのキャパシティもシームレスに変動し、バッファプールなどは維持される。
- スケールアップは即座に行われるが、スケールダウン時は進行中の処理に影響を与えないようメモリの解放などはゆっくり行われる。
- AuroraクラスターとAurora Serverlessの混在も可能。
- (参考) https://dev.classmethod.jp/articles/reinvent-2020-new-launch-aurora-serverless-v2/