Appcues が ClickHouse Cloud でパーソナライズされた顧客エンゲージメントを実現

Appcues は、SaaS 企業が顧客エンゲージメントを高めて成長を促進できるよう支援するプラットフォームです。顧客のプロダクト内に組み込まれ、オンボーディングフロー、ツールチップ、チェックリスト、バナー、メール、プッシュ通知といった機能を支えています。顧客は SDK、Segment ストリーム、CRM、公開 API から Appcues へデータを送信しており、エンジニアリング担当 VP の Chris Brookins 氏が語るように、Appcues は顧客企業が「適切なタイミングで、適切な顧客に、適切な体験を届ける」ことを支援しています。

現在、Appcues は 1.31 PB のデータを管理し、4,100 億件のイベントを処理し、10 億件を超えるユーザープロファイルを継続的に更新しています。「あらゆるアプリから膨大なデータを取り込んでおり、提供すべきオブザーバビリティも多岐にわたります」と Chris 氏は話します。そのデータの多くは Appcues Studio に表示され、顧客はパフォーマンスや成果を追跡できます。

「10 億件を超えるユーザープロファイルに対し、これらすべての情報を集約して迅速に届けることが極めて重要です。ページの読み込み時間は実質的に一瞬でなければなりません」

— Chris Brookins 氏(Appcues、エンジニアリング担当 VP)

Appcues は長年にわたり、Airflow や Snowflake などのスタックでアナリティクスプラットフォームを運用していました。Snowflake は依然として BI やレポート作成に強力なソリューションですが、顧客からの期待が高まり続けるリアルタイムなプロダクトアナリティクス体験を提供するには、別のアプローチが必要でした。ボストンで開催されたミートアップで、Chris 氏は AWS 上の ClickHouse Cloud へと至った道のりを共有してくれました。

快適なプロダクト体験を提供する上での課題 #

創業当初から、このプラットフォームは主に 2 つのデータベースで運用されていました。DynamoDB は、次のページ読み込み前にどの体験を表示すべきかを Appcues が判断できるよう、リアルタイムの訪問者をセグメントに照合するサブ秒単位の処理を担当しました。Snowflake は、ダッシュボード、パフォーマンスグラフ、NPS の結果、そして提供した体験が実際に効果を上げているかを顧客が確認するためのレポート機能など、アナリティクス全般を支えていました。

「私たちの目的は、顧客に快適なプロダクト体験を届けることです」と Chris 氏は言います。しかし、Appcues がスケールして取り込むデータが増え続けるにつれて、クエリ時間は最大 20 秒にまで延び、コストの管理も課題となりました。以前のスタックは、大規模環境における低レイテンシなアナリティクスを想定したものではなかったからです。

クエリ速度を上げるため、Appcues は Airflow に頼っていました。5〜10 分ごとにジョブがデータを集約・事前処理し、書き戻す仕組みです。これによって求められるプロダクト体験は実現できたものの、コストが増加し、増え続けるジョブとサーバーのネットワークを維持管理する必要が生じました。またこの構成では、顧客は 10 分単位のデータしか確認できませんでした。

チームがメール機能の導入を決定した際、Chris 氏のチームは、リアルタイムアナリティクスにおいて高いパフォーマンスを発揮し、かつコスト効率に優れた新しいソリューションが必要だと認識しました。「それはまったく新しいチャネルであり、あらゆる新しいイベントや追加のセグメンテーション要件を伴うものでした」と Chris 氏は振り返ります。従来、Appcues は「このユーザーはどのセグメントに属しているか？」という直接的かつリアルタイムな問いに答えるよう最適化されていました。しかしメール機能では、顧客あたり数百に及ぶセグメントにわたって、過去の行動に基づく複雑な条件や「過去 30 日間アクセスがない」といった否定論理も含め、「セグメント内のすべてのユーザー」を極めて高速に算出する必要がありました。

ClickHouse の検証 #

チームはまず、必須要件のリスト作成から着手しました。小規模なチームであるため、運用オーバーヘッドは最小限に抑えたいと考えていました。また、透明性と選択肢の確保のためにオープンソースエンジンを求めていました。以前のクラウドデータウェアハウスでの経験から、大規模環境におけるコスト効率は最優先事項でした。さらに、HIPAA に準拠したワークロードと、将来的な EU データセンターリージョンをサポートしていることも必須条件でした。「要件は山積みでした」と Chris 氏は振り返ります。「可能な限りあらゆる負荷テストを行いたいと考えました」。同氏はプリンシパルエンジニアの Andy LeClair 氏を ClickHouse のミートアップに参加させて情報収集を行い、そこでの議論が評価計画の出発点となりました。

最初のステップは、Snowflake のすべてのデータを S3 の Parquet にエクスポートし、ClickHouse にロードすることでした。また、プラットフォームが大量の個人識別情報を保存しているため、Appcues は顧客に対し、ClickHouse を新たな再委託先(sub-processor)として利用することを通知しました。

概念実証(PoC)では、メールのセグメンテーション課題に焦点を当てました。「これらのセグメントの多くは非常に複雑でした」と Chris 氏は説明します。「AND/OR 条件やネストされた条件があり、他のユーザーセグメントや、『過去 3 か月間にこのイベントが発生したことがあるか？』といった過去のイベントを参照することもありました。実に骨の折れる作業でした」。

並行して、チームは本番環境向けの基盤構築を開始しました。Kafka 経由でイベントが新たなコンシューマーである「clickwriter」に送られ、軽微な重複排除と高速な挿入が行われます。アプリケーション側では、セグメントロジックが Elixir の Ecto 上に構築された「clickclient」ライブラリとして形式化され、複雑な ClickHouse クエリを一元的に制御しながら生成できるようになりました。

以前のデータウェアハウスと ClickHouse の双方をテストし、各プラットフォームを限界までチューニングしました。ClickHouse の場合、SharedReplacingMergeTree などの機能が「パフォーマンスの向上に極めて大きな効果」をもたらしたと Chris 氏は語ります。

最終的な結果は明白でした。ClickHouse はセグメントクエリを 73% 高速に実行しました。

「以前のクラウドデータウェアハウスをどれほどチューニングしても、ClickHouse のほうが高速でした。『よし、これでいこう』となりました」

— Chris Brookins 氏(Appcues、エンジニアリング担当 VP)

ClickHouse Cloud への移行 #

そこからプロジェクトは、1 年間にわたる稼働中の移行へと移行しました。「飛行機が飛んでいる最中に作業を進めているようなものでした」と Chris 氏は言います。「プロジェクト全体を通じて正確性を確保しなければなりませんでした」。

履歴データはすでに ClickHouse にロードされていたため、次のフェーズは検証と改善を着実に繰り返すことでした。チームはスキーマを改良し、ClickHouse が求めるデータモデリング手法を学び、ClickHouse チームと緊密に連携しながら適切なテーブルエンジンやマテリアライズドビューを選定しました。「この移行を通じて、優れたベストプラクティスを数多く学びました。ClickHouse へ移行したことで、データ管理における確固たる規律が身につきました」と Chris 氏は語ります。

Appcues のデータは決して均一ではないため、その規律は重要でした。「顧客からはあらゆるデータが送られてきます。単なるキー・バリューのペアなのです」と Chris 氏は言います。レポート機能は、小規模なスタートアップから大企業まで、顧客ごとに大きく異なるデータ構造に対応する必要がありました。チームはアカウント全体で継続的にテストを実施し、エッジケースを用いてシステムへ負荷をかけ、広く一般公開する前に十分な検証を行いました。

確信が深まるにつれ、ClickHouse Cloud の本格的な運用化に着手しました。異なるワークロードを適切な規模のサービスへ分離し、オートスケーリングルールを調整しながら、安定するまで試行錯誤を繰り返しました。そして安定稼働を確認した上で、顧客を段階的に移行していきました。

特にエンタープライズの顧客にとって、その違いは歴然でした。「以前の構成では完了までに 1 週間かかっていたクエリや、実行すらできなかった処理がありました」と Chris 氏は語ります。「最大手の顧客にも大変喜んでいただいています」。

Appcues の新しい ClickHouse ベースの構成 #

Chris がボストンの登壇に立つ頃には、Appcues のアナリティクスシステムは大きく様変わりしていました。大まかに言えば、ノイズの多いキーバリューストリームを受け取り、製品がユーザーや体験を把握する実際の要件に合った、高速にクエリ可能なテーブルへと変換する仕組みになっています。

すべてのイベントは Kafka を経由して Appcues の「clickwriter」コンシューマーに送られ、そこで軽い重複排除が行われた後に ClickHouse へ挿入されます。そこからデータは主に 2 つの系統に分かれます。1 つは、顧客のワークフローに紐づくインプレッション、完了、アンケート、成果などの「体験アナリティクス」、もう 1 つは、クリーンな最新状態のビューへと集約する必要があるプロパティ更新ストリームから構築される「ユーザーおよびグループのプロファイル」です。

デプロイモデルには、Appcues の規模とコンプライアンス要件が反映されています。メインの ClickHouse ウェアハウスでは 5 つのサービスが稼働し、それぞれ 2〜3 台、合計 13 台のレプリカで構成されています。これらのサービスは、Chris が「ClickHouse の非常に高速なスケールアップとスケールダウン」と呼ぶ機能を活かし、通常時は 16 GB メモリ・4 vCPU の控えめなインスタンスから、ピーク時には 1 TB 以上の RAM と数百コアを備えたマシンへと拡大し、その後スケールダウンしてコストを抑えています。また、HIPAA 対応の顧客向けには、完全に分離された別のウェアハウスを用意しています。

この仕組みを大規模に機能させる鍵となったのが マテリアライズドビュー です。かつて Airflow が数分おきにデータをロールアップしていたのに対し、現在は ClickHouse が挿入時にカウントや合計値を事前計算しています。「これにより、すべてのクエリが劇的に改善されました」と Chris は語ります。「Airflow のインフラを全廃でき、そこにかかっていたすべてのコスト、そして何よりもすべてのレイテンシを排除できました」

プロファイルデータの設計の中核を担うのが SharedReplacingMergeTree です。更新はイベントとして届き、ClickHouse がそれらをフラット化されたプロファイルテーブルへと集約します。重要な最適化の 1 つは、FINAL を 使わない タイミングを見極めることでした。「これらすべてをリアルタイムに行い、処理速度を一切落とさないようにしようとしていました」と Chris は振り返ります。「代わりに argMax を使うことで、システムの負荷を抑えつつ、最小限のオーバーヘッドで最新のユーザープロファイルを取得できることがわかりました」

プロジェクトの終盤に、最後の難題が浮上しました。それがデータ削除です。Appcues は GDPR やテストデータ削除用のセルフサービス API を提供しており、一部の顧客からは継続的に削除リクエストが送られてきます。従来の削除処理では負荷の高いバックグラウンドマージが発生し、データ量が増加するにつれて、GDPR の 30 日間という削除期限が迫る中でバックログが膨らみ続ける事態に直面しました。

その解決策となったのが、ClickHouse 25.6 と 軽量削除 (lightweight deletes) の導入でした。「軽量パッチパートのメカニズムのおかげで、これらの削除を瞬時に処理できるようになりました」と Chris は語ります。「大きな課題を一気に乗り越えることができました。本当に素晴らしい機能でした」

クエリの高速化、データの鮮度向上、コスト削減 #

以前は、P95 のクエリ時間は約 20 秒でした。ClickHouse への移行後は、システム上により多くのワークロードや機能を追加したにもかかわらず、P95 は 2 秒未満へと 90% 改善しました。Chris によれば、P99 や最大レイテンシでさえ「それほど高くなく、非常に妥当な範囲に収まっている」とのことです。

取り込みレイテンシの改善はさらに目覚ましいものがあります。以前は Airflow によるロールアップ処理のため、新しいイベントがレポートに反映されるまでに 10 分以上かかることもありました。しかし ClickHouse では、それが約 5 秒にまで短縮されました。「イベントがサーバーに到達した瞬間から、ClickHouse で結果をクエリできるようになるまでの時間が 99% 短縮されました」と Chris は述べています。

一方、機能を拡張したにもかかわらずコストは大幅に削減されました。新たなセグメンテーションやメール配信のワークロードを ClickHouse に集約し、アナリティクススタック全体を 23% 削減したことで、利用量の増加に応じたコストの変動も予測しやすくなりました。

その理由の一端は、クラウドデータウェアハウスのコンピュート課金体系 や 実行・スケーリングモデルの違いが性能あたりのコストにどう影響するか という基本的な経済性にあります。プロビジョニング型の「ウェアハウス」モデルでは、性能や同時実行数をスケールさせると、それに比例して課金メーターも跳ね上がることが珍しくありません。ClickHouse Cloud により、Appcues は実際のワークロードに合わせてコンピュートを柔軟にサイジングし、オートスケールさせることが可能になりました。

Chris と Appcues のチームにとって、これは始まりに過ぎません。「ここで立ち止まるつもりはありませんでした」と彼は語ります。「単に既存環境と同等の機能を実現するだけのプロジェクトではなかったのです」。チームはすでにプラットフォームのさらなる拡張に着手しており、ClickHouse の ウィンドウ関数 を活用してユーザーがワークフローやメッセージングパイプラインをどのように進んでいるかを可視化する、新しいファネルレポートをリリースしました。さらに、AI を活用した自然言語インサイトも追加され、「clickclient」クエリライブラリを利用するエージェントが、製品やユーザーのアクティビティ、ベンチマーク、製品の定着度に関する顧客からの質問に回答できるようになっています。

ClickHouse Cloud を導入したことで、Appcues はリアルタイムな製品判断に追従し、新しいチャネルや機能をサポートし、ビジネスの足枷となることなく効率的にスケールできるアナリティクスプラットフォームを遂に手に入れました。

「結果には大変満足していますし、ClickHouse チームから受けたサポートにも心から感謝しています」

— Chris Brookins 氏 (VP of Engineering, Appcues)