LINEヤフーが世界有数のKafkaデプロイメントのオブザーバビリティにClickHouseを活用

LINEヤフーについては、まずその規模を説明する必要があるでしょう。「巨大テックカンパニー」では足りず、「国民的デジタルインフラ」と理解していただく必要があります。LINEとYahoo!の合併により生まれたLINEヤフーは、日本で最も有名なメッセージングアプリと、国内有数のニュースポータル、および巨大な支払いエコシステムを運営し、それらの間のデータ転送を、数えきれないほどの基幹サービスによって稼働させています。

それほどのスケールを堅実に動かしているのが、同社が全社的に使用しているApache Kafkaプラットフォームです。この中枢のプラットフォームがまるで神経系のように、アプリログ、マイクロサービスイベント、ゲーム内テレメトリなど、あらゆるデータを運んでいます。ピーク時には毎秒3,100万件のメッセージを処理することもあり、1日に流れるメッセージの数は1兆、さらにI/Oは2.6ペタバイトを超えるほどです。

「これはかなり大規模なKafkaクラスターです」と、LINEヤフーのKafkaプラットフォームチームで上級ソフトウェアエンジニアとテックリードを兼務する岡田 遥来氏は言います。「巨大です。おそらく世界でも有数の規模でしょう。」

ClickHouseが2025年6月に開催したObservability happy hour in Tokyoで、岡田氏はKafkaを巨大な規模で運用していることや、まだ誰も知らない問題を発見したことを説明しました。その問題を解決するために、ほとんどの企業が想像もできないようなレベルのオブザーバビリティと、データベース速度、コスト効率、そして開発者にとって使いやすいことなどが求められました。

稀有なKafkaデプロイメント #

岡田氏は、「社内で最もよく使用しているミドルウェアソリューションはKafkaです。」と説明しました。これは大袈裟ではありません。LINEヤフーはKafkaを、たとえばサービス間のクラシックなPub/Sub通信、ログパイプライン、非同期処理、ゲーム内データのストリーミング、そして、内部システム間でデータベースの同期を保つためのCDCフローなど、あらゆる処理に使用しています。サービスから送信されるデータのほとんどがKafkaに到達するといった状態です。

しかし、彼らにとって重要なのはそこではなく、そのボリュームです。LINEヤフーのKafkaプラットフォームは、200を超えるブローカーで構成され、25,000以上のクライアントサービスに機能を提供しています。負荷がそのレベルに達すると、ほんの些細な問題でも雪だるまが膨らむように効率が急降下し、稼働停止に追い込まれます。

また、KafkaはもともとLinkedInが開発し、2011年にオープンソース化されたプラットフォームです。1日に1兆を超えるほどのワークロードは想定されていません。未知の領域に足を踏み入れるようなチャレンジを、LINEヤフーは続けてきました。「これほどの規模で運用すると、世界中でまだ誰も目にしたことのない問題にも遭遇します。」（岡田氏）これまで、彼らはログの削除でレースコンディションが起きること、予期しないfsyncコールによりパフォーマンスがわずかに低下すること、Linuxカーネルの問題により接続が急増した際にパフォーマンスが急低下することなど、アップストリームの問題を修正およびレポートし、貢献してきました。

「こういった問題が日々起こったり起こらなかったりするので、オブザーバビリティが非常に重要になります」と岡田氏は言います。「各問題のルート構造を分析し、根本原因を突き止めるために、システムスタックのどの部分に関しても最大限のオブザーバビリティが必要です。」

マルチレイヤで構成されるLINEヤフーのオブザーバビリティスタック #

巨大なシステムで問題をいち早く検出するため、社内でオブザーバビリティスタックを構築しました。それは一般的なモニタリングセットアップというよりも、むしろ完璧な調査研究システムに近いものでした。

（図）Kafka、JVM、カーネル、ディスクのメトリクスをキャプチャし、リアルタイムで診断するマルチレイヤオブザーバビリティスタック

このスタックの最上部で実行されるプルーブは、エンドツーエンドのパフォーマンスを定期的に測定し、メッセージがプロデューサーからブローカーを通過してコンシューマーに到達するまでの時間を調べます。その下の層では、Async Profilerを使用してKafkaの処理をプロファイリングし、CPU動作の情報とJVMレベルのインサイトを取得して、問題をピンポイントで特定するために使用します。そこからさらに、ディレイアカウンティング、eBPFツール、各ディスクのリードコレクター、およびSMARTデータエクスポーターを使用してLinuxカーネルを詳しく測定します。カーネルスケジューラに問題が起きたり、ディスクが異常な動作を始めたりすると、わかるようになっています。

ですが、何か問題が起きた際に最も活躍するのは、やはりClickHouseを活用したKafka APIリクエストログパイプラインです。LINEヤフーはこのレイヤで、システムのあらゆる瞬間の動作を正確に把握していると言います。プロデュース、フェッチ、コンシューム、ブローカー間レプリケーション、管理オペレーションなど、Kafkaへのあらゆるリクエストがインターセプトされ、プロトコルバッファ経由でシリアル化されて、内部のKafkaクラスターにプッシュされます。その後、「ログインジェスター」にコンシュームされて、ClickHouseに大規模バッチで書き込まれます。

（図）Kafka APIのリクエストフロー。インターセプト後にClickHouseに送られる大容量のクエリ可能データをオブザーバビリティに使用。

これにより、莫大な量のデータが生成されます。同社では毎秒700万行のAPIリクエストログをClickHouseに格納しますが、やがてそれは4.1兆行を超えるデータセットにまで拡大します。「ClickHouseにインジェストされるデータ量はとんでもなく大きいです」（岡田氏）

ClickHouseを選んだ理由 #

LINEヤフーがClickHouseを選んだ理由は主に3つあります。まず、ClickHouseはSQLに対応しており、エンジニアが特別なトレーニングを受けなくてもデータをクエリできることです。「SQLは社内の開発者にとって最も使い慣れたクエリ言語です」と岡田氏は言います。「これは非常に大きな利点です。」

2つ目は、ClickHouseの圧縮機能です。「ClickHouseはとにかくストレージ効率に優れています。カラムナーアーキテクチャのおかげで、非常に高い圧縮率が得られます。データ量が多くなっても、高いストレージ効率を維持できます。」（岡田氏）

最後は何と言っても、ClickHouseのパフォーマンスと水平方向への拡張性です。「パフォーマンスは非常に重要」と岡田氏は言います。「毎秒700万行のインジェストを24のClickHouseクラスターノードだけで実行できます。エネルギー効率にも、コスト効果にも非常に優れています。」

データアクセスにはRedashのダッシュボードを使用しますが、デバッグのセッション中にSQLクエリをダイレクトに実行して行うこともあります。また、岡田氏がClickHouseのTokyo happy hourで説明したように、このクエリこそが、まだ誰も知らないKafkaのバグを捕捉する立役者となるのです。

Kafkaのバグを運用環境で捉える #

ことの始まりは、Kafkaのパーティションでプロデュースリクエストが失敗したという、過去に体験したことのないエラーに遭遇したことでした。岡田氏はいつものようにダッシュボードをチェックし、レプリケーションが完全に停止したという、非常に深刻なアラームを確認します。リーダーはメッセージを受信するものの、フォロワーがそれに追いついておらず、プロデューサーがクォーラムを失うため、新しいメッセージが拒否されています。

最初はフォロワーの問題のように思えたのですが、フォロワーのログを詳しく調査すると、「offset out of order」や「non-monotonic offsets」という奇妙なメッセージに気付きました。これはあってはならないことです。Kafkaパーティションのオフセットは常に1つずつ前進するように作られており、1つでも後退すると、レプリケーションのパイプライン全体が壊れる可能性があります。そこで岡田氏はバッファのダンプを調査しますが、そのとき、「奇妙な現象」に遭遇します。正常にカウントアップされていたオフセットが、突如として大幅に巻き戻されているのです。Kafkaの奥深くに何か問題があると思いました。

岡田氏は、ProduceとListOffsetsの2つのKafka API（どちらもディスクのログセグメントにタッチする）の間でレースコンディションが起きていると推測します。極度に短い瞬間に2つのスレッドが同時にアクセスし、オフセットの状態を変えることで矛盾が起きたと仮定したのです。「この時点ではコードを解読しただけであり、単なる仮定に過ぎませんでした」と岡田氏は言います。「これをどう証明するかが重要でした。」

これを調査するため、どのAPIコールがどの瞬間に起きているかを厳密に知る必要がありました。岡田氏は言います。「ClickHouseで収集したAPIリクエストログが非常に役に立ちました。」ClickHouseに格納されたAPIリクエストログを使用し、エラーが発生した瞬間の数百万行に対してSQLクエリを実行しました。そして岡田氏の推測どおり、ListOffsetsコールはProduceリクエストが失敗したまさにその瞬間に起きていたことを突き止めました。2つのオペレーションが衝突したという明確な証拠により、アップストリームのバグであると証明されたのです。

岡田氏はチームでKafkaコミュニティに修正プログラムを提出し、イシューは現在レビュー中とのことです。数兆ものAPIログを簡単にクエリできるClickHouseのパワーがなければ、これほど簡単には解決しなかったはずです。

LINEヤフーのスケールに欠かせないClickHouse #

ほとんどの企業にとって、Kafkaは堅牢で予測可能なインフラストラクチャです。LINEヤフーほどの規模であっても、Kafkaというオープンソースプラットフォームに与えられた処理を何でも高速に実行します。

そこにClickHouseを組み込むことで、同社はメッセージ件数が1日に1兆を超えるほどのシステムで、リアルタイムなフォレンジックをプレーンなSQLで可能にしています。エンジニアは仮定を立て、クエリを作成し、数十億、あるいは数兆ものレコードに対して動作の追跡をミリ秒単位で行うことができます。

岡田氏は最後に、「ClickHouseは我々のオブザーバビリティスタックの中でも非常に重要な役割を果たしています。」と付け加えました。「毎秒700万行という莫大な量のデータ処理を24台のサーバーで賄うという、驚くようなコストパフォーマンスを達成しています。」

LINEヤフーほどのスケールで運用していると、何が起きても不思議ではありません。ですが、オブザーバビリティプラットフォームの中枢でClickHouseが機能している限り、どれほど奇妙で稀なバグであろうと必ず手掛かりは残ります。その手掛かりのおかげで、岡田氏のチームは世界有数の規模を誇るKafkaシステムを毎日無事に稼働させているのです。