Clera の 500 GB 本番データベースを一晩で ClickHouse Managed Postgres へ移行した方法

本記事は、Clera の CTO 兼共同創業者である Daniel Wintermeyer 氏と、創業期エンジニアの Julian Bouchard 氏によるゲスト投稿です。元の記事は Clera のブログ(こちら)に掲載されています。

採用活動は破綻しています。候補者は手応えのないまま応募を続け、創業者は読みたくもない履歴書に忙殺され、本来なら抜群にマッチするはずの人たちが同じ場に出会うことはほとんどありません。私たちは、もっと良い方法があるはずだと考えました。仕事を探す必要はありません。Clera と話すだけでいいのです。

Clera は、市場の双方に働きかける AI 人材エージェントです。20 万人以上の候補者を支援し、主にニューヨークやサンフランシスコにあるプレシードからシリーズ B の企業への採用をサポートしています。現在、プラットフォーム上には約 2,250 件の求人が掲載されており、毎日 2,000 人以上の新しい候補者が参加しています。

システム内部では、マルチエージェントシステムを稼働させています。候補者側では、サインアップ後にメール、iMessage、またはチャットインターフェースを通じてやり取りするだけで、エージェントが最初のヒアリングや希望条件の把握から、適切な職種の提案やマッチングに至るまでをすべて担当します。企業側では、創業者の Slack チャンネルに参加して候補者を直接紹介するため、応募のステップすら不要です。マッチする求人だけを提案し、徹底的に選別しているため、紹介の約 50% が面接につながっています。Clera は成功報酬型で運営しているため、何よりも重要なのは、候補者が本当に働きたいと思える職場に採用されることです。

システムの核となるのはデータです。あらゆるヒアリング内容、求人情報、どの役割に誰が適しているかというシグナルがマッチメイキングエンジンに送られます。そして、そのエンジンの精度は背後にあるデータ次第です。しかし、この課題の解決は想像以上に困難でした。

従来のデータベースベンダーの限界 #

移行当時、Postgres 上で 500 GB 以上のデータを運用していました(現在は 1 TB 近くに達しています)。ClickHouse Managed Postgres に移行する前は、以前のデータベースベンダーで非常に多くの問題に直面していました。

最もわかりやすい例が、候補者検索を行う単一のクエリでした。一瞬で終わるはずの処理に約 3 秒もかかっていたのです。至るところで分析クエリが実行され、データベースの CPU 使用率が 6 日間連続で 100% に張り付くこともありました。タイムアウトや書き込みの失敗、データの欠落も発生していました。同じ経験がある方なら、リトライが必要になるもどかしさや、データベースに足を引っ張られる辛さがよくわかるはずです。最悪のときには、主キーを指定したテーブルへの更新処理すら書き込めないバースト状態に陥りました。

Julian がワークロードを分析したところ、以下の 3 つのタイプに分類できることがわかりました。

• ホットリード: ユーザーがサイトを閲覧する際にすばやく表示する必要がある、小規模な CTE、求人一覧クエリ、マテリアライズドビューの読み取り。
• ポイントルックアップ: 何にもブロックされていなければ 1 ミリ秒未満で完了するはずの、ごくわずかな主キーの読み書き。
• バックグラウンド処理: チームメンバーが実行したりダッシュボードに表示されたりする重い分析 CTE や、SEO 向けのマテリアライズドビューのリフレッシュ。

最大の課題はポイントルックアップでした。バックグラウンドクエリにブロックされ、数秒もかかっていたのです。さらに、大量のデータをスクレイピングしているため、スパイク的な負荷が突発的に発生し、IOPS や CPU、実実行時間の負荷がさらに重なっていました。

そこで私たちは、分析処理やスクレイピングのバースト負荷が並行して走っていてもポイントルックアップが高速に保たれ、高い IOPS に耐えうるストレージを備えた、フルマネージドの運用向け Postgres が必要だと判断しました。私たちはデータベースの専門家ではありません。求めていたのは、手がかからず「そのまま動く」ものでした。

ClickHouse Managed Postgres の選定 #

まず、Supabase、Neon、PlanetScale、そして ClickHouse Managed Postgres の 4 つのベンダーの評価から始めました。Langfuse の友人たちから「そういえば、ClickHouse もその選択肢に入るよ。NVMe ストレージを備えたマネージド Postgres を提供しているから、話を聞いてみるといい」と言われるまで、ClickHouse が選択肢になるとは知る由もありませんでした。

ベンダーのテストは 2 つの方法で実施しました。1 つ目は、自社の本番データを使い、実際に運用しているワークロードを再現した擬似負荷環境での検証です。2 つ目は、他のプロバイダーも結果を公開している標準化されたベンチマークを用いて、汎用的な測定値を取得することでした。

本番ワークロードのベンチマーク検証 #

再現テストでは、約 500 GB の本番データを 4 つのプロバイダーすべてにロードし、前述の 3 種類のクエリを実行して以下を測定しました。

• 秒間クエリ数(QPS)
• P99 レイテンシ
• エラー率
• コネクション取得時間
• 待機イベント(ブロックされてほしくない処理がどの程度の頻度でブロックされたか)

Julian は各プロバイダーのプーラーを介してすべてを実行しようと試みましたが、プーラーごとに設定が異なり、条件を揃える手間が見合わなかったため、最終的な数値は直接接続で測定しました。

ClickHouse Managed Postgres は、特に IOPS においてほぼすべての項目で圧倒的な結果を出しました。勝因は、大半のプロバイダーが採用しておりディスクの読み書きごとにレイテンシが生じるネットワーク接続ストレージに対し、ローカル NVMe ストレージ を採用している点にありました。この違いだけで Supabase と Neon は即座に対象外となり、PlanetScale と ClickHouse に絞られました。

TPC-C によるベンチマークの検証 #

続いて、sysbench TPC-C を実行しました。これは基本的に、読み取りと書き込みのクエリが混在するビジネス環境を模擬したデータセットです(sysbench は厳密には完全な TPC-C 準拠ではないものの、比較可能なベースラインとしては十分機能します)。両プロバイダーとも同等のマシンクラスを使用し、生成された 500 GB のデータを用いてテストを行いました。1 つの実験では、スループットだけでなく実行ごとのばらつきも測定できるよう、8、16、32、64、128 スレッドのテストを 3 回連続で実施しました。複数の実験を重ね、前回同様に QPS、P99、エラー率を追跡したほか、今回は秒間トランザクション数(TPS)とそのばらつきも測定しました。

結果は、再び ClickHouse Managed Postgres の圧勝でした。何も手を加えない初期状態のままで、スループットのアドバンテージは 128 スレッド時の約 16% から 16 スレッド時の 42% にまで及びました。

留意すべき点として、両者は初期状態での PostgreSQL の設定値が同一ではありません。チューニングは各プロバイダーの提供価値の一部ですが、ある程度は手動で調整できます。そこで PlanetScale から設定を揃えるためのフィードバックをもらい、それらを反映させました(ただし、Huge Pages は同社のエンジニアリングチームを介さなければテストできませんでした)。

すべての結果、ログ、スクリプト、Terraform ファイル、短い LaTeX の解説文書、LLM 用のコンテキストダンプは、GitHub のオープンソースリポジトリ で公開しています。ぜひ内容を精査し、再現環境を試してみてください。誤りがあればメールでお知らせください。どのような種類のデータベースを評価する場合でも、このように自身で検証を行い、オープンソースとして公開することをおすすめします。間違っていれば、周囲の人が正してくれます。これこそが、コミュニティで知識を共有することの素晴らしさです。

ClickPipes を使って一夜でデータベースを移行 #

ClickHouse Managed Postgres の採用を決めたのは、ある木曜日のことでした。金曜日の朝、Daniel はフラットホワイトを片手に、控えている移行作業について話し合うつもりで午前 10 時のデイリーミーティングに参加しました。すると Julian が「そういえば、もう ClickHouse への移行は終わったよ」と言ったのです。

前夜の午後 11 時、Julian は最終的な準備作業を完了していました。入念に準備だけ整えて放置してしまうと、移行を先延ばしにし続けることになるとわかっていたため、いずれやるなら今やってしまおうと決断したのです。

準備段階では、ClickHouse の移行ガイド に従いました。移行元での作業としては、WAL の保持期間設定、パブリケーションの有効化、キーや拡張機能の事前チェックなどが含まれます。最大の難関は拡張機能でした。Postgres には多種多様な拡張機能があり、一部のプロバイダーには他の環境へ移植できない独自のものが存在します。Julian はどのプロバイダーへもクリーンに移行できるよう、数日前からシステムの一部を変更して対処していました。

Julian は 2 つの ClickPipes パイプラインを立ち上げました。主要データ用と非重要データ用に分け、主要データに集中しつつ両方を並行して稼働させるためです。創業者チームがドイツ出身ということもあり、従来のデータベースは EU に置かれていたため、この機会に米国へ移転させることにしました。本番トラフィックを処理しながら、500 以上のテーブルが大西洋を渡ったことになります。テスト中、EU とのレイテンシとテーブル数の多さが重なり問題に直面した場面がありましたが、ClickHouse の担当者が夜の 11 時にプルリクエストを作成して対応してくれました。このような手厚い対応のおかげで、移行作業が格段にスムーズになりました。

データ移行自体は非常にシンプルでした。むしろ手間がかかったのは、トリガーの再設定、インデックスの再構築、テーブルのシーケンス番号の再割り当てです。その後、整合性チェックを行い、新しいデータベースを参照するようにシステム全体を再デプロイして重大な問題がないことを確認するカットオーバーを実施しました。スキーマ変更が頻繁に行われる環境では、新しいデータベースへのコピー完了後に古いスキーマが更新される事態を防ぐ必要があるため、すべての工程を迅速に進める必要がありました。朝の 6 時から 7 時頃には、大半の作業がモニタリングとクリーンアップを残すのみとなっていました。そして午前 10 時のデイリーミーティングを終えた Julian は、そのまま眠りにつきました。

高速化したクエリとスケーラビリティの確保 #

ClickHouse Managed Postgres の導入により、ユーザーだけでなく、社内ツールを日々利用している社内管理者にとっても、あらゆる画面の読み込みが格段に高速化され、大変感謝されています。チームの誰かが数時間かかる重い分析クエリを不意に実行してシステム全体をダウンさせてしまうのではないか、と怯えることもなくなりました。以前は時折起きていたことですが、今では過去の話です。

同じくらい重要なのは、システムリソースに十分な余裕が生まれたことです。現在、CPU 使用率は大半の時間で 10〜20% 程度に収まっています。移行後、設定は 1 つも変更していません。初期状態のパフォーマンスが求めていた要件に合わせてすでにチューニングされており、まさに「そのまま動いた」状態でした。コスト面でも以前とほぼ同等か、むしろわずかに安価になりながら、パフォーマンスとスケーラビリティが向上しました。

なお、私たちが移行したのは分析用データベースとしての ClickHouse ではなく、マネージド Postgres サービスです。これは本質的に、ネットワーク接続ディスクではなくローカル NVMe ストレージを基盤とした標準的な Postgres です。現時点ではこれで十分ですが、将来的に分析業務がこの規模を超えることがあっても、対応する道はすでに用意されています。必要になれば、マネージド Postgres から ClickHouse へデータを同期できるからです。それまでの間も、このシステムならさらに多くの負荷を安心して投入できると確信しています。

数字で見る成果

• 移行したデータ量: 500 GB(現在は 1 TB 近く)
• EU から米国へ移行したテーブル数: 500 以上
• 最終準備からカットオーバーまでの期間: 1 晩
• CPU 使用率: 100% → 10〜20%
• sysbench TPC-C において次点ベンダー比で最大 42% 高い TPS を記録
• 移行後に変更した設定の数: 0 件