AWSでWebサービスを構築06 RDS構築の前知識、前準備

前回はEC2でインスタンスを起動し、AMIの作成まで行った。

先にデータベースを用意した方が良さそうなので、まずはRDSを使ってデータベースを構築する。
が、そのまえに、ちょっとデータベースに関する前知識を説明し、前準備をしたい。

前知識

LAMP環境などが充実している昨今、データベースを用意する場合はApacheと同じサーバにMySQLをインストールして・・・と考える人もいるかと思うが、サービスを行う場合データベースは別にサーバに用意した方がいい。

データベースはreadとwriteで使用頻度に差がある傾向がある。(readの方がかなり多い）
そのため、データベースサーバは複数台用意して、書き込み用、読み込み用と用途を分けて、それらを上手く構成する必要がある。



上はDBのクラスタ構成例。APサーバにはPHPか何かが動いていて、DBに書き込み、読み込みを行うものとする。
まず、書き込みは「マスターサーバ」に行う。
マスターサーバは最新のデータが集約されるため、バックアップなどもここのデータを保存する。

マスターサーバから読み込みを行うとマスターサーバの負荷が高くなるため、読み込み用のコピーを複数作る。
これを「リードレプリカ」と呼び、DBのコピー操作を「レプリケーション」と呼ぶ。
（現在リリースされているDBアプリケーションは、このレプリケーション機能を持っている場合が多い）

マスターサーバに書き込まれた内容は、その都度リードレプリカたちに反映される仕組みだ。
APサーバは、このリードレプリカの一つから読み込みを行う。

このような構成をとることで、比較的多いread要求に対して負荷分散を行う。

ここまでのクラスタ構成は直感的に理解できるかと思う。
ただ、実際には「あ、マスターサーバは冗長化しておかないと、隕石が落ちたらサービス止まるなー」とか考えるとかなり複雑になってくる。

そこで、データベースのクラスタ機能に特化しているAWS RDSというサービスを使用する。
冗長化を意識することなく安定したDBインスタンスを提供してくれるし、バックアップを定期的にとってくれるので、安定したサービスを提供できる。

ただ、無料枠をこえると結構高い料金がかかる。
悲しいことに、冗長化をONにすると無料枠を超えるので、今回は涙を飲んで冗長化なしで構成していく。

補足

データベースに関しては、サービスによって構成もまるで異なるので、補足しておく。読み飛ばしてもいいよ。

書き込み操作は比較的少ないとはいえ、操作そのものの負荷が大きいこともあり、マスターサーバはスペックのいいサーバを用意する必要があるだろう。
また、レプリケーションは同期、非同期などがあるが、非同期の場合リードレプリカへの反映にタイムラグがあるため、書き込んだデータをすぐに見ることができない(ほとんどが非同期）。そのため、一部はマスターから読み込んだりもする。

あと、読み込みの方が多い、という前提もサービスによって異なる。
例えばゲーム用のバックエンドを作る場合は、書き込みが頻繁に行われる。
さすがに読み込みよりかなり多くなる、ということはないだろうが、マスターにかかる負荷が大きいため分散しづらいといわれている。

だからサービス開始してすぐにゲームのサーバが落ちたとしても、あまり怒ってはいけないよ。

ゲームではクラスタを幾つか用意して、クラスタ間のやり取りが少ないという、比較的原始的な負荷分散が行われる。
（「このアカウントは〇〇サーバだ」みたいなやつ）

サービスによるDB構成は、やはり徐々に設計していくしかないんだろうと思う。

セキュリティグループの作成

以前はDB用のセキュリティグループというものがあったが、今はEC2とかと同じセキュリティグループで管理する。
EC2のショートカットからEC2の管理画面を開き、画面左部メニューから「ネットワーク&セキュリティ→セキュリティグループ」を選択する。

作成方法は以前説明した通りなので、省略する。
設定するルールは
インバウンド：
「タイプ：MYSQL/Aurora、送信元：VPCの設定CIDR（このシリーズでは10.0.0.0/16） 」
他はデフォルトでいいかと。

これは、VPC内でのみアクセス可能に設定してある。
アウトバウンドも同様に設定してもいいが、まあTCPなのでインバウンドだけでいいのではないだろうか。


少し短いが、説明が多かったので今回はこのくらいで。
次回はRDSでDBインスタンスを作成する。