Neon Postgres から ClickHouse Managed Postgres へ

TL;DR: ここ数か月で、本番の Postgres ワークロードを Neon から ClickHouse Managed Postgres へ移行するチームが増えています。理由はさまざまですが、私たちとの会話では共通するテーマが浮かび上がりました。負荷時の信頼性の問題、ワークロードの拡大に伴って予測しにくくなる性能、増え続けるインフラコスト、そしてネットワーク転送料金です。移行後、これらのチームは信頼性の向上、より高速で安定したクエリ性能、運用上の問題の減少、コストの低減を実感したと話しています。多くは ClickPipes を使って数時間でデータ移行を完了しました。1 社はネイティブの論理レプリケーションの上に独自の移行ツールを構築しました。

私たちはこのうち 4 チームに話を聞き、経験を詳しく伺いました。各チームのステージはまったく異なります。Shipsidekick は AI を活用した物流スタートアップ、socialpruf. は急成長中のリアルタイムソーシャルインテリジェンスプラットフォーム、Infinitas Learning は欧州を代表する教育出版社の 1 つ、そしてあるステルススタートアップはマルチテナントプラットフォーム上で AI データ製品を構築しています。各チームに同じ 4 つの質問をしました。以下がその回答です。

「スキーマはまったく同じままで、Postgres クエリの p99 レイテンシが数秒から 1 桁ミリ秒に改善しました。」

— Jerome van den Heuvel 氏、Infinitas Learning エンジニアリングマネージャー

御社の事業内容と、Postgres が製品をどのように支えているかを教えてください #

Shipsidekick 創業者兼 CTO の Sawyer Bateman 氏: 「Shopify と物流事業者をつなぎ、配送と倉庫業務をシームレスにしています。Vercel 上の Next.js アプリケーションからバックエンド業務まで、あらゆるものを Postgres が支えています。」

socialpruf. 創業者の Semyon Khlavich 氏: 「ソーシャルデータをリアルタイムのインサイトに変え、ブランド、タレントエージェンシー、スポーツメディア企業に提供しています。Postgres が私たちのシステムオブレコードで、顧客向けアナリティクスは ClickHouse が担っています。」

Infinitas Learning エンジニアリングマネージャーの Jerome van den Heuvel 氏: 「Infinitas Learning は欧州最大級の教育出版社の 1 つです。私たちの Results & Insights チームは、デジタル学習プラットフォーム上で完了した演習を処理・分析するために Postgres と ClickHouse を使っています。」

ステルススタートアップ: 「私たちは、AI を使って企業のデータ、ツール、システムをまたぐ業務を自動化するデータ製品を構築しています。私たちのプラットフォームでは、フィールドデプロイメントエンジニアがカスタマイズしたフルスタックのソリューションを素早く構築できます。ClickHouse Managed Postgres がマルチテナントのコントロールプレーンと顧客データプレーンを支え、アナリティクス向けの ClickHouse ウェアハウスとネイティブに統合されています。」

製品も規模も 4 つそれぞれ異なりますが、根底にあるパターンは同じです。Postgres がシステムオブレコードであり、4 チームのうち 3 チームではすでに ClickHouse が併せてアナリティクスを担っています。

Neon ではどのような課題を経験しましたか #

具体的な内容は異なりますが、テーマは同じです。当初はどのチームでも Neon がうまく機能していましたが、ワークロードと本番環境の要求が拡大するにつれ、課題に直面するようになりました。

Shipsidekick では、問題が顧客にまで影響しました。Sawyer 氏はこう語ります。「Neon は顧客の不満の原因になっていました。頻繁なクラッシュ、ピーク時間帯に 10 分以上続く障害、共有ゲートウェイでのコネクションプールの枯渇を経験しました。最大の 16 コンピュートユニットにしても CPU 使用率は高いままで、キャッシュヒット率は低かったのです。」

socialpruf. はデータの増加に伴い、信頼性とコストの両方で限界に達しました。Semyon 氏の言葉です。「数百 GB 規模にスケールするにつれ、Neon は不安定になり、費用も高くなりました。接続の切断と再起動でデータパイプラインが停止し、手動での対応が必要になりました。さらに、ClickHouse へのネットワーク転送料金がコンピュートコストの半分以上に膨らみました。」

Infinitas Learning は、運用面とプラットフォーム面の問題が重なりました。Jerome 氏: 「Neon ではいくつかの課題を経験しました。

• サポートの対応が遅く、反応も鈍くなりました。
• CPU とメモリの使用率が、明確な説明のないまま上昇しました。
• Neon が Azure リージョンを廃止したため、移行を余儀なくされました。
• Postgres のメジャーバージョン間のアップグレードには、まったく新しいサーバーへの移動が必要でした。」

ステルススタートアップの場合、問題は障害ではなく適合性でした。「Neon の開発者体験は優れていましたが、私たちの本番ワークロードには常時稼働のコンピュート、論理レプリケーション、予測可能な性能が必要で、サーバーレスの利点の多くは当てはまりませんでした。常時稼働の Postgres に移行したことで、API レイテンシは数秒から 1 秒未満に短縮され、OLAP と監査ログのワークロードへの道筋もシンプルになりました。

当時、私たちの Neon 環境には、求めていたシンプルな FDW や OLAP 拡張との統合もありませんでした。pg_mooncake には管理したくない追加のインフラが必要でしたし、pg_clickhouse は ClickHouse Managed Postgres の評価を決める大きな要因になりました。現在は Postgres と ClickHouse データウェアハウスの組み合わせでアプリケーションとアナリティクスのニーズの大半をまかない、残りをコントロールプレーンとマネージドサービスが担っています。」

ClickHouse Managed Postgres への移行後、どのような価値を得られましたか #

どのチームも、クエリやスキーマを書き直すことなく、プラットフォームを変えただけで改善が即座に現れたと述べています。

Shipsidekick: 「違いはすぐに現れました。ダウンタイムはゼロ、キャッシュヒット率は 99%、同程度のコンピュートで、ピーク時のワークロードでも CPU 使用率は 10% 程度です。現在の支払額は以前より少なく、さらに縮小する余地もあります。」

socialpruf.: 「効果はすぐに現れました。接続の切断や再起動はゼロになり、クエリは全体で 30% ほど速くなり、一部のクエリは最大 5 倍高速になりました。ある重要なクエリは 42 ms から 22 ms に短縮されました。ネットワーク転送コストもなくなり、現在は PgBouncer で数千の同時接続を安定して処理しています。」

Infinitas Learning: 「スキーマはまったく同じままで、Postgres クエリの p99 レイテンシが数秒から 1 桁ミリ秒に改善しました。性能もより安定し、予測しやすくなりました。」

ステルススタートアップ: 「顧客は API とアプリケーション描画の高速化にすぐ気づきました。私たちのチームも、SSR などの最適化でクエリのウォーターフォールを回避する作業に費やす時間が減りました。Neon で信頼性が最大の懸念だったことはありません。最大の成果は、一貫して高い性能、インフラをより細かく制御できること、そしてアナリティクス用に Postgres から ClickHouse へ直接つながる経路です。」

ここで 2 点を取り上げておきます。第一に、これらの結果は ClickHouse Managed Postgres のアーキテクチャがもたらす利点と一致しています。このアーキテクチャはローカル NVMe ストレージを使い、ネットワーク接続ストレージのボトルネックを取り除いています。それにより、クエリは高速になり、同じくらい重要な点として、性能が予測しやすくなります。第二に、すでにアナリティクスに ClickHouse を使っているチームでは、両方のシステムが同じプラットフォーム上に置かれるため、Postgres から ClickHouse へ変更をストリーミングするためのネットワーク転送料金がそのまま消えます。さらに pg_clickhouse が、Postgres のクエリから ClickHouse ウェアハウスへ直接つながる経路を提供します。

「常時稼働の Postgres に移行したことで、API レイテンシは数秒から 1 秒未満に短縮され、OLAP と監査ログのワークロードへの道筋もシンプルになりました。」

— ステルススタートアップ

移行にはどのように取り組み、全体としてどのような経験でしたか #

ここが私たちの最も知りたかった部分です。チームが限界を迎えたプラットフォームに留まり続ける理由は、たいてい移行のリスクです。4 チームのうち 3 チームは ClickPipes を使いました。ClickPipes は ClickHouse Managed Postgres に組み込まれており、スキーマの移行、並列スナップショットによる最適化された初期ロード、そしてカットオーバーまで両方のデータベースを同期し続ける CDC (Change Data Capture) を担います。残る 1 チームは、多数の Neon プロジェクトにまたがるマルチテナントのデータプレーンを持っていたため、ネイティブの Postgres ツールの上に独自の移行サービスを構築しました。

「750 GB のデータベースを 16 時間未満で移行できました。比較として、それより小さい 250 GB のデータベースを Neon へ移行したときは 3 日かかり、大量の手作業が必要でした。」

— Jerome van den Heuvel 氏、Infinitas Learning エンジニアリングマネージャー

Shipsidekick はガイドに従い、週末のうちにカットオーバーしました。Sawyer 氏: 「移行は速く、簡単でした。Neon 移行ガイドに従い、ClickPipes で 4〜5 時間でデータを移動し、週末に ClickHouse Managed Postgres へシームレスにカットオーバーしました。」

socialpruf. は最初に手動の方法を試し、その後 ClickPipes に切り替えました。Semyon 氏: 「ネイティブの論理レプリケーションが失敗した後、ClickHouse チームの支援を受け、ClickPipes を使ってわずか数時間で 0.5 TB を移行しました。両方のデータベースを 1 週間同期させたまま、データベースのフォークでテストを行い、その後スムーズに本番をカットオーバーしました。」

Infinitas Learning は、以前 Neon へ移行した際の経験と直接比較できました。Jerome 氏: 「ClickPipes での移行は簡単でした。サーバーをプロビジョニングし、スキーマを作成し、ClickPipes でデータを転送しました。750 GB のデータベースを 16 時間未満で移行できました。比較として、それより小さい 250 GB のデータベースを Neon へ移行したときは 3 日かかり、大量の手作業が必要でした。」

「ネイティブの論理レプリケーションが失敗した後、ClickHouse チームの支援を受け、ClickPipes を使ってわずか数時間で 0.5 TB を移行しました。」

— Semyon Khlavich 氏、socialpruf. 創業者

ステルススタートアップは、多数の Neon プロジェクトにまたがるマルチテナントのデータプレーンを移行しました。「私たちのデータプレーンは共有型、パフォーマンス型、専用型のテナンシーモデルに対応しているため、移行は複雑でした。pgcopydb、論理レプリケーション、制御された書き込み停止、整合性の照合、コネクションのドレインを組み合わせた自動移行サービスを構築しました。このツールは、多数の Neon プロジェクトから本番の ClickHouse インスタンスへ、計画的なダウンタイム/カットオーバーを挟んで容易に移行する際にも使いました。この投資は現在、インスタンス、データベース、スキーマ、リージョンをまたぐ移行を支えています。カットオーバー以降、性能と稼働率は非常に良好で、ワークロードの監視とスケーリングもはるかに予測しやすくなりました。」

共通しているのは、ClickPipes でも独自ツールでも、初期ロードは数時間で完了し、テスト中もレプリケーションが移行先を最新の状態に保ち、チームが自分たちのスケジュールでカットオーバーできたという点です。

移行の道筋 #

同じ移行を検討しているなら、手順の要点は次のとおりです。すべてのステップは Neon から ClickHouse Managed Postgres への移行ガイド に記載されています。

1. Neon を準備する。 読み取り権限とレプリケーション権限を持つ専用ユーザーを作成し、Neon コンソールの Settings → Logical Replication で論理レプリケーションを有効にします。レプリケーションするすべてのテーブルには、主キーまたは REPLICA IDENTITY FULL が必要です。IP 制限を使っている場合は、ClickPipes の静的 IP を許可します。Neon ソース設定ガイド に手順があります。

2. ClickPipes で移行する。 ClickHouse Cloud コンソールの Managed Postgres サービスから Data sources → Start import に進み、Neon を指定して Initial load + CDC を選びます。ClickPipes は空の移行先データベースにスキーマを移行し、並列の初期ロードを実行し、その後は移行先を Neon と同期し続けます。テーブルごとの進行状況とレプリケーション遅延はコンソールで確認できます。

3. カットオーバーする。 レプリケーション遅延がほぼゼロになったら、Neon への書き込みを停止し、行数とスキーマを検証し、シーケンスをリセットし、アプリケーションの接続文字列を更新します。ロールバックが必要になった場合に備えて Neon をしばらく読み取り専用のまま残し、その後 ClickPipe とそのレプリケーションスロットを削除します。

留意点をいくつか挙げます。

• ブランチ。 Neon のコピーオンライトのブランチは即時に作成されます。ClickHouse Managed Postgres では、ブランチはポイントインタイムリカバリで作成される独立したデプロイメントで、データベースのサイズに応じて通常は数分から数十分で利用できるようになります。多くのチームは、サニタイズしたデータを入れた小さな開発用データベースを持ち、そこからブランチを作成しています。ブランチのドキュメントを参照してください。
• Neon Serverless Driver。 アプリが @neondatabase/serverless (Vercel でよく使われます) を使っている場合は、node-postgres などの標準ドライバーに置き換えます。短命な接続が多い場合は、トランザクションプーリングモードで動作する同梱の PgBouncerを使います。
• 接続数の上限。 デフォルトは直接接続 500 です。PgBouncer は最大 5,000 のクライアント接続に対応し、max_connections は Settings → Edit parameters で引き上げられます。
• 移行中のスキーマ変更。 CDC は insert、update、delete と ADD COLUMN をレプリケーションします。それ以外の DDL (インデックス、トリガー、enum の変更、制約、関数) は、カットオーバー前に移行先へ手動で適用する必要があります。ClickPipes の開始からカットオーバーまでの期間は短く保ちます。よくあるエラーは移行 FAQにまとめています。
• 多数のデータベースやテナント。 ステルススタートアップのように多数の Neon プロジェクトを統合する場合は、pgcopydb と論理レプリケーションのようなネイティブツールをプロジェクトごとにスクリプト化できます。手動の手順は論理レプリケーションガイドにあります。

始めるには #

「現在の支払額は以前より少なく、さらに縮小する余地もあります。」

— Sawyer Bateman 氏、Shipsidekick 創業者

Sawyer 氏、Semyon 氏、Jerome 氏はいずれも、移行は短時間でリスクも低かったと語り、現在は高速で予測しやすい Postgres を以前より低いコストで運用しています。複雑なマルチテナント構成を持つステルススタートアップは、カットオーバー以降の性能と稼働率が非常に良好であること、そしてアナリティクス用に Postgres から ClickHouse へ直接つながる経路が得られたことを報告しています。

Neon からの移行を検討しているなら、ClickHouse Managed Postgres は数時間の作業で手が届きます。手順は移行ガイドにまとめています。支援が必要な場合はお問い合わせください。私たちが一緒に進めます。