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.find({'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 flushes 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 profiling
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日金曜日