Your SlideShare is downloading. ×
  • Like
AmebaのMongoDB活用事例
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

AmebaのMongoDB活用事例

  • 7,295 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,295
On SlideShare
0
From Embeds
0
Number of Embeds
7

Actions

Shares
Downloads
89
Comments
0
Likes
34

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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日金曜日
  • 4. ピグライフ12年8月24日金曜日
  • 5. ピグライフ n サービス情報 l 2011/05/31オープン l 会員数360万人(2012/01現在) l サービス開始3週間で100万人突破 l 接続数:20万同時接続12年8月24日金曜日
  • 6. ピグアイランド12年8月24日金曜日
  • 7. ピグアイランド n サービス情報 l 2012/05/22オープン l サービス開始5日で100万人突破 l 接続数:約10万同時接続12年8月24日金曜日
  • 8. ピグカフェ12年8月24日金曜日
  • 9. ピグカフェ n サービス情報 l 2012/08/21オープン12年8月24日金曜日
  • 10. 様々なサービスをピグ プラットフォームで 展開中12年8月24日金曜日
  • 11. これらのサービスは全 てMongoDBを使っ ています12年8月24日金曜日
  • 12. サービス環境の変遷12年8月24日金曜日
  • 13. n まずは弊社サービスの成長の変遷について説明し ます12年8月24日金曜日
  • 14. アーキテクチャ n アプリケーションサーバ l Node.js l Nginx n データストアサーバ l MongoDB12年8月24日金曜日
  • 15. アーキテクチャ BackEnd FrontEnd ユーザ/エリア等の状態 データ staticサーバ Node.jsサーバ Socketサーバ mongodbサーバ Flashデータ 必要なデータの取得 →リクエスト/取得 HTTP WebSocket接続 ・ユーザ情報 ・チャットデータ →リクエスト/取得 ユーザ (ブラウザ:Flash)12年8月24日金曜日
  • 16. [ピグライフ]の変遷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 MongoDB12年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シャー ド) MongoDB12年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 mongosStaticサーバ_A系 Staticサーバ_B系 Node.jsサーバ_A系 行動ログの保存 DB統合 23シャード追 加(合計27 ・・・・・ シャード=81 台) MongoDB12年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日金曜日
  • 29. サービスを支える MongoDB12年8月24日金曜日
  • 30. この成長速度を支えた MongoDBの基本的 な機能12年8月24日金曜日
  • 31. MongoDBの構成アプリケーションサー バ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC]12年8月24日金曜日
  • 32. アーキテクチャについて n システムアーキテクチャ l スキーマレス l 冗長化 l ReplicaSets l スケーラビリティ l Sharding12年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 -> ShardC12年8月24日金曜日
  • 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. アーキテクチャの課題 n MongoDBのこれらの基本機能により、アプリ 側の実装コストは軽くなります。 n 前述した、9台→100台への変更においても、ア プリ側のDB接続部分の変更点は殆どありませ ん。 n スケーラビリティを保ったまま、シンプルなサー ビス構築を行うことができています。12年8月24日金曜日
  • 42. 使いどころ12年8月24日金曜日
  • 43. まとめ n データ量が大き過ぎない n 書き込みが多過ぎない n 単位時間あたりの処理データが各シャードのメモ リ量を超えない処理は得意 l 現在のピグ系のリアルタイム処理には合っている n ホットデータが無い様なデータの使い方は苦手12年8月24日金曜日
  • 44. 困ったことについて12年8月24日金曜日
  • 45. 運用中に困ったことに ついて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日金曜日
  • 50. 日々の運用12年8月24日金曜日
  • 51. ここからは実際の運用 でやっていること12年8月24日金曜日
  • 52. n MongoDBに使用するハードウェア l CPU l (現在は)CPUはあまり負荷が来ないためそれほど良い物で なくて良い l そのかわりノードを増やすことになるのであればラックの効 率を上げるため消費電力の少ないものを選択する12年8月24日金曜日
  • 53. n MongoDBに使用するハードウェア l メモリ l 積めば積むほどキャッシュが効くのでできるだけ積む l 現在は1ノード32GBのサーバを用意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のDelay12年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をOn12年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 C12年8月24日金曜日
  • 65. n ロック Collection A Collection C Collection B12年8月24日金曜日
  • 66. n ロック Collection A Collection C Collection B12年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日金曜日
  • 69. n 各種コマンド、ステータスなど l トレンドが見たい l 現状が把握したい12年8月24日金曜日
  • 70. n 各種コマンド、ステータスなど l mongostat l mongotop l mongosniff12年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:5712年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 8ms12年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 - 1408684012年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日金曜日
  • 77. まとめ12年8月24日金曜日
  • 78. まとめ n まだ各所に未熟な点はありますが、運用を安定さ せる事で、綺麗な構成でスケーラビリティを確保 したサービスを構築することができるプロダクト になる可能性がMongoDBにはあると考えてい ます。12年8月24日金曜日
  • 79. まとめ n 今後のアップデートなども様々な物が控えてお り、現在の問題点も徐々に改善されると考えてお ります。12年8月24日金曜日
  • 80. まとめ n ただ、NoSQLは適材適所、という言葉もあり、 徐々に使って慣れていくのが大事だと思います。 スモールスタートでまずは使ってみてはどうで しょうか。12年8月24日金曜日
  • 81. ご清聴ありがとう ございました12年8月24日金曜日