hbase at line
Post on 15-Jan-2015
1.553 Views
Preview:
DESCRIPTION
TRANSCRIPT
中村 俊介, Shunsuke Nakamura (LINE, twitter, facebook: sunsuk7tp)
NHN Japan Corp.
HBase at LINE~ How to grow our storage together with service ~
自己紹介中村 俊介
• 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
• はてなインターン/インフラアルバイト
• NHN = Next Human Network• NAVER Korea: 検索ポータルサイト
• 韓国本社の検索シェア7割
• 元Samsungの社内ベンチャー
• NAVER = Navigate + er
• NAVER Japan
• Japanは今年で3年目
• 経営統合によりNAVERはサービス名、グループ、宗教
• LINE、まとめ、画像検索、NDrive
NHN/NAVER
• NAVER• Hangame • livedoor• データホテル• NHN ST • JLISTING• メディエータ• 深紅
韓国本社Green Factory
LINE is NHN Japan STAND-ALONE
8.17 5,500万users (日本 2,500万users) AppStore Ranking - Top 1
Japan, Taiwan, Thailand,, HongKong, Saudi, Malaysia, Bahrain, Jordan, Qatar, Singapore, Indonesia, Kazakhstan, Kuwait, Israel, Macau, Ukraine, UAE,
Switzerland, Australia, Turkey, Vietnam, Germany, Russian
LINE Roadmap2011.6 iPhone first release
Android first release
LINE Card/Camera/Brush
VOIP
2011.8
2011.10I join to LINE team.
PC (Win/Mac), Multi device Sticker Shop
LINE platform
Bots (News, Auto-translation, Public account, Gurin)
Sticker
WAP
WP first release
BB first releaseTimeline
2012.6
2012.8
Target of LINE Storage
1. Performing well (put < 1ms, get < 5ms)
2. A high scalable, available, and eventually consistent storage system built around NoSQL
3. Geological distribution
43.2% 56.8%
Japan�Global�
start
future
LINE Storage and NoSQL1. Performing well
2. A high scalable, available, and eventually consistent storage system
3. Geological distribution
LINE launched with Redis.
At first,
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
app server queue
backup
node
storage
master
slave
......
queuedispatcher
August 28~29 2011 Kuwait Saudi Arabia Qatar Bahrain…
1Million over
• Sharded Redis
• Shard coordination: ZKs + Manager Daemons(shard allocation using consistent hashing, health check&failover)
2011
x 3
x 3 or 5
October 13 2011 Hong Kong
However, in fact...
���
100M DL within 2012
Billions of Messages/Day...
We had encountered so much problems every day in 2011.10...
Redis isNOT easily scalableNOT persistent
And,
easily dies
2. A high scalable, available, and eventually consistent storage system built around
NoSQL
2011年内1Mユーザーを想定したストレージを、サービス無停止で2012年内1Bユーザーに対応する
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.
LINEのmessage数/月はいくら?
10億x30 = 300億 messages/month
Data and Scalability• constant
• DATA: async operation
• SCALE: thousands ~ millions per each queue
• linear
• DATA: users’ contact and group
• SCALE: millions ~ billions
• exponential
• DATA: message and message inbox
• SCALE: tens of billion ~ 0
2500000000
5000000000
7500000000
10000000000
constant linear exponential
• constant
• FIFO
• read&write fast
• linear
• zipf.
• read fast [w3~5 : r95]
• exponential
• latest
• write fast [w50 : r50]
Data and WorkloadQueue
Zipfian curve
Message timeline
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ものを使うべき
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
LINE Storage (2012.3)
app. server (nginx)
HDFS
Message HBaseContact HBaseBackup MySQL
Thrift API / Authentication / Renderer
iPhone Android WAP
app. server (nginx)app. server (nginx)
async operationfailed operation
x 100 nodes
x 400 nodes
backup operationx 2 nodesx 100 nodes
x 25 Million
Sharded Redis clusters (message, contact, group)
Redis Queue
dispatcher dispatcher
Redis Queue
dispatcher
Redis Queue
app. server (nginx)
HDFS01
Primary HBaseBackup MySQL
Thrift API / Authentication / Renderer
phone (iPhone/Android/WP/blackberry/WAP) PC (win/mac)
app. server (nginx)app. server (nginx)
async operationfailed operation
x 200 nodes
x 600 nodes
backup operationx 2 nodes
x 200 nodes
x 50 Million
Msg HBase01
dispatcher
Redis Queue
HDFS02
Msg HBase02
Redis Queue
dispatcher dispatcher
Redis Queue
Sharded Redis clusters (message, contact, group)
LINE Storage (2012.7)
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
LINE Data on HBase• LINE data
• MODEL: <key> → <model>
• INDEX: <key> ↔ <property in model>
• User: <userId> → <User obj>, <userId> ↔ <phone>
• 各modelを1つのrowで表現
• HBaseのconsistency: 1つのrow, columnFamily単位でstrong consistencyを保証
• contactなどの複数modelをもつものはqualifier (column)を利用
• レンジクエリが必要なDataは一つのrowにまとめる (e.g. message Inbox)
• Cons.) column数に対してリニアにlatency大 → delete, search filter with timestamp
User ModeluserIdemail phone
INDEX
timestamp, version• Column level timestamp
• modelのtimestampでindexを構築
• API実行timestampでasync, failure handling
• Search filterとしても利用 (Cons. TTLの利用不可)
• Multiple versioning
• 複数emailのbinding (e.g. Google account password history)
• CSの為のdata trace
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 splitting
a b z
a500a250 a750a000 b000
HRegion260026262652
2756 c2601 2602 d27822808
• Message, Inbox
• exponential scale
• immutable
Data stored in HBase
• User, Contact, Group
• linear scale
• mutable
Message, Inbox
• Sharded-Redisとのhybrid構成
• 片方から読み書きできればOK (< quorum)
• failed queryはJVM Heap,Redisにqueuing&retry
• immutable&idempotent query: 整合性, 重複の問題なし
performance, availability重視
• Sharded-Redisがまだprimary
• scalabilityの問題はない
• mutableなので整合性重要
• RedisからHBaseへ移行 (途中)
• Model Objectのみbackup
User, Contactperformanceよりconsistency重視
RedisからHBaseへ移行1. modelのbackup
• Redisにsync、HBaseにasync write (Java Future, Redis queuing)
2. M/Rを使ってSharded-Redisからfull migration
3. 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 Coprocessor
4. access path切り替え, Redis cache化
HBaseに置き換えたら幸せになれた?
ある意味ではYES
• Scalability Issuesが解決
•今年いっぱいまでは
•広域分散 → 3rd issue (To be continue...)
Failure Decreased?
ABSOLUTELY NOT!
HBaseを8ヶ月運用してみた印象
• HBaseは火山
• 毎日小爆発
• 蓄積してたまに大爆発
• 火山のふもとでの安全な暮らし
爆発• 断続的なネットワーク障害によるRS退役
• H/W障害によるDN性能悪化・検知の遅延
• get (get, increment, checkAndPut, checkAndDelete)性能劣化、それに伴う全体性能低下
• (major) compactionによる性能劣化
• データ不整合
• SPOF絡みの問題はまだ起こってない
HBaseのAvailability
• SPOF or 死ぬとdowntimeが発生する箇所が幾つか
1. HDFSのNameNode
2. HBaseのRegionServer, DataNode
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 configuration deploying two NN (cloudera)
HA NN using Linux-HA
• DRBD+heartbeatで冗長化
• DRBD: disk mirroring (RAID1-like)
• heartbeat: network monitoring
• pacemaker: resource management (failover logicの登録)
2. RegionServer, DataNode• HBase自体がレプリカをもたない
• failoverされるまでdowntime発生
• 複数コンポーネントで構成されているので、故障検知から全体合意まで、それぞれの通信区間でtimeoutを待たなければいけない
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
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向けではない
HDFS tuning for HBase
• Shortcut a local client reads to a Datanodes files directly > 0.23.1, 0.22.1, 1.0.0 (HDFS-2246)
• Rack-aware Replica Placement (HADOOP-692)
削除問題• 削除が少し低速
• 論理削除なので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単位の削除に
Compaction対策
• Bigtable: I/O最適化と削除の為に定期的なCompaction処理が必要
• RSごとにQueuingされ同時に1 HRegionずつCompactionが実行される
• Compaction実行中にCPU利用率が上がるので、タイミング注意
• タイミング: periodic, StoreFile数, ユーザー実行
• peak-time時に連続して発生しないよう、off-peakにcompactionとregion splitting
Balancing, Splitting, and Compaction
• Region balancing
• 自動balancer (request数ベースのbalancing)はOFF
• serviceのoff-peak時にbalancing
• 異なるtableの同一keyは同じserverに割当→障害を限定
• 問題のあるRegion専用のserver: prison RS
• Region splittingとcompactionのスケジューリング
• 自動splitもなるべく避ける (hbase.hregion.max.filesizeで自動split)
• 連続的なmajor compactionを避ける
• immutable storageはperiodic compactionをOFF
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)
今後の課題• 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を使うか
top related