AWS 13：RDS ― データベースをサーバーから分けて預ける

データベースを1か所に分けて、全部のサーバーから同じものを見る

データベース（DB）は、データを整理してしまっておき、必要なものをすばやく探し出すための専用のソフトです。フォトログで使うのはリレーショナルデータベースと呼ばれる種類で、データを「表」の形でしまい、SQL という問い合わせの言葉で読み書きします。

解決策は単純です。データベースを専用の機械に分けて、Web サーバーは全部そこへ読み書きしに行きます。

図では、AZ-a と AZ-c（第2章）の Web サーバーが、どちらも同じデータベースを見ています。これで、どの Web サーバーに振られても同じ投稿が見え、Web サーバーを捨ててもデータは残ります。

このように「入口（ALB）」「計算（Web）」「データ（DB）」の3つの層に分けた形を、3層構成と呼びます。第16章で完成させる形の骨組みです。

ただし、今度は新しい困りごとが生まれます。データベースが1台しかないなら、それが壊れたときにすべてが止まります。そして、データベースを安全に動かし続けるのは、実はかなり手間のかかる仕事です。次から、その手間を誰が引き受けるのかを見ていきます。

データベースを自分で運用すると、世話が山ほどある

データベースの専用機は、EC2（第9章）を1台借りて、そこに PostgreSQL や MySQL といったデータベースのソフトを自分で入れても作れます。自由度は最大です。

でも、そうすると次の世話が全部あなたの仕事になります。

このように、機械やソフトの世話を AWS が引き受けてくれるサービスをマネージドサービスと呼びます。

データベースは、壊れたときの被害がいちばん大きい部品です。Web サーバーは作り直せば戻りますが、データは消えたら戻りません。だからこそ、世話をプロに任せて、あなたは表の設計やアプリの中身に集中するのが、クラウドでの基本の考え方です。

EC2 に自分で入れるのは、RDS が対応していない特別なソフトや設定がどうしても必要な場合に限るのがよいでしょう。

RDS は「データベースの世話」を AWS に任せるサービス

Amazon RDS（Relational Database Service）は、リレーショナルデータベースを借りられるマネージドサービスです。

使えるデータベースのソフトをエンジンと呼びます。

RDS で DB を作るときに、あなたが決めるのは主に次のことです。

逆に、OS にはログインできません。RDS の中の機械は AWS が管理していて、あなたが触れるのはデータベースの入口だけです。これは不便に見えますが、触れないから壊せない、という安心でもあります。

DB はプライベートサブネットに置き、扉は Web からだけ開ける

データベースには、利用者がインターネットから直接つなぐ必要は一切ありません。利用者はいつも Web サーバーを通してデータを読み書きします。だから DB は、インターネットから届かない場所に置きます。

ポートは、1台の機械の中で「どのソフト宛てか」を区別する番号でした（第8章）。PostgreSQL は既定で 5432 番、MySQL は 3306 番を使います。

db-sg の許可の相手に IP アドレスではなく app-sg（Web サーバーの SG）そのものを指定するのがポイントです。Auto Scaling で Web サーバーが増えても減っても、app-sg を付けている限り自動で通れます。

もう1つ、RDS には DB サブネットグループという設定があります。「この DB はこれらのサブネットに置いてよい」という名簿です。2つ以上の AZ のサブネットを登録する決まりになっていて、後で見る Multi-AZ の待機系はこの名簿の中の別 AZ に置かれます。フォトログでは、AZ-a と AZ-c に DB 用のプライベートサブネットを1つずつ作って登録します。

接続先は IP アドレスではなく「エンドポイント」という名前

アプリが DB につなぐとき、接続先に IP アドレスは書きません。RDS が作るエンドポイントという名前を書きます。図の下の板のような、長い名前です。

名前をどうやって IP アドレスに直すかは第14章で詳しく見ますが、ここでは「名前を問い合わせると、今の DB の住所が返ってくる」と考えてください。

なぜ IP アドレスを直接書かないのでしょうか。

アプリの設定には、エンドポイント・ポート・DB 名・ユーザー名・パスワードを書きます。ただしパスワードはソースコードに直接書かないこと。この章の後半で、RDS にパスワードを作らせて、AWS の金庫（Secrets Manager）にしまう方法を紹介します（詳しくは第20章）。

postgresql://photolog:（金庫から読む）@photolog-db.xxxxxxxx.ap-northeast-1.rds.amazonaws.com:5432/photolog

図の小包「SQL」は、Web サーバーから DB への問い合わせを表しています。Web サーバーは、どの AZ にいても、同じエンドポイントに向けて問い合わせを送ります。

DB が1台だけだと、その AZ が止まったら全部止まる

ここまでで、データは1か所にまとまりました。でも、その1か所が1台の機械だとしたらどうでしょう。

第2章で見たように、AZ（アベイラビリティーゾーン）は独立した電源や回線を持つデータセンターのまとまりです。まれですが、AZ ごと調子が悪くなることがあります。

図では AZ-a に障害が起き、そこにある Web サーバーと DB が止まりました。

せっかく Web サーバーを2つの AZ に分けても、DB が1台なら意味が半減します。このように、そこが止まると全体が止まる1か所を単一障害点と呼びます。構成を考えるときは、いつも「単一障害点はどこか」を探します（第29章で詳しく扱います）。

AZ の障害でなくても、DB の機械の故障、ディスクの故障、ソフトの更新のための再起動など、1台が止まる理由はいくつもあります。次に、これを防ぐ Multi-AZ を見ます。

Multi-AZ：別の AZ に待機系を置き、書き込みを同時に写す

Multi-AZ（マルチ AZ）は、本体とは別の AZ に待機系（スタンバイ）の DB を置く設定です。作るときにチェックを1つ入れるだけで、RDS が用意してくれます。

図の小包は、Web サーバーからの書き込みです。書き込みは本体に届き、同時に待機系にも写されます。

同期とは、「写し終わるまで待ってから次へ進む」やり方です。少しだけ書き込みが遅くなる代わりに、本体が突然倒れても、完了と返した書き込みは待機系に必ず残っています。

待機系は読めないので、「予備があるから読み取りも速くなる」わけではありません。Multi-AZ の目的は止まらないことだけです。読み取りを増やす方法は、この後のリードレプリカで見ます。

また、DB の更新のための再起動も、Multi-AZ なら待機系を先に更新して切り替えることで、止まる時間を短くできます。本番のデータベースは Multi-AZ にするのが基本です。

本体が倒れたら、待機系が本体に昇格する（フェイルオーバー）

AZ-a に障害が起きたときの動きです。

この切り替えをフェイルオーバーと呼びます。AWS の説明では、Multi-AZ の DB インスタンスの切り替えはふつう1〜2分（60〜120秒）ほどかかります。その間、DB への接続は切れます。

アプリの側で気をつけることは2つです。

切り替わった後、RDS は壊れた側の AZ が戻ると、そちらに新しい待機系を作り直します。人が夜中に起きて作業する必要はありません。

ここまでで、データが1か所にまとまり、しかも AZ が1つ止まっても動き続けるDB ができました。

読む人が増えたら、リードレプリカで「読み取り」を分ける

フォトログが人気になると、DB への問い合わせの大半は「読む」ものになります。タイムラインを開くたび、写真の一覧を読むからです。書く（投稿する・いいねする）回数よりずっと多くなります。

読み取りで本体が忙しくなったら、リードレプリカを足します。本体の変更を後から写した、読み取り専用の複製です。

非同期とは「写すのは後でいい、先へ進む」やり方です。だから、投稿した直後にリードレプリカを読むと、まだ写っていないことがあります。

アプリの側で「書く処理と、投稿直後の自分の画面は本体へ」「他人のタイムラインの一覧はリードレプリカへ」と振り分ける必要があります。勝手には分かれない点に注意してください。

リードレプリカは別のリージョン（第2章）にも置けます。遠くの利用者に近い場所から読ませたり、災害時の備えにしたりできます（第29章）。

Multi-AZ とリードレプリカは、目的がまったく違う

どちらも「DB の写しをもう1つ持つ」ので、初めは混同しがちです。表で比べます。

可用性とは「使いたいときに使える度合い」のことです。

両方を組み合わせることもできます。前の図のように、本体＋待機系（Multi-AZ）に、読み取り用のリードレプリカを足す形です。

もう1つの形として、Multi-AZ DB クラスターがあります。待機系を2つ持ち、しかもその2つが読める形です。AWS の説明では、切り替えもふつう35秒未満と、1つの待機系を持つ形より速くなります。ただし使えるエンジンやクラスに制限があるので、使うときは公式の説明で確かめてください。

判断の問いはこうです。「止まると困るのか（→ Multi-AZ）」「読み取りが重いのか（→ リードレプリカ）」。困りごとが違えば、部品も違います。

自動バックアップ：毎日の丸ごとと、細かい記録で「時刻を指定して戻す」

Multi-AZ は機械の故障には強いですが、間違った操作には無力です。アプリのバグで全員の投稿を消してしまったら、その削除は待機系にも同期で写ります。予備ごと消えるのです。

そこでバックアップが要ります。RDS の自動バックアップは、2つの仕組みを組み合わせています。

戻したい時刻を指定すると、RDS は「その直前の丸ごと」から始めて、「その後の記録を指定の時刻まで」再生して DB を作ります。これをポイントインタイムリカバリ（時刻指定の復元）と呼びます。保持期間の中なら、好きな秒に戻せます（直近の数分は除く）。

図の赤い旗は「木曜 14:32:05、誤って消す直前に戻したい」という例です。

復元は「新しい DB を作る」こと。元の DB は上書きされない

RDS で復元すると、今の DB が上書きされるのではなく、新しい DB が別の名前で生まれます。エンドポイントも新しくなります。

元の DB を残したまま戻せるので、「戻してみたら違った」ときもやり直せます。一方で、接続先の切り替えは自分でする必要があります。SG・パラメータの設定なども、復元時に指定し直すのを忘れないようにします。

自動バックアップとは別に、手動スナップショットも撮れます。

いちばん大事なのは、一度は実際に戻してみることです。戻したことのないバックアップは、いざというときに戻せるかわかりません。

サーバーが増えると、DB への「接続」が足りなくなる

アプリが DB と話すには、まず接続を張ります。電話をかけてつながった状態のようなものです。つなぐたびに手間がかかるので、アプリはふつう何本かの接続をつないだまま持っておき、使い回します（コネクションプール）。

ところが、DB が同時に受け付けられる接続の数には上限があります（PostgreSQL・MySQL では max_connections という設定）。接続1本ごとに DB のメモリを使うので、小さいクラスほど上限は低くなります。

Auto Scaling で Web サーバーが増えるほど、接続の合計も増えます。上限に達すると、新しい接続は断られ、利用者にはエラーが返ります。混雑している一番大事なときに、です。

対策は3つあります。

RDS Proxy：接続をまとめて、DB に渡す本数を減らす

RDS Proxy は、アプリと DB の間に立って、接続をまとめる係です。

図では、たくさんの Web サーバーの線が Proxy に集まり、Proxy から DB へは3本だけになっています。これを接続プーリングと呼びます。

もう1つの利点は、フェイルオーバーのときです。Proxy がアプリからの接続を受け止めたまま、新しい本体へつなぎ直してくれるので、アプリから見た切り替えの影響が小さくなります。

RDS Proxy には別に料金がかかります。フォトログの最初の規模（Web が2〜4台）なら、まずはアプリのプールの大きさを見直せば足ります。接続数が困りごとになってから足せばよい部品です。

Aurora：クラウド向けに作り直された、AWS 独自のデータベース

RDS の中には、Amazon Aurora という特別なエンジンがあります。MySQL や PostgreSQL と互換（同じ SQL・同じ接続方法で使える）ですが、中身はクラウド向けに作り直されています。

いちばんの違いは、計算とディスクが分かれていることです。

図の下の緑の帯が共有ストレージです。3つの AZ に2つずつ、合わせて6つの写しがあり、どれかが壊れても自動で直されます。

さらに Aurora Serverless v2 を選ぶと、負荷に合わせて計算の大きさが自動で伸び縮みします。使われていない時間は計算の料金をゼロ近くまで下げる設定もできます。

料金の数え方は RDS とは違い、ストレージや入出力の数え方にいくつか選択肢があります。この本では仕組みを学ぶために、フォトログはまず RDS for PostgreSQL で作ります。

作り方：6つの決めごとで DB ができる

コンソールでは、RDS の画面の「データベースの作成」から作ります。図の番号の順に決めていきます。

同じことを CLI（第1章の CloudShell で使える）で書くと、次のようになります。

aws rds create-db-instance \
  --db-instance-identifier photolog-db \
  --engine postgres --db-instance-class db.t4g.micro \
  --allocated-storage 20 --storage-type gp3 \
  --master-username photolog --manage-master-user-password \
  --db-subnet-group-name photolog-db-subnets \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --no-publicly-accessible --multi-az \
  --backup-retention-period 7 --deletion-protection

--manage-master-user-password を付けると、RDS がパスワードを作って Secrets Manager にしまいます。既定では7日ごとに自動で取り替えられます。アプリは起動時に金庫から読み出します。

フォトログでは：利用者・写真・いいねを RDS に置く

フォトログのデータを、3つの表にしまいます。

表どうしは番号でつながります。photos の user_id は users の id を指し、likes は「誰が」「どの写真に」を2つの番号で持ちます。これがリレーショナル（関係のある）データベースの名前の由来です。

大事なのは、写真の画像そのものは DB に入れないことです。写真は数 MB と大きく、DB に入れるとディスクもバックアップも膨らみ、読み書きも遅くなります。DB には s3_key として、写真の置き場所の名前（例：uploads/2026/09/abc.jpg）だけを書きます。画像そのものの置き場所は第15章の S3 です。

「何をどこに置くか」を決めるのも、構成を考える大事な判断です。

お金：動いている時間・ディスクの容量・予備の分

RDS の料金は、主に次のものに対してかかります。

DB は24時間動き続けるので、起動している時間の料金がいちばん大きくなります。Web サーバーのように「夜は減らす」ことができないからです。

節約の考え方は次のとおりです。

無料枠の条件は変わることがあるので、第4章の考え方で、料金ページと Pricing Calculator を必ず確かめてください。

よくある落とし穴

DB の事故は、取り返しがつかないことが多いのが特徴です。よくある6つを挙げます。

もう1つ、DB の SG に `0.0.0.0/0`（どこからでも）を許可してしまう事故もよく起きます。第8章で見たとおり、許可の相手は必ず app-sg にします。

また、DB の設定を変えるとき、変更によっては「すぐに適用」か「次のメンテナンスウィンドウで適用」かを選べます。すぐに適用すると再起動が入るものもあります。利用者が多い時間に変更しないのが安全です。

片付け：消す前に「最後の写し」を撮るか決める

練習で作った DB は、終わったら消します。DB は動いているだけで課金され続けるからです。

削除の画面では「自動バックアップを残すか」も聞かれます。残すと保持期間が過ぎるまで残り、そのぶん課金されます。練習なら残さなくて大丈夫です。

CLI で消す場合は次のとおりです。

aws rds modify-db-instance --db-instance-identifier photolog-db \
  --no-deletion-protection --apply-immediately
aws rds delete-db-instance --db-instance-identifier photolog-db \
  --skip-final-snapshot --delete-automated-backups

DB を消した後に、残りものがないか確かめます。