NHN techcon-20120519-fujimoto
- 1. データストレージEXPOで 話してきた、感想を交えつつ GREEのストレージのはなし Masaki Fujimoto <masaki.fujimoto@gree.net> GREE, Inc.
- 2. (祝) 第1回NHN テクノロジーカンファレンス
- 3. DSEの感想 • スーツのかた多かったです (すごく) • 避けようのないaway感
- 4. DSE感想 • キャパシティに関するかんがえかた • 小さく始めたい • 自分たちで作りたい/障害対応したい • 合わせて新鮮さ
- 5. ソーシャルプラットフォーマー としてのGREEのストレージ戦略 Masaki Fujimoto <masaki.fujimoto@gree.net> GREE, Inc.
- 6. GREEのストレージ • MySQL (HDD + SSD) • やはりMySQL安定 / 多くのツール / 多くの ノウハウと実績 • ほとんどのデータはやはりここ • 詳しくは前の前のセッション？
- 7. GREEのストレージ • MySQL (Appliance Storage) • for Analytics • 1PB∼ • FAQ: Hadoopは？
- 8. HDFS? •N PB on HDFS? • ¥100,000 x 1,000∼ (別に安くないような 気がする) • MySQLやっぱりべんり • HDFSがだめってことじゃないです
- 9. GREEのストレージ • Object Storage • Photoとか • 詳しくは前のセッション？
- 10. GREEのストレージ • KVS • In Memory or Disk • memcached, flare, etc • 最近はある種落ち着きぎみ？ • でもまだまだやれることはたくさん
- 11. GREEのストレージ • And More (including experimental ones) • Hadoop (AD, etc) • 3rd party storages / analytics • 細かいところは端折ります
- 12. OK, IT WORKS • Currently, it works (esp. for Social Apps) • さらなる読み込み / 書き込み (プラット フォーム的観点で) • さらなるリアルタイム性 (Analytics)
- 13. OK, IT WORKS • Currently, it works • つきることのない欲望 / 性能限界による意 識/無意識のキャップ • すべてのデータをNormalize/Summarizeせずにそのまま瞬時に 検索/集計できたら？ (まぁムリなんですが) • DAUをリアルタイムに計算したい、とか / チャットログとか
- 14. どこへ向かうか？ • とりあえず先人の知恵を活かす • タイムリーに丸山先生がFacebookの論文抄 訳を → https://docs.google.com/file/d/0B04ol8GVySUuN0psUVdSSW1rM1E/edit
- 15. FACEBOOK • DAU: 845,000,000 • Like: 2,700,000,000 • Photo Uploads: 250,000,000 • Links: 100,000,000,000
- 16. LIKE • 2,000,000,000ならなんとなく捌けそうな気 はする(Social Appの連打に耐えている僕ら なら) • ただ、Peakで200,000/secと聞くとちょっ としんどそう • ShardingしてもHot Spotが偏るという
- 17. LIKE • MySQL: WriteのThrough Putが上がったとき のロック競合/書き込み性能限界 • In Memory: 耐障害性についての問題がルー プする / memcachedのincrでも0.2M/kpsは厳 しいか
- 18. LIKE • Scribe + PTail + Puma + HBase (P*は Facebook Original) • 分散と非同期書き込み • 高いスループットと柔軟な解析 • トラフィックが集中する箇所はこのアプ ローチか
- 19. ANALYTICS • Hadoop/Hive based • latencyが厳しい(そうです) • daily basedなbatch処理のリスク Analytics based on Hadoop/Hive Hourly Daily 12hで終わらなかったら？ seconds seconds Pipeline Jobs • Copier/Loader HTTP Scribe NFS Hive MySQL Hadoop • 3000-node Hadoop cluster • Copier/Loader: Map-Reduce hides machine failures • Pipeline Jobs: Hive allows SQL-like syntax • Good scalability, but poor latency! 24 – 48 hours.
- 20. ANALYTICS • Scribe + PTail + Puma + HBase • リアルタイム処理: リスク回避の側面 • Will be Open Sourced? Puma3 Architecture PTail Puma3 HBase • Read workflow Serving ▪ Read uncommitted: directly serve from the in-memory hashmap; load from Hbase on miss. ▪ Read committed: read from HBase and serve.
- 21. ANALYTICS • Yet... Currently HBase resharding is done manually. • Automatic hot spot detection and resharding is on the roadmap for HBase, but it's not there yet. • Every Tuesday someone looks at the keys and decides what changes to make in the sharding plan. Tailer Hot Spots • In a distributed system there's a chance one part of the system can be hotter than another. • One example are region servers that can be hot because more keys are being directed that way. Top Lists • Very hard to find the top URLs, the URLs with the most likes, for domains like YouTube which have millions of URLs shared very quickly. • Need more creative solutions to keep an in-memory sorts and keep it up to date as data changes. • And arbitrary queries? / MySQL still wins?
- 22. OTHER PARTS • 冗長性/レイテンシ: HDFSの性質上Response Timeへのコミットメントは高くない (障害 復旧/通常のI/O) • Avatar Node, etc (詳細は論文へ、という) • ただし書き込みスループットに関しては トップクラス
- 23. STILL MYSQL WINS (IN MANY CASES) • 基本的なデータストアとしてはMySQLがま だまだ最重要 • MySQLへの技術投資は引き続き継続して いく必要があろうかと
- 24. KVS • まだまだ進化の余地あり (Atomicityは常に大 きな話題だが) • List/Push/Pop/Index/... • 最も全うに進んでいるのがMongoDB (私 見)
- 25. SUMMARY • MySQL: 依然としてProduction Storageの中心 / 更なる改善へ • KVS: 大いに改善の余地あり / Social Appsなど はMySQLなしでも運用は可能となっていく
- 26. SUMMARY • Super High Traffic Feature (Like Like) + Analytics • HBaseの書き込み性能を活用していく + PTail / Pumaに期待 (勝手) • (注: 無保証です)
- 27. THANK YOU & HAPPY HACKING! Masaki Fujimoto <masaki.fujimoto@gree.net>
- 28. WE ARE HIRING! :) Masaki Fujimoto <masaki.fujimoto@gree.net>