新たなサーバーを気軽にReplicaSetのメンバーに追加すると 同期の負荷に耐えられなくなることがある という落とし穴がある。ResplicaSetって便利な機能だけど、正しく利用しないと痛い目にあうので、チェックリストをまとめることにした。
キャパシティプランニングは入念に行っているか？
当たり前だが、これを怠ると同期した瞬間サーバーが負荷に耐えられなくなり大変なことになる場合がある。どの程度のプランニングが必要か？基本、iopsとmemoryとcpuを十分確保することを勧めたい。ギリギリのキャパシティーだと危険。富豪ならスパイク時の2、3倍のキャパは欲しいところ。
使っているバージョンのバグを把握しているか？
例えば、v3.0.5の場合、awsの方から聞いて知ったのですが、負荷に耐えられない問題があるらしく、至急アップデートすることになった。この様にバグを把握していると、未然に防げることがある。当たり前の話しだけど、基本、できるだけ新バージョンを使うようにした方が良いと考えている。ただ、DBのバージョンアップは辛いのでついつい怠ってしまうことがある。
サーバーの設定は正しく行っているか？
プロダクション利用の場合、しっかりProduction Notes読んで、設定を怠らないことが重要。
https://docs.mongodb.org/manual/administration/production-notes/
データの容量が膨れないようにしているか？
データ容量が大きいと同期の時間が長くサーバーへの負荷が増す状態が続く。気持ち的に辛い。backupしたデーターを移動してなどの対応も考えられるが、ReplicaSetの手軽さの恩恵が受けられれない。肥大していくデータをMongoDBで扱うのはお勧めできない。
特にGridFSを使っているDBをReplicaSetにおくと、どんどんデータが肥大していくので気をつけた方が良い。私の結論として、GridFSはProductionでは使わない方が得策。使う場合、ReplicaSetのメンバーに入れない使い方を考えた方が良い。
DBをうまく使い分けているか？
DBの用途によって、ReplicaSetを使わない、もしくは、メンバーに入れないという選択肢もある。
例えば、アプリケーションでReadとWriteを使い分けてDBに接続してサーバーのパフォーマンスを引き出すなどするためのDBは、ReplicaSet向きだと言えるが、バッチやバックグラウンドで何か処理するために使うデータ、例えばログ的なものは、ReplicaSetを使う必要はないので別にDBを作るか、別のものを使った方が良い。データー容量の肥大化も防げる。
まとめ
ReplicaSetはとても便利で簡単に使えるが、間違った使い方をすると落とし穴に落ちてしまう可能性がある。是非、チェックリストを参考にMongoDBと戯れてみてください。
以下、MongoDB+WiredTiger+ReplicaSet+NewRelicでサーバー構築について書いてます。
http://qiita.com/kiyotaman/items/354875fbd421594698d0