1月21日に開催された「Hadoop Conference Japan 2013 Winter」の基調講演では、先日、ついに1億ユーザを達成したメッセージングサービス「LINE」で利用されているHBaseの実態について、NHN JapanでLINEのストレージを担当する中村俊介氏が紹介を行いました。本稿ではその概要をレポートします。

最も重要視するのは「ストレージの高可用性」、HBaseはそのためにある

FacebookやTwitterを抜くスピードで急成長を遂げるLINE。1月18日にはサービス提供開始からわずか19ヵ月で1億ユーザを達成し、大きな話題となりました。

急成長中のサービスを提供するために、その裏側で動くストレージにはどんなミッションが課せられているのか。インフラエンジニアであれば誰もが気になるところでしょう。中村氏によれば、LINEのサービスは

• 1日あたり100億のローをさばく拡張性
• 応答時間は10ミリ秒以下を維持する低レイテンシ
• デュアルクラスタによる高可用性

を実現するため、HBaseを採用しています。

この年末年始、とくに大晦日は通常のピークの3倍のトラフィックが生じたそうですが、「⁠HBaseのおかげで問題なく乗り切ることができた」と中村氏。少し前まではキャリアが「回線に障害が出るからあけおめメールは自粛して」などと呼びかけていましたが、ユーザにサービス利用の自粛を訴えるなんて、いまとなっては古い時代のできごとなのかもしれません。

グローバル展開を図るLINEにとって、メッセージングサービスがダウンすることは決して許されないと中村氏は言います。携帯電話だけでなく、タブレットやPCといったあらゆるデバイス上で同時に表示されるようメッセージを同期させ、しかも一定期間はメッセージをサーバに保管しておかなければなりません。

「そのためにはストレージの高可用性が最も重要。HBaseを選択した理由もそこにある」と「絶対にサービスを止めないためには、データロスをしない、ローレイテンシ、リニアなスケールアウトといった要素はもちろん重要です。そしてLINEは現在、ものすごいスピードで開発を行っているので、その変化に柔軟についてこれるスキーマも求められる。さらに、我々にとっては一貫性の維持よりもフェイリャーハンドリングのほうが重要」であり、だからHBaseを選択したとのこと。

さらにHBaseに限らずHadoopエコシステム全般を採用している理由として、オペレーティングコストを低く抑えられることも挙げています。

独自ツールを使ってサービスを止めずにデータセンターを統合

ストレージ上で1日に100億ものローを10ミリ秒以下で読み書きするような環境においても、「⁠HBaseだからこそデータロスもなく運用できた。LINEはHBaseに本当に助けられている」と中村氏は強調しますが、「⁠そのかわり、いろんな試練を与えられた」とも。数々の試練のうち、今回は「データセンターのマイグレーション」「⁠ネームノードのフェイルオーバー」「⁠LINEメッセージクラスタの安定化」にまつわる経験談を披露してくれました。

サービスが拡大するにつれてキャパシティに不安を覚えるのはサービス事業者なら当然のことで、LINEも昨年、データセンターのオンラインマイグレーションを実施、すべてのHBaseクラスタとデータを移行しています。このときの課題はゼロダウンタイムでの移行、サービスの提供もしつつ、マイグレーションも同時に行うというものです。そのための工夫として「⁠（⁠push型の）HBaseのレプリケータは使用せず、独自開発のツールを使って2種類のマイグレーションを実施した」と中村氏。

まず、アプリケーションサーバから本番運用中のストレージ（src-HBase）と移行先のストレージ（dst-HBase）の両方に対してクライアントベースで書き込みを行います。その後、新たに発生するデータに関してはインクリメンタルレプリケーションを行い、古いデータについてはスタンドアロンのバルクマイグレータを使ってsrc-HBaseからdst-HBaseへの移行を行ったそうです。

「インクリメンタルレプリケーションはプル型のレプリケータ（LINE HBase Replicator）を独自開発して実装した。各HLogのエントリにPutを作り、HLogのパスを定期的にdst-HBaseに渡すことで、数秒でエントリがレプリケートできた」と中村氏。将来的には「独自のログクリーナーも開発したい」とのことです。

古いデータを移行するために開発したバルクマイグレータはHBaseからHBaseへのデータ移行を可能にします。特徴はMapReduceではなくMapのみを使った処理であるという点です。各リージョンのサービスに影響が出ないよう、リージョンサーバごとにデーモンを立ち上げてスキャンやバッチ処理を行い、スループットスロットリングでデータセンター間でのマイグレーションを達成しました。

HAクラスタ構成の落とし穴

順調にサービスを拡大しているように見えるLINEですが、HBase運用から1年が経過した2012年10月、突然のネームノード障害という悲しいアクシデント（中村氏は"屈辱的な失敗"と表現しています）に遭遇しています。

その原因はHA構成にありました。この障害で、Virtual IPがプライマリとスレーブの両方に書き込まれてしまい、ネットワークパーティショニングが正しく行われなくなってしまったとのこと。スレーブが投入不可という状態に陥ります。「⁠複雑なスクリプティング、そしてVirtual IPをHDFSに使用するといかにリスキーか、身をもって知った」と中村氏は振り返っています。

フェイルオーバーによりすべてのHBaseクラスタの再起動を余儀なくされた経験から、現在ではHA構成は取っておらず、少ないダウンタイムを許容するという方針にしているそうです。「⁠/etc/hostsにスタンバイのIDを書いておくのが一番シンプルでダウンタイムが少ない方法ということがわかった」というコメントに会場から笑いと驚きの声が出ていました。

HBase利用の成功例がここにある

HBaseを運用してきた経験から、LINEがメッセージングサービスとして安定化を図るためにはどんな課題が残っているのでしょうか。中村氏は4つのケースとして

• Too many HLogs
• Hotspot problems
• META region workload isolation
• Region mappings to RS

を挙げています。とくにHLogの肥大化については「HLogをまじめに運用していると必ずぶつかる問題」としています。LINEはリージョンごとにサービスの成長の度合いが大きく異なるため、削除できないHLogがどんどん溜まっていってしまい、コンパクションストームの発生や非効率なI/Oによる性能低下を引き起こしているとのこと。対策としては「リージョンバランシングが重要。外部でフラッシュスケジューラを立てるなどして解決したい」と語っています。

また、Hotspotの問題については「異常なローが発生すると、それを読みだしたりコンパクションで削除しようとするのでGCで問題になってしまう。Hotspotがトラブったらまずはほかのリージョンに影響が派生しないようにすることが第一」としています。

さらに、LINEではメタテーブルが高負荷の要因となっていることも課題となっており、「⁠HBaseのクライアントがタイムアウトしたのに、ローカルのキャッシュがinvalidしたと勘違い」（⁠中村氏）し、クライアントからタイムアウトが何度も発生する事態になりやすくなっています。そこで現在は、メタテーブル専用のリージョンを設けるという対策を実施しているとのことです。

プレゼンの最後、あらためて「HBaseが、LINEの1億ユーザを支えています」と強調した中村氏。課題は数あれど、グローバルで急成長するメッセージングサービスのHBase運用は、HBaseのみならずHadoopエコシステム全体の発展に大きく貢献する事例といえるでしょう。