HBaseを止めるな！～OKWaveの挑戦～

いまだにHBaseには怖くて手が出せてないんですが、12/10のHadoopソリューションセミナー＠東京カンファレンスセンター品川でのOKWaveさんの事例紹介が素晴らしかったのでご紹介します。

この発表を聴いていたら「何とかなるんじゃないか？」という気がしてきました。

まず気を付けるポイントは以下の4点

1. リージョン自動分割はしない

デフォルトではリージョンが一定サイズを超えると自動分割が走ってしまい、分割中はリージョンにアクセスできなくなる。

リージョンは事前に分割しておいて、自動分割閾値を極端に大きい値にしてリージョン自動分割を走らせない方が良い。

デフォルトでは24h±20%毎に走るけれどもこれだと影響が大きくなってしまうので、そうなる前にこまめに実行した方が良い。

OKWaveでは、N時間に1回 100ファイルを超えたリージョンでコンパクションを狙い撃ち実行するスクリプトを作成。

ただ、それでもメジャーコンパクションが走ってしまうことがあるのでhbase.hstore.blockingWaitTime(デフォルト90秒)を0秒に設定した方が良い。

HBaseは一定サイズを超えたMemStoreをディスクにフラッシュするが、更新処理中の場合はフラッシュを保留する。

ただ、そのままフラッシュできずにMemStoreが一定サイズを超えると全更新処理をブロックしてフラッシュする。

OKWaveではBlockingUpdatesが原因の無応答は一時的な更新集中が多かったので、hbase.hregion.memstore.block.multiplier(デフォルト2)を17に設定。

※一時的な更新集中ならこの対処でOKだが、更新が集中し続けると結局フラッシュできないので設計でも気を付ける

長時間のGCが起きるとリージョンダウン扱いになってしまう。そうするとZooKeeperがリージョンをクラスタから切り離して、GCが終わっても復帰できない。。

対策はGarbage-First GC(G1GC)の実行。

G1GCを実行するとStop the Worldの目標時間が設定できるので、停止目標10秒にする。

ただし, G1GCはJava7以降でないと正常に機能しないのでJava6以下の場合はバージョンアップが必要。

HBaseは動いてくれそうです。

さらに運用するうえで役に立つポイントは以下の通り。

メジャーコンパクションが起きると任意の時刻のデータエクスポートができないが、上記の設定をしていれば問題なし。

定期的にMapReduceのExportを利用してバックアップを実施可能。

リストアはMapReduceのImportを利用して任意の時刻のフルバックアップを戻す。

リージョンを障害から復旧させるとHBaseのバランサーがリージョン偏りを検出して再配置を指示する。

この時に移動候補リージョンが一斉にOfflineになってしまう。しかもこの移動がシーケンシャルなので、リージョンによってはかなり長時間Offlineに。

対策としてはバランサーを無効化して、ログから元々割り当てられていたリージョンを一つずつ移動する。

JMXで監視するとプロセスが正常稼働していなくてもJMXが応答を返してしまうのでHTTPで監視する。

Thrift監視はmozillaが監視用ユーティリティを公開しているのでそちらを利用する。 http://blog.mozilla.org/data/2010/09/09/hbase-thrift-health-check-utility/

HDFSが1 Socket⇔1 Selectorで実装しているので、1TCP/IP接続あたりsocket, epoll, read pipe, write pipeの4FDを消費する。なので、TCP/IP接続で消費するFDの最大値は想定最大接続数の4倍で見積もる。

なお、データノードが最大数から最少数に縮退する時に大量のファイル移動が発生して、生き残ったDataNodeでファイルオープン＆TCP/IP接続を行うので、FDの想定最大数は縮退時で見積もる。

ここにいたるまでのスケール感は「戦車に豆鉄砲を当ててるような気分」で、高付加時のRegion Serverが鬼門だったとのこと。

そのような手強いHBaseをここまで攻略したOKWaveさんには頭が下がります。発表者の鈴木さんならびにOKWave HBaseチームの皆様、ご発表おつかれさま＆ありがとうございました。