AmebaのMongoDB活用事例

AmebaのMongoDB
活用事例

株式会社サイバーエージェント
アメーバ事業本部ピグディヴィジョン

桑野章弘

12年8月24日金曜日

アジェンダ

n Amebaのサービス
n サービス環境の変遷
n サービスを支えるMongoDB
n 困ったことなど
n 運用について
n まとめ


自己紹介

n 桑野章弘
l サイバーエージェント
l Ameba を運営しています。
l ピグソーシャルゲームの運用／構築を担当

l Twitter
l @kuwa_tw

l Blog
l http://d.hatena.ne.jp/akuwano/


ピグライフ


ピグライフ

n サービス情報
l 2011/05/31オープン
l 会員数360万人（2012/01現在）
l サービス開始3週間で100万人突破
l 接続数：20万同時接続


ピグアイランド


ピグアイランド

l 2012/05/22オープン
l サービス開始5日で100万人突破
l 接続数：約10万同時接続


ピグカフェ


ピグカフェ

l 2012/08/21オープン


様々なサービスをピグ
プラットフォームで
展開中

これらのサービスは全
てMongoDBを使っ
ています

サービス環境の変遷


n まずは弊社サービスの成長の変遷について説明し
ます


アーキテクチャ

n アプリケーションサーバ
l Node.js
l Nginx
n データストアサーバ
l MongoDB


アーキテクチャ
BackEnd
FrontEnd

ユーザ/エリア等の状態
データ
staticサーバ Node.jsサーバ
Socketサーバ

mongodbサーバ
Flashデータ必要なデータの取得
→リクエスト/取得

HTTP

WebSocket接続

・ユーザ情報
・チャットデータ
→リクエスト/取得

ユーザ
（ブラウザ：Flash）


[ピグライフ]の変遷


ピグライフ

n リリースから現在
l βテスト時代
l リリース後
l 現在


ピグライフ

n リリースから現在
l βテスト時代
l リリース後
l 現在

どんなフェーズを経たか


ピグライフ：βテスト時代

n 4/26∼5/31
l テストユーザ数5000∼30000
l 毎日リリース、機能追加、インフラ構成変更
l サーバも最小限を用意


ピグライフ：βテスト時代

βテスト時に実
装

6

mongos

行動ログの保存
Staticサーバ Node.jsサーバ MongoDB Log

MongoDB


ピグライフ：リリース後

n 問題点洗い出しのフェーズ
l Node.jsのサーバや、mongodbも、パフォーマン
スが出ていなかったため増設
l Swfファイルをnode.jsのサーバから静的ファイル専
用のサーバへと切り出す



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


リリース時構成

大量追加

3 44

mongos
行動ログの保存
サーバにも取得
Staticサーバ Node.jsサーバ MongoDB Log

1シャード追加
(合計4シャー
ド)

MongoDB



n パフォーマンス確保のフェーズ
l ボトルネック調査
l 状況を見つつサーバ台数、リソースの確保


ピグライフ：現在

n 9/1 ∼
l 順調な成長
l 開始3ヶ月弱(8/22)で200万人突破


現在時構成
リリース時切替

高スペックサー
バにリプレイス

5 5 10 10
Node.jsサーバ_B系
mongos mongos

Staticサーバ_A系 Staticサーバ_B系 Node.jsサーバ_A系行動ログの保存
DB統合

23シャード追
加(合計27
・・・・・
シャード＝81
台)

MongoDB


ピグライフ：現在

n 運用改善のフェーズ
l メンテ時間短縮のため稼働グループを分割
l A系、B系での切替

l 構成はシンプルにしていく
l CDNなどの導入検討
（CDNを入れられるように仕様変更）


ピグライフ：成長速度

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

サービスの予想以上の成長


サービスを支える
MongoDB


この成長速度を支えた
MongoDBの基本的
な機能

MongoDBの構成
アプリケーションサー
バ

mongos Mongod[ShardA]

Mongod[ShardB]

mongoc
Mongod[ShardC]


アーキテクチャについて

n システムアーキテクチャ
l スキーマレス
l 冗長化
l ReplicaSets

l スケーラビリティ
l Sharding


アーキテクチャの課題

n スキーマレスなデータ構造による柔軟なデータ管
理
l ユーザ情報なども柔軟に持つことができるので、機能
追加時等が比較的楽
l 次ページ例



n スキーマレスなデータ構造
l ユーザーコレクションに趣味を追加したい場合

{
"_id" : "1234567889",
"userid" : "akuwano",
"username" : "Akihiro Kuwano"
}

{
"_id" : "1234567889",
"userid" : "akuwano",
"hobby" : Movie ,
"username" : "Akihiro Kuwano"
}



n ReplicaSets
l 相互死活監視＆投票により冗長性を保つ。最小単位は
3台。

プライマリ

セカンダリセカンダリ



n ReplicaSets
l 相互死活監視＆投票により冗長性を保つ。最小単位は
3台。

生きているサープライマリ
バで投票が行わ
れ新しいプライ
マリが選ばれる

セカンダリセカンダリ → プライマリ



n Sharding
l データをChunkの細かい粒度に分割する。
各mongodに分散して渡すことで各サーバの負荷を
分散します


MongoDBの構成
Sharding
アプリケーションサー ReplicaSetsに
データをChunk
バよりサーバの冗長
の単位に分ける
性を確保
DATA

mongos

Mongod[ShardA]

Mongod[ShardB]

mongoc

Mongod[ShardC]


MongoDBの構成
Sharding
データをChunk
性を確保
ChunkA ChunkB ChunkC

mongos

mongocは
Mongod[ShardA]
シャーディング情
報を持つ

Mongod[ShardB]

mongoc

ChunkA -> ShardA
ChunkB -> ShardB Mongod[ShardC]
ChunkC -> ShardC


MongoDBの構成
Sharding
データをChunk 性を確保

mongos

mongocは
ChunkA Mongod[ShardA]
シャーディング情
報を持つ

ChunkB Mongod[ShardB]

mongoc

ChunkA -> ShardA
ChunkB -> ShardB ChunkC Mongod[ShardC]
ChunkC -> ShardC



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


使いどころ


まとめ

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


困ったことについて


運用中に困ったことに
ついて


n クラスターのスローダウン
l 必要なデータを一気にデータをインポートした場合
l oplogデータ量範囲を超えてレプリケーションが停止
l 一度に入れたため、PrimaryShardにChunkが溜
まってしまいI/Oバウンドに
l 負荷が高いのでBalancerは動かないためクラスタの
スローダウン

→Oplogの容量を増やすことができるのでそれらで対
応


n シャード設定のスローダウン
l ほんとに突然パフォーマンスダウンする
「10分前は動いてたけど、、、」
l PrimaryShardはリソースを潤沢な状態にする
l 各シャードのmmapの容量が実メモリを超えてきた
ら注意する

→シャード設定は定期的に確認＆シャードの設定を自
動化


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


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


日々の運用


ここからは実際の運用
でやっていること


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


l メモリ
l 積めば積むほどキャッシュが効くのでできるだけ積む
l 現在は1ノード32GBのサーバを用意


l DISK
l こちらも書き込み、読み込みが早いに越したことは無い
l 今までは、SAS * 4 RAID10 -> SSD * 2 RAID0となっ
ている。
l 現在はSSDはSASの3倍のiopsが出ています。
l FileSystemはxfs or ext4（高速なfallocate()がサ
ポートされている必要があるため）


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


n バックアップ
l mongodump
l ReplicaSetsのDelay


l mongodump
l mongosに対してmongodump実行するのはバックアッ
プとしては一番簡単です。
l 稼働中にかけると完全なポイントイン・タイムのバックアッ
プにはなりません


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


バックアップの構成
1、Chunkが
アプリケーションサー２，fsync lock
バックアップ中に
バをかけることで更
移動させない
新を止める

mongos

Mongod[ShardA]
３，各シャードか
らデータを取得

Mongod[ShardB]

mongoc

Mongod[ShardC]


l ReplicasetsのDelay
l バックアップと言うよりはオペミスの防止
l 常に最新の状態よりも一定期間古い状態となる、
Replicasetsを追加します


RS Delayの構成
アプリケーションサー
この Replica
バ
Sets のみ、他の
RSよりも3時間
前のデータを持つ

mongos

Mongod[ShardA]

Mongod[ShardB]
mongoc

Mongod[ShardC]


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,


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


n ロック

Collection A Collection B Collection C


n ロック

Collection A Collection C Collection B


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


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


n 各種コマンド、ステータスなど
l トレンドが見たい
l 現状が把握したい


n 各種コマンド、ステータスなど
l mongostat
l mongotop
l mongosniff


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


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


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


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


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


n ステータス確認・変更
l proﬁling
l loglevel変更
l db.adminCommand("connPoolStats")
l db.serverStatus()
l db.currentOp()
l db.collection.stat()
l db.stats()


まとめ


まとめ

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


まとめ

n 今後のアップデートなども様々な物が控えてお
り、現在の問題点も徐々に改善されると考えてお
ります。


まとめ

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


ご清聴ありがとう
ございました


AmebaのMongoDB活用事例

More Related Content

What's hot

Viewers also liked

Similar to AmebaのMongoDB活用事例

More from Akihiro Kuwano

AmebaのMongoDB活用事例