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

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

インタビュイー

LINE Z Part チーム シニアソフトウェアエンジニア
ルカデテナ ハビエル アキラ
LINE Z Part チーム シニアソフトウェアエンジニア 鶴原翔夢

画像

毎秒数十億件のユーザリクエストに対応するLINEのストレージ環境では、Key-Value Store(KVS)が積極的に活用されています。⁠LINE DEVELOPER DAY 2020」では、LINE Z Part チーム シニアソフトウェアエンジニアであるルカデテナ ハビエル アキラ氏が「LINEアプリにおける大規模トラフィックを支えるストレージ」と題して講演し、LINEで使われるストレージ技術を詳しく解説しました。このLINEのストレージ環境の変遷や将来について、ルカデテナ ハビエル アキラ氏、そして鶴原氏に詳しくお話を伺います。

LINEの強みはテクノロジーの内部までエンジニアが理解していること

――LINEのストレージ開発で意識していることを教えてください。

ハビエル:開発時にとくに気にしているのはパフォーマンスです。それに加えてコンシステンシー(整合性)も意識しているところになります。またLINEではRedisをストレージの1つとして使っていて、巨大なクラスタを構成しています。そのクラスタ内でデータの一貫性を保つことも重要な点です。

何らかの課題があり、その解決策を検討する際には、それぞれのソリューションのメリット・デメリットやビジネス上のニーズを考えながら判断することも重要だと認識しています。

――ストレージで使うソリューションを選定する際に、気をつけていることを教えてください。

ハビエル:現在はさまざまなテクノロジーがあり、新しいものが続々と登場しているほか、既存のプロダクトの改善も進められています。これらのテクノロジーの中には、LINEが抱えている課題を解決できるものも少なくないでしょう。

画像

そうした中で我々が意識しているのは、テクノロジーの内部まで理解することです。LINEでは、ストレージとして利用しているRedis、そしてHBaseの専用チームがあり、それぞれのテクノロジーの内部に至るまで把握しています。我々の強みはテクノロジーにあるのではなく、その詳細を理解しているチームのエンジニアだと考えています。

新しいテクノロジーを利用することも当然視野に入っていますが、一方でLINEはグローバルで約2億人が使っているサービスであり、もしテクノロジーの選定に失敗すれば大きな問題に発展します。このようにテクノロジーの新規採用には大きなリスクが伴います。

一方、現状で利用しているテクノロジーは安定していて、またコミュニティの活動も活発です。さらに先に話したとおり、専属のエンジニアが所属するチームもあるため、今後もRedisとHBaseを使い続けます。ただ、新たなストレージを探し続けていることも事実です。

――LINEのストレージ環境は、これまでどのような変遷を辿ってきたのでしょうか。

鶴原:LINEがサービスを開始した当初は、スピードを重視して立ち上げたこともあり、当初はRedisだけを利用していました。これはパフォーマンスを重視した結果だったわけですが、一方でデータを永続化するレイヤのデータベースがないという課題がありました。

サービスが拡大するに従い、この状態では問題があるということで、Redisに加えてHBaseを利用するようになり、徐々にRedisからHBaseへとプライマリーデータを移行しました。

ハビエル:HBaseの選定では、MongoDBやCassandraなどいくつかのストレージをテストしたと聞いています。その際、最もパフォーマンスが良かったこと、また安定性が優れていたことから、HBaseが使われることになりました。もし同じ検証を現時点で行えば、また違った結果になったかもしれません。

LINEストレージの変遷
LINEストレージの変遷 LINEストレージの変遷 LINEストレージの変遷

今後も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が必要であるかどうか、十分に検討すべきでしょう。

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

おすすめ記事

記事・ニュース一覧