1日約2.7兆のリクエストを、高いパフォーマンスと信頼性で処理　LINE Messaging PlatformのSREが高トラフィックを支える

LINE Messaging Platformの構成

加藤亙貴氏：LINE Platform Development Center1 Messaging Platform Development室 Z Partチーム HBase Unitの加藤亙貴です。このセッションでは、分散ストレージリライアビリティエンジニアというポジションにおける、LINEプラットフォームのSREについて紹介します。よろしくお願いします。

今日はこのようなアジェンダに沿ってお話しします。始めに、LINE Messaging Platformや私の所属するZ Part HBase Unitの紹介。次にHBase Unitの技術スタックや実践しているReliability Engineeringについて紹介します。最後にまとめとして、今私たちが直面している問題、そしてチームにジョインしていただいた際、どのような問題を私たちと一緒に解いていくのかについてお話しします。

さて、LINEアプリのバックエンド、LINE Messaging Platformは概ねこのような構成になっています。左側のline-serverというグループの中に、メッセージングの中核であるtalk-server、talk-decatonといったコンポーネントが存在します。また、関連するアプリケーションとして、Bot関連の処理や認証、ユーザー設定の管理を行うものなども存在します。

そして、このプラットフォームを支える重要なストレージが、Redis、HBase、Kafkaという3つのミドルウェアです。私たちは、Z PartまたはIMF Partというチームにおいて、これらのミドルウェアの管理や、関連するプラットフォームアプリケーションにおける開発業務を行っています。

LINE Messaging Platformのストレージ

私たちが管理するLINE Messaging Platformのストレージは、主要4ヶ国において1億7,100万人に上るユーザーのために、1日約2.7兆のリクエストを高いパフォーマンス、そして高い信頼性を維持して処理しなければなりません。そのためにLINE Messaging Platformおよびそのストレージは、およそ9,000台の物理マシン、または仮想マシンによって構成されています。

私が所属するZ Part HBase Unitは、先ほどの3つのストレージのうち、HBaseクラスタの開発・運用を行っています。HBaseはMessaging Platformにおける主要な永続分散ストレージです。主な業務として、継続的な監視・調査・改善によってHBaseクラスタの信頼性やパフォーマンスを高めたり、操作や監視ツールの機能向上、他のチームの開発サポートなどが挙げられます。

私たちは「分散ストレージリライアビリティエンジニア」というポジションで、新しいメンバーを募集しています。

HBase Unitの監視のための技術スタック

ここで、HBase Unitの監視のための技術スタックを紹介します。下にあるように、私たちは複数のHBaseクラスタを用途別に分けて運用しています。これらのログを分析するのは、左に示したパイプラインです。各ホストは、FilebeatによってログをLogstashに送ります。Logstashはログの内容、例えばGCのポーズタイムやHBaseのリカバリータイムなどの情報をパースし、Elasticsearchに保存します。そしてKibanaによる可視化、またElastalertによる通知を行っています。

次に紹介するのが、メトリクス分析のためのパイプラインです。各ホストはディスクI/OのレイテンシーやHBaseのレスポンスタイムなどのメトリクスを、エクスポーターを通じて公開します。このメトリクスは、クラスタごとにPrometheusが収集・保存し、Grafanaによる可視化や、Alertmanagerによるアラーティングに用いられます。

またメトリクスはPrometheusのフェデレーションインスタンスによって長期保存され、HBaseクラスタのキャパシティプランニングの際にも用いられます。さらにHBaseクラスタのログやメトリクスは、IMONという内製の監視ツールにも送信されています。これはログからの信頼性の高いアラーティングに用いられています。

HBase Unitでは一部を除き、これらを自分たちで運用および自動化を行っています。アプリケーションは物理マシンと、「Verda」というプライベートクラウドの仮想マシン上に構築され、その自動化にはAnsibleが用いられています。さらに一部のツールは、VKSと呼ばれるマネージドKubernetesクラスタにデプロイされています。

安全でスケーラブルなパフォーマンステスト環境の構築

このような監視基盤をベースに、私たちはさまざまなReliability Engineeringを実践しています。その1つが、安全でスケーラブルなパフォーマンステスト環境の構築です。例として、テスト用のHBaseクラスタを準備し、ある設定やスペックを適用した際のパフォーマンスを評価するとします。

ここで、本番用のHBaseクラスタに送信されるRPCリクエストをインターセプトし、Kafkaを経由して、Replayerと呼ばれるアプリケーションに複製します。Replayerは受信したリクエストをフィルタまたは増幅し、テストクラスタに対して再現します。

これにより、テストクラスタの設定やスペックが本番環境と同様の負荷に耐え得るか、また、ニューイヤーバーストのような、急激なトラフィックの増加に耐え得るかを、安全かつ高い再現性を持ってテストできます。

この検証環境を用いてテストしたものの1つが、HBaseのHedged Readsです。Hedged Readsとは、Readリクエストをプライマリ以外のレプリカにも送信し、もっとも早く返ってきたレスポンスを採用する仕組みのことです。これにより、ディスクI/Oやネットワーク遅延によるレスポンスタイムへの影響の削減が期待できます。

不安定なディスクI/Oを再現するため、私たちはLD_PRELOADを用いてI/Oの不具合をテスト環境で再現し、Hedged Readsによってレスポンスタイムの改善が実現できることを確かめました。さらに、特定の状況によってデッドロックが発生し、リージョンサーバーがダウンする問題の発見、メトリクスの追加による可観測性の向上などを通じて、コミュニティに貢献しました。

HBaseクラスタのマイグレーション

もう1つ、私たちが取り組んでいる例として、HBaseクラスタのマイグレーションが挙げられます。あるHBaseクラスタにおけるテーブルを別の場所に移転しなければいけない状況を考えます。メジャーバージョンのアップグレード、スキーマの変更、マシンを配置するサーバールームの転換などによって、私たちは日々多くのマイグレーションを行っています。

LINEに求められる高い可用性から、これらの作業はすべてゼロダウンタイムで行っています。まずライトアヘッドログの送信やスナップショットのコピーなどによって、新しいクラスタにデータを複製します。次にアプリケーション側を新しいクラスタに対する読み取り、書き込みができるように変更します。

この時、Central DogmaというConfigurationサービスを通じて、プライマリとセカンダリクラスタの切り替えや、読み書きの単一または同時モードへの切り替えなどを動的に反映できるようにしています。これにより、読み取りの際にデータの不整合がないかを確認しながら新しいクラスタにスイッチできます。

さらにこれはマイグレーション作業に限りませんが、ベータ環境においてdestabilizerと呼ばれる、リクエストを一定の確率で失敗させるコンポーネントをHBaseに挟んでいます。これにより、障害発生時にもリトライ機能によってデータの整合性が保たれるかどうかをチェックしています。

LINE技術組織が抱える未解決課題

ここまで、私たちの実践しているエンジニアリングについて紹介しました。しかし私たちにはまだ達成できていない問題がいくつか存在しています。例えばマルチデータセンター環境におけるアーキテクチャの改善、より信頼性の高いトランザクションやセカンダリーインデックスの実装、TiDBなどの新世代ストレージミドルウェアの検討や導入。そして、一つひとつ異なるrequirementを持ったクラスタへのSLOの導入と運用などが挙げられます。

詳しくは「LINE技術組織が抱える未解決課題」というサイトで紹介されているので、ぜひ読んでみてください。

ストレージミドルウェアの開発に共通する2つの特徴

LINEの分散ストレージリライアビリティエンジニアとしてジョインすると、LINE Messaging PlatformにおけるRedisやHBase、Kafkaといったストレージミドルウェアの開発に携わることになります。今回は、そのうちHBaseについて紹介しましたが、これら3つのユニットが取り組む問題には、2つの共通する特徴があると思っています。

まず、問題が非常に大きいトラフィックによってもたらされるということ。これはすなわち、その問題の解決が多くのユーザーに影響を与えるということでもあります。2つ目は、技術的な観点において、解決すべき問題が高いレイヤーから低いレイヤーまで非常に多岐に渡るということです。分散システムにありがちな一貫性の問題といったレイヤーの高いものから、ミドルウェアからJVM、Linux、ハードウェアに起因するような、いわゆる低レイヤーに属するものまで、日々多種多様な問題に取り組んでいます。

私たちは、このようなLINEの分散ストレージリライアビリティエンジニアならではの課題に、ともに楽しく取り組んでいけるメンバーを募集しています。ぜひ応募をご検討ください。最後になりますが、本セッションで紹介した事例はこのようなメディアを通じて、より詳しく解説されています。興味があればぜひご覧ください。本日はご参加いただき、ありがとうございました。