成功事例
このガイドは、コミュニティミートアップから得られた知見をまとめたコレクションの一部です。より多くの実践的なソリューションやインサイトについては、問題ごとに絞り込んで閲覧できます。 本番環境で発生した問題をデバッグするためのヒントが必要ですか？Debugging Insights コミュニティガイドを参照してください。
ここで紹介する事例は、企業が自社のユースケースで ClickHouse を活用して成功を収めた方法を示しており、中には従来のデータベースカテゴリの枠組みに挑戦し、「間違った」ツールが実は最適なソリューションになり得ることを証明しているものもあります。
レートリミッターとしての ClickHouse
Craigslist がユーザーを保護するために Tier 1 のレート制限を追加する必要に迫られたとき、彼らはあらゆるエンジニアリングチームが直面するのと同じ選択を迫られました ―― 定石どおり Redis を使うか、それとも別の選択肢を探るかです。Craigslist に所属していた Brad Lhotsky は、Redis が標準的な選択肢であることを理解していました ―― 実際、ほとんどすべてのレート制限に関するチュートリアルやオンラインのサンプルが、もっともな理由から Redis を採用しています。レート制限処理向けの豊富なプリミティブがあり、よく確立されたパターンと実績があります。しかし、Craigslist における Redis の運用経験は、教科書どおりとはいきませんでした。「私たちの Redis の経験は、皆さんが映画で見ているようなものとは違います…… Redis クラスター内のノードを再起動すると、フロントエンド側でレイテンシスパイクが発生するなど、変なメンテナンス問題にたくさん遭遇しました。」 メンテナンスの単純さを重視する少人数チームにとって、これらの運用上の頭痛のタネは深刻な問題になりつつありました。
そこで Brad がレート制限の要件について相談を受けたとき、彼は別のアプローチを取りました。「上司に『このアイデアについてどう思いますか？ ClickHouse で試してみるのはどうでしょう？』と聞いたんです。」 そのアイデアは一般的なやり方から外れたものでした ―― 通常はキャッシュレイヤーで扱う問題に対して分析用データベースを使うというものです ―― しかし、Craigslist の中核要件には合致していました。すなわち、フェイルオープンであること、レイテンシのペナルティを課さないこと、そして小規模チームでもメンテナンス面で安全に運用できることです。このソリューションは、既存インフラストラクチャを活用しました。アクセスログはすでに Kafka 経由で ClickHouse に流し込まれていました。別途 Redis クラスターを運用する代わりに、アクセスログデータから直接リクエストパターンを分析し、既存の ACL API にレート制限ルールを注入できるようにしたのです。このアプローチは、Redis よりわずかに高いレイテンシになります。Redis は 「実際には、そのデータセットをあらかじめインスタンス化しておくという、ある意味反則的なやり方をしている」 ためリアルタイムの集計クエリではありませんが、それでもクエリは 100 ミリ秒未満で完了していました。
主な成果:
- Redis ベースのインフラストラクチャと比較して劇的に改善
- 自動クリーンアップのための TTL を標準で備えており、メンテナンス負荷を解消
- SQL の柔軟性により、単純なカウンターを超えた複雑なレート制限ルールを実現
- 別個のインフラを追加することなく、既存のデータパイプラインを活用
顧客分析のための ClickHouse
ServiceNow がモバイル分析プラットフォームのアップグレードを検討した際、直面したのはきわめてシンプルな問いでした。「問題なく動いているものを、なぜ置き換える必要があるのか？」 ServiceNow の Amir Vaza 氏は、既存システムが信頼できることは理解していましたが、顧客からの要求はすでにその処理能力を超えつつありました。「既存の信頼性の高いモデルを置き換える動機は、実はプロダクト側の要請から生まれてくるものです」 と Amir 氏は説明します。ServiceNow は、Web、モバイル、チャットボット向けソリューションの一部としてモバイル分析を提供していましたが、顧客は事前集計済みデータを超えた、より柔軟な分析機能を求めていました。
従来のシステムでは、事前に集計されたデータを基に、アプリケーション、アプリバージョン、プラットフォームといった固定ディメンションで区切られた約 30 個のテーブルを使用していました。顧客が送信できるカスタムプロパティ（キーと値のペア）については、グループごとに個別のカウンタを作成して対応していました。この方式によってダッシュボードの表示は高速でしたが、大きな制約がありました。「素早く値を分解して確認できるという点では優れているものの、この制約によって分析上の多くのコンテキストが失われてしまうと先ほどお話ししました」 と Amir 氏は指摘します。顧客は複雑なカスタマージャーニー分析を行ったり、「『research RSA token』という検索語で始まったセッションがいくつあり、そのユーザーがその後何をしたか」といった質問を投げかけたりすることができませんでした。事前集計された構造によって、多段階の分析に必要なシーケンシャルなコンテキストが失われてしまい、新しい分析ディメンションを追加するたびに、事前集計と保存のためのエンジニアリング作業が必要になっていたのです。
こうした制約が明確になったタイミングで、ServiceNow は ClickHouse へ移行し、これらの事前計算の制約を完全に取り除きました。あらゆる変数をあらかじめ計算しておくのではなく、メタデータをデータポイントへと分解し、すべてを直接 ClickHouse に挿入するようにしました。彼らは ClickHouse の async insert queue を使用して効率的にデータを取り込んでおり、Amir 氏はこれを 「本当に素晴らしいものだ」 と表現しています。このアプローチにより、顧客は自分たちでセグメントを作成し、任意のディメンションで自由にデータを切り分け、従来は不可能だった複雑なカスタマージャーニー分析を実行できるようになりました。
主な成果:
- 事前計算なしで、任意のディメンションにわたる動的なセグメンテーションが可能に
- 複雑なカスタマージャーニー分析が実現
- 顧客自身がセグメントを作成し、自由にデータを切り分け可能に
- 新たな分析要件に対するエンジニアリングのボトルネックを排除
動画リソース
- Breaking the Rules - Building a Rate Limiter with ClickHouse - Brad Lhotsky (Craigslist)
- ClickHouse as an Analytical Solution in ServiceNow - Amir Vaza (ServiceNow)
これらの事例は、従来のデータベースに関する常識に疑問を投げかけることで、分析用データベースで何が可能かという範囲を塗り替える画期的なソリューションが生まれ得ることを示しています。
