AWS Black Belt Online Seminar「AWSで使うMongoDB 」資料公開
こんにちは、ソリューションアーキテクトの舟崎です。
4/26(火)に開催しましたAWS Black Belt Online Seminar「AWSで使うMongoDB 」の資料が公開されました。
また、頂いたOnline Seminarで頂いたご質問とその回答が以下になります。こちらも併せてご覧ください。
Q1: MongoDBのシャードの追加・削除/ノードのスケールアップに関しては、メンテナンスなどを使用せずオンラインで実施できますでしょうか？
止められるなら確認等の意味で安心ではありますが、シャーディングのシャード追加・削除は完全にオンラインで可能ですし、スケールアップもレプリカセットのメンバーを1台ずつローリングでスケールアップすることで実施可能です
Q2: 別リージョンのレプリカセットに接続するにはVPNを利用する想定でしょうか？
インターナルな接続であればVPNを使用する想定です。もしインターネット経由で接続する場合はSSLで暗号化したレプリカセットを行うとセキュリティ面で好ましいです
mongodのSSL/TLS関連オプション
https://docs.mongodb.com/manual/reference/program/mongod/#tls-ssl-options
SSL/TLSを使用したmongod構築方法
https://docs.mongodb.com/manual/tutorial/configure-ssl/
Q3: Mongodの冗長化は、すべてのシャードを含んだノードをすべてのAZに分散させるイメージでしょうか？スライドp33の例ですと、各AZに1台ずつのノードが配置されているように見えましたが、これはすべてのシャードが1ノードに含まれるときの例という理解で正しいですか？
mongodの冗長化ですが、各AZにレプリカセットのメンバが1台は存在するようにし、各AZがダウンした場合でも、過半数のメンバがダウンしないように設計する、というイメージで考えていただければと思います
Q4: MongoDBをマグネティックのEBSにて運用しています(1レプリカ3サーバー)。今回EBSをSSD化しようとしていますが、1) DBのストレージをEBSのSnapShotからSSD化しても、作成したEBSの全ブロックにreadをかけなければいけなくて、それをするのに(DBが使える状態になるのに)手元の環境では12h程かかる 2) dumpを出力してSSDのEBSにrestoreしても10hとかかかる、のですが、事前にread replicaにコピーしておいて、primary secondaryを入れ替える的なことでサーバー停止の時間を短くすることは可能でしょうか?初期が3台の場合で移行後も3台にしたい場合は、一回7台にして最初に2台減らして、その後でさらに2台減らす必要がありますか?
レプリカセットに新しいノードを追加することでデータは自動で最新に追従するように同期がかかります。
以下の手順で無停止で実施可能です。
- 新しくgp2のEBSで構築したインスタンスを今のレプリカセットにvotes=0、hiddenで入れる（3台同時でも1台ずつでもいいですが、1台ずつのほうが時間はかかりますがお金は節約できます）
- 新しいインスタンスにデータが同期されたことを確認する
- 古いマグネティックのインスタンスをレプリカセットから外す（念のため停止だけするかスナップショットを取ってください）同時に新しいインスタンス側のhiddenや、votesを適切な値に設定し直す
Q5: WiredTigerはコレクションロックでしたでしょうか？ドキュメントだったような気もします。
コレクションロックなのは3.0以降のMMAPv1です。
WiredTigerはドキュメントロックになっています。
Q6: mongodumpはoplogオプションがあって、それだと「そのポイントのバックアップ」になりませんか?
各シャードに所属しているレプリカセットでOplogオプションを使用してバックアップを取得することで限りなくPITRに近いものは実現可能です。ただ、特にシャーディング環境において運用コストが見合うのであれば、という回答になります
mongodump:oplogオプション
https://docs.mongodb.com/manual/reference/program/mongodump/#cmdoption--oplog
Q7: mongostatの数値を見て、高IOPSのディスクへ_切り替える兆候が見つけられますか?
IOPSの兆候を見たい場合にはCloudwatch等のメトリクスを見ていただく事でIOPSの推移がわかるかと思います
Q8: レプリカセットを偶数台で組むと全部secondaryになってしまう問題があると思っていて、その場合のスケールアウトは2台ずつとかやらないといけないでしょうか？
レプリカセットは偶数台ではQuorumが取れないため組むことができません。ですので、基本的には全体の台数として奇数にしたほうがいいのですが、なんらかの事情で偶数で行う場合にはレプリカセットのvotesオプションを設定することで可能となります。
レプリカセット：votesオプション
https://docs.mongodb.com/manual/reference/replica-configuration/#rsconf.members[n].votes
Q9: オンプレミスのmongodbからAWSのmongodbへの移行のベストプラクティス例があればお聞かせ頂けますでしょうか？
・無停止と言うことであれば、データとしてはDirectConnectやVPNでレプリカセットメンバとしてAWSインスタンスを指定していただき（ただしアプリケーションからは見えないようにしておく）、データが追いついたところで切り替える
・多少でもダウン、もしくは遅延が許容されるのであれば、アプリケーション側でログやキュー等で一時書き出しをして置けるようにしておき、MongoDBへのアクセスを止めている間に、オンプレミス側mongodump＞AWS側mongorestoreしたあとで止めておいたデータの書き出しをAWS側のMongoDBに行う＞AWS側で切り替えを行う
・長期間のダウンでも問題ないのであれば、オンプレミス側へのアクセス止めて、オンプレミス側mongodump＞AWS側mongorestore
等の方法になるかと思います。
mongodump
https://docs.mongodb.com/manual/reference/program/mongodump/
mongorestore
https://docs.mongodb.com/manual/reference/program/mongorestore/
以上です。今月のAWS Black Belt Online Seminarの予定に関しましては、こちらをご参照ください。
引き続き多くの方のご参加をお待ちしております！
コメント