こないだ初めてスノボ体験しました。agoです。
弊社ではAmazon Web サービスを利用してmixi、モバゲーアプリを提供していますが、その中でも今日はRDS（MySQLホスティングサービス）の利点と欠点を紹介したいと思います。
利点
- 設定が容易
my.cnfを設定せずとも各instance classに合わせて各種パフォーマンス項目が設定済みのため、設定を変更せずとも使用開始時からある程度の性能を出すことが可能です。
- AWSのSecurity Groupsと連携できる
EC2 instanceはサーバ負荷によって台数が増減するため、通常のIP制限では台数を変更するたびに制限するIPを変更する必要があります。
これに関しては通常のEC2 instanceでMySQLサーバを立てるときにも専用のSecurity Groupを用意することで連携は可能ですが、RDSの場合、RDSを使用しているしているアカウント以外のSecurity Groupも指定できるためより柔軟な運用が可能です。
- 容易にスケールアップができる
コマンドから簡単にRDS intanceのスケールアップが可能です。
通常のEC2 instanceにMySQLサーバをインストールして運用する場合でも、Elastic IP、EBS等を使用して同じように容易なスケールアップを実現することは可能ですが、そういった設定なしに最初からコマンド一行でスケールアップできることが保証されている環境は魅力です。
- バックアップ、スナップショット等の環境が用意されている
バックアップ、リストアに関して専用手順が用意されているため、特にこちら側で考慮する必要がありません。
- パッチ等を自動で適応してくれる
必要最低限のパッチのみ自動で適応してくれます。
適応時間は一週間の中でこちらで指定した4時間の間に適応されますが、実際運用していると適応されるのはだいたい一ヶ月に一度程度のようです。
欠点
- レプリケーションができない
現在大きな問題点としてRDSはレプリケーション設定が行えないことがあげられます。
これに関してはAmazonでも解決に向けて対応しているとのことなので、そう遠くない内に解決することを期待しています。
また、この点が解決されれば以下であげている欠点のいくつかも解決できる可能性が高いため、より選択肢として有望になると考えています。
- エラーログが見られない
shellが公開されていないため、OSやMySQLのエラーログ等が見えません。
専用環境のため起動不能等でエラーログが重要になる可能性は低いのですが、それでもいざというときに原因を追及できない可能性が高いです。
ただ、slow query logはテーブルに出力することで閲覧可能です。
blog.hori-uchi.com: AmazonRDSでslow queryを出力するようにする方法
- 設定の変更にInstance rebootが必要
通常のEC2 instanceにMySQLサーバをインストールした状態でもmy.cnfの変更はmysqldのrestartが必要ですが、RDSの場合この変更がInstance rebootになるため反映までに数分のダウンタイムが必要になります。
普段必要な作業ではないですが、「通常のMySQLサーバに比べて設定変更に時間がかかる」というのは覚えておいていいと思います。
- バックアップが遅い
日毎のバックアップで数分間（20GBで3分程度）のダウンタイムが発生します。
これに関しては実際のデータ使用量ではなく確保したDBのサイズによって時間がかかるようなので、実データの量によっては付近のEC2 instance上からmysqldump等でバックアップした方が早いです。
- 週一のメンテナンス時間が必須
現状最低でも4時間設定する必要があるためダウンタイムを0にすることができません。
これに関しては実際メンテナンスでダウンする頻度はそれほど多くないのですが、4時間の内いつダウンするかわからないため一週間の内必ず不安定になる可能性のある時間が発生することになります。
- メモリの使用率が見えない
CPU使用率等は外部サービスのYlasticCloudWatchのパッケージに含まれるmon-get-statsを使用することにより確認できますが、メモリ使用量は確認することができません。
（ただ、YlasticがどうやってRDSのリソースをグラフ化しているかわかりませんでした。RDSCli.zip内に該当するコマンドは確認できなかったのですが。。。）
2010/2/26 社内からの指摘で修正しました。
DBサーバはメモリ使用率も重要なため、この点で負荷が上がってきた場合の原因を追求するのが困難になる可能性はあります。
まとめ
簡単に開始できる点は魅力ですが、ダウンタイム等を考慮するとまだEC2にMySQLインストールする方が利点は大きいと考えています。
容易にスケールアップできる点は魅力と言えば魅力ですが、レプリケーションが使えないため割と早く最上位クラスの限界に達します。
そうなった場合RDSでは打つ手が無くなるため、通常のアプリであればレプリケーションでスレーブサーバを増やす構成の方が性能限界は高くなると感じています。
ただ、欠点に関してはレプリケーションができないことが大きいため、これが解決されればもっと利用できる範囲は多くなると思います。
