エンジニアリングの究極的な挑戦の場はここにある　Kafkaインフラを全社に提供するIMFチームの仕事のやりがい

全社的なKafkaのインフラを開発・提供しているIMFチーム

河村勇人氏：IMFチームの紹介をいたします。私の名前は河村勇人と言います。現在IMFチームでマネージャーをやっています。LINEには2015年に新卒として入っていて、以降さまざまなことをやりながら今日まで働いています。

さっそく、IMFチームのResponsibilityについてお話しします。IMFはチームとしてのミッションを持っています。（スライドを示して）このようにステートメント自体は英語で書かれているのですが、「サービス間のデータ連携をシンプルかつ信頼性高く行うために、高いパフォーマンスを持ち、信頼性が高く、また簡単に使えるHubを提供する」というのがIMFチームのミッションになっています。

では具体的には何をやっているのかというと、Apache Kafkaというメッセージングのミドルウェアインフラの開発・提供を全社的にしています。

また、Kafkaのプラットフォームをサービス開発者のみなさんに使ってもらうにあたって必要なクライアントライブラリや、それを使いやすくするためのライブラリを開発したり、メンテナンスしています。ほかにも、サービスでKafkaを導入してアーキテクチャを作る時や、実装上やセキュリティ上の問題に対してアドバイスをしたり、コンサルティングをしたりするのが主な役割になっています。

Kafkaの特徴は1つのクラスタが非常に大きなスケールを持っていること

Kafkaですが、いわゆるマネージドなKafkaのクラスタを提供していて、非常に高い信頼性と簡単な使い勝手を備えています。

パブリッククラウドのそういったサービスだと、サービス単位でクラスタを作るというやり方をしているところもけっこうあると思いますが、IMFチームは、1つの大きなKafkaクラスタ上にIMFのインフラを使っているさまざまなサービスを同居する、マルチテナンシーなモデルで運用しています。

なので、1つのクラスタが非常に大きなスケールを持っているという特徴があります。

Kafkaは160を超えるサービス・システムで使われている

LINEにおいてKafkaはどのように使われているかをお話しします。代表的なものとして、あるサービスで発生したデータに関するアップデートを、それを必要とする他のサービスに対して伝播するハブとしての役割があります。

例えば、LINEアプリにおいてユーザーが何か操作をしたり、友だちを追加したり、メッセージを送ったりすると、それに伴ったイベントが発生するわけですね。この情報は、もちろんLINEのサービス自体も使用するのですが、それと同じ情報を必要とする他のサービスも他にいくつかあります。

例えばbotのシステム。いわゆるLINE公式アカウントと呼ばれる、サービスを提供しているbotのシステムでは、ユーザーがそのボットにメッセージを送ったという情報、つまりイベントに対してWebhookをトリガーにすることで、レスポンスを返すという実装をしています。

また、LINEのアプリ上で広告を送るというスパム行為をするユーザーがいることがあるので、そういったユーザーの不正なアクティビティをモニタリングして、自動的にペナルティを加えていくという機能を持ったシステムが、その情報を解析するためのソースとしても使われています。

今日登壇する人のほとんどが須くスケールの話をしていると思いますが、私たちのKafkaのプラットフォームに関しても強調したいのはそのスケールです。どのくらいの社内のサービスやインフラが使っているかに関して、スライドにはOver 100と書いてあるのですが、昨日（※発表当時）ちょっと見てみたら、166の独立したサービスや社内システムで私たちのKafkaのプラットフォームが使われていました。

結果として入ってくるトラフィックの量も非常に大きくなっていて、Kafkaにおいては一番小さいデータの単位としてメッセージというものがあるのですが、それの秒間の入ってくる量は15ミリオン、つまり1,500万件という非常に大きなものになっています。なので、ここで今1と数えたらこの瞬間に1,500万件増えています。あと10秒もすれば、軽く1億件を超えてしまうというトラフィックの世界になっています。

なので、当然データサイズも非常に大きくなっています。これはデイリーですが、私たちのKafkaのクラスタに対して1日の間に入ってくるデータと出ていくデータの総合計が1.4PBと、非常に大きなスケールであることがおわかりいただけると思います。

信頼性を担保するためにタイトな条件で運営している

もう1つ大事なのが信頼性で、私たちはSLO（Service Level Objective）というものをクラスタに設定をして、そこに向けて運用しています。いくつか指標があるのですが、代表的なものとして、Availabilityと99パーセンタイルのレスポンスタイムがあります。

Availabilityとして、年間で99.999パーセント、いわゆるファイブナインズといったAvailabilityをターゲットに運用していて、99パーセンタイルのレスポンスタイムは、いわゆるテールレイテンシの中で一番遅い部分に関しても50ミリ秒未満という非常にタイトな条件で運営しています。

高い信頼性が求められるチャレンジングな環境

今日ここで皆さんにお話しするにあたって、私自身がなぜLINEにいるのか、LINEのエンジニアリングの何が楽しくてここにいるのかをお話ししたいと思っています。まず1つは、非常に高い信頼性が求められるということです。

これ（非常に高い信頼性）単体が、エンジニアリングとしてものすごくチャレンジングなことであるのは、みなさんにもご理解いただけると思うのですが、それに加えて非常に大きなトラフィックやデータのスケールがあります。これも単体でものすごく大きな挑戦ですね。

ただLINEでおもしろいのは、常にこの2つが一緒に合わさっているということです。その結果として、私はエンジニアリングにおける究極的な挑戦だと思っていて、そういったものに対して立ち向かっていかなければならない環境になっています。

高い信頼性は、ただ放っておけば達成できるものではもちろんありません。特にIMFにおいては、何か問題が起きた際にアプリケーションの表層だけではなくて、その下で動いている複数のそのソフトウェアを動かしているレイヤーに対して横断的に調査をしていかなければならないシチュエーションが多くあります。

その一例として、2019年の「LINE DEVELOPER DAY」で私がお話した内容が一番わかりやすいと思うのでリンクを貼りました。今日は、時間的に詳細をお話しできないので本当にざっくりとした内容を話します。

アプリケーションのレスポンスタイムがものすごく悪化したという現象を観測したところから調査を始めました。KafkaはScalaという言語で書かれているので、JVMで動いているのですが、レスポンスタイムの悪化の原因が、実はアプリケーションレベルではなくて、その下の言語のランタイムであるJVMのレベルにあるということがわかりました。

さらにJVM内の問題を追及するにしたがって、実はさらにその下のLinux Kernelの中に問題の所在があることがわかり、それを追求するとさらにその下のRAIDコントローラのレベルに根本原因があったというところまで深追いをしたケースがあります。

細かい具体的な内容はリンク先で見てもらいたいのですが、私がここで強調したいのは、こういったソフトウェアを動かしている複数のレイヤーでさまざまな調査をする必要が生じるということです。

ここではアプリケーションはKafkaですが、そのレベルではメトリックとログを解析したり、コードを読んだりすることが必要になり、その下の言語のランタイムであるJVMのレベルでは、GCログの解析をしたり、JVMTI agentというJVM自体の機能を拡張するインターフェイスを使って普通ではわからないインサイトを得たりする必要があります。

また、OSレベルにおいてはeBPFやSystemTapなど、動いているカーネルに対してダイナミックにプルーブをかけていくことを可能にするツールがあるのですが、そういったものを活用したりします。ほかにも、ハードウェアレベルのエラーやfaultを環境的に再現するためにKernelのモジュールを書いて、任意のエラーをインジェクトできるようにしています。

ヒューマンリソース最適化のためのプロジェクトが進行中

もう1つの側面として、ヒューマンリソースに関する最適化があります。Kafkaのシステムの利用が拡大していくのは当然うれしいのですが、運営をするために必要な人間のリソースが比例して増えてしまうのはあまり美しくないと考えています。

なので、システムのスケールが増したとしても、なるべく定数人数で運用できるように心がけているのですが、usageが広がり、それに伴って増えるトラフィックを捌くためには、マシンの台数を増やす必要が現実としてはあります。マシンの台数が増えると、故障の件数もアラートも多くなり、調査コストも増えて、デプロイの時間も長くなってしまいます。

これまでIMFチームは、そのクラスタに対して直接オペレーションしていくチームだったのですが、その状況を改善していくために、機械のコンポーネントたちで構成された「機械仕掛けのIMFチーム」を作って、人間のIMFチームはその仕組みを作る側に回るというプロジェクトを進めています。

その一例として、Alert Inspectorというものがあります。これは非常に増えてしまったアラートの件数に対するコストを下げるというプロジェクトです。IMFチームでは、人間が調査をする場合においても、そのアラートの調査フローをデータベース化するということを、もう1年以上行っています。

具体的には、YAMLのファイルの形式でアラートが鳴った場合には、まずここを見て、次にここを見て、ここを見ればいいという手順をそれぞれのメンバーが記録をしていって、1つの大きなデータベースを作っています。

調査のために必要なメトリックやログを1ヶ所に集めておいて、既知のパターンに対して機械的にマッチングをかけて、人間が一次調査に入らなくても、まず既知のパターンに合致するかどうかを機械的に判断する仕組みづくりを目指しています。

もう1つのテーマとして、クライアントライブラリの開発があります。クライアントライブラリも多くのものを開発しているのですが、今日は1つの代表例として、Decatonプロジェクトを紹介します。DecatonというのはLINEで公開されたKafkaのコンシューマーライブラリで、オープンソースになっているのでみなさんも見ていただけると思います。

これ自体の価値をきちんと説明しようとすると、Kafkaに対するある程度の知識が必要になるので、興味がある方は後ほど（スライドを示して）このリンク先にあるリポジトリ内にあるドキュメントをご覧ください。

簡単に言うと、Kafkaにおいてそのデータが送られてくるパーティションというパターンです。本来これは、逐次的にしか処理ができないものですが、それに対して複数のスレッドで並列に処理することを可能にするためのライブラリです。これは非常に多くのLINEのサービスに使ってもらっていて、IMFチームとしても精力的に開発をしています。

幅広いエンジニアリングが必要とされる究極の挑戦の場

ということでまとめですが、IMFチームでは全社向けのKafkaのインフラを開発して、メンテナンスをして提供をしています。IMFチームでは非常に幅の広いエンジニアリングが必要とされていて、ソフトウェア開発は当然のこと、Reliabilityエンジニアリングやユーザーに対するコンサルテーションやサポートなども必要となります。

IMFチームでは、すべてのメンバーがこれらの3つのエンジニアリングに深く関わる体制になっています。エンジニアリングのターゲットとしているソフトウェアのレイヤーも非常に幅が広く、アプリケーションはもちろん、その下の言語のランタイムであるJVMであったり、それが動いているOS、つまりLinuxのKernelであったりまでエンジニアリングの対象としているのがIMFチームの大きな特徴の1つだと思っています。

ということで最後ですが、IMFチームがみなさんにとってどんな場所になり得るか。冒頭でも強調しましたが、非常に高い信頼性と大きなトラフィックスケール、これらが組み合わさった時に生まれるエンジニアリング上の究極の挑戦に対して挑める場であるということがまず1つあります。

また、自分自身が作ったシステムをデプロイをして動かしていくのもIMFチームになるので、ユーザーや、あるいはそのシステムをリリースしている自分自身からダイレクトなフィードバックを受けやすい環境になっています。そういった点にやりがいを感じてもらえるのかなと思っています。