2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
LINE Messaging Platform - IMF Teamの紹介(全1記事)
提供:LINE株式会社
リンクをコピー
記事をブックマーク
河村勇人氏:IMFチームの紹介をいたします。私の名前は河村勇人と言います。現在IMFチームでマネージャーをやっています。LINEには2015年に新卒として入っていて、以降さまざまなことをやりながら今日まで働いています。
さっそく、IMFチームのResponsibilityについてお話しします。IMFはチームとしてのミッションを持っています。(スライドを示して)このようにステートメント自体は英語で書かれているのですが、「サービス間のデータ連携をシンプルかつ信頼性高く行うために、高いパフォーマンスを持ち、信頼性が高く、また簡単に使えるHubを提供する」というのがIMFチームのミッションになっています。
では具体的には何をやっているのかというと、Apache Kafkaというメッセージングのミドルウェアインフラの開発・提供を全社的にしています。
また、Kafkaのプラットフォームをサービス開発者のみなさんに使ってもらうにあたって必要なクライアントライブラリや、それを使いやすくするためのライブラリを開発したり、メンテナンスしています。ほかにも、サービスでKafkaを導入してアーキテクチャを作る時や、実装上やセキュリティ上の問題に対してアドバイスをしたり、コンサルティングをしたりするのが主な役割になっています。
Kafkaですが、いわゆるマネージドなKafkaのクラスタを提供していて、非常に高い信頼性と簡単な使い勝手を備えています。
パブリッククラウドのそういったサービスだと、サービス単位でクラスタを作るというやり方をしているところもけっこうあると思いますが、IMFチームは、1つの大きなKafkaクラスタ上にIMFのインフラを使っているさまざまなサービスを同居する、マルチテナンシーなモデルで運用しています。
なので、1つのクラスタが非常に大きなスケールを持っているという特徴があります。
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チームになるので、ユーザーや、あるいはそのシステムをリリースしている自分自身からダイレクトなフィードバックを受けやすい環境になっています。そういった点にやりがいを感じてもらえるのかなと思っています。
最後ですが、IMFチームに関するリンクですね。外部公開しているさまざまな資料をまとめておきました。興味を持っていただけた方は、ぜひご覧ください。IMFチームからは以上です。ありがとうございました。
LINE株式会社
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略