Uken Games が ClickHouse でオブザーバビリティのコストを 87% 削減した方法

数百万人のプレイヤーに向けてゲームを作り、世界最大級のブランドと提携しているなら、何よりも重要な問いが 1 つあります。プレイヤーが楽しんでいるかどうかを、どうやって知るのか、という問いです。

Uken Games はトロントに拠点を置く独立系ゲームスタジオです。2009 年の創業以来、Sony Pictures や Apple といった企業と提携し、Tim Hortons のアプリに組み込まれたモバイルゲームを開発し、あるゲームをゲーム開発会社の Jam City に 1 億ドルで売却しました。

このゲームスタジオの成功は、プレイヤーを飽きさせないことだけでなく、その行動を観測して理解する力にかかっています。それができなければ、プレイヤーは離れて競合へ移ってしまいます。2026年6月にトロントで開催された ClickHouse ミートアップでは、当時 Uken のソフトウェア開発者だった Alexei Zenin 氏が、この問いにどう答え、何を収集するかをどう決めているかを語りました。

Alexei 氏はオブザーバビリティを 2 つの層に分けています。上の層は、ゲームが楽しいかどうかを明らかにするプロダクト分析です。日次アクティブユーザー、クリアしたレベル数、アプリ内課金、セッション時間、リテンションなどが含まれます。その下にあるのが、氏が「技術的オブザーバビリティ」と呼ぶ土台です。CPU、RAM、レイテンシ、エラーといった、仕組みそのものが動いていることを確かめるためのシグナルです。

Uken は内部で、クラウドセーブやインベントリからプッシュ通知、リーダーボードまで幅広いサービスを運用しています。「リーダーボードで 1 位になろうと、みんな熱心に競い合います」と Alexei 氏は言います。「24 時間 365 日、『誰かが不正をしている、私が 1 位のはずだ』という『サポートチケット』を送ってきます。そして何より重要なのは、そうしたプレイヤーは課金ユーザーである可能性が高いことです」。こうした場面では、誰が正しいかを証明できるテレメトリの価値は非常に大きいのです。

しかし、その規模の運用を監視するにはコストがかかります。私たちは Alexei 氏に、Uken が Datadog から離れた理由と、オブザーバビリティスタックを ClickHouse 上に作り直したことで年間コストを 87% 削減できた経緯を聞きました。

ベンダーロックインという課題 #

Uken は長年、300 のコンテナ、50 台以上の EC2 マシン、100 以上のディスク、数十のデータベース、100 以上のサービスデプロイメントからなるインフラを Datadog で監視してきました。Alexei 氏は「うまく動いてはいましたが、どれだけ削減に努めても、コストは必ず持続不可能な水準まで戻ってしまいました」と語ります。

Uken の旧スタック。ログは CloudWatch へ送り、トレースとメトリクスは Datadog エージェント経由でルーティングしていました。

複雑な料金体系の例として、氏は Datadog のコンテナ料金を挙げます。コンテナ 1 つにつき 1 時間あたり 0.002 ドルが追加で課金され、1 つあたり月額 1 ドルで前払いする選択肢もありました。一方で、プロプライエタリな Datadog エージェントは Uken のシステムに深く組み込まれており、Alexei 氏によれば、主導権はすべてベンダー側にありました。たとえば Datadog の料金モデルは、アーキテクチャの意思決定にまで影響し始めました。サーバーレスと EC2 のように、監視する技術によって料金が大きく変わるためです。

ClickHouse を中心に据えた新しいスタック #

Uken Games のチームは「Datadog を出して、オープンソースを入れる」という方針に決めました。新システムの目標は 3 つです。コストを下げること、オープンソース寄りでありながら柔軟なアーキテクチャにすること、そしてオブザーバビリティの 3 本柱であるメトリクス、トレース、ログについて、実用上は同等と言える機能をそろえることです。

新システムのデータプレーンは OpenTelemetry です。Alexei 氏はこれをオブザーバビリティの「新しいデファクトスタンダード」と呼びます。「要するに、さまざまなシグナルを収集して、標準化されたベンダー非依存の形で定義できるのです」と氏は言います。「OpenTelemetry が標準であり、特定のデータベースに書き込む必要はありません。それはパイプラインの後段で決めることであり、自分たちで制御できます。ベンダーロックインはもうありません。ClickHouse はオープンソースに根ざしているので、この考え方をよく補完してくれます」。

収集は OTel コレクター(YAML で設定する単体の Go プロセス)が担い、2 層構成でデプロイされています。各 ECS インスタンスでは、マイクロサービスと並んで軽量なエージェントが動きます。アプリケーションは各トレースを localhost への高速な呼び出しでこのエージェントに渡し、エージェントは事前フィルタリングを適用したうえでゲートウェイ層へ転送します。ゲートウェイ層は自動スケールし、ClickHouse への書き込みをバッチ化してバッファリングします。この分割により、エッジ側の計測は軽く済みます。ローカルへの高速な受け渡しで、動いているアプリケーションにはほとんど負荷をかけません。一方、スケーリングとバッファリングという重い処理は 1 か所に集約され、チームはそこを独立してチューニングできます。

トレースは SigNoz を介して ClickHouse に書き込まれます。SigNoz は ClickHouse 上に構築されたオープンソースの APM ツールです。「Datadog で得ていたものとまったく同じ感触と使い勝手を得られました」と Alexei 氏は言います。「SigNoz のツールに入って『これは決済サービスだから、こういうグラフを見せて』と指定する必要はありませんでした。エラー率、P90、秒間リクエスト数といった定番のものは、すべてテレメトリから自動的に推定されました」。

Uken のトレースパイプライン。各 ECS インスタンス上のエージェントコレクターが、負荷分散された OTel ゲートウェイ層にデータを送り、ゲートウェイ層が単一の ClickHouse ノードに書き込みます。その上に SigNoz が載っています。

Alexei 氏が本当に感心したのは、その下にあるデータベースでした。会社が生成するすべてのトレースを、単一の ClickHouse ノードが受け止めています。「やったのは ClickHouse を起動することだけで、それでそのまま動きました。そこが気に入りました」と Alexei 氏は言います。「他に再設計して構築しなければならないものが山ほどありました。これほど簡単に動いたこと自体が、その性能と背後にあるエンジニアリングを物語っています」。

メトリクスは同じコレクターのパターンで AWS マネージドの Prometheus に送られます。これは意図的な選択です。Uken は自前で構築したもののオンコールは自分たちで担うことになりますし、Prometheus というオープンな標準に乗っていれば、AWS の料金が上がったときにいつでも離れられるからです。ログは CloudWatch に残しています。Alexei 氏は「ログは最大のコスト要因ではないことがわかり、作り直すエンジニアリングの労力に見合わないと判断しました」と言います。最後に Grafana が全体をつなぎ、メトリクスをクエリして Slack と PagerDuty にアラートを送るところまでを担っています。

Uken のチームはアラート自体も自動化し、カスタム CloudFormation リソースを書いて、アラートを完全にコードでプロビジョニングできるようにしました。Grafana を手作業でクリックして回るのではなく、エンジニアが YAML でアラートを定義してプルリクエストを開き、マージされると Jenkins が CloudFormation スタックをデプロイし、そのスタックが Grafana の API 経由でアラートをプロビジョニングします。「ボタン 1 つで何百ものアラートを作成できます」と Alexei 氏は言います。Grafana は現在、ClickHouse、CloudWatch、Prometheus に対して毎分およそ 600 のクエリを実行し、警告は Slack へ、午前 3 時の緊急事態は PagerDuty へエスカレーションしています。

Uken のアラート層。Grafana が ClickHouse、CloudWatch、マネージド Prometheus にクエリを実行し、Slack と PagerDuty へエスカレーションします。アラートは CloudFormation を通じてコードとして定義されています。

道中で得た教訓 #

Uken のチームにとって、この移行は無駄を削らざるを得ない機会にもなりました。Alexei 氏によれば、チームは収集しているメトリクスと属性の 95% を使っていません。氏はこう付け加えます。「学んだことをすべて要約するなら、『そんなものは必要にならない』です。とにかく削れるものはできる限り削ってください」。

トレースについても同様に見直しました。「成功したトレースを本当に 1 つ残らず取る必要があるでしょうか」と Alexei 氏は問います。「それとも、5〜10% のような統計的に代表となるサンプルだけで十分でしょうか」。最終的に採用した方針は、重要なトレース(たとえばエラーや高レイテンシのリクエスト)は残し、残りは代表的なサンプルを取り、ノイズは捨てるというものです。盲点を作らないよう、アラートはサンプリングなしで計算した集計メトリクスに基づいています。そのため、データを削ってもシグナルが鈍ることはありません。

過剰なエンジニアリングも避けました。「人間が何かをデバッグしようとしているなら、ダッシュボードの読み込みにミリ秒単位の応答時間は本当のところ必要ありません」と Alexei 氏は言います。また、データを何年も保持する規制上の理由はなかったため、保持期間を 2 週間に制限しました。「これもコスト削減に役立ちました」と氏は付け加えます。

結果: ClickHouse ノード 1 台、コストは 87% 減 #

現在、Uken のすべてのトレースは、約 170 GB のディスクを使う単一の ClickHouse ノードに収まっており、複数の OTel コレクターからデータが送られています。そして、新システムを展開する間、ダウンタイムはゼロでした。世界中に数百万人のプレイヤーを抱えるライブサービスにとって、これは小さくない成果です。

「私たちは実用上は同等と言える機能をそろえました。こうしたメトリクスとトレースをすべて探索し、可視化し、収集しながら、ビデオゲームをきちんと動かし続けられています」と Alexei 氏は語ります。「私たちが構築したオープンソースソリューションの運用費は年間およそ 12,000 ドルにすぎないと、誇りを持って言えます」と氏は続けます。「つまり、コストはほぼ 1 桁下がりました」。削減幅が 87% 近くと非常に大きかったため、エンジニアリングの投資は 2 年足らずで回収できました。Datadog とほぼ同等の機能をわずかな価格で得たことに加え、Uken は今ではインフラを完全に自分たちで制御し、ベンダーロックインを避け、将来のニーズに合わせてシステムを発展させていけます。

オープンソースのオブザーバビリティを選ぶ理由 #

Alexei 氏は講演の締めくくりで、特定のスタックよりも進む方向のほうが重要だと述べました。ClickHouse は「大量のデータがあってそれを素早く分析したいときに、いつでも頼れるツール」だと氏は言います。Uken のようなハイブリッドなアーキテクチャで使う場合でも、ClickStack のようなオールインワンのオープンソースプロジェクトを通じて使う場合でも同じです。ClickStack について氏は「セットアップも運用も本当に簡単」と評しています。

氏が強調したのは、オープンソースのオブザーバビリティツールが、妥協ではなく真剣に検討すべき既定の選択肢と言えるところまで成熟した、という点です。「業界として、ベンダーから主導権を取り戻す方法を考え始める時期です」と氏は言います。「そして、自分たちが書くコードへの信頼を自信を持って築けるよう、オープンソースのツールをもっと積極的に受け入れていくべきです」。