大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)

36,547
-1

Published on

Published in: Technology
0 Comments
42 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
36,547
On Slideshare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
0
Comments
0
Likes
42
Embeds 0
No embeds

No notes for slide

大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)

  1. 1. 大規模化するピグライフを支えるインフラ 〜MongoDBと Chefについて〜(前編) 株式会社サイバーエージェント アメーバ事業本部プラットフォームディビジョン サービスディベロップメントグループ CA Developers Connect 桑野 章弘
  2. 2. 自己紹介桑野章弘 サイバーエージェント Ameba を運営しています。 - Blogを中心として様々なサービスがあります。 ピグライフの運用/構築を担当 Twitter @kuwa_tw Blog http://d.hatena.ne.jp/akuwano/ 著書/活動 「MySQLによるタフなサイトの作り方」 勉強会(hbstudy, qpstudyほか)などでの発表など 2
  3. 3. Ameba 3
  4. 4. アジェンダピグライフなぜMongoDBを採用したか? サービスアーキテクチャの課題 システムアーキテクチャの課題運用上での課題 キャパプラ 運用まとめ 4
  5. 5. ピグライフ 5
  6. 6. ピグライフピグのキャラクターを利用したガーデニングゲームこんなことができます ガーデニング 裁縫 料理 ティーパーティー 羊を飼ったり 6
  7. 7. ピグライフ 7
  8. 8. ピグライフサービス情報 2011/05/31オープン 会員数360万人(2012/01現在) サービス開始3週間で100万人突破 接続数:20万接続 8
  9. 9. アーキテクチャ:ピグとの比較アメーバピグのシステムを踏襲していますが使用しているアーキテクチャが異なります システム概要 Adobe Flashを使用したリアルタイム処理 Flashから直接TCP通信を⾏う事によって実現 9
  10. 10. アーキテクチャ:ピグとの比較アメーバピグのシステムを踏襲していますが使用しているアーキテクチャが異なります アメーバピグ ピグライフアプリケーションサー フルスクラッチ Node.jsバ Javaサーバ サーバデータベースサーバ MySQL MongoDB 10
  11. 11. ピグライフのアーキテクチャ:全体構成 BackEnd FrontEnd ユーザ/エリ ア等の状態 staticサーバ Node.jsサーバ Socketサーバ データ mongodbサーバ Flashデータ 必要なデータ →リクエスト の取得 /取得HTTP WebSocket接続 ・ユーザ情報 ・チャット データ →リクエスト /取得 ユーザ(ブラウザ) 11
  12. 12. なぜMongoDBを採用 したか? 12
  13. 13. アーキテクチャの課題サービスアーキテクチャの課題 開発スピードシステムアーキテクチャの課題 冗⻑化 ReplicaSets スケーラビリティ Sharding 13
  14. 14. アーキテクチャの課題サービスアーキテクチャの課題 開発スピードシステムアーキテクチャの課題 冗⻑化 ReplicaSets スケーラビリティ Sharding これらの課題を解決できる ソリューションだったため 14
  15. 15. MongoDBの構成アプリケーションサーバ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 15
  16. 16. アーキテクチャの課題開発スピードの構造 Node.jsとの相性の良さ データのやりとりがJSONで統一される スキーマレスなデータ構造による柔軟なデータ管理 機能追加時 ユーザ情報なども柔軟に持つことができる(次ページ例) 16
  17. 17. アーキテクチャの課題開発スピードの構造 ユーザーコレクションに最終ログインタイムを追加し たい場合{ "_id" : "1234567889", "userid" : "akuwano", "username" : "Akihiro Kuwano"} 17
  18. 18. アーキテクチャの課題開発スピードの構造 ユーザーコレクションに最終ログインタイムを追加し たい場合{ "_id" : "1234567889", "userid" : "akuwano", "lastLoginTime" : ISODate("2011-12-25T14:22:46.777Z"), "username" : "Akihiro Kuwano"} 18
  19. 19. アーキテクチャの課題スケーラビリティの問題 Sharding データをChunkの細かい粒度に分割し、各mongodに分散し て渡すことで各サーバの負荷を分散します 19
  20. 20. MongoDBの構成 Shardingアプリケーションサーバ データをChunk ReplicaSetsに の単位に分ける よりサーバの冗 ⻑性を確保 DATA mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 20
  21. 21. MongoDBの構成 Shardingアプリケーションサーバ データをChunk ReplicaSetsに の単位に分ける よりサーバの冗 ⻑性を確保 ChunkA ChunkB ChunkC mongos mongocは Mongod[ShardA] シャーディング 情報を持つ Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB Mongod[ShardC] ChunkC -> ShardC 21
  22. 22. MongoDBの構成アプリケーションサーバ ReplicaSetsに Sharding よりサーバの冗 データをChunk ⻑性を確保 の単位に分ける mongos mongocは ChunkA Mongod[ShardA] シャーディング 情報を持つ ChunkB Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB ChunkC Mongod[ShardC] ChunkC -> ShardC 22
  23. 23. アーキテクチャの課題冗⻑性の問題 ReplicaSets 相互死活監視&投票により冗⻑性を保つ。最⼩単位は3台。 プライマリ セカンダリ セカンダリ 23
  24. 24. アーキテクチャの課題冗⻑性の問題 ReplicaSets 相互死活監視&投票により冗⻑性を保つ。最⼩単位は3台。生きているサー プライマリバで投票が⾏われ新しいプライマリが選ばれる セカンダリ セカンダリ → プライマリ 24
  25. 25. アーキテクチャの課題MongoDBのこれら機能により、アプリ側の実装コストは軽く、スケーラビリティを保ったシステム構築を⾏うことが出来ました。 実際の運用ではそこまで 上⼿く⾏ったのでしょうか? 25
  26. 26. 実運用上での課題 26
  27. 27. 実運用での課題MongoDBの機能は自動でスケーラビリティや、冗⻑性の確保が⾏えます。現在の台数は140台となっており、おそらくこの規模の台数で使っているMongoDBのクラスタはあまり無いのでは無いでしょうか。その際に生まれたノウハウについて説明します。 27
  28. 28. 実運用での課題:サーバキャパプラサーバキャパプラ まずは各サーバプロセスのキャパプラについて説明し ていきます 28
  29. 29. 実運用での課題:サーバキャパプラサーバキャパプラ mongos スケーラビリティはありません アプリケーションサーバに同居する形にしている サーバへの負荷は少ないです 29
  30. 30. 実運用での課題:サーバキャパプラサーバキャパプラ mongoc スケーラビリティはない 通常時に負荷はかからないが、潤沢なリソースを使える状態 にしておくほうがよい(上記理由) 冗⻑性は同期書き込み( 2フェーズコミット)という形で確 保されています 30
  31. 31. 実運用での課題:サーバキャパプラサーバキャパプラ mongod DISK I/O:定期的に書きだすのである程度の性能が必要 - ioDriveで⾼速に処理することも可能だが、レプリケーションが 停止する可能性があるのでサーバ単体で使った方がioDriveの性 能を使い切ることができます CPU:書き込みはグローバルロックが存在しているために、 複数コアを効率良く使えません メモリ:Index、データをメモリにキャッシュするため多け れば多いほどよいです アクセスが多岐に渡る場合にはIndexがメモリから溢れてし まうので、パフォーマンスが落ちる。その場合ページフォル トが⼤量に発生し始めるのでそれが目安 31
  32. 32. 実運用での課題:運用面index 特定のカラムで検索を⾏う場合にはindexを貼る事で⾼速化を 図ります 2.0系でIndexが⾼速化 & コンパクト化されているので Indexを多用する場合はバージョンアップする 32
  33. 33. 実運用での課題:運用面Index Indexの確認->explain() IndexなしreplSetTest1001:PRIMARY> db.User.find({Field02: test}).explain(){{"_id" : "1234567889", "cursor" : "BasicCursor", "userid" : "akuwano", "nscanned" : 706456, "username" : "Akihiro Kuwano"} "nscannedObjects" : 706456, "n" : 1, "millis" : 749, "nYields" : 0, "nChunkSkips" : 0, "isMultiKey" : false, "indexOnly" : false, "indexBounds" : { }} 33
  34. 34. 実運用での課題:運用面Index Indexの確認->explain() IndexありreplSetTest1001:PRIMARY> db.User.find({Field01: test}).explain(){ "cursor" : "BtreeCursor testIndex_1",{ "nscanned" : 1, "_id" : "1234567889", : 1, "nscannedObjects" "userid" : "akuwano", "n" : 1, "username": :7, "millis" "Akihiro Kuwano"} "nYields" : 0, "nChunkSkips" : 0, "isMultiKey" : false, "indexOnly" : false, "indexBounds" : { "Field01" : [ [ "test", "test" ] ] }} 34
  35. 35. 実運用での課題:運用面バックアップ fsyncコマンドでレプリケーションを停止して、dumpを取得 する 1. Replication 2. Dump取得 をとめる DUMP 35
  36. 36. 実運用での課題:運用面グローバルロック 同じサーバ上に異常に書き込みの多いコレクションが あった場合には(結果的に)クラスタ全体のアクセス に影響します 現状は別クラスタに分ける事で影響を局所化 今後コレクションレベルロックが実装されるとこのよ うな⼿間はなくなる予定です 36
  37. 37. 実運用での課題:運用面グローバルロック Collection A Collection B Collection C 37
  38. 38. 実運用での課題:運用面グローバルロック Collection A Collection C Collection B 38
  39. 39. 実運用での課題:運用面Chunkの偏り AutoBalanceがOnの場合Chunkは「データ量」もし くは「オブジェクト数」によって分割されます -> Not「データアクセス頻度」 「データアクセス頻度」によるShard分割をしたい場 合にはManualBalanceにする必要がある ->⼿動Chunk移動を⾏った場合には現状全mongos の再起動が必要となるため厳しい 今後の課題 ただし、2.0系のAutoBalanceはかなり頭が良くなっている 39
  40. 40. 実運用での課題:運用面バグとの戦い(今まで踏んだバグ) mongodumpをmongos経由で実⾏すると落ちる 各シャードへのdump実⾏ mongos->mongocの接続断が起こった場合の再接 続でmongocが負荷が上がる 主にmongos経由の接続を同時に⼤量に⾏った場合 mongocのスペックアップ(mongoc > mongod) バージョンアップ mongod replicasetsのPRIMARYが切り替わった時 にmongosがdown バージョンアップ待ち 40
  41. 41. 実運用での課題:運用面サーバの台数増 定常的なサーバ追加が必要 Chef,Puppet等を使用し構築をプログラマブルにする ->この後Chefに関しては並河よりお話しします 41
  42. 42. まとめ 42
  43. 43. 実運用での課題:運用面MongoDBは、仕様など改善の余地はある物の、スケーラビリティを確保するための要素としての「Sharding」「ReplicaSets」と、同時に柔軟なデータ構造などサービス開発を加速するために必要な要素を兼ね揃えたプロダクトです。弊社の使用サービスも増え、ノウハウも蓄積できて来ているのでそれが固まり、バージョンが上がる頃には安定して成⻑できる運用の一要素として⼤事な役割を持つことになると考えています。 43
  44. 44. この後はといった所で弊社並河へChefに関して語ってもらいます さあどーぞ! 44

×