LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

「膨大な量のトラフィックを扱えるLINEの環境は魅力的」Kafkaスペシャリストが語る仕事の醍醐味

LINEで働くエンジニアに色々と話を聞いていく「LINE Engineer Insights」。LINEの技術組織で働く個々人に、何を重視して技術者としてのキャリアを歩んでいるのか、今LINEで何に取り組んでいるのか、今後実現していきたいことなどを聞いていきます。

今回登場するのは、LINEのMessaging Platform IMFチームのApache Kafka(以下、Kafka)スペシャリストである岡田遥来です。IMFチームは全社的に利用されるマルチテナントKafkaプラットフォームの開発・運用を行っています。最も大きなKafkaクラスターが処理するトラフィックは秒間1,500万メッセージ・7.5GBにのぼり、単一クラスターとしては世界でも有数の規模です。

また、IMFチームではOSSのKafka ConsumerライブラリであるDecatonをメンテナンスしています。秒間100万件を超えるI/Oヘビーなタスクを、リソース効率を最大化しつつ信頼性を損なわずに処理することを目的として、Decatonの改善を続けています。

この記事では岡田にIMFチームの業務の醍醐味や今後の目標などを聞きました。

日本でトップレベルに大量のデータを扱う会社で働きたかった

──岡田さんのこれまでの経歴を教えてください。

私は大学時代に数学を専攻しており、C言語で画像処理をする授業を受けたことがきっかけで、プログラミングの面白さに気づきました。大学卒業後は独立系SIerに就職し、そこからネット広告の代理店に転職して広告効果計測システムの開発を担いました。

その会社ではAmazon EMRなどを活用してデータ分析基盤を構築していたのですが、徐々に膨大なデータを扱うことが楽しくなりました。日本でトップレベルに大量のデータを扱う会社で、より難易度の高い仕事に取り組みたいと思い、2017年にLINEに転職しました。

LINE広告(旧 LINE Ads Platform)やLINE公式アカウントの開発を経て、2019年からはIMFチームでKafkaプラットフォームの開発・運用に携わっています。LINE社内では多種多様なシステムでKafkaが用いられており、ユースケースもさまざまです。

──岡田さんが希望して、IMFチームに異動されたと伺っています。

LINE広告の開発組織に所属していた時代に私はユーザーとしてKafkaプラットフォームを利用しており、IMFチームには優れたスキルを持つエンジニアが所属していることを知っていました。

それに、LINE広告の開発ではIMFチームがメンテナンスするDecatonというKafka Consumerライブラリを使っていたのですが、これが非常によくできていて。IMFチームのエンジニアリングに関わりたいと思い、異動の希望を出しました。働き始めてからは、このチームに所属するエンジニアのスキルの高さを実感しています。

知識を総動員して解決策を見つける面白さ

──IMFチームで経験した中で、印象に残る仕事があれば教えてください。

今年のLINE DEVELOPER DAY 2021で発表した内容なのですが、TCP実装に起因する大規模Kafkaクラスターのリクエスト遅延解決が印象に残っています。非常に難易度の高い課題であり、自分自身の大きな成長につながりました。

KafkaにはProducerとConsumer、Brokerというコンポーネントが存在します。ProducerとConsumerがクライアント側、Brokerがサーバー側のコンポーネントです。あるとき、設定変更をロールアウトするためにBrokerを1台ずつローリングリスタートしている最中に、Kafkaクラスターを利用する一部のサービスでProducerのリクエストが突如著しく遅延し、メッセージの送信に支障をきたす現象が発生しました。

あるBrokerを再起動した後から、ProducerからそのBrokerへのリクエストが遅延し始めました。かつ、その事象は特定のProducerと特定のBrokerの組み合わせでしか発生しませんでした。さらに言えば、もう一度再起動するとなぜか直り、謎のタイミングでまた発生するという感じで、再現条件が不明でした。Producerのリクエスト遅延が起きると最悪の場合はタイムアウトによってデータをロストしてしまうため、相当にクリティカルな問題でした。

かなり難易度の高い不具合でしたが、tcpdumpやss、 eBPF といった各種ツールを活用したり、Linuxカーネルのコードを読んだりした結果、LinuxのTCPスタックに原因があることを突き止めました。そして、サーバーの設定変更を行うことでその事象を回避できました。

──相当に難易度の高い調査ですね。

IMFチームはわりとこのような性質の業務が多いです。インターネットや書籍で調べれば簡単に答えがわかるような課題ではなく、知識を総動員して調査しなければ解決策を見つけ出せない課題がたくさんあります。この業務はその典型例で、大きな達成感を得てスキルアップにもつながりました。

──他のエピソードもぜひお聞かせください。

過去に、Kafka本体の不具合が原因でレースコンディション*が発生したことがありました。

*…複数のプロセスが同じデータに同時アクセスした場合に、機能停止など予期しない処理結果が生じること。

Kafkaにはトピックと呼ばれる、同じ性質のメッセージをまとめる単位があります。例えばアクセスログのトピック、バックグラウンドタスクのトピック、といった具合です。そして、不要になったトピックは削除されます。

それとは別に、 Kafkaにはログリテンションという概念があります。Kafkaはストリーミングミドルウェアであり永続的にデータを溜めておくためのソフトウェアではないため、数日ほどでデータを削除する設計になっています。これをログリテンションと呼びます。

私たちが遭遇したのは、トピックの削除とログリテンションによる削除が運悪く同じタイミングで起きることでレースコンディションが生じ、Kafkaサーバーがクラッシュしてしまう事象でした。

──こちらの事例もかなりクリティカルですね。

この事例ではクラッシュが発生したKafkaサーバーが一台のみだったのでサービスを継続できました が、相当に危なかったです。その後、メンバー同士で協力し合いながら復旧作業を行い、Kafkaの開発チームにバグレポートを送りました。こうした事例は、大規模なKafkaクラスターを運用していなければ起きないレアケースです。大変ですが、エンジニアとしてやりがいを感じる瞬間でもあります。

IMFチームでやりたいことは山ほどある

──岡田さんの思う、LINEの魅力は何でしょうか?

まず、コミュニケーションアプリ「LINE」の魅力について話すと、多くの人々の生活に溶け込んでいるサービスだということ。身近な人たちも「LINE」を使用していますし、だからこそより良いサービスにしていきたいです。「LINE」はもはや、人々にとってのプラットフォームやインフラのようなものになっています。

それから、インタビュー内でも何度かお伝えしましたが、大規模なトラフィックやリクエストを扱えることやサービスに高い信頼性が求められること。エンジニアとして挑みがいのある環境だと思います。そもそも、マルチテナントKafkaクラスターの運用をしている会社が世の中に少ないですから、そういう意味でもIMFチームの業務はLINEでしか経験できない貴重な仕事だと感じています。 

──IMFチームで働くうえで大切にしていることはありますか?

私たちのプラットフォームを利用する人々の目線に立ってものごとを考えることですね。例えば仮に、私たちが意図したベストプラクティスとは異なる形でKafkaクラスターを利用しているチームが社内にあったとします。そんなとき、「私たちは○○という使い方を想定しているので、それに従ってください」とか「私たちの意図と違う使い方をするのならば、サポートできません」と拒絶するのは簡単です。

しかし、特定のチームがベストプラクティスとは異なる運用をしなければならないということは、裏を返せば必要とされる機能がプラットフォームに欠けているのかもしれないですし、そこに改善のヒントがあるかもしれません。そういう視点を持って業務に取り組むことを、今後も大切にしていきたいです。

──素晴らしいマインドですね。最後に今後挑戦したいことを教えてください。

私たちが現在使っているKafkaのバージョンは2.4ですが、バージョン3.0が最近リリースされました。そして、3.0ではかなり大規模な変更が入っています。これまではKafkaを利用する際にZookeeperが必要でしたが、3.0ではZookeeperが担っていた役割そのものをKafka本体に取り込む改善がなされています。この機能を私たちのKafkaクラスターにも適用していきたいです。

さらに、Decatonもまだまだ改善の余地があります。Decatonが最初に開発されてから現在まで、KafkaのConsumerの機能には複数の改善が行われました。例えばCooperative Rebalancingという仕組みががKafkaクライアントのバージョン2.4で導入されており、これらの機能を使うことでConsumerのローリングリスタートにおけるダウンタイムを減らせます。
こうした便利な機能を取り込むことで、KafkaクラスターやDecatonをさらに改善していきたい。 IMFチームでやりたいことは尽きないです。
そして、チームとしては mIMF (Machinary IMF)という、Kafkaインフラの運用をほとんど全自動化する様な試みも進めています。

まだまだやらなきゃいけないこと、難易度は高いですがおもしろそうな課題がたくさんあるので、個人としても組織の取り組みとしてもレベルを高め続けていきたいです。

私たちのチームでは、一緒に働くメンバーを募集しています。

少しでもこれらの取り組みに興味があれば、気軽にお声がけください。