HBase Meetup Tokyo Summer 2015 での講演資料です

1. 100億超メッセージ/日のサービスを
支えるHBase運用におけるチャレンジ
LINE株式会社 開発1センター
坂井 隆一
ⓒ 2015 LINE CORPORATION

2. 自己紹介
坂井 隆一
• LINE入社前
ネットワーク関連のソフトウェア開発に従事
ストレージはほぼ未経験
• 2014年秋 LINEに入社
HBase開発・運用チームに配属
絶賛HBase修行中

3. 本日の話題
• LINEのHBase clusterの紹介
• あるGCとの戦いの記録

4. LINEのHBaseの用途と要求
• 主な用途
非同期メッセージングの実現
複数デバイス(smartphone + desktop)への対応
social graph
• 要求
低遅延
高可用性(HA)
スケーラビリティ

5. ストレージのHA構成
Redis + HBase × 2 のHA構成
• LINE独自のsharded Redis clusters
• HBase 0.90.6-cdh3u5 clusters
• writeだけでなくreadも多重化
storage API
Redis
cluster
HBase
cluster
HBase
cluster
messaging servers

6. データの配置
ストレージの構成 データの性質 データの種類
Redis + HBase
×2
• 頻繁にアクセスされる
データ
• リアルタイムアクセス
されるデータ
• user information
• message
• event
HBase ×2 • リアルタイム要求が
低めのデータ
• social graph
• message box
HBase ×1 • HA要求が高くない
データ
• stats
event : イベントを逐次処理するためのキュー

7. Multi-tenancy or Small Clusters?
現状は “small clusters” 構成
• multi-tenancy
巨大なclusterに複数のサービスを配置
• small clusters
サービスごとに1つのclusterを運用
multi-tenancyに比べて”small”

8. HBase cluster構成の方針
• 機能・サービスごとにclusterを分離
• ZK ensemble : HDFS cluster : HBase cluster = 1 : 1 : 1
• リソース競合や障害の影響の局所化を意図
HDFS
HBase
Server Server
HDFS
HBase
Server Server
ZK
cluster 1 cluster 2
ZK

9. 主なHBase cluster
message event stats
HBase version 0.90.6-cdh3u5 0.90.6-cdh3u5 0.94.27
RegionServers 250 170 500
Used Capacity 133 TB 134 TB 11 PB
Peak Time Requests 約2,000,000 / sec 約2,000,000 /sec -
RegionServerのspec（導入時期による違いあり）
• CPU : 6 cores × 2 / 2.40 GHz
• Memory : 192 GB (RegionServerのheapに31GB)
• Storage : 3.0 TB ioDrive2
※message, eventはHAのため上記specのclusterが×2

10. あるGCとの戦いの記録
• メッセージ送信処理のresponse timeに時折
spikeが発生
• HBaseのresponse timeのspikeが原因
multiMaxTime (msec)

11. spike発生時のRegionServer GC log
• new領域のpromotionに失敗
• full GCが発生して長時間のstop the world
※GCはCMSを使用
[GC 3439234.481: [ParNew (promotion failed): 235968K->214934K(235968K),
0.0474320 secs]3439234.528: [CMS: 11335704K->6744545K(16410692K), 7.5043760
secs] 11553160K->6744545K(16646660K), [CMS Perm : 25993K->25890K(43476K)],
7.5576600 secs] [Times: user=8.04 sys=0.00, real=7.55 secs]

12. full GC付近のRegionServer log
• BlockCache evictionが多発
00:50:15,918 LruBlockCache: Block cache LRU eviction started; Attempting to
free 731.93 MB of total=4.91 GB
00:50:15,935 LruBlockCache: Block cache LRU eviction completed; freed=859.86
MB, total=4.07 GB, single=1.12 GB, multi=3.74 GB, memory=0 KB
### ここでfull GC ###
00:50:28,546 LruBlockCache: Block cache LRU eviction started; Attempting to
free 700.12 MB of total=4.88 GB
00:50:28,573 LruBlockCache: Block cache LRU eviction completed; freed=769.88
MB, total=4.13 GB, single=326.15 MB, multi=4.51 GB, memory=0 KB
00:50:28,887 LruBlockCache: Block cache LRU eviction started; Attempting to
free 634.66 MB of total=4.81 GB
00:50:28,892 LruBlockCache: Block cache LRU eviction completed; freed=720.2
MB, total=4.11 GB, single=334.97 MB, multi=4.44 GB, memory=0 KB

13. なぜBlockCache evictionが多発？
原因の可能性
• read requestが多すぎる
• 巨大なKeyValueをreadしている
block cacheを大量に占有してしまうKeyValueがあ
る？
しかし、KeyValueサイズを調べたところ最大で
123KB

14. KeyValue以外に何か？
meta blockもblock cacheを使っている
(HFile.java)
public ByteBuffer getMetaBlock(String metaBlockName, boolean cacheBlock)
throws IOException {
...
if(cacheBlock && cache != null) {
cache.cacheBlock(name + "meta" + block, buf.duplicate(), inMemory);
}

15. meta blockの内容は？
BloomFilterのmeta情報、そしてデータも！
(StoreFile.java)
...
ByteBuffer bloom = reader.getMetaBlock(BLOOM_FILTER_DATA_KEY, true);
…
ByteBuffer b = reader.getMetaBlock(BLOOM_FILTER_META_KEY, false);

16. BloomFilterのサイズを確認
$ hbase org.apache.hadoop.hbase.io.hfile.Hfile –m –r XXXXX
Block index size as per heapsize: 13860008
...
BloomSize: 164952448
No of Keys in bloom: 88121307
Max Keys for bloom: 88121307
Block Index:
size=150648
164,952,448 B = 157 MB

17. 問題の原因
• 160MBのBloom filterのblockがcacheされる
• やがてGCの際にold領域にpromotionされる
• old領域は多数の通常block (64KB)でフラグメ
ンテーション状態
• 160MBの連続領域が確保できないとfull GC
• HFile v1の問題
⇒ HFile v2 (HBase 0.92〜)では解決済み

18. 問題の対策
問題のclusterではBloomFilterのチェックが効か
ないアクセスをしていた
⇒ BloomFilterを作らないようにした
io.storefile.bloom.max.keys
• key数がこの設定値を越えるとBloomFilterを
作成しない

19. 問題の緩和策
別clusterではBloomFilterのサイズを下げた
m: Bloom filterのbit数
n: keyの最大数
e: 平均エラー率（defaultは0.01）
m = -
n´ln(e)
(ln(2))2
e を 0.01 から 0.1 にすると m は 1/2

20. GCとの戦いは続く
• その他にもlong GC問題は発生
• 対策例
heap利用の最適化
MemStore領域とBlockCache領域のバランシング
Java VM optionの最適化
Readを減らすschema/application設計
• BucketCache (HBase 0.96〜)が使えれば・・・

21. まとめ
• LINEのHBase cluster
HAのため2 cluster構成
現状は multi-tenancy ではなく small clusters
• 運用におけるチャレンジ
問題解決にはHBaseの深い理解が必要
新しいバージョンでは解決されている問題も・・・

22. 学んだこと
HBase 0.90 はもう使わない方がいいらしい
はやく 1.X になりたい ⇒ 現在進行中