ClickHouse Cloudにより、Cleverは同じコストで200倍のログを取り込み可能に

Cleverは、すべての生徒を学びの世界につなげることをミッションとしています。K-12教育向けの主要なアイデンティティプラットフォームとして、Cleverは2,900万人以上の教師と生徒に安全なデジタル学習体験を提供し、米国のK-12学校の77%にリーチしています。

この規模になると、ログは急速に膨らみます。CleverはAWS Fargate上で400のサービスとワーカーを稼働させ、さらに200のAWS Lambdaも合わせて毎月約150 TBのログを生成しています。シニアソフトウェアエンジニアのJake Gutierrez氏にとって、これらのログをClever のエンジニアリングチーム全体がアクセスできる状態に保つこと自体が課題になりつつありました。

Jake氏はソリューションアーキテクトのJake Vernon氏とともにウェビナーに登壇し、ロギングインフラをどのように再構築したか、そしてDatadogからAWS上のClickHouse Cloudへの移行によって、追加コストなしで200倍のログをインデックスできるようになった経緯について語りました。

もどかしく断片化していたロギングシステム #

ClickHouse導入以前、Cleverはすべてのログを Datadogに送信していました。問題は、DatadogがCleverのログの約10%しかインデックスせず、しかも保持期間はわずか3日間だったことです。残りの90%は AWS Athenaに送られ、最大60日間利用可能でしたが、アクセスするにはSQLを書く必要がありました。問題をデバッグしようとするエンジニアは、3日間の保持期間を超えて調査する必要があるかどうかを判断し、ツールを切り替えなければなりませんでした。

「この二重脳的なシステムは、非常に混乱を招くものであることが判明しました」とJake氏は語ります。「エンジニアは『私のログはどこにあるの?』と言うでしょう。なぜなら我々はデバッグログをインデックスしていなかったからです。あるいは、『このエラーログは3日前から出始めた』と言うことがありますが、実際にはもっと前から出ていることがあります。30日間のトレンドを見たい場合、非常に困難で、Athenaに行く必要がありました。」

ClickHouseへ導いた3つの要件 #

より良いソリューションが必要になり、Cleverチームは3つの要件から検討を始めました。

第一に、すべてのログを1か所に60日間保存できることを望みました。これにより、エンジニアがトレンドを把握し、自信を持ってデバッグするために必要な履歴コンテキストを提供できます。

第二に、ソリューションは価格競争力があり、高可用性を備え、理想的にはマネージドサービスであること。Jake氏の言葉を借りれば、「メンテナンスのオーバーヘッドを負担する必要がない」ことです。

第三に、使いやすいこと。Cleverのエンジニアの大半は日常的にSQLを扱いません。新しいシステムは、Jake氏によれば「非常に分かりやすく、Datadogと同様で、同等のパフォーマンスレベルである」必要がありました。

ClickHouse Cloudはこれらの条件を満たしていました。Jake氏はこう振り返ります。「最近、著名なオブザーバビリティのユースケースがたくさん登場していたため、ClickHouseに行き当たりました。」チームはClickHouseベースの他のいくつかのソリューションも評価しましたが、「データセット全体を保存するには高価すぎる」として除外しました。ClickHouseのマネージドサービスは、必要なパフォーマンスを提供しつつ、コストとメンテナンス負担を低く抑えるという絶妙なバランスを実現していました。

ClickHouseによるオブザーバビリティのためのスキーマ設計 #

Jake氏が指摘するように、スキーマ設計はClickHouseコミュニティにおいて特に興味深いトピックの1つです。「ClickHouseにログを保存する方法は多岐にわたります」と彼は言います。Cleverのログは主に構造化JSONなので、チームはクエリ時にパースするのではなく、書き込み時にインデックスする方法を求めていました。

次に、level や service などの頻繁にクエリされるフィールドは、それぞれ専用のカラムに直接抽出されます。その他のフィールドについては、Jake氏がハイブリッドアプローチと呼ぶ方式を採用しており、完全なログを生のJSON文字列と属性マップの両方として保存します。マップには、すでに専用カラムに抽出されていないフィールドのみが含まれるため、エンジニアはトップレベルのフィールドを素早く取り出し、より詳細が必要な場合にのみ生のJSONに展開できます。

Cleverは様々なデータスキッピングインデックスを使用しています。timestampカラムのminmaxインデックスは通常のタイムスタンプフィルタリングを正しく機能させます。bodyフィールドのトークンブルームフィルタは、高速で大文字小文字を区別しない全文検索を可能にします。マップキーのブルームフィルタとマップ値のトークンブルームフィルタは、その検索性を属性にも拡張します。内部ベンチマークを通じて、Jake氏はbodyと属性値のインデックスに対して粒度32がパフォーマンスとインデックスサイズの良好なバランスを提供することを確認しました。

パーティショニングは、Jake氏の言葉を借りれば「非常にシンプル」で、日付単位で行い、60日のTTLとttl_only_drop_partsと組み合わせています。「これにより、パーティション全体を削除する際にかなり良好なパフォーマンスが得られます」と彼は述べています。

次はプライマリキーとORDER BYです。「ここが面白いところです」とJake氏は言います。Cleverはレコードを通常の時系列順ではなく、Unixタイムスタンプの負の値で並べて逆順に保存します。これによりClickHouseはデータをスキャンするのではなく、データの先頭で目的のものを見つけることができます。結果としてクエリ時間は8~10倍高速化しました。timestampカラムのminmaxインデックスは(Jake氏が指摘するようにプライマリキーがあると冗長に思えるかもしれませんが)、エンジニアがクエリを反転させなくても通常のタイムスタンプフィルタリングを正しく機能させるために必要なものです。

タイムスタンプは秒とミリ秒の両方の精度で保存されます。「秒単位のタイムスタンプでフィルタリングし、その範囲内でミリ秒を使って絞り込みます」と彼は説明します。「これにより、非常に良好なパフォーマンスと圧縮が得られます。」

最後に、CleverはClickHouse Cloudの設定cache_populated_by_fetchを有効にし、データが取り込まれるとレプリカ上のファイルシステムキャッシュを積極的に埋めるようにしています。これにより、どのレプリカがリクエストを処理してもクエリパフォーマンスが一貫することが保証されます。Jake氏はこう述べています。「あるレプリカへのSELECTクエリは、すべてのレプリカにわたって一貫した結果と一貫したパフォーマンスを持つべきです。」

システムのレジリエンスを維持する #

「オブザーバビリティはあらゆるシステムにおいて最も重要な部分の1つです」とJake氏は語ります。「つまり、障害に対して耐性があり、高可用性である必要があります。」彼はCleverの3つのレジリエンス要件について説明しました。本番環境と開発環境のログを分離すること、複数のリージョンに書き込むこと、そしてシステム全体をコードとして管理することです。

本番環境と開発環境のログを分離するのは、主に「競合を避ける」ためだと彼は言います。例えば、開発者が負荷テストを実行するとログ量が急増し、本番のロギングシステムをダウンさせる可能性があります。開発用のClickHouseサービスを別途用意することでそのリスクを排除し、本番に影響を与えることなくロギングパイプラインの変更を安全にテストできる環境をチームに提供します。

本番ログはリージョンに基づいて2つのClickHouseサービスに分割され、開発ログはさらに別のClickHouseサービスに保存されます。

Cleverは複数のAWSリージョンで運用されているため、チームはロギングシステムもマルチリージョンにしたいと考えました。これにより、Jake氏が言うように「us-east-1でClickHouseがダウンしたり接続の問題が発生したりしても、そのリージョンのすべてのログを失うわけではありません」。本番ログはリージョンと環境で分割されます。us-eastとus-westのClickHouse Cloudサービス、そして開発ログを処理する3つ目のサービスです。ClickHouseのremoteSecureテーブル関数とマージテーブルにより、2つの本番サービスは単一のクエリ可能なサーフェスとして統合され、読み取りは両リージョン間で負荷分散されます。

「ClickHouse Cloudのマルチリージョン可用性は、我々が必要としていた事業継続性と災害復旧を提供してくれます。障害が発生した場合、これらのサービスの1つだけにすべての読み取りや書き込みを停止・リダイレクトすることが容易にでき、はるかにレジリエントになります。」 — Jake Gutierrez氏、Cleverシニアソフトウェアエンジニア

Infrastructure-as-codeの要件は、システムを容易に再現可能にすることに関するものでした。すべてのClickHouseサービス、シークレット、KMSキーはTerraformでプロビジョニングされます。スキーマの変更はGooseによる増分SQLマイグレーションファイルで管理され、動的なリソース作成を必要とするもの(例えばリージョン間のサービスを接続するリモートテーブル)にはGoベースのマイグレーションで補完しています。「Go関数は認証情報を取得する際にも便利で、GitHubに平文パスワードを保存する必要がなくなります」とJake氏は言います。

ClickHouseをホームのように感じさせる #

Jake氏が取り上げた3つ目の領域はクエリ体験です。「エンジニアが急な学習曲線なしにこの新しいシステムに慣れやすいよう、Datadogに似たものを求めていました」とJake氏は言います。ClickHouseへの生のSQLアクセスは強力ですが、Cleverのエンジニアの多くは日常的にSQLを使いません。彼らはGrafanaに慣れており、それを使い続けたいと考えていましたが、公式のClickHouse Grafanaプラグインは彼らの非標準的なスキーマをサポートしていませんでした。

そこでCleverチームは独自のクエリレイヤーを構築しました。「Q-Layer」として知られるこのサービスは、GrafanaのLogQLのサブセットを実装し、それらのクエリを裏側でClickHouse SQLに変換します。エンジニアは使い慣れたDatadogライクな構文でクエリを書き、Q-Layerが翻訳を担当します。Jake氏が指摘するように、「より複雑なクエリはSQLで書くこともでき、エンジニアはいつでもLogQL実装の改善をリクエストできます」。プロジェクションがログボリュームチャートの高速カウントクエリを支え、マテリアライズドビューがログラベルのIntelliSense風の自動補完を実現します。

Jake氏の言葉を借りれば、その結果として、エンジニアが裏で何が動いているかを意識せずにクエリできるロギングシステムが完成しました。

200倍のログ、コスト増加0% #

ClickHouseの導入により、Cleverは月間150 TBのログに対して10倍の圧縮率を実現しました。そしてDatadogがログの10%しかインデックスしていなかったのに対し、ClickHouseはそのすべてをインデックスしており、検索可能なログ量は200倍に増加しました。

「ClickHouseにより、圧縮率10倍、インデックスされたログが200倍に増加しました。これらのログはすべてのエンジニアが容易にアクセスでき、Grafana、Athena、Datadogなどのどれを使うかを考える必要がありません。そしてこれらすべてがコスト増加0%で実現されました。」 — Jake Gutierrez氏、Cleverシニアソフトウェアエンジニア

同様のものを構築しようと考えている人へのJake氏のアドバイスはシンプルです。とにかく始めることです。「ClickHouseをローカルで立ち上げて、自分で試してみてください」と彼は言います。「ランダムなレコードをテーブルに挿入したり、ログをClickHouseクラスタにバックフィルするだけでも、私にとって大いに役立ちました。」Jake氏はまた、最初は両方のシステムを並行して運用することも推奨しています。「これによって、既存のものから確実にステップアップしたシステムに移行できることが保証されました」と彼は言います。

Cleverは構造化JSONログに合わせたカスタムスキーマを構築しましたが、すべてのチームがゼロから始める必要はありません。OpenTelemetryを使用しているチームには、ClickStackが最適化されたスキーマを標準で提供しており、1日あたり数十テラバイト規模のオブザーバビリティワークロードを処理できるよう設計されています。頻繁にクエリされるフィールドの抽出、データスキッピングインデックスの使用、一般的なアクセスパターンに合わせたソート順の最適化など、Cleverが採用した多くのテクニックは、より大規模なデプロイメント向けにClickStackをチューニングする際にも推奨される原則と同じものです。