過去の日記を読み返していて，あることに気づいた。
今日までに，俺がAWSでやってきたこと。
オンプレ時代であれば，サーバをラッキングして，電源を入れ，ネットワーク機器をケーブルでつないだ事くらいしかやっていない。サーバに至っては，電源を入れて，SSHで接続して，pingを打っただけ。
クラウドという環境に初めて触れて，すごいことをしている気分だったのに，改めて考えてみると，すごく単純作業しかしていないことに気づいてしまった。でも，今までであれば，必ずデータセンターに行って作業していた事が，手元ですぐに完結するというのはすごい。それは俺がすごいんじゃなくて，AWSがすごい。
とはいえ，俺も何もしていないわけではなくて，ネットワークを作ったり，サーバを立ち上げたりするのをいかに早くできるかというのを反復練習していたわけで，今となってはネットワークを構築して，サーバを起動するくらいなら30分もあれば余裕でできる。
そんな俺が次にやるのは，クラウドっぽいWEB-DB構成を作ること。前回作ったVPCにDBサーバを設置して行くことにする。
ちなみに前回作ったネットワークはこれ
RDSって便利
サーバを起動してDBサーバをつくろうと思ったけれど，AWSにはデータベースのマネージドサービスがあるらしい。
勝手にバックアップをとってくれるわ，レプリケーションをしてくれるわと，インフラエンジニアにとってお仕事を奪われかねないぐらいの機能があるな。でもそれはポジティブに考えると，これを使いこなすことができれば，俺，楽できる，ということだ。
というわけでRDSというサービスを触ってみて，使いこなせるように頑張ってみることにした。
DB Subnetってなに？
さっそくプライベート側のネットワーク（Subnet-2）にRDSを設置しようと思う。
とりあえず，何が必須項目か知るために，なんのオプションも付けずにコマンド投入。
$ aws rds create-db-instance usage: aws [options] <command> <subcommand> [parameters] aws: error: argument --db-instance-identifier is required
--db-instance-identifierをつけろと。dentifierと入っているなら，何かしら一意になるようなものをつければよいんだろうな。とりあえず，test-dbとしておく。
$ aws rds create-db-instance --db-instance-identifier test-db usage: aws [options] <command> <subcommand> [parameters] aws: error: argument --allocated-storage is required
まだ足りないパラメータがあるらしい。こんなやりとりを繰り返すこと数回。
$ aws rds create-db-instance --db-instance-identifier test-db \ --allocated-storage 5 --db-instance-class db.t2.micro \ --engine mysql --master-username root --master-user-password password
結局これだけの必須項目があった。ちなみに--master-user-password はちゃんとしたパスワードにしよう。
起動したようだけれど…，俺は気づいた。どこに起動しているんだこれ？？VPCのプライベートなサブネットじゃないぞきっと。とりあえず，消す。
$ aws rds delete-db-instance --db-instance-identifier test-db
まさかこんなにすぐに-db-instance-identifierを使うことになるとは。
A client error (InvalidDBInstanceState) occurred when calling the DeleteDBInstance operation: Instance test-db is currently creating - a final snapshot cannot be taken.
すぐに削除しようとしたせいか，上記のエラーがでたので，Snapshotを取るかどうかみたいな事を言われてしまったので，--skip-final-snapshotをつけてもう1回
$ aws rds delete-db-instance --db-instance-identifier test-db --skip-final-snapshot
今度はうまくいった。
気を取り直してもう1回作る。
$ aws rds create-db-instance --db-instance-identifier test-db --vpc[TAB]
これできっとVPCのなんかいい感じのパラメータが出てくることだろう。
--vpc-security-group-ids…。違う。違くないけど，違う。そうじゃない。どこのサブネットにつながるのかを指定したいというのに…，諦めて，全部のオプションを見てみることにする。 たぶんそれっぽいのは--db-subnet-group-name これ。けど，db-subnet-groupって何だ。
調べてみると，DB-SubnetGroupというのはデータベースを設置する用のサブネットをグルーピングする方法らしい。なぜSubnetGroupとして複数のSubnetを使うのかというと，RDSのMultiAZという複数のAvailability Zoneにまたがってレプリケーションを作る機能があるので，1つのSubnetを指定してというわけにはいかないんだと思う。
複数のAvailability Zoneを含んだSubnetを束ねて，RDSを起動するときに指定するとMultiAZという機能によって自動的に冗長化させることができる。MultiAZについては後ほど深追いするつもり。
というわけでこのDB Subnet Groupというのを作ってみる。create-db-subnet-groupというコマンドで，既存のSubnetを指定することで作れるようだ。
$ aws rds create-db-subnet-group[TAB]
オプションを見てみると，--subnet-idsというのがある。ここにsubnet-idを指定すれば良さそう。
$ aws ec2 describe-subnets
で今回対象のsubnetIdを調べておく。プライベートなサブネットを二つ作ったので，その二つをしていけばよいだろう。
AWSとオンプレでの違いは，いろいろあるけれど，このAvailability Zoneが一番の大きな違いなんじゃないかと思う。Availability Zoneの概念がわかれば，だいぶいろいろと便利な機能が使えるようになるから。
$ aws rds create-db-subnet-group --subnet-id subnet-ea00d79d subnet-db06ee82 --
他にも，必須項目があるらしい。--db-subnet-group-nameと--db-subnet-group-descriptionが必須のようなので，それぞれに名前と説明的なものを入れて実行する。
$ aws rds create-db-subnet-group --subnet-ids subnet-ea00d79d subnet-db06ee82 --db-subnet-group-name test-db-subnet --db-subnet-group-description "test db subnet group"
{
"DBSubnetGroup": {
"Subnets": [
{
"SubnetStatus": "Active",
"SubnetIdentifier": "subnet-db06ee82",
"SubnetAvailabilityZone": {
"Name": "ap-northeast-1c"
}
},
{
"SubnetStatus": "Active",
"SubnetIdentifier": "subnet-ea00d79d",
"SubnetAvailabilityZone": {
"Name": "ap-northeast-1a"
}
}
],
"DBSubnetGroupName": "test-db-subnet",
"VpcId": "vpc-6ac1020f",
"DBSubnetGroupDescription": "test db subnet group",
"SubnetGroupStatus": "Complete"
}
}
なんとか無事にできたらしい。RDSを起動するときにはこのdb-subnet-groupを指定することになるんだろう。
改めてRDSを起動する
DBSubnetGroupを作った所で，改めてRDSを起動する。さっき打ったコマンドに，
$ aws rds create-db-instance --db-instance-identifier test-db \ --allocated-storage 5 --db-instance-class db.t2.micro \ --engine mysql --master-username root --master-user-password password \ --db-subnet-group-name test-db-subnet
--db-subnet-group-nameオプションを追加して，起動する。今度こそ，想定していた場所にRDSが起動されているはずだ。
$ aws rds describe-db-instances
－略－
"DBSubnetGroup": {
"Subnets": [
{
"SubnetStatus": "Active",
"SubnetIdentifier": "subnet-db06ee82",
"SubnetAvailabilityZone": {
"Name": "ap-northeast-1c"
}
},
{
"SubnetStatus": "Active",
"SubnetIdentifier": "subnet-ea00d79d",
"SubnetAvailabilityZone": {
"Name": "ap-northeast-1a"
}
}
],
"DBSubnetGroupName": "test-db-subnet",
"VpcId": "vpc-6ac1020f",
"DBSubnetGroupDescription": "test db subnet group",
"SubnetGroupStatus": "Complete"
},
－略－
"AvailabilityZone": "ap-northeast-1a",
－略－
RDSのインスタンスを見てみると，確かにDBSubnetGroupというところに自分が作ったSubnetが書かれていてほっと一安心。
今の状態はこんな感じだろう。
MultiAZってなんだ
MutliAZのAZはAvailability Zoneの事で，RDSを地理的に離れた場所に設置して，冗長化しようという仕組みらしい。Endpointはひとつで，Masterに障害が発生すれば，Slave側に自動的に切り替わり，今度はそっちがMasterになる。冗長化以外の恩恵も結構大きくて，パッチ当てのようなものも，無停止でやってくれる。
他にもいろいろありそうで，RDSの便利さをフルに活用したいのであれば，MultiAZを選択する方が良さそうだ。