LINE テクノロジー&エンジニアリング大全

LINEの大規模ストレージの現在と未来

この記事を読むのに必要な時間:およそ 3 分

今後もRedisとHBaseを併用して大量のトラフィックに対応

――Redisのみでサービスを開始したことは技術的負債の1つとのことですが,それ以外で問題になったことはありますか。

ハビエル:HBaseを使い始めたときのバージョンは,あまり成熟していないものでした。そこでもう少し成熟していて安定しているバージョンにマイグレーションしたことは印象に残っています。

当然ですが,サービスは止められないため,オンラインでマイグレーションを行わなければなりません。このプロジェクトには,3年もの時間を費やすことになってしまいました。

鶴原:サービスがスタートしてから現在まで,スピード重視で機能を追加しているため,コードベースが巨大になっていることは課題であると認識しています。ビルドやテストに時間がかかっているほか,リリースのプロセスも長くなっており,1日に何度もデプロイ作業を行うことができません。

ハビエル:古いAPIと新しいAPIが混在していることも解決したい課題の1つです。新しいAPIでは,ストレージにかかる負荷を軽減するように変更していて,クライアントの新しいバージョンではそちらを使うようになっています。しかし過去のバージョンを使い続けているユーザもいて,古いAPIでのアクセスも少なくありません。ここはなかなか難しいところです。

――ストレージを利用する,バックエンドなどのシステムの開発者とはどのようにコミュニケーションを行っているのでしょうか。

鶴原:まず僕たち自身がバックエンドの開発者でもあるため,直接アプリケーションサーバーのコードも書きます。とくにLINEのコアのメッセージをやり取りする部分については,僕たちは詳細に把握しています。

コア以外の部分はほかのチームのメンバーとのやり取りになりますが,その点に関してはコードレビューやバグトラッキングシステムなどを利用して早い段階からコミュニケーションを取るようにしています。

なおアプリケーション側のエンジニアが書いたコードがHBaseに悪影響を及ぼし,その影響がメッセージングのコアに波及してしまうこともありえます。コードレビューの際には,そういった部分をとくに注意してチェックしています。

ハビエル:基本的にHBaseは複雑で,その内部を理解していないと利用するのは困難です。とくにRDBを使ったことがあるエンジニアは,HBaseも同じようなことができると考えているケースが少なくありません。私自身,HBaseを触り始めたときは戸惑うことが少なくありませんでした。そのため,エンジニアの要望を聞いてアドバイスしたり,彼らが実装した方法とは別のやり方を提案したりすることもあります。

――現状はRedisとHBaseを組み合わせてストレージを構成されていますが,今後はどのようになっていくのでしょうか。

ハビエル:まずRedisに関しては今後も使い続けます。現在LINEのメッセージングでは約2.7兆のリクエストが処理されていますが,そのうちの約2.4~2.5兆のリクエストをRedisで対応しています。

一方,HBaseはインメモリ型のストレージではないため,SSDやHDDにアクセスすることになってしまいます。それでも速いのですが,Redisには及びません。そもそもHBaseではガベージコレクターの処理などの問題もあり,LINEのメッセージングサービスのすべてのリクエストに対応することは困難で,おそらくサービスを提供できない状況に陥るでしょう。そのように考えると,今後もRedisはLINEのストレージ環境において大きな役割を担っていくことになります。

次世代のストレージ環境を見据えて新たなテクノロジーにも注目

――今後もデータ量は増大し続けることになると思いますが,それにどのように対応されていくのでしょうか。

ハビエル:頻繁にアクセスされるホットデータと,アクセス頻度が低いアーカイブデータを分けていて,アーカイブデータに関してはコストを抑えたインフラ上に蓄積していますが,コンパクトに蓄積できるようにバックエンドの処理の改善を行っているところです。

鶴原:もちろんデータが増えれば,それに応じてハードウェアが増えていく部分もありますが,データを圧縮したり,あるいはサービスによっては間引くこともできるため,工夫しつつインフラの負担を抑えるようにしています。

――今後,どういったことに取り組んでいきたいと考えていますか。

ハビエル:KVSにはさまざまな制限があります。たとえばRDBと比べると,どうしてもトランザクション処理の部分で弱いところがあります。そういった課題を解決するための取り組みを進めています。

鶴原:これまでお話ししたとおり,現状はRedisとHBaseをメインで使っていますが,いろいろと苦しんでいる部分はあります。そうした課題を解決するテクノロジーがオープンソースの世界で登場し始めているので,そういった新たなテクノロジーをキャッチアップしていきたいですね。

画像

また,現状ではKVSの制約を回避するために,アプリケーションサーバー側に複雑なロジックが入り込んでいる状況です。そのため,サービスを開発する側が低レイヤの複雑なところまで意識する必要があります。そうしたロジックをストレージのミドルウェア側に寄せていきたい。それによってサービスを開発するエンジニアは,ストレージの詳細を意識しなくてもハイパフォーマンスなデータベースとして使えるようになります。

ハビエル:注目しているテクノロジーの1つとして,コンセンサスアルゴリズムを使ったデータベースがあります。これによって複数のデータセンターで同じデータを持つことができるようになれば,ディザスタリカバリなどで複数のデータセンターを使う際に有用ではないかと考えています。

ただ複数のデータセンターを利用すればレイテンシが増加してしまうため,メッセージングサービスにも影響が生じる可能性があります。そうしたメリット・デメリットを見極めつつ,将来に向けてストレージ環境の改善を進めていきます。

――最後に,これからHBaseを使おうと考えているエンジニアにアドバイスがあればお願いします。

ハビエル:HBaseは非常に複雑なプロダクトです。使ったことがないエンジニアがWebサイト上にある情報を読むと,実はそこまで複雑じゃないんじゃないかと思うかも知れません。確かにコンセプトとしてはシンプルです。しかし実際に使い始めると意外と難しい。内部が分からなければ,解決することが困難なトラブルに遭遇することもあります。

鶴原:HBaseが必要になるほどのトラフィックを流すケースでは,チュートリアルレベルの理解だと苦労することが多いと思います。よさそうだからと軽い気持ちで使うものではなく,そもそも本当にHBaseが必要であるかどうか,十分に検討すべきでしょう。

――本日はありがとうございました。

画像

著者プロフィール

川添貴生(かわぞえたかお)

株式会社インサイトイメージ代表取締役。企業サイトの構築及び運用支援のほか、エンタープライズ領域を中心に執筆活動を展開している。

メール:mail@insightimage.jp


馮富久(ふぉんとみひさ)

株式会社技術評論社クロスメディア事業室部長代理。

1975年生まれ。横浜市出身。1999年4月株式会社技術評論社に入社。入社後から『Software Design』編集部に配属,同誌編集長(2004年1月~2011年12月)や『Web Site Expert』編集長を歴任。その後,2008年9月に設立したクロスメディア事業部(現クロスメディア事業室)の責任者として,イベントやWeb・オンライン企画を統括。現在は,技術評論社の電子出版事業を中心に,デジタル・オンライン事業を取りまとめる。社外活動として電子書籍を考える出版社の会の代表幹事やWebSig 24/7のモデレーター,TechLIONプロデューサーなども務める。過去にIPAオープンソースデータベースワーキンググループ委員やアックゼロヨン・アワード他各賞審査員などの経験を持つ。

Twitte ID:tomihisa(http://twitter.com/tomihisa/