RedisとClickHouseの限界を突破：ScyllaDB移行でレイテンシを最大8分の1に削減したSprigの事例

急速な成長を遂げるスタートアップにとって、データ基盤の選定はビジネスの成否を分ける極めて重要な意思決定となります。

AIを活用した製品調査プラットフォームを提供するSprigは、プロダクトマーケットフィット (PMF) を予想以上の速さで達成しました。

その結果、当初の想定を遥かに上回る膨大なデータトラフィックに直面し、既存のデータベース構成では対応できない限界に達しました。

本記事では、SprigがいかにしてPostgreSQL、Redis、そしてClickHouseといった標準的な構成から脱却し、ScyllaDBへの移行によって劇的なパフォーマンス向上を実現したのか、その技術的な舞台裏を詳解します。

Sprigが直面した「ハイパースケール」の現実

Sprigのプラットフォームは一見シンプルですが、その裏側では極めて高度なリアルタイム・データ処理エンジンが稼働しています。

ユーザーがモバイルアプリやウェブサイトで特定のアクションを実行した際、その振る舞いをリアルタイムで評価し、最適なタイミングで調査フォームを表示させる必要があるためです。

このシステムは、アドテクやレコメンデーションエンジンと同様に、低レイテンシで計算負荷の高い処理を、1秒間に数千回実行しなければなりません。

Sprigが管理するデータの規模は、スタートアップとしては異例の数値に達しています。

膨大なデータボリュームの統計

2026年時点でのSprigのデータ規模を以下の表にまとめました。

これらのデータをミリ秒単位で処理し、ユーザー体験を損なうことなくフィードバックを収集することが、Sprigのエンジニアリングチームに課せられた最大のミッションでした。

Phase 1：PostgreSQLによる初期構築とその限界

多くのスタートアップがそうであるように、Sprigも最初はAmazon Aurora PostgreSQLから開発をスタートさせました。

PostgreSQLは汎用性が高く、初期のPMFを模索するフェーズでは最適な選択肢と言えます。

しかし、顧客規模が拡大するにつれ、単一のライターインスタンスでは書き込みスループットを捌ききれなくなりました。

AWSが提供する最大サイズのインスタンスを利用し、リーダーインスタンスを限界まで増設しても、運用の継続が困難な状況に陥ったのです。

特に問題となったのが、150億行に達したパーティション化されていない単一テーブルの存在でした。

インデックスの肥大化によりワーキングセットがメモリに収まらなくなり、IOPSコストが跳ね上がるとともに、P99レイテンシは50msを超えるまでに悪化しました。

Phase 2：RedisとClickHouseの導入による延命策

PostgreSQLの限界を突破するため、チームは訪問者データのみをPostgreSQLに残し、イベントと属性データをClickHouseとRedisの組み合わせに移行する戦略を採りました。

ClickHouseは分析用途に優れていますが、高頻度なポイントクエリには不向きであるため、その前面にライトスルーキャッシュとしてRedisを配置しました。

最適化の試み

このフェーズでチームは、ClickHouseの性能を引き出すために以下のような高度なチューニングを実施しました。

• グラニュールサイズの縮小： ディスクI/Oを最小限に抑えるため、標準の8,200行から大幅に縮小しました。
• スレッド制御： max_threadsを1に設定し、preadシステムコールを使用することで、コンテキストスイッチによるオーバーヘッドを抑制しました。
• IDハッシング： 訪問者IDをハッシュ化し、特定のパーティションのみを検索対象とするように設計しました。

これらの対策により、毎秒4万件から5万件の書き込みを処理できるようになったものの、読み取りのレイテンシは不安定なままでした。

バッチ処理の実行中やアクセスパターンの変化により、定期的にシステムの停滞 (ブラウンアウト) が発生していたのです。

ScyllaDBへの移行：決定的なソリューション

将来的な3〜5倍のトラフィック増加を見越し、Sprigは抜本的なデータベースの刷新を決断しました。

DynamoDB、DataStax Astra、セルフホストのCassandraなど、複数の選択肢を詳細に比較検討しました。

データベース選定の比較

Sprigが検討した主要な選択肢とその評価は以下の通りです。

特に決定打となったのは、ScyllaDBの実装する「マテリアライズドビュー」の堅牢性でした。

巨大な訪問者テーブルを複数のカラムでインデックス化する必要があったSprigにとって、この機能は不可欠な要素でした。

システム移行の実装プロセス

既存のトラフィックを止めずに移行を完了させるため、SprigはKafkaを活用したデュアルライト（二重書き込み）戦略を採用しました。

まず、Kafkaコネクタを介して、ClickHouseへの書き込みと同時にScyllaDBへもリアルタイムでデータを流し込みました。

並行して、バルクロードツールを用いて過去の履歴データをClickHouseからScyllaDBへと一括転送しました。

# 競合解決のための Last-Write-Wins 戦略のイメージ
def resolve_conflict(existing_record, incoming_record):
    # updated_at フィールドを使用して最新のデータを優先
    if incoming_record['updated_at'] > existing_record['updated_at']:
        return incoming_record
    return existing_record

新旧両システムから同時に読み取りを行い、その値をPrometheusで比較・検証するバリデーション層を設けることで、データの不整合がほぼゼロであることを確認してから正式な切り替えを行いました。

驚異的なパフォーマンス向上と成果

ScyllaDB Cloudへの移行完了後、システムのパフォーマンスは劇的に改善されました。

最も顕著な成果は、Redisを使用していた時と比較して、読み取りレイテンシが4倍から8倍改善されたことです。

平均的な読み取りレイテンシはわずか500マイクロ秒 (0.5ミリ秒) に抑えられ、P90レイテンシでも1～2ミリ秒という驚異的な数値を記録しました。

これは、インメモリキャッシュであるRedisよりも、最適化されたストレージエンジンを持つScyllaDBの方が、高負荷環境下で一貫した性能を発揮できることを証明しています。

運用面のメリット

技術的な指標以外にも、移行によって以下の運用上の恩恵が得られました。

• インフラの単純化： RedisとClickHouseの多段構成を解消し、ScyllaDBに統合することでアーキテクチャを簡素化しました。
• アラートの激減： データベースのボトルネックによる深夜の呼び出しがなくなり、開発チームが製品開発に集中できる環境が整いました。
• 容易なスケーラビリティ： 新しい顧客やワークロードが追加されても、ノードを追加するだけでリニアに拡張が可能になりました。

まとめ

Sprigの事例は、一般的な「Postgresから始めよう」という教訓の先にある、真のスケールアップの課題を鮮明に示しています。

データ構造が複雑化し、トラフィックがテラバイト、ペタバイト級に達したとき、従来のRDBや一時的なキャッシュによるパッチワークでは限界が訪れます。

ScyllaDBのような、ハードウェアの性能を極限まで引き出す分散データベースへの移行は、運用コストの削減とユーザー体験の向上を同時に実現する強力な選択肢となります。

低レイテンシと高スループットの両立を追求する技術者にとって、Sprigが辿った「シンプルさから洗練された分散システムへの進化」は、非常に価値のあるロードマップと言えるでしょう。