AmebaのMongoDB活用事例

1. AmebaのMongoDB 活用事例株式会社サイバーエージェントアメーバ事業本部ピグディヴィジョン桑野章弘 12年8月24日金曜日

2. アジェンダ n Amebaのサービス n サービス環境の変遷 n サービスを支えるMongoDB n 困ったことなど n 運用について n まとめ 12年8月24日金曜日

3. 自己紹介 n 桑野章弘 l サイバーエージェント l Ameba を運営しています。 l ピグソーシャルゲームの運用／構築を担当 l Twitter l @kuwa_tw l Blog l http://d.hatena.ne.jp/akuwano/ 12年8月24日金曜日

4. ピグライフ 12年8月24日金曜日

5. ピグライフ n サービス情報 l 2011/05/31オープン l 会員数360万人（2012/01現在） l サービス開始3週間で100万人突破 l 接続数：20万同時接続 12年8月24日金曜日

6. ピグアイランド 12年8月24日金曜日

7. ピグアイランド n サービス情報 l 2012/05/22オープン l サービス開始5日で100万人突破 l 接続数：約10万同時接続 12年8月24日金曜日

8. ピグカフェ 12年8月24日金曜日

9. ピグカフェ n サービス情報 l 2012/08/21オープン 12年8月24日金曜日

10. 様々なサービスをピグプラットフォームで展開中 12年8月24日金曜日

11. これらのサービスは全てMongoDBを使っています 12年8月24日金曜日

12. サービス環境の変遷 12年8月24日金曜日

13. n まずは弊社サービスの成長の変遷について説明します 12年8月24日金曜日

14. アーキテクチャ n アプリケーションサーバ l Node.js l Nginx n データストアサーバ l MongoDB 12年8月24日金曜日

15. アーキテクチャ BackEnd FrontEnd ユーザ/エリア等の状態データ staticサーバ Node.jsサーバ Socketサーバ mongodbサーバ Flashデータ必要なデータの取得 →リクエスト/取得 HTTP WebSocket接続・ユーザ情報・チャットデータ →リクエスト/取得ユーザ（ブラウザ：Flash） 12年8月24日金曜日

16. [ピグライフ]の変遷 12年8月24日金曜日

17. ピグライフ n リリースから現在 l βテスト時代 l リリース後 l 現在 12年8月24日金曜日

18. ピグライフ n リリースから現在 l βテスト時代 l リリース後 l 現在どんなフェーズを経たか 12年8月24日金曜日

19. ピグライフ：βテスト時代 n 4/26∼5/31 l テストユーザ数5000∼30000 l 毎日リリース、機能追加、インフラ構成変更 l サーバも最小限を用意 12年8月24日金曜日

20. ピグライフ：βテスト時代 βテスト時に実装 6 mongos 行動ログの保存 Staticサーバ Node.jsサーバ MongoDB Log MongoDB 12年8月24日金曜日

21. ピグライフ：リリース後 n 問題点洗い出しのフェーズ l Node.jsのサーバや、mongodbも、パフォーマンスが出ていなかったため増設 l Swfファイルをnode.jsのサーバから静的ファイル専用のサーバへと切り出す 12年8月24日金曜日

22. ピグライフ：リリース後 n 5/31 ∼ l ピグライフ、正式リリース l 人気が爆発、予想以上の伸び l 開始3週間(6/22)で100万人突破 l とにかく増設の時期 12年8月24日金曜日

23. リリース時構成大量追加 3 44 mongos 行動ログの保存サーバにも取得 Staticサーバ Node.jsサーバ MongoDB Log 1シャード追加 (合計4シャード) MongoDB 12年8月24日金曜日

24. ピグライフ：リリース後 n パフォーマンス確保のフェーズ l ボトルネック調査 l 状況を見つつサーバ台数、リソースの確保 12年8月24日金曜日

25. ピグライフ：現在 n 9/1 ∼ l 順調な成長 l 開始3ヶ月弱(8/22)で200万人突破 12年8月24日金曜日

26. 現在時構成リリース時切替高スペックサーバにリプレイス 5 5 10 10 Node.jsサーバ_B系 mongos mongos Staticサーバ_A系 Staticサーバ_B系 Node.jsサーバ_A系行動ログの保存 DB統合 23シャード追加(合計27 ・・・・・シャード＝81 台) MongoDB 12年8月24日金曜日

27. ピグライフ：現在 n 運用改善のフェーズ l メンテ時間短縮のため稼働グループを分割 l A系、B系での切替 l 構成はシンプルにしていく l CDNなどの導入検討（CDNを入れられるように仕様変更） 12年8月24日金曜日

28. ピグライフ：成長速度 n 成長速度 l リリースから3ヶ月程度で、サーバ規模としては8倍に。それにともなって、トラフィック(1.3Gbps)、総コネクション数(18万)も増加。 l その期間は3ヶ月余り。3週間の伸びは単位にすれば 30倍サービスの予想以上の成長 12年8月24日金曜日

29. サービスを支える MongoDB 12年8月24日金曜日

30. この成長速度を支えた MongoDBの基本的な機能 12年8月24日金曜日

31. MongoDBの構成アプリケーションサーバ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 12年8月24日金曜日

32. アーキテクチャについて n システムアーキテクチャ l スキーマレス l 冗長化 l ReplicaSets l スケーラビリティ l Sharding 12年8月24日金曜日

33. アーキテクチャの課題 n スキーマレスなデータ構造による柔軟なデータ管理 l ユーザ情報なども柔軟に持つことができるので、機能追加時等が比較的楽 l 次ページ例 12年8月24日金曜日

34. アーキテクチャの課題 n スキーマレスなデータ構造 l ユーザーコレクションに趣味を追加したい場合 { "_id" : "1234567889", "userid" : "akuwano", "username" : "Akihiro Kuwano" } { "_id" : "1234567889", "userid" : "akuwano", "hobby" : Movie , "username" : "Akihiro Kuwano" } 12年8月24日金曜日

35. アーキテクチャの課題 n ReplicaSets l 相互死活監視＆投票により冗長性を保つ。最小単位は 3台。プライマリセカンダリセカンダリ 12年8月24日金曜日

36. アーキテクチャの課題 n ReplicaSets l 相互死活監視＆投票により冗長性を保つ。最小単位は 3台。生きているサープライマリバで投票が行われ新しいプライマリが選ばれるセカンダリセカンダリ → プライマリ 12年8月24日金曜日

37. アーキテクチャの課題 n Sharding l データをChunkの細かい粒度に分割する。各mongodに分散して渡すことで各サーバの負荷を分散します 12年8月24日金曜日

38. MongoDBの構成 Sharding アプリケーションサー ReplicaSetsにデータをChunk バよりサーバの冗長の単位に分ける性を確保 DATA mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 12年8月24日金曜日

39. MongoDBの構成 Sharding アプリケーションサー ReplicaSetsにデータをChunk バよりサーバの冗長の単位に分ける性を確保 ChunkA ChunkB ChunkC mongos mongocは Mongod[ShardA] シャーディング情報を持つ Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB Mongod[ShardC] ChunkC -> ShardC 12年8月24日金曜日

40. MongoDBの構成アプリケーションサー ReplicaSetsにバよりサーバの冗長 Sharding データをChunk 性を確保の単位に分ける mongos mongocは ChunkA Mongod[ShardA] シャーディング情報を持つ ChunkB Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB ChunkC Mongod[ShardC] ChunkC -> ShardC 12年8月24日金曜日

41. アーキテクチャの課題 n MongoDBのこれらの基本機能により、アプリ側の実装コストは軽くなります。 n 前述した、9台→100台への変更においても、アプリ側のDB接続部分の変更点は殆どありません。 n スケーラビリティを保ったまま、シンプルなサービス構築を行うことができています。 12年8月24日金曜日

42. 使いどころ 12年8月24日金曜日

43. まとめ n データ量が大き過ぎない n 書き込みが多過ぎない n 単位時間あたりの処理データが各シャードのメモリ量を超えない処理は得意 l 現在のピグ系のリアルタイム処理には合っている n ホットデータが無い様なデータの使い方は苦手 12年8月24日金曜日

44. 困ったことについて 12年8月24日金曜日

45. 運用中に困ったことについて 12年8月24日金曜日

46. n クラスターのスローダウン l 必要なデータを一気にデータをインポートした場合 l oplogデータ量範囲を超えてレプリケーションが停止 l 一度に入れたため、PrimaryShardにChunkが溜まってしまいI/Oバウンドに l 負荷が高いのでBalancerは動かないためクラスタのスローダウン →Oplogの容量を増やすことができるのでそれらで対応 12年8月24日金曜日

47. n シャード設定のスローダウン l ほんとに突然パフォーマンスダウンする「10分前は動いてたけど、、、」 l PrimaryShardはリソースを潤沢な状態にする l 各シャードのmmapの容量が実メモリを超えてきたら注意する →シャード設定は定期的に確認＆シャードの設定を自動化 12年8月24日金曜日

48. n データ肥大 l 運用していくに連れてデータの肥大化が起きます l 定期的なデータのコンパクションが必要です l repairコマンドは、データ容量と同容量のスペースを利用するので注意 l データ容量が小容量かつ、一時的にMongoDBのクラスタを止められるなら、データdrop→データ resoreの方が簡単です。 12年8月24日金曜日

49. n ドライバ関連 l Node.jsのドライバのバージョンによってデータの持ち方などが異なる場合があった（現在は解消）ので、バージョンアップは慎重に行ないましょう 12年8月24日金曜日

50. 日々の運用 12年8月24日金曜日

51. ここからは実際の運用でやっていること 12年8月24日金曜日

52. n MongoDBに使用するハードウェア l CPU l （現在は）CPUはあまり負荷が来ないためそれほど良い物でなくて良い l そのかわりノードを増やすことになるのであればラックの効率を上げるため消費電力の少ないものを選択する 12年8月24日金曜日

53. n MongoDBに使用するハードウェア l メモリ l 積めば積むほどキャッシュが効くのでできるだけ積む l 現在は1ノード32GBのサーバを用意 12年8月24日金曜日

54. n MongoDBに使用するハードウェア l DISK l こちらも書き込み、読み込みが早いに越したことは無い l 今までは、SAS * 4 RAID10 -> SSD * 2 RAID0となっている。 l 現在はSSDはSASの3倍のiopsが出ています。 l FileSystemはxfs or ext4（高速なfallocate()がサポートされている必要があるため） 12年8月24日金曜日

55. n MongoDBに使用するハードウェア l DISK l ioDriveでの検証に関しては、現状では8000opsを超えた位でReplicaSetsのoplogの転送が止まる事を確認しています。 l 速度は3倍以上出ていたので、単体で使用するようなデータには使えるかもしれません。（試してないです） l 2.2以降では改善されている可能性があるので再検証予定 12年8月24日金曜日

56. n バックアップ l mongodump l ReplicaSetsのDelay 12年8月24日金曜日

57. n バックアップ l mongodump l mongosに対してmongodump実行するのはバックアップとしては一番簡単です。 l 稼働中にかけると完全なポイントイン・タイムのバックアップにはなりません 12年8月24日金曜日

58. n バックアップ l 稼働中にスナップショットバックアップを取得 l １，mongos経由でAutoBalancingをOff l ２，各レプリカセットにfsync lockをかける l ３，各mongodからデータを取得する（AWSなら Snapshotがいいですね） l ４，各レプリカセットにfsync unlock l ５，mongos経由でAutoBalancingをOn 12年8月24日金曜日

59. バックアップの構成 1、Chunkがアプリケーションサー２，fsync lock バックアップ中にバをかけることで更移動させない新を止める mongos Mongod[ShardA] ３，各シャードからデータを取得 Mongod[ShardB] mongoc Mongod[ShardC] 12年8月24日金曜日

60. n バックアップ l ReplicasetsのDelay l バックアップと言うよりはオペミスの防止 l 常に最新の状態よりも一定期間古い状態となる、 Replicasetsを追加します 12年8月24日金曜日

61. RS Delayの構成アプリケーションサーこの Replica バ Sets のみ、他の RSよりも3時間前のデータを持つ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 12年8月24日金曜日

62. n Index l indexが効いているかはexplain()で確認 l できるだけPK=_id で検索する実装にする replSetTest1001:PRIMARY> db.User.ﬁnd({'Field01': 'test'}).explain() { "cursor" : "BtreeCursor testIndex_1", "nscanned" : 1, "nscannedObjects" : 1, "n" : 1, "millis" : 7, "nYields" : 0, 12年8月24日金曜日

63. n ロック l 同じサーバ上に異常に書き込みの多いコレクションがあるとクラスタ全体のアクセスに影響するため、コレクションを分ける l アプリ実装はコレクション間を疎結合で作る l 2.2系でDBレベルロックが実装されるとDBを分ければよいのでこの様な手順は要らない 12年8月24日金曜日

64. n ロック Collection A Collection B Collection C 12年8月24日金曜日

65. n ロック Collection A Collection C Collection B 12年8月24日金曜日

66. n ロック Collection A Collection C Collection B 12年8月24日金曜日

67. n 運用効率化 l どうしても台数が多くなる傾向にあります。 l そのため「標準のコマンドだと表示が多すぎて見づらい」「今のマスターの一覧が簡単に出したい」等の不満がでます。 l これらはスクリプト作成等で対応しています、このあたりもJSONで各種データを取ってこれるために管理ツールなどは作りやすいです。 12年8月24日金曜日

68. n 運用効率化：運用スクリプトの内容 l ロックタイムの取得 l シャードに入っているmongod一覧のリスト出力 l レプリカセットのマスター検索 l レプリカセットのpriority検索 l printShardingStatusの整形 l レプリカセット一括作成／設定変更（現在のRSに Delayホスト追加するなど） 12年8月24日金曜日

69. n 各種コマンド、ステータスなど l トレンドが見たい l 現状が把握したい 12年8月24日金曜日

70. n 各種コマンド、ステータスなど l mongostat l mongotop l mongosniff 12年8月24日金曜日

71. n mongostat l クエリや、プロセスの現状を確認するコマンド $ ./mongostat --host 192.168.8.41:27018,192.168.8.62:27018 insert query update delete getmore command ﬂushes mapped vsize res faults locked % idx miss % qr¦qw ar¦aw netIn netOut conn set repl time 192.168.8.41:27018 0 361 132 0 209 437 0 36.1g 76.2g 14.3g 1 2.2 0 0¦0 2¦0 85k 698k 3056 RSTest1001 M 11:16:57 192.168.8.62:27018 0 384 164 0 245 480 0 30.1g 63.9g 15.6g 0 2 0 0¦0 2¦0 96k 652k 2587 RSTest1002 M 11:16:57 12年8月24日金曜日

72. n mongostat - 見るべき項目 l faults - 1秒当りのページフォールト数 l Locked % - グローバルライトロックの時間割合 l idx miss % - indexのヒット率の時間割合 l qr¦qw - 読み込みキュー¦書き込みキューの大きさ 12年8月24日金曜日

73. n mongostat - 見るべき項目 l faults が多い場合キャッシュメモリ溢れの可能性があるので、メモリ、もしくはサーバを増設 l Locked % が高い場合書き込みのクエリを見直す or クラスタ分割。 l qr¦qw が高い場合サーバ負荷が低ければ、ロックの可能性を疑う。負荷が高ければ単純なクエリ増による高負荷を疑う。 12年8月24日金曜日

74. n mongotop l 現在重いmongodのどのcollectionへアクセスがかかっているかを確認したりとかできまする。 l 障害の時がメイン $ /usr/local/mongodb2_1/bin/mongotop --host mongos_ip --port 27018 connected to: mongos_ip ns total read write writeに時間 2012-05-23T02:14:12 がかかってい local.oplog.rs 1929ms 1929ms 0ms life_prd_main.TestOnline 0ms 500ms 10ms life_prd_main.Test2Soil 8ms 0ms 8ms 12年8月24日金曜日

75. n mongosniff l 最後はパケットキャプチャですので、何か会った際のアクセス状況の確認が可能 l mongosのアクセス状況とか、複雑なクエリを見たい場合はこれで見るのが良い # mongosniff --source NET eth0 27017 # 以下にパケットがズラズラっと並ぶ 127.0.0.1:55858 -->> 127.0.0.1:27017 testdatabase.TestCol1 89 bytes id:kjkjkjkj 14086840 query: { _id: "1234567891234567" } ntoreturn: -1 ntoskip: 0 127.0.0.1:27017 <<-- 127.0.0.1:55858 205 bytes id:77383268 2000171624 - 14086840 12年8月24日金曜日

76. n ステータス確認・変更 l proﬁling l loglevel変更 l db.adminCommand("connPoolStats") l db.serverStatus() l db.currentOp() l db.collection.stat() l db.stats() 12年8月24日金曜日

77. まとめ 12年8月24日金曜日

78. まとめ n まだ各所に未熟な点はありますが、運用を安定させる事で、綺麗な構成でスケーラビリティを確保したサービスを構築することができるプロダクトになる可能性がMongoDBにはあると考えています。 12年8月24日金曜日

79. まとめ n 今後のアップデートなども様々な物が控えており、現在の問題点も徐々に改善されると考えております。 12年8月24日金曜日

80. まとめ n ただ、NoSQLは適材適所、という言葉もあり、徐々に使って慣れていくのが大事だと思います。スモールスタートでまずは使ってみてはどうでしょうか。 12年8月24日金曜日

81. ご清聴ありがとうございました 12年8月24日金曜日

AmebaのMongoDB活用事例

AmebaのMongoDB活用事例

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Similar to AmebaのMongoDB活用事例

Similar to AmebaのMongoDB活用事例(20)

More from Akihiro Kuwano

More from Akihiro Kuwano(8)

AmebaのMongoDB活用事例