リア充爆発日記

You don't even know what ria-ju really is.

貧乏臭くRDSを使っていくために調べたメモ

AWS

AWSでRDBMS使うならRDSでしょ、というところまではいいとして、どう使うのか？というところは非常に難しい。

用途をスタートアップのWebサービスだとした場合、最初はお金をできるだけつかいたくないけど、人気が出たときにはスムーズに対応していきたい、というのはごく普通の欲求だと思われる。

最初からお金ジャンジャン使っていいからどんなアクセスにも耐えられるようにしとけ！ってんならクアドラプルなんとかインスタンスをMulti-AZにしとけばいいんだろうけど、こちとらカネがない。
妥協すべきところとそうでないところはケースバイケースだけど、検討するポイントはどんなケースも似たようなもんでしょう。

今回はそんな場合のそんな検討をしたときのメモ。

VPC?

これはもうVPC内で起動しとけ。AWSに払う金は発生しないからな。非VPCが許されるのは小学生までだそうだし。http://dev.classmethod.jp/cloud/aws/minimum-amazon-vpc-server-environment/

ストレージサイズ

最小の5GBでいいでしょう。サイズを上げる分には無停止でOKとのこと。

Multi-AZを採用するか？

Multi-AZを採用すると耐久性がガツンと上がるいっぽう倍の料金がかかる。
サービスの最初期はたまに落ちるくらいだったら許容するか！という考えもアリだろう。

Multi-AZのメリットはここに書いてある。
http://aws.amazon.com/jp/rds/multi-az/

あとは

  • どれだけ障害が実際に起きるか？
  • 起きた時のインパクトは？（データロストなどは？）
  • 復旧までの時間は？

などを考慮して、費用と天秤にかけて採用の有無を決めることになる。

ちなみに、あとからでもMulti-AZに変更できるから、それも考慮に入れておくべし。

どれだけ障害が実際に起きるか？

どれだけ障害が起きるかについては、EC2インスタンスはけっこう落ちる、という話は聞くものの、イマイチよくわからないから各々で判断してみるしかないと思われる。
ちなみにRDSにはメンテナンスウィンドウという、不定期メンテナンスがある。メンテナンスはおよそ３０分程度かかり、その際はアクセスができなくなると考えたほうがいい。メンテナンスウィンドウは１週間の中で時間帯が指定できるし、実際に行われるのは数ヶ月に１度だそうだから、それが許容できるかどうかもポイントになるかと思う。
http://aws.amazon.com/jp/rds/faqs/#12

起きた時のインパクト

そもそもRDSは自動でバックアップ取ってくれて、通常5分以内のデータに戻すことができるとのこと。
http://aws.amazon.com/jp/rds/faqs/#23

データロストに関してはとりあえず置いておいてよいとすれば、障害発生のインパクトは後述の復旧までの時間にようする時間のあいだ、サービスが止まるということのインパクトをどうとるか、ということになる。バッチ処理とかあってそのタイミングでコケれば、その復旧の手間などのインパクトも考慮する必要がある。

復旧までの時間

復旧までの時間はインスタンスのリブートだけなら対応着手から１０分もあれば復旧できそう。データリカバリーも必要ならデータボリュームとかによっては数時間かかるとのことだけど、、、仮にオンプレミスだとすれば、S3からスナップショット持ってきて差分ログあてるような処理をするとなると5GBでディスクの性能がだいたい100iopsくらいでれば（どこかに通常100くらいって書いてあった）10分かからないくらいなんじゃないかなぁ。。

※転送速度の参考
https://github.com/mechamogera/MyTips/wiki/S3%E3%81%AE%E8%BB%A2%E9%80%81%E9%80%9F%E5%BA%A6%E3%82%92%E8%A8%88%E6%B8%AC%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F

※15分で復帰した例
https://forums.aws.amazon.com/thread.jspa?messageID=415143

っていうか、自動でフェイルオーバーするんだ。。

起動するインスタンスのタイプは？

もちろん最初はmicroでしょう。ダメなら上げていけばいいんだから。問題は、上げるときにどういう制約があるか？ということになる。
インスタンスタイプの変更設定自体はカンタンで、Webコンソールで変更手続きをすればいいだけだった。設定変更のタイミングを今すぐ行うか、メンテナンスウィンドウのときにするかについて、すぐにやってみた場合の挙動を確認してみた。
micro->smallへの変更は７分ほどで済んだ。その間、ずっとDBにアクセスできないかというとそういうわけではなく、実際にDBに繋がらずサービスダウンとなった時間は１〜２分だった。データは空に等しい状態だったので、それなりに運用されているDBだともっとかかるかもしれない。

provisionedIOPSストレージの採用も同様に必要になってから適用すればいいと思う。

まとめ

ということで、すごく大雑把にまとめると、とりあえず、15分くらいのダウンタイムが許容できるならVPC組んでその中でmicroインスタンスを5GBの容量から初めておけばいいんじゃない、それがダメならMulti-AZで、あとは必要に応じてスケールアップすればいいんじゃない、ということでどうだろうか。

ちなみに、Multi-AZでも多少のダウンタイムは発生するらしい。
https://forums.aws.amazon.com/thread.jspa?messageID=378077

また、スケールアップしよう！と思ったときはリードレプリカの存在とかも忘れてはいけない。とにかくAWSはドキュメントが豊富で親切なので公式サイトで熟知すべし。