![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]](https://image.slidesharecdn.com/hbasemeetup2015-line-150714055939-lva1-app6892/75/100-HBase-11-2048.jpg)
Uploaded byLINE Corporation
100億超メッセージ/日のサービスを 支えるHBase運用におけるチャレンジ
HBase Meetup Tokyo Summer 2015 での講演資料です
More Related Content
![[db tech showcase Tokyo 2014] L32: Apache Cassandraに注目！！（IoT, Bigdata、NoSQLのバ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbtstokyo2014l32datastaxapachecassandraiotbigdatanosql-141120022255-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
100億超メッセージ/日のサービスを 支えるHBase運用におけるチャレンジ
- 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 SmallClusters? 現状は “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 eventstats 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が多発？ 原因の可能性 • readrequestが多すぎる • 巨大なKeyValueをreadしている block cacheを大量に占有してしまうKeyValueがあ る？ しかし、KeyValueサイズを調べたところ最大で 123KB
- 14. KeyValue以外に何か？ meta blockもblock cacheを使っている (HFile.java) publicByteBuffer 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.
- 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のため2cluster構成 現状は multi-tenancy ではなく small clusters • 運用におけるチャレンジ 問題解決にはHBaseの深い理解が必要 新しいバージョンでは解決されている問題も・・・
- 22. 学んだこと HBase 0.90 はもう使わない方がいいらしい はやく1.X になりたい ⇒ 現在進行中