Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AmebaのMongoDB活用事例

9,645 views

Published on

  • Be the first to comment

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 MongoDB12年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 MongoDB12年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シャー ド) MongoDB12年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 mongosStaticサーバ_A系 Staticサーバ_B系 Node.jsサーバ_A系 行動ログの保存 DB統合 23シャード追 加(合計27 ・・・・・ シャード=81 台) MongoDB12年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. サービスを支える MongoDB12年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 Sharding12年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 -> ShardC12年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 -> ShardC12年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のDelay12年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をOn12年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 C12年8月24日金曜日
  65. 65. n ロック Collection A Collection C Collection B12年8月24日金曜日
  66. 66. n ロック Collection A Collection C Collection B12年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 mongosniff12年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:5712年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 8ms12年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 - 1408684012年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日金曜日

×