Successfully reported this slideshow.
Your SlideShare is downloading. ×

AmebaのMongoDB活用事例

More Related Content

Viewers also liked

Related Audiobooks

Free with a 30 day trial from Scribd

See all

AmebaのMongoDB活用事例

  1. 1. AmebaのMongoDB 活用事例 株式会社サイバーエージェント アメーバ事業本部ピグディヴィジョン                 桑野 章弘 12年8月24日金曜日
  2. 2. アジェンダ n Amebaのサービス n サービス環境の変遷 n サービスを支えるMongoDB n 困ったことなど n 運用について n まとめ 12年8月24日金曜日
  3. 3. 自己紹介 n 桑野章弘 l サイバーエージェント l Ameba を運営しています。 l ピグソーシャルゲームの運用/構築を担当 l Twitter l @kuwa_tw l Blog l http://d.hatena.ne.jp/akuwano/ 12年8月24日金曜日
  4. 4. ピグライフ 12年8月24日金曜日
  5. 5. ピグライフ n サービス情報 l 2011/05/31オープン l 会員数360万人(2012/01現在) l サービス開始3週間で100万人突破 l 接続数:20万同時接続 12年8月24日金曜日
  6. 6. ピグアイランド 12年8月24日金曜日
  7. 7. ピグアイランド n サービス情報 l 2012/05/22オープン l サービス開始5日で100万人突破 l 接続数:約10万同時接続 12年8月24日金曜日
  8. 8. ピグカフェ 12年8月24日金曜日
  9. 9. ピグカフェ n サービス情報 l 2012/08/21オープン 12年8月24日金曜日
  10. 10. 様々なサービスをピグ プラットフォームで 展開中 12年8月24日金曜日
  11. 11. これらのサービスは全 てMongoDBを使っ ています 12年8月24日金曜日
  12. 12. サービス環境の変遷 12年8月24日金曜日
  13. 13. n まずは弊社サービスの成長の変遷について説明し ます 12年8月24日金曜日
  14. 14. アーキテクチャ n アプリケーションサーバ l Node.js l Nginx n データストアサーバ l MongoDB 12年8月24日金曜日
  15. 15. アーキテクチャ BackEnd FrontEnd ユーザ/エリア等の状態 データ staticサーバ Node.jsサーバ Socketサーバ mongodbサーバ Flashデータ 必要なデータの取得 →リクエスト/取得 HTTP WebSocket接続 ・ユーザ情報 ・チャットデータ →リクエスト/取得 ユーザ (ブラウザ:Flash) 12年8月24日金曜日
  16. 16. [ピグライフ]の変遷 12年8月24日金曜日
  17. 17. ピグライフ n リリースから現在 l βテスト時代 l リリース後 l 現在 12年8月24日金曜日
  18. 18. ピグライフ n リリースから現在 l βテスト時代 l リリース後 l 現在 どんなフェーズを経たか 12年8月24日金曜日
  19. 19. ピグライフ:βテスト時代 n 4/26∼5/31 l テストユーザ数5000∼30000 l 毎日リリース、機能追加、インフラ構成変更 l サーバも最小限を用意 12年8月24日金曜日
  20. 20. ピグライフ:βテスト時代 βテスト時に実 装 6 mongos 行動ログの保存 Staticサーバ Node.jsサーバ MongoDB Log MongoDB 12年8月24日金曜日
  21. 21. ピグライフ:リリース後 n 問題点洗い出しのフェーズ l Node.jsのサーバや、mongodbも、パフォーマン スが出ていなかったため増設 l Swfファイルをnode.jsのサーバから静的ファイル専 用のサーバへと切り出す 12年8月24日金曜日
  22. 22. ピグライフ:リリース後 n 5/31 ∼ l ピグライフ、正式リリース l 人気が爆発、予想以上の伸び l 開始3週間(6/22)で100万人突破 l とにかく増設の時期 12年8月24日金曜日
  23. 23. リリース時構成 大量追加 3 44 mongos 行動ログの保存 サーバにも取得 Staticサーバ Node.jsサーバ MongoDB Log 1シャード追加 (合計4シャー ド) MongoDB 12年8月24日金曜日
  24. 24. ピグライフ:リリース後 n パフォーマンス確保のフェーズ l ボトルネック調査 l 状況を見つつサーバ台数、リソースの確保 12年8月24日金曜日
  25. 25. ピグライフ:現在 n 9/1 ∼ l 順調な成長 l 開始3ヶ月弱(8/22)で200万人突破 12年8月24日金曜日
  26. 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. 27. ピグライフ:現在 n 運用改善のフェーズ l メンテ時間短縮のため稼働グループを分割 l A系、B系での切替 l 構成はシンプルにしていく l CDNなどの導入検討 (CDNを入れられるように仕様変更) 12年8月24日金曜日
  28. 28. ピグライフ:成長速度 n 成長速度 l リリースから3ヶ月程度で、サーバ規模としては8倍 に。それにともなって、トラフィック(1.3Gbps)、 総コネクション数(18万)も増加。 l その期間は3ヶ月余り。3週間の伸びは単位にすれば 30倍 サービスの予想以上の成長 12年8月24日金曜日
  29. 29. サービスを支える MongoDB 12年8月24日金曜日
  30. 30. この成長速度を支えた MongoDBの基本的 な機能 12年8月24日金曜日
  31. 31. MongoDBの構成 アプリケーションサー バ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 12年8月24日金曜日
  32. 32. アーキテクチャについて n システムアーキテクチャ l スキーマレス l 冗長化 l ReplicaSets l スケーラビリティ l Sharding 12年8月24日金曜日
  33. 33. アーキテクチャの課題 n スキーマレスなデータ構造による柔軟なデータ管 理 l ユーザ情報なども柔軟に持つことができるので、機能 追加時等が比較的楽 l 次ページ例 12年8月24日金曜日
  34. 34. アーキテクチャの課題 n スキーマレスなデータ構造 l ユーザーコレクションに趣味を追加したい場合 { "_id" : "1234567889", "userid" : "akuwano", "username" : "Akihiro Kuwano" } { "_id" : "1234567889", "userid" : "akuwano", "hobby" : Movie , "username" : "Akihiro Kuwano" } 12年8月24日金曜日
  35. 35. アーキテクチャの課題 n ReplicaSets l 相互死活監視&投票により冗長性を保つ。最小単位は 3台。 プライマリ セカンダリ セカンダリ 12年8月24日金曜日
  36. 36. アーキテクチャの課題 n ReplicaSets l 相互死活監視&投票により冗長性を保つ。最小単位は 3台。 生きているサー プライマリ バで投票が行わ れ新しいプライ マリが選ばれる セカンダリ セカンダリ → プライマリ 12年8月24日金曜日
  37. 37. アーキテクチャの課題 n Sharding l データをChunkの細かい粒度に分割する。 各mongodに分散して渡すことで各サーバの負荷を 分散します 12年8月24日金曜日
  38. 38. MongoDBの構成 Sharding アプリケーションサー ReplicaSetsに データをChunk バ よりサーバの冗長 の単位に分ける 性を確保 DATA mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 12年8月24日金曜日
  39. 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. 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. 41. アーキテクチャの課題 n MongoDBのこれらの基本機能により、アプリ 側の実装コストは軽くなります。 n 前述した、9台→100台への変更においても、ア プリ側のDB接続部分の変更点は殆どありませ ん。 n スケーラビリティを保ったまま、シンプルなサー ビス構築を行うことができています。 12年8月24日金曜日
  42. 42. 使いどころ 12年8月24日金曜日
  43. 43. まとめ n データ量が大き過ぎない n 書き込みが多過ぎない n 単位時間あたりの処理データが各シャードのメモ リ量を超えない処理は得意 l 現在のピグ系のリアルタイム処理には合っている n ホットデータが無い様なデータの使い方は苦手 12年8月24日金曜日
  44. 44. 困ったことについて 12年8月24日金曜日
  45. 45. 運用中に困ったことに ついて 12年8月24日金曜日
  46. 46. n クラスターのスローダウン l 必要なデータを一気にデータをインポートした場合 l oplogデータ量範囲を超えてレプリケーションが停止 l 一度に入れたため、PrimaryShardにChunkが溜 まってしまいI/Oバウンドに l 負荷が高いのでBalancerは動かないためクラスタの スローダウン →Oplogの容量を増やすことができるのでそれらで対 応 12年8月24日金曜日
  47. 47. n シャード設定のスローダウン l ほんとに突然パフォーマンスダウンする 「10分前は動いてたけど、、、」 l PrimaryShardはリソースを潤沢な状態にする l 各シャードのmmapの容量が実メモリを超えてきた ら注意する →シャード設定は定期的に確認&シャードの設定を自 動化 12年8月24日金曜日
  48. 48. n データ肥大 l 運用していくに連れてデータの肥大化が起きます l 定期的なデータのコンパクションが必要です l repairコマンドは、データ容量と同容量のスペース を利用するので注意 l データ容量が小容量かつ、一時的にMongoDBのク ラスタを止められるなら、データdrop→データ resoreの方が簡単です。 12年8月24日金曜日
  49. 49. n ドライバ関連 l Node.jsのドライバのバージョンによってデータの持 ち方などが異なる場合があった(現在は解消)ので、 バージョンアップは慎重に行ないましょう 12年8月24日金曜日
  50. 50. 日々の運用 12年8月24日金曜日
  51. 51. ここからは実際の運用 でやっていること 12年8月24日金曜日
  52. 52. n MongoDBに使用するハードウェア l CPU l (現在は)CPUはあまり負荷が来ないためそれほど良い物で なくて良い l そのかわりノードを増やすことになるのであればラックの効 率を上げるため消費電力の少ないものを選択する 12年8月24日金曜日
  53. 53. n MongoDBに使用するハードウェア l メモリ l 積めば積むほどキャッシュが効くのでできるだけ積む l 現在は1ノード32GBのサーバを用意 12年8月24日金曜日
  54. 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. 55. n MongoDBに使用するハードウェア l DISK l ioDriveでの検証に関しては、現状では8000opsを超えた 位でReplicaSetsのoplogの転送が止まる事を確認してい ます。 l 速度は3倍以上出ていたので、単体で使用するようなデータに は使えるかもしれません。(試してないです) l 2.2以降では改善されている可能性があるので再検証予定 12年8月24日金曜日
  56. 56. n バックアップ l mongodump l ReplicaSetsのDelay 12年8月24日金曜日
  57. 57. n バックアップ l mongodump l mongosに対してmongodump実行するのはバックアッ プとしては一番簡単です。 l 稼働中にかけると完全なポイントイン・タイムのバックアッ プにはなりません 12年8月24日金曜日
  58. 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. 59. バックアップの構成 1、Chunkが アプリケーションサー 2,fsync lock バックアップ中に バ をかけることで更 移動させない 新を止める mongos Mongod[ShardA] 3,各シャードか らデータを取得 Mongod[ShardB] mongoc Mongod[ShardC] 12年8月24日金曜日
  60. 60. n バックアップ l ReplicasetsのDelay l バックアップと言うよりはオペミスの防止 l 常に最新の状態よりも一定期間古い状態となる、 Replicasetsを追加します 12年8月24日金曜日
  61. 61. RS Delayの構成 アプリケーションサー この Replica バ Sets のみ、他の RSよりも3時間 前のデータを持つ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 12年8月24日金曜日
  62. 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. 63. n ロック l 同じサーバ上に異常に書き込みの多いコレクションが あるとクラスタ全体のアクセスに影響するため、コレ クションを分ける l アプリ実装はコレクション間を疎結合で作る l 2.2系でDBレベルロックが実装されるとDBを分けれ ばよいのでこの様な手順は要らない 12年8月24日金曜日
  64. 64. n ロック Collection A Collection B Collection C 12年8月24日金曜日
  65. 65. n ロック Collection A Collection C Collection B 12年8月24日金曜日
  66. 66. n ロック Collection A Collection C Collection B 12年8月24日金曜日
  67. 67. n 運用効率化 l どうしても台数が多くなる傾向にあります。 l そのため「標準のコマンドだと表示が多すぎて見づら い」「今のマスターの一覧が簡単に出したい」等の不 満がでます。 l これらはスクリプト作成等で対応しています、このあ たりもJSONで各種データを取ってこれるために管理 ツールなどは作りやすいです。 12年8月24日金曜日
  68. 68. n 運用効率化 :運用スクリプトの内容 l ロックタイムの取得 l シャードに入っているmongod一覧のリスト出力 l レプリカセットのマスター検索 l レプリカセットのpriority検索 l printShardingStatusの整形 l レプリカセット一括作成/設定変更(現在のRSに Delayホスト追加するなど) 12年8月24日金曜日
  69. 69. n 各種コマンド、ステータスなど l トレンドが見たい l 現状が把握したい 12年8月24日金曜日
  70. 70. n 各種コマンド、ステータスなど l mongostat l mongotop l mongosniff 12年8月24日金曜日
  71. 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. 72. n mongostat - 見るべき項目 l faults - 1秒当りのページフォールト数 l Locked % - グローバルライトロックの時間割合 l idx miss % - indexのヒット率の時間割合 l qr¦qw - 読み込みキュー¦書き込みキュー の大きさ 12年8月24日金曜日
  73. 73. n mongostat - 見るべき項目 l faults が多い場合 キャッシュメモリ溢れの可能性があるので、メモリ、 もしくはサーバを増設 l Locked % が高い場合 書き込みのクエリを見直す or クラスタ分割。 l qr¦qw が高い場合 サーバ負荷が低ければ、ロックの可能性を疑う。負荷 が高ければ単純なクエリ増による高負荷を疑う。 12年8月24日金曜日
  74. 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. 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. 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. 77. まとめ 12年8月24日金曜日
  78. 78. まとめ n まだ各所に未熟な点はありますが、運用を安定さ せる事で、綺麗な構成でスケーラビリティを確保 したサービスを構築することができるプロダクト になる可能性がMongoDBにはあると考えてい ます。 12年8月24日金曜日
  79. 79. まとめ n 今後のアップデートなども様々な物が控えてお り、現在の問題点も徐々に改善されると考えてお ります。 12年8月24日金曜日
  80. 80. まとめ n ただ、NoSQLは適材適所、という言葉もあり、 徐々に使って慣れていくのが大事だと思います。 スモールスタートでまずは使ってみてはどうで しょうか。 12年8月24日金曜日
  81. 81. ご清聴ありがとう ございました 12年8月24日金曜日

×