Amazon RDS
（Relational Database Service）

この記事でわかること

① ストーリー性を取り入れた説明

旅行会社の新規事業開発部では、年末年始に向けて「旅行写真でフォトブックを作れるサービス」を企画していました。ところが、申込みが増えるほどデータベースが遅くなり、画面が固まったり、注文確定が失敗したりする問題が出始めました。

ケンイチ：
「課長、ご相談があります。フォトブックのサービスが、データベースの遅延でピンチです。
アクセスが増えると画面が重くなって、問い合わせも増えてきました…」

課長：
「原因がDBなら、まず“DBをちゃんと運用できる形”にしよう。
Amazon RDSを検討するのが早い」

ケンイチ：
「Amazon RDS…それは一体何でしょうか？」

課長：
「一言でいうと、AWSが提供するフルマネージド型のリレーショナルデータベースだ。
AWSが面倒を見てくれる業務用データベースってところだな。。
DBのインストール、バックアップ、障害対策みたいな運用を、AWS側でやりやすくしてくれる」

ケンイチ：
「つまり、DBサーバーを自社で管理しなくてよくなる、ということですか？」

課長：
「そう。
フォトブックの注文情報、顧客情報、決済結果みたいな“正確さが命”のデータは、
DBが止まると即アウトだろ。RDSは“止まりにくくする仕組み”や“戻せる仕組み”を揃えやすい」

ケンイチ：
「止まりにくく…戻せる…って、具体的には何ですか？」

課長：
「まずバックアップ。RDSは自動バックアップを作って、必要なら“ある時点”に戻すこともできる。
それとマルチAZ。別の場所に待機役を用意して、障害が起きたら切り替える考え方だ」

ケンイチ：
「なるほど…。じゃあ“遅い”のは、RDSにしたら全部解決しますか？」

課長：
「そこは注意。RDSは“魔法の高速化装置”じゃない。
遅い理由が、
・DBのパワー不足（CPU/メモリ）
・読み込みが多すぎる（参照が集中）
・クエリが重い（設計・索引）
どれなのかで対策が変わる」

ケンイチ：
「対策って、どんな選択肢がありますか？」

課長：
「まず基本はスケールアップ。つまり大きいインスタンス（仮想サーバー）にする。
読み込みが多いなら“読み取り用”を分ける設計もある。
あとは、よく使うデータをキャッシュしてDBに行く回数を減らす、みたいな手もある」

◆ Amazon RDSのポイント
・DB運用（バックアップ/可用性）を整えやすい
・マルチAZや自動バックアップで「止まりにくい・戻せる」に近づける
・性能は“原因に合わせた対策”が必要（RDSだけで魔法の解決ではない）

ケンイチ：
「メリットは分かりました。デメリットも知りたいです」

課長：
「大きく3つ。
1) 料金：使い方次第でコストは増える。
2) 自由度：OSレベルまで好き放題はできない（マネージドだから）。
3) 結局、設計と運用は必要：権限、テーブル設計、バックアップ方針などは人が決める」

ケンイチ：
「なるほど…。任せられるけど、丸投げではないんですね」

課長：
「そう。だから“業務を支えるDBを、ちゃんと回す”には最適になりやすい。
今回なら、まず注文DBをRDSで安定させて、繁忙期に耐えられる形にしよう」

用語	管理	強み	向いている用途
Amazon RDS	AWSが運用を支援（マネージド）	バックアップ/可用性/運用負荷軽減	予約/会員/決済など業務DB
EC2上のDB	自社で全部管理	自由度が高い	特殊な要件/細かい制御が必要
Amazon Redshift	AWS（分析向け）	大量データの集計	分析/BI/データ倉庫