> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 教訓 - 独創的なユースケース

> 遅いクエリ、メモリエラー、接続の問題、設定の問題など、ClickHouseでよくある問題に対する解決策を見つけましょう。

*このガイドは、コミュニティミートアップで得られた知見をまとめたシリーズの一部です。実運用に役立つ解決策や知見をさらに知りたい場合は、[問題別に参照](/docs/ja/resources/support-center/tips-and-tricks/community-wisdom)できます。*
*本番環境での問題をデバッグするためのヒントが必要ですか？コミュニティガイドの[Debugging Insights](/docs/ja/resources/support-center/tips-and-tricks/debugging-insights)をご覧ください。*

これらの事例では、各社がそれぞれのユースケースでClickHouseを活用し、どのように成果を上げたかを紹介します。中には、従来のデータベース分類にとらわれず、ときに「不向き」と思われるツールこそが、実は最適な解決策になることを示す例もあります。

<div id="clickhouse-rate-limiter">
  ## レートリミッターとしての ClickHouse
</div>

Craigslist がユーザーを保護するために最上位のレート制限を導入する必要に迫られたとき、彼らはあらゆるエンジニアリングチームが直面するのと同じ判断を迫られました。定石どおり Redis を使うのか、それとも別の方法を模索するのか、ということです。Craigslist の Brad Lhotsky は、Redis が標準的な選択肢であることを理解していました。実際、オンライン上のレート制限に関するチュートリアルや例のほとんどが、もっともな理由から Redis を使っています。Redis にはレート制限処理に必要な豊富な基本機能があり、確立されたパターンと実績もあります。しかし、Craigslist の Redis 運用経験は、教科書どおりのものではありませんでした。*「Redis の運用は、映画で見るような話とは違います……Redis クラスターのノードを再起動するとフロントエンドでレイテンシのスパイクが起きるなど、厄介なメンテナンス上の問題に何度もぶつかりました。」* メンテナンスの簡潔さを重視する小規模チームにとって、こうした運用上の悩みは深刻な問題になっていました。

そこで Brad は、レート制限の要件を持ちかけられたとき、別のアプローチを取りました。*「上司にこう聞いたんです。『このアイデア、どう思いますか？ ClickHouse で試してみてもいいかもしれません』と。」* この発想は型破りでした。通常はキャッシュ層の問題として扱われるものに、分析データベースを使うというものです。しかしこれは、障害時には fail open にすること、レイテンシのペナルティを生じさせないこと、そして小規模チームでも無理なく保守できること、という中核要件に合致していました。この解決策では、アクセスログがすでに Kafka 経由で ClickHouse に流れている既存のインフラストラクチャを活用しました。別途 Redis クラスターを維持する代わりに、アクセスログのデータからリクエストパターンを直接分析し、既存の ACL API にレート制限ルールを組み込めたのです。このアプローチでは Redis よりレイテンシはやや高くなりました。Redis は、*「リアルタイムの集計クエリを実行するのではなく、そのデータセットを事前に用意しているという意味で、ある種ずるをしている」* からです。それでもクエリは 100 ミリ秒未満で完了しました。

**主な結果:**

* Redis インフラストラクチャと比べて大幅に改善
* 組み込みの有効期限 (TTL) による自動クリーンアップで、メンテナンス負荷を解消
* SQL の柔軟性により、単純なカウンターを超える複雑なレート制限ルールを実現
* 別個のインフラストラクチャを必要とせず、既存のデータパイプラインを活用

<div id="customer-analytics">
  ## 顧客分析向け ClickHouse
</div>

ServiceNow がモバイル分析プラットフォームの刷新を検討したとき、直面した問いはシンプルでした。*"うまく動いているものを、なぜ置き換えるのか？"* ServiceNow の Amir Vaza 氏は、既存システムが信頼性の高いものだと認識していましたが、顧客の要求はその対応力を超えつつありました。*"既存の信頼できるモデルを置き換える動機は、実はプロダクト側から生まれたものです"* と Amir 氏は説明します。ServiceNow は Web、モバイル、チャットボット向けソリューションの一部としてモバイル分析を提供していましたが、顧客は事前に集計されたデータの枠を超える、より柔軟な分析を求めていました。

以前のシステムでは、アプリケーション、アプリのバージョン、プラットフォームといった固定の次元ごとに分けた事前集計データを、約 30 種類の異なるテーブルで扱っていました。顧客が送信できるカスタムプロパティ (キー・バリューのペア) については、グループごとに個別のカウンターを作成していました。このアプローチによりダッシュボードは高速に表示できましたが、大きな制約もありました。*"これは値の内訳をすばやく確認するには非常に優れていますが、その一方で分析コンテキストが大きく失われてしまいます"* と Amir 氏は指摘します。顧客は複雑なカスタマージャーニー分析を行えず、たとえば「検索語 'research RSA token' で開始されたセッションはいくつあるか」といった問いを立てたうえで、その後にそのユーザーたちが何をしたかを分析することもできませんでした。事前集計された構造では、複数ステップの分析に必要な時系列のコンテキストが失われてしまい、新たな分析次元が必要になるたびに、事前集計して保存するためのエンジニアリング作業が発生していました。

こうした制約が明確になると、ServiceNow は ClickHouse へ移行し、こうした事前計算の制約を完全になくしました。あらゆる変数をあらかじめ計算する代わりに、メタデータをデータポイントに分解し、すべてを ClickHouse に直接挿入するようにしました。データを効率的にインジェストするために、Amir 氏が *"本当にすばらしい"* と評した ClickHouse の非同期 INSERT キューも活用しました。このアプローチにより、顧客は任意の次元で独自のセグメントを作成し、データを自由に切り分けられるようになり、以前は不可能だった複雑なカスタマージャーニー分析も実行できるようになりました。

**主な成果:**

* 事前計算なしで、任意の次元にまたがる動的なセグメンテーションを実現
* 複雑なカスタマージャーニー分析が可能に
* 顧客が独自のセグメントを作成し、データを自由に切り分け可能に
* 新たな分析要件のたびに発生していたエンジニアリングのボトルネックを解消

<div id="video-sources">
  ## 関連ビデオ
</div>

* **[常識を打ち破る — ClickHouseでレートリミッターを構築する](https://www.youtube.com/watch?v=wRwqrbUjRe4)** - Brad Lhotsky (Craigslist)
* **[ServiceNowにおける分析基盤としてのClickHouse](https://www.youtube.com/watch?v=b4Pmpx3iRK4)** - Amir Vaza (ServiceNow)

*これらの事例は、従来のデータベースの常識に疑問を投げかけることで、分析データベースの可能性を塗り替える画期的なソリューションが生まれることを示しています。*