HBase at LINE

1. HBase at LINE~ How to grow our storage together with service ~ 中村俊介, Shunsuke Nakamura (LINE, twitter, facebook: sunsuk7tp) NHN Japan Corp.

2. 自己紹介中村俊介• 2011.10 旧 Japan新卒入社 (2012.1から Japan) • LINE server engineer, storage team• Master of Science@東工大首藤研 • Distributed Processing, Cloud Storage, and NoSQL • MyCassandra [CASSANDRA-2995]: A modular NoSQL with Pluggable Storage Engine based on Cassandra• はてなインターン/インフラアルバイト

3. NHN/NAVER• NAVER Korea: 検索ポータルサイト • NHN = Next Human Network • NAVER • 韓国本社の検索シェア7割 • Hangame • 元Samsungの社内ベンチャー • livedoor • NAVER = Navigate + er • データホテル• NAVER Japan • NHN ST • Japanは今年で３年目 • JLISTING 韓国本社 • メディエータ Green Factory • 経営統合によりNAVERはサービス名、グループ、宗教 • 深紅 • LINE、まとめ、画像検索、NDrive

4. LINE is NHN Japan STAND-ALONE

5. 8.17 5,500万users (日本 2,500万users) AppStore Ranking - Top 1Japan,Taiwan,Thailand,, HongKong, Saudi, Malaysia, Bahrain, Jordan, Qatar, Singapore, Indonesia, Kazakhstan, Kuwait, Israel, Macau, Ukraine, UAE, Switzerland, Australia,Turkey,Vietnam, Germany, Russian

6. LINE Roadmap 2011.6 iPhone first releaseAndroid first release 2011.8 WAP I join to LINE team. 2011.10 Sticker VOIP Bots (News, Auto-translation, Public account, Gurin)PC (Win/Mac), Multi device Sticker Shop LINE Card/Camera/BrushWP first release 2012.6 TimelineBB first release 2012.8 LINE platform

7. Target of LINE Storagestart 1. Performing well (put < 1ms, get < 5ms) 2. A high scalable, available, and eventually consistent storage system built around NoSQL 3. Geological distributionfuture Global Japan 56.8% 43.2%

8. LINE Storage and NoSQL1. Performing well2. A high scalable, available, and eventually consistent storage system3. Geological distribution

9. At ﬁrst,LINE launched with Redis.

10. Initial LINE Storage• Target: 1M DL within 2011• Client-side sharding with a few Redis nodes• Redis • Performance: O(1) lookup • Availability: Async snapshot + slave nodes (+ backup MySQL) • Capacity: memory + Virtual Memory node queue app dispatcher server queue ... ...master storage backup slave

11. August28~29 2011KuwaitSaudi ArabiaQatarBahrain…

12. 1Million over 2011 • Sharded Redis • Shard coordination: ZKs + Manager Daemons (shard allocation using consistent hashing, health check&failover) x 3 or 5 x3

13. October 132011Hong Kong

14. However, in fact... 100M DL within 2012Billions of Messages/Day...

15. We had encountered so much problems every day in 2011.10... Redis is NOT easily scalable NOT persistent And, easily dies

16. 2. A high scalable, available, and eventually consistent storage system built around NoSQL2011年内1Mユーザーを想定したストレージを、サービス無停止で2012年内1Bユーザーに対応する

17. Zuckerberg’s Law of Sharing (2011. July.7)Y = C * 2 ^ X (Y: sharing data, X: time, C: constance) Sharing activity will double each year.

18. LINEのmessage数/月はいくら？

19. 10億x30 = 300億 messages/month

20. Data and Scalability• constant • DATA: async operation • SCALE: thousands ~ millions per each queue• linear • DATA: users’ contact and group 10000000000 • SCALE: millions ~ billions 7500000000• exponential 5000000000 • DATA: message and message inbox 2500000000 • SCALE: tens of billion ~ 0 constant linear exponential

21. Data and Workload Queue• constant • FIFO • read&write fast Zipﬁan curve• linear • zipf. • read fast [w3~5 : r95] Message timeline• exponential • latest • write fast [w50 : r50]

22. Choosing Storage• constant: Redis• linear, exponential: 選択肢幾つか • HBase • ⃝ workload, NoSQL on DFSで運用しやすい (DFSスペシャリスト++) • × SPOF, Random Readの99%ile性能がやや低い • Cassandra • ⃝ workload, No SPOF (No Coordinator, rack/DC-aware replication) • × Weak consistencyに伴う運用コスト, 実装が複雑 (特にCAS操作) • MongoDB • ⃝ 便利機能 (auto-sharding/failover, various query) → 解析向けで不要 • × workload, 帯域やディスクの使い方悪い • MySQL Cluster • ⃝ 使い慣れ (1サービス当たり最大数千台弱運用) • × 最初から分散設計でwrite scalableものを使うべき

23. HBase• 数百TBを格納可能• 大量データに対してwrite scalable, 効率的なrandom access• Semi-structured model (< MongoDB, Redis)• RDBMSの高級機能はもたない (TX, joins)• Strong consistency per a row and columnfamily• NoSQL constructed on DFS • レプリカ管理不要 / Region移動が楽• Multi-partition allocation per RS • ad hocなload balancing

24. LINE Storage (2012.3) iPhone Android WAP x 25 Million Thrift API / Authentication / Renderer app. server (nginx) app. server (nginx) app. server (nginx) Redis Queue Redis Queue Redis Queue x 100 nodesasync operationfailed operation dispatcher dispatcher dispatcher Sharded Redis clusters (message, contact, group) x 400 nodes Contact HBase Message HBase Backup MySQL HDFS x 100 nodes x2 nodes backup operation

25. LINE Storage (2012.7) phone (iPhone/Android/WP/blackberry/WAP) PC (win/mac) x 50 Million Thrift API / Authentication / Renderer app. server (nginx) app. server (nginx) app. server (nginx) Redis Queue Redis Queue Redis Queue x 200 nodesasync operationfailed operation dispatcher dispatcher dispatcher Sharded Redis clusters (message, contact, group) x 600 nodes Msg HBase01 Primary HBase Msg HBase02 Backup MySQL HDFS01 HDFS02 x2 nodes backup operation x 200 nodes

26. 2012.3 → 2012.7• ユーザー数2倍、インフラ2倍 • まだHBaseにとってCasual Data• Message HBaseはdual cluster • message TTLに応じて切り替え (TTL: 2week → 3week) • HDFS DNはHBase用のM/Rとしても利用• Sharded-Redisがまだ基本プライマリ (400→600) • messageはHBaseにもget • 他はmodelのみをbackup

27. LINE Data on HBase• LINE data userId User Model • MODEL: <key> → <model> email phone • INDEX: <key> <property in model> INDEX • User: <userId> → <User obj>, <userId> <phone>• 各modelを1つのrowで表現 • HBaseのconsistency: 1つのrow, columnFamily単位でstrong consistencyを保証 • contactなどの複数modelをもつものはqualiﬁer (column)を利用 • レンジクエリが必要なDataは一つのrowにまとめる (e.g. message Inbox) • Cons.) column数に対してリニアにlatency大 → delete, search ﬁlter with timestamp

28. timestamp, version• Column level timestamp • modelのtimestampでindexを構築 • API実行timestampでasync, failure handling • Search ﬁlterとしても利用 (Cons. TTLの利用不可)• Multiple versioning • 複数emailのbinding (e.g. Google account password history) • CSの為のdata trace

29. Primary key for LINE • Long Type keyを元に生成: e.g. userId, messageId • simple ^ random for single lookup • range queryのためのlocalityの考慮不要 • prefix(key) + key • prefix(key): ALPHABETS[key%26] + key%1000 • o.a.h.hbase.util.RegionSplitter.SplitAlgorithmを実装 • prefixでRegion splittinga HRegion 2600 2626 2756 2782 b 2601 c 2602 d z 2652 2808a000 a250 a500 a750 b000

30. Data stored in HBase • User, Contact, Group • linear scale • mutable• Message, Inbox • exponential scale • immutable

31. Message, Inbox performance, availability重視• Sharded-Redisとのhybrid構成• 片方から読み書きできればOK (< quorum)• failed queryはJVM Heap,Redisにqueuing&retry • immutable&idempotent query: 整合性, 重複の問題なし

32. User, Contact performanceよりconsistency重視• Sharded-Redisがまだprimary • scalabilityの問題はない • mutableなので整合性重要• RedisからHBaseへ移行 (途中) • Model Objectのみbackup

33. RedisからHBaseへ移行1. modelのbackup • Redisにsync、HBaseにasync write (Java Future, Redis queuing)2. M/Rを使ってSharded-Redisからfull migration3. modelを元にindex/inverted index building (eventual) ←イマココ • Batch Operation: w/ M/R, model table full-scan using TableMapper • Incremental Operation: Diff logging and sequential indexing or Percolator, HBase Coprocessor4. access path切り替え, Redis cache化

34. HBaseに置き換えたら幸せになれた？

35. ある意味ではYES• Scalability Issuesが解決 • 今年いっぱいまでは • 広域分散 → 3rd issue (To be continue...)

36. Failure Decreased?

37. ABSOLUTELY NOT!

38. HBaseを8ヶ月運用してみた印象• HBaseは火山 • 毎日小爆発 • 蓄積してたまに大爆発 • 火山のふもとでの安全な暮らし

39. 爆発• 断続的なネットワーク障害によるRS退役• H/W障害によるDN性能悪化・検知の遅延• get (get, increment, checkAndPut, checkAndDelete)性能劣化、それに伴う全体性能低下• (major) compactionによる性能劣化• データ不整合• SPOF絡みの問題はまだ起こってない

40. HBaseのAvailability• SPOF or 死ぬとdowntimeが発生する箇所が幾つか 1. HDFSのNameNode 2. HBaseのRegionServer, DataNode

41. 1. HDFS NameNode (NN)• HA Framework for HDFS NN (HDFS-1623) • Backup NN (0.21) • Avatar NN (Facebook) • HA NN using Linux HA • Active/passive conﬁguration deploying two NN (cloudera)

42. HA NN using Linux-HA• DRBD+heartbeatで冗長化 • DRBD: disk mirroring (RAID1-like) • heartbeat: network monitoring • pacemaker: resource management (failover logicの登録)

43. 2. RegionServer, DataNode• HBase自体がレプリカをもたない• failoverされるまでdowntime発生• 複数コンポーネントで構成されているので、故障検知から全体合意まで、それぞれの通信区間でtimeoutを待たなければいけない

44. downtime対策• HBase自身がreplicaを持たないのでRS死亡時のdowntimeが必ず発生 • distributed HLog splitting (>=cdh3u3) • timeout&retry • ほとんどHClient RS間のtimeout時間 • timeout調整 (retryごと, operationごと) • RS ZK間は短いとnetworkが不安定なときにRSが排除されやすい• 同じkeyを持つregionを同じRSに配置 → 障害の限定化• LINEのHBase accessは基本的にasync• Cluster replication

45. HBase cluster replication• Cluster Replication: master push方式 • (MySQLのようなbinary logging mechanism), 馬本8.8章参照 • 非同期でWAL (HLog)をslave clusterにpush • 各RSごとにSynchronous Call • syncされていないWAL ListをZKが管理• 検証しつつも、• 独自実装 or 他の手段も考慮中multi-DC間のreplication向けではない

46. HDFS tuning for HBase• Shortcut a local client reads to a Datanodes ﬁles directly > 0.23.1, 0.22.1, 1.0.0 (HDFS-2246)• Rack-aware Replica Placement (HADOOP-692)

47. 削除問題• 削除が少し低速 • 論理削除なのでgetほどではないが、putの2倍かかる • 例) 1万件のコンタクトをもつユーザー退会処理 • カラム多すぎでクライアント側でtimeout → queuing + iterative delete • 例) TTLが過ぎたmessage削除 • cold dataに対するRandom I/Oが発生し、serviceに影響 • → dual cluster, full-truncate or TTL利用 • 例) スパマー対応 • compactionされるまでのget性能 (大量のskip処理)への影響 • → column単位ではなく、row単位の削除に

48. Compaction対策• Bigtable: I/O最適化と削除の為に定期的なCompaction処理が必要• RSごとにQueuingされ同時に1 HRegionずつCompactionが実行される• Compaction実行中にCPU利用率が上がるので、タイミング注意 • タイミング: periodic, StoreFile数, ユーザー実行 • peak-time時に連続して発生しないよう、 off-peakにcompactionとregion splitting

49. Balancing, Splitting, and Compaction• Region balancing • 自動balancer (request数ベースのbalancing)はOFF • serviceのoﬀ-peak時にbalancing • 異なるtableの同一keyは同じserverに割当→障害を限定 • 問題のあるRegion専用のserver: prison RS• Region splittingとcompactionのスケジューリング • 自動splitもなるべく避ける (hbase.hregion.max.ﬁlesizeで自動split) • 連続的なmajor compactionを避ける • immutable storageはperiodic compactionをOFF

50. HBase Tools• Client: • HBaseTemplate: HBase Wrapper like spring’s RedisTemplate • MirroringHTable: 複数HBase cluster対応• 運用監視: • auto splitting: off-peak時のregion split • auto HRegion balancer: metricsを元にoff-peak balancing • Region snapshot&restore: META Tableをdaily dump、RS死亡時の復元 • Data Migration: • Migrator with M/R (Redis → HBase) • H2H copy tool with M/R: table copy (HBase → HBase) • metrics collecting via JMX• Index Builder and Inconsistent Fixer with M/R, incremental implementation (coprocessor)

51. 今後の課題• HBase上の<key, model>を中心にindexやRedis上にcacheを構築• 停電・地震対策 (rack/dc-awareness) • HBase cluster replication • Cassandraをgeological distributed storage for HLogとして利用• 今以上のスケーラビリティ (数 - 数十億ユーザー) • HBaseはnetwork-boundで1クラスタ数百台弱が限界 • Multi-clusterで凌ぐかCassandraを使うか