Netflixのロギングアーキテクチャ。ホットデータ用のClickHouseと長期保存用のIcebergを組み合わせている。
その結果、システムはほぼ瞬時に動作するように感じられます。ログは通常、生成から20秒以内に検索可能となり、Netflixの5分のSLAをはるかに上回ります。場合によっては、エンジニアは2秒のレイテンシでライブログをストリーミングすることもできます。イベントをクリックして開いたり、JSONペイロードを展開したり、フィンガープリントハッシュで数百万のメッセージをグループ化したり、周辺のログをドリルダウンしたり――これらすべてをクエリの完了を待つことなく行えます。 しかしDaniel氏が説明するように、このレベルのインタラクティブ性は一夜にして実現したわけではありません。取り込み、シリアライゼーション、クエリの3つの大きな最適化が、システムを今日の姿へと変えたのです。 --- ## Get started today Interested in seeing how ClickHouse works on your data? Get started with ClickHouse Cloud in minutes and receive $300 in free credits. [Sign up](https://console.clickhouse.cloud/signUp?loc=blog-cta-2148-get-started-today-sign-up&utm_blogctaid=2148) --- ## 最適化 #1: 取り込み - フィンガープリンティング ログを有用にするためには、Netflixはまず類似メッセージをグループ化する必要があります。フィンガープリンティングと呼ばれるこのプロセスは、エンジニアがほぼ同一の何百万ものエントリーを1つのパターンに集約することで、ノイズを切り抜けるのを助けます。これがなければ、Netflixの規模でログを検索することは、控えめに言っても圧倒的なものになるでしょう。 初期段階では、チームはログメッセージをグループに分類するために機械学習モデルを試しました。理論的には機能しましたが、実際にはリソースを使いすぎました。「非常に高価で、非常に遅く、製品全体が機能しなくなりました」とDaniel氏は振り返ります。 次にチームは正規表現に移り、ログテキスト内のパターンをマッチングし、値を汎用トークンに置き換えました。これは助けになりましたが、正規表現では毎秒1,000万イベントには追いつけませんでした。「生のテキストからエンティティを認識することは、コンパイラが長らく行ってきたことです」とDaniel氏は説明します。「基本的には同じ問題に同じ解決策があります――レキサーが必要なのです。」 そこでチームは、JFlex(最適化されたトークナイザーを生成するJavaツール)を使用して、フィンガープリンティングを生成型レキサーとして再構築しました。実行時に複雑な正規表現を評価する代わりに、新しいシステムはパターンを効率的なコードにコンパイルします。その成果は絶大で、スループットは8〜10倍に増加し、平均フィンガープリンティング時間は216マイクロ秒から23マイクロ秒に低下しました。99パーセンタイルでさえ、レイテンシは大幅に低くなりました。 「大きな勝利でした」とDaniel氏は語ります。「そして、基本的にはただ書き直しただけでした。」その書き直しはシステムの最大の取り込みボトルネックの1つを解消し、Netflixがスケーリングを続けるための余地を与えました。 ## 最適化 #2: ハブ - シリアライゼーション ログがフィンガープリント化されると、それでも毎秒数百万のレートでClickHouseに書き込む必要があります。ここでNetflixは別のボトルネックに直面しました――シリアライゼーションです。 チームの最初の実装は[JDBC](https://clickhouse.com/docs/integrations/language-clients/java/jdbc)バッチ挿入に依存していました。シンプルで馴染みやすかったものの、非効率でもありました。すべてのプリペアドステートメントが、クライアントにデータベースとスキーマやシリアライゼーションの詳細を交渉させ、スケールが悪いオーバーヘッドを追加していました。「もっと改善できると思いました」とDaniel氏は言います。 そこでチームは抽象化スタックの一段下に降り、ClickHouseの低レベルJavaクライアントが公開する[RowBinary](https://clickhouse.com/docs/interfaces/formats/RowBinary)フォーマットを使用しました。これは、データを列ごとに手動でシリアライズすることを意味しました――マップ長を書き込み、[DateTime64](https://clickhouse.com/docs/sql-reference/data-types/datetime64)をエポックからのナノ秒としてエンコードし、その他の癖を処理しました。これによって「大きなパフォーマンスの向上」が得られたとDaniel氏は言いますが、それでもまだ十分ではありませんでした。 「CPUとアロケーションのプロファイルを見たとき、本当に気になりました」と彼は言います。「なぜ私が望んでいる以上の作業をしているのか? なぜ私が望んでいる以上のメモリを使っているのか?」 ブレークスルーは、Daniel氏が[入力フォーマットをベンチマークするClickHouseのブログ記事](https://clickhouse.com/blog/clickhouse-input-format-matchup-which-is-fastest-most-efficient)を読んだときに訪れました。ネイティブプロトコルは一貫してRowBinaryを上回るパフォーマンスを示しましたが、Javaクライアントはそれをサポートしていませんでした。サポートしていたのは[Goクライアント](https://clickhouse.com/docs/integrations/go)だけでした。「だから私はGoクライアントをリバースエンジニアリングしました」とDaniel氏は言います。 Netflixは、ネイティブプロトコルを使用してLZ4で圧縮されたブロックを生成し、ClickHouseに直接送信する独自のエンコーダーを構築しました。その結果、CPU使用率の低下、メモリ効率の向上、そしてRowBinaryと同等(場合によってはそれ以上)のスループットが得られました。 「完璧ではありません。完成したばかりなので」とDaniel氏は言います。「でも、以前と同等のレベルに達していて、最適化の余地はまだまだあります。」 ## 最適化 #3: クエリ - カスタムタグ 取り込みとシリアライゼーションが主に書き込み中心の課題だったのに対し、3つ目のボトルネックは読み込み側にありました。Netflixのエンジニアはタグに大きく依存しています――各ログイベントに付加される動的なキーと値のペアで、マイクロサービス、リクエストID、その他のカスタム属性でフィルタリングできるようにするものです。便利である一方、タグはシステムの最大の頭痛の種の1つにもなりました。 「カスタムタグは私たちにとって大きな問題です」とDaniel氏は語ります。「ユーザーが一般的に使用する中で、最もコストの高いクエリです、ダントツで。」 当初、タグはシンプルな[Map(String, String)](https://clickhouse.com/docs/sql-reference/data-types/map)として保存されていました。内部的には、ClickHouseはマップをキーと値の2つの並列配列として表現します。各ルックアップはそれらの配列を線形スキャンする必要がありました。1時間あたり最大25,000のユニークなタグキーと数千万のユニークな値があるNetflixのスケールでは、クエリのパフォーマンスは急速に低下しました。 Daniel氏はClickHouseの作成者Alexei Milovidov氏と話し合い、彼は[LowCardinality型](https://clickhouse.com/docs/sql-reference/data-types/lowcardinality)の使用を提案しました。それはキーには有効でしたが、値はあまりにも多すぎたため、問題の半分しか解決できませんでした。「LowCardinality値はオプションになりませんでした」とDaniel氏は指摘します。 解決策は驚くほどシンプルでした――マップをシャード化することです。タグキーを31個の小さなマップにハッシュ化することで、クエリはすべてのキーをスキャンする代わりに、適切なシャードに直接ジャンプできるようになりました。 違いは絶大でした。かつて3秒かかっていたフィルタリングクエリは1.3秒に低下しました。フィルター+プロジェクションのクエリは、ほぼ3秒から700ミリ秒未満に低下しました。どちらの場合も、スキャンされるデータ量は5倍から8倍小さくなりました。 「以前は多くの問題を引き起こしていたクエリが、今ではそこそこ大丈夫になりました」とDaniel氏は言います。そしてNetflixのスケールでは、と彼は付け加えます、「それは大きな、大きな勝利です。」 ## シンプルさの美しさ これら3つの最適化――フィンガープリンティングの再考、シリアライゼーションの書き直し、そしてクエリの再形成――を組み合わせることで、ボトルネックが解消され、NetflixのロギングシステムはどこにあるClickHouse展開の中でも最大かつ最速のものの1つとして確固たる地位を築きました。 エンジニアを遅らせるどころか、Netflixの超人的なスケールにおいてさえ、システムは軽量でインタラクティブに感じられるようになりました。そのような応答性は、障害対応に追われるか、世界中の何億人もの視聴者のためにサービスをスムーズに稼働し続けるかの違いを生み出すことができます。 最終的にDaniel氏は、チームの成功を巧妙なトリックよりも、規律ある エンジニアリングのおかげだと評価しています。「鍵は、最小限の作業で済むようにいかに物事をシンプルにするか、ということに尽きます」と彼は言います。 チームのデータオペレーションを変革しませんか? [ClickHouse Cloudを30日間無料でお試しください](https://clickhouse.com/cloud)。