1. 大規模化するピグライフを支
えるインフラ 〜MongoDBと
Chefについて〜(前編)
株式会社サイバーエージェント
アメーバ事業本部プラットフォームディビジョン
サービスディベロップメントグループ
CA Developers Connect
桑野 章弘

2. 自己紹介
桑野章弘
サイバーエージェント
Ameba を運営しています。
- Blogを中心として様々なサービスがあります。
ピグライフの運用／構築を担当
Twitter
@kuwa_tw
Blog
http://d.hatena.ne.jp/akuwano/
著書／活動
「MySQLによるタフなサイトの作り方」
勉強会（hbstudy, qpstudyほか）などでの発表など
2

3. Ameba
3

4. アジェンダ
ピグライフ
なぜMongoDBを採用したか？
サービスアーキテクチャの課題
システムアーキテクチャの課題
運用上での課題
キャパプラ
運用
まとめ
4

5. ピグライフ
5

6. ピグライフ
ピグのキャラクターを利用したガーデニングゲーム
こんなことができます
ガーデニング
裁縫
料理
ティーパーティー
羊を飼ったり
6

7. ピグライフ
7

8. ピグライフ
サービス情報
2011/05/31オープン
会員数360万人（2012/01現在）
サービス開始3週間で100万人突破
接続数：20万接続
8

9. アーキテクチャ：ピグとの比較
アメーバピグのシステムを踏襲していますが使用
しているアーキテクチャが異なります
システム概要
Adobe Flashを使用したリアルタイム処理
Flashから直接TCP通信を⾏う事によって実現
9

10. アーキテクチャ：ピグとの比較
アメーバピグのシステムを踏襲していますが使用してい
るアーキテクチャが異なります
アメーバピグ ピグライフ
アプリケーションサー フルスクラッチ Node.js
バ Javaサーバ
サーバ
データベースサーバ MySQL MongoDB
10

11. ピグライフのアーキテクチャ：全体構成
BackEnd
FrontEnd
ユーザ/エリ
ア等の状態
staticサーバ Node.jsサーバ
Socketサーバ
データ
mongodbサーバ
Flashデータ 必要なデータ
→リクエスト の取得
/取得
HTTP
WebSocket接続
・ユーザ情報
・チャット
データ
→リクエスト
/取得
ユーザ
（ブラウザ）
11

12. なぜMongoDBを採用
したか？
12

13. アーキテクチャの課題
サービスアーキテクチャの課題
開発スピード
システムアーキテクチャの課題
冗⻑化
ReplicaSets
スケーラビリティ
Sharding
13

14. アーキテクチャの課題
サービスアーキテクチャの課題
開発スピード
システムアーキテクチャの課題
冗⻑化
ReplicaSets
スケーラビリティ
Sharding
これらの課題を解決できる
ソリューションだったため
14

15. MongoDBの構成
アプリケーションサーバ
mongos Mongod[ShardA]
Mongod[ShardB]
mongoc
Mongod[ShardC]
15

16. アーキテクチャの課題
開発スピードの構造
Node.jsとの相性の良さ
データのやりとりがJSONで統一される
スキーマレスなデータ構造による柔軟なデータ管理
機能追加時
ユーザ情報なども柔軟に持つことができる（次ページ例）
16

17. アーキテクチャの課題
開発スピードの構造
ユーザーコレクションに最終ログインタイムを追加し
たい場合
{
"_id" : "1234567889",
"userid" : "akuwano",
"username" : "Akihiro Kuwano"
}
17

18. アーキテクチャの課題
開発スピードの構造
ユーザーコレクションに最終ログインタイムを追加し
たい場合
{
"_id" : "1234567889",
"userid" : "akuwano",
"lastLoginTime" : ISODate("2011-12-25T14:22:46.777Z"),
"username" : "Akihiro Kuwano"
}
18

19. アーキテクチャの課題
スケーラビリティの問題
Sharding
データをChunkの細かい粒度に分割し、各mongodに分散し
て渡すことで各サーバの負荷を分散します
19

20. MongoDBの構成
Sharding
アプリケーションサーバ データをChunk ReplicaSetsに
の単位に分ける よりサーバの冗
⻑性を確保
DATA
mongos
Mongod[ShardA]
Mongod[ShardB]
mongoc
Mongod[ShardC]
20

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

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

23. アーキテクチャの課題
冗⻑性の問題
ReplicaSets
相互死活監視＆投票により冗⻑性を保つ。最⼩単位は3台。
プライマリ
セカンダリ セカンダリ
23

24. アーキテクチャの課題
冗⻑性の問題
ReplicaSets
相互死活監視＆投票により冗⻑性を保つ。最⼩単位は3台。
生きているサー プライマリ
バで投票が⾏わ
れ新しいプライ
マリが選ばれる
セカンダリ セカンダリ → プライマリ
24

25. アーキテクチャの課題
MongoDBのこれら機能により、アプリ側の実装
コストは軽く、スケーラビリティを保ったシステ
ム構築を⾏うことが出来ました。
実際の運用ではそこまで
上⼿く⾏ったのでしょうか？
25

26. 実運用上での課題
26

27. 実運用での課題
MongoDBの機能は自動でスケーラビリティや、
冗⻑性の確保が⾏えます。
現在の台数は140台となっており、おそらくこの
規模の台数で使っているMongoDBのクラスタは
あまり無いのでは無いでしょうか。
その際に生まれたノウハウについて説明します。
27

28. 実運用での課題：サーバキャパプラ
サーバキャパプラ
まずは各サーバプロセスのキャパプラについて説明し
ていきます
28

29. 実運用での課題：サーバキャパプラ
サーバキャパプラ
mongos
スケーラビリティはありません
アプリケーションサーバに同居する形にしている
サーバへの負荷は少ないです
29

30. 実運用での課題：サーバキャパプラ
サーバキャパプラ
mongoc
スケーラビリティはない
通常時に負荷はかからないが、潤沢なリソースを使える状態
にしておくほうがよい（上記理由）
冗⻑性は同期書き込み（ 2フェーズコミット）という形で確
保されています
30

31. 実運用での課題：サーバキャパプラ
サーバキャパプラ
mongod
DISK I/O：定期的に書きだすのである程度の性能が必要
- ioDriveで⾼速に処理することも可能だが、レプリケーションが
停止する可能性があるのでサーバ単体で使った方がioDriveの性
能を使い切ることができます
CPU：書き込みはグローバルロックが存在しているために、
複数コアを効率良く使えません
メモリ：Index、データをメモリにキャッシュするため多け
れば多いほどよいです
アクセスが多岐に渡る場合にはIndexがメモリから溢れてし
まうので、パフォーマンスが落ちる。その場合ページフォル
トが⼤量に発生し始めるのでそれが目安
31

32. 実運用での課題：運用面
index
特定のカラムで検索を⾏う場合にはindexを貼る事で⾼速化を
図ります
2.0系でIndexが⾼速化 & コンパクト化されているので
Indexを多用する場合はバージョンアップする
32

33. 実運用での課題：運用面
Index
Indexの確認->explain() Indexなし
replSetTest1001:PRIMARY> db.User.find({'Field02': 'test'}).explain()
{
{"_id" : "1234567889",
"cursor" : "BasicCursor",
"userid" : "akuwano",
"nscanned" : 706456,
"username" : "Akihiro Kuwano"
} "nscannedObjects" : 706456,
"n" : 1,
"millis" : 749,
"nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
"indexBounds" : {
}
}
33

34. 実運用での課題：運用面
Index
Indexの確認->explain() Indexあり
replSetTest1001:PRIMARY> db.User.find({'Field01': 'test'}).explain()
{
"cursor" : "BtreeCursor testIndex_1",
{ "nscanned" : 1,
"_id" : "1234567889", : 1,
"nscannedObjects"
"userid" : "akuwano",
"n" : 1,
"username": :7,
"millis" "Akihiro Kuwano"
} "nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
"indexBounds" : {
"Field01" : [
[
"test",
"test"
]
]
}
}
34

35. 実運用での課題：運用面
バックアップ
fsyncコマンドでレプリケーションを停止して、dumpを取得
する
1. Replication 2. Dump取得
をとめる
DUMP
35

36. 実運用での課題：運用面
グローバルロック
同じサーバ上に異常に書き込みの多いコレクションが
あった場合には（結果的に）クラスタ全体のアクセス
に影響します
現状は別クラスタに分ける事で影響を局所化
今後コレクションレベルロックが実装されるとこのよ
うな⼿間はなくなる予定です
36

37. 実運用での課題：運用面
グローバルロック
Collection A Collection B Collection C
37

38. 実運用での課題：運用面
グローバルロック
Collection A Collection C Collection B
38

39. 実運用での課題：運用面
Chunkの偏り
AutoBalanceがOnの場合Chunkは「データ量」もし
くは「オブジェクト数」によって分割されます
-> Not「データアクセス頻度」
「データアクセス頻度」によるShard分割をしたい場
合にはManualBalanceにする必要がある
->⼿動Chunk移動を⾏った場合には現状全mongos
の再起動が必要となるため厳しい
今後の課題
ただし、2.0系のAutoBalanceはかなり頭が良くなっている
39

40. 実運用での課題：運用面
バグとの戦い（今まで踏んだバグ）
mongodumpをmongos経由で実⾏すると落ちる
各シャードへのdump実⾏
mongos->mongocの接続断が起こった場合の再接
続でmongocが負荷が上がる
主にmongos経由の接続を同時に⼤量に⾏った場合
mongocのスペックアップ(mongoc > mongod)
バージョンアップ
mongod replicasetsのPRIMARYが切り替わった時
にmongosがdown
バージョンアップ待ち
40

41. 実運用での課題：運用面
サーバの台数増
定常的なサーバ追加が必要
Chef,Puppet等を使用し構築をプログラマブルにする
->この後Chefに関しては並河よりお話しします
41

42. まとめ
42

43. 実運用での課題：運用面
MongoDBは、仕様など改善の余地はある物の、
スケーラビリティを確保するための要素としての
「Sharding」「ReplicaSets」と、同時に柔軟
なデータ構造などサービス開発を加速するために
必要な要素を兼ね揃えたプロダクトです。
弊社の使用サービスも増え、ノウハウも蓄積でき
て来ているのでそれが固まり、バージョンが上が
る頃には安定して成⻑できる運用の一要素として
⼤事な役割を持つことになると考えています。
43

44. この後は
といった所で弊社並河へ
Chefに関して語ってもらいます
さあどーぞ！
44