Mais conteúdo relacionado
Semelhante a AmebaのMongoDB活用事例 (20)
Mais de Akihiro Kuwano (10)
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日金曜日
- 5. ピグライフ
n サービス情報
l 2011/05/31オープン
l 会員数360万人(2012/01現在)
l サービス開始3週間で100万人突破
l 接続数:20万同時接続
12年8月24日金曜日
- 7. ピグアイランド
n サービス情報
l 2012/05/22オープン
l サービス開始5日で100万人突破
l 接続数:約10万同時接続
12年8月24日金曜日
- 9. ピグカフェ
n サービス情報
l 2012/08/21オープン
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日金曜日
- 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日金曜日
- 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日金曜日
- 43. まとめ
n データ量が大き過ぎない
n 書き込みが多過ぎない
n 単位時間あたりの処理データが各シャードのメモ
リ量を超えない処理は得意
l 現在のピグ系のリアルタイム処理には合っている
n ホットデータが無い様なデータの使い方は苦手
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日金曜日
- 52. n MongoDBに使用するハードウェア
l CPU
l (現在は)CPUはあまり負荷が来ないためそれほど良い物で
なくて良い
l そのかわりノードを増やすことになるのであればラックの効
率を上げるため消費電力の少ないものを選択する
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 1,mongos経由でAutoBalancingをOff
l 2,各レプリカセットにfsync lockをかける
l 3,各mongodからデータを取得する(AWSなら
Snapshotがいいですね)
l 4,各レプリカセットにfsync unlock
l 5,mongos経由でAutoBalancingをOn
12年8月24日金曜日
- 59. バックアップの構成
1、Chunkが
アプリケーションサー 2,fsync lock
バックアップ中に
バ をかけることで更
移動させない
新を止める
mongos
Mongod[ShardA]
3,各シャードか
らデータを取得
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日金曜日
- 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日金曜日
- 78. まとめ
n まだ各所に未熟な点はありますが、運用を安定さ
せる事で、綺麗な構成でスケーラビリティを確保
したサービスを構築することができるプロダクト
になる可能性がMongoDBにはあると考えてい
ます。
12年8月24日金曜日
- 79. まとめ
n 今後のアップデートなども様々な物が控えてお
り、現在の問題点も徐々に改善されると考えてお
ります。
12年8月24日金曜日
- 80. まとめ
n ただ、NoSQLは適材適所、という言葉もあり、
徐々に使って慣れていくのが大事だと思います。
スモールスタートでまずは使ってみてはどうで
しょうか。
12年8月24日金曜日