スケーリング

ClickHouse Managed Postgres では、ワークロード要件に応じて柔軟にスケーリングできます。50 種類以上の NVMe 対応インスタンスタイプから選択でき、CPU、メモリ、ストレージをそれぞれ個別にスケーリングして、用途に応じてパフォーマンスとコストを最適化できます。

ClickHouse Managed Postgres では、さまざまなワークロード特性に応じて最適化された幅広いインスタンスタイプを提供しています。

• 50 種類以上のインスタンスタイプ を、コンピュート、メモリ、ストレージ最適化構成で利用可能
• すべてのインスタンスタイプで NVMe ベースのストレージ を採用し、一貫した高性能なディスク I/O を実現
• リソースの個別スケーリング: ワークロードに応じて、CPU、メモリ、ストレージの適切なバランスを選択可能

ワークロードの種類によって、適したリソース構成は異なります。

インスタンスタイプを変更すると、ClickHouse Managed Postgres は垂直スケーリングを実行し、新しいインフラストラクチャをプロビジョニングしたうえで、ダウンタイムを最小限に抑えながらデータベースを移行します。

スケーリングのワークフローでは、バックアップから新しいスタンバイを起動し、制御されたフェイルオーバーを実行します。

1. スタンバイのプロビジョニング: ターゲットのインスタンスタイプ (CPU、メモリ、ストレージ構成) で新しいスタンバイインスタンスが作成されます

2. S3 バックアップからの復元: スタンバイは、S3 に保存されている最新のバックアップから復元されて初期化されます

3. 並列 WAL リプレイ: スタンバイは、WAL-G を利用した並列復元メカニズムによって、バックアップ以降のすべての Write-Ahead Log (WAL) の変更を適用します

   • WAL-G により、高速な並列リストア操作が可能になります
   • WAL-G の開発者は、当社が提携している Ubicloud チームの一員であり、深い専門知識と最適化が確保されています

4. レプリケーションのキャッチアップ: スタンバイは、継続中の WAL の変更をストリーミングして適用することで、プライマリに追いつきます

5. フェイルオーバー: スタンバイが完全に同期されると、制御されたフェイルオーバーによってスタンバイが新しいプライマリに昇格します

   • ダウンタイムが発生するのはこのステップだけです (約 30 秒)
   • フェイルオーバー中は、すべてのアクティブな接続が中断されます
   • フェイルオーバーの完了後、クライアントは再接続する必要があります

6. 古いインスタンスの廃止: 元のインスタンスは、フェイルオーバーの完了後に廃止されます

スケーリングに必要な総時間は、主にデータベースのサイズと、バックアップからリプレイする必要がある WAL データの量によって決まります。

• バックアップの復元: 最新のフルバックアップを S3 から新しいインスタンスに復元するのにかかる時間
• WAL のリプレイ: 最後のフルバックアップ以降のインクリメンタルな WAL の変更をリプレイするのにかかる時間
• 並列復元: WAL-G の並列復元機能により、このプロセスは大幅に高速化されます

復元時間は数分から数時間に及ぶ場合がありますが、メンテナンス時間やダウンタイムは非常に短く、約 30 秒程度です。

ClickHouse Managed Postgres では、スケーリング操作中のバックアップ復元を高速化するために WAL-G を使用しています。特に、WAL-G の開発者が、当社が提携している Ubicloud チームの一員であるため、復元プロセスには深い専門知識が活かされています。

WAL-G には、次のような特長があります。

• 並列ダウンロードと解凍: 複数のバックアップセグメントを S3 から取得し、同時に解凍します
• 効率的な WAL リプレイ: インクリメンタルな WAL の変更を、可能な場合は並列に適用します
• 最適化されたストリーミング: 中間コピーを作成せずに、S3 ストレージから直接ストリーミングします
• 高速な復元: 全体の所要時間はデータ量に依存しますが、並列化されたアプローチにより復元は非常に高速になります

これらの最適化により、新しいスタンバイインスタンスを立ち上げるまでの時間が大幅に短縮されます。最も重要なのは、復元が完全にバックグラウンドで行われることです。アプリケーションでダウンタイムが発生するのは、約 30 秒の短いフェイルオーバー時間だけです。

ClickHouse Managed Postgres インスタンスをスケールするには、次の手順に従います。

1. インスタンスの Settings タブに移動します
2. スケーリング セクションで Service size までスクロールします
3. 変更先のインスタンスタイプを選択します
4. 変更内容を確認し、"Apply changes" をクリックします

垂直スケーリング (インスタンスタイプの変更) は、ClickHouse Managed Postgres でリソースを調整する主な方法です。この方法には、次のような利点があります。

• きめ細かな制御: 50 種類以上のインスタンスタイプから選択し、CPU、メモリ、ストレージを細かく調整できます
• ワークロードの最適化: 特定のワークロード (コンピュート、メモリ、またはストレージ集約型) に最適化された構成を選択できます
• コスト効率: 過剰なプロビジョニングを避けつつ、必要なリソースに対してのみ料金を支払えます

読み取り負荷の高いワークロードでは、読み取り容量を水平にスケールさせるために、読み取りレプリカの利用を検討してください。

• 読み取りクエリを専用の読み取りレプリカ インスタンスにオフロードする
• 各読み取りレプリカは、それぞれ独自のコンピュートとメモリを備えた、完全に独立した Postgres インスタンスです
• 読み取りレプリカは、効率的なレプリケーションのためにオブジェクトストレージから WAL の変更をストリーミングします

この方法は、レポート用ダッシュボード、分析クエリ、読み取り負荷の高い API エンドポイントなど、読み取り比率の高いアプリケーションに最適です。

ClickPipes を使用して ClickHouse にデータをレプリケーションしている場合は、CDC (変更データキャプチャ) パイプラインを個別にスケールできます。

• CDC ワーカーは 1 ～ 24 CPU コアまでスケール可能
• メモリは CPU コア数の 4 倍に自動でスケール
• ClickPipes OpenAPI でスケーリングを調整可能

これにより、Postgres インスタンスのリソースとは別に、レプリケーションのスループットを最適化できます。

ClickHouse Managed Postgres はディスク使用量を監視し、インスタンスの容量不足を防ぐためにストレージを自動的にスケーリングします。

• ディスク使用量 85%: Cloud Console とメールで通知が届きます。
• ディスク使用量 90%: オートスケーリングが開始されます。ストレージは、インスタンスファミリーで利用可能な次に大きいサイズに増量されます。現在のインスタンスサイズでより大きなディスクがサポートされていない場合を除き、CPU とメモリは変わりません。サポートされていない場合は、インスタンスサイズも増やされます。読み取りレプリカもプライマリとともにスケーリングされます。
• ディスク使用量 95%: 待機時間を設けず、新しいサーバーの準備ができ次第、切り替えが実行されます。

インスタンスがすでに利用可能な最大構成の場合、オートスケーリングでそれ以上拡張することはできません。ディスク容量を確保するか、サポートにお問い合わせください。

ストレージのサイズはその場で変更されません。オートスケーリングでは、手動でインスタンスタイプを変更する場合と同じスケーリングプロセスが実行されます。より大容量のストレージを備えた置換サーバーがプロビジョニングされ、最新のバックアップから復元されて WAL に追いついた後、制御された切り替えによって新しいプライマリに昇格します。高可用性構成のインスタンスでは、同じ操作の一環として新しいサイズの置換スタンバイもプロビジョニングされます。

ダウンタイムが発生するのは切り替え時のみで、通常は 1 分未満です。設定済みのスケジュールされたアップグレードウィンドウによって切り替えが遅延することはありません。このウィンドウはスケーリングではなく、プラットフォームのメンテナンスに適用されます。切り替え中は、開いている接続が切断され、実行中のトランザクションはロールバックされます。接続文字列は変更されません。DNS が新しいプライマリを指すように更新されるため、標準的な再接続ロジックを備えたアプリケーションは自動的に復旧します。

オートスケーリングの完了よりも速く書き込みによってディスクが埋まると、ディスク容量の完全な枯渇を防ぐため、インスタンスは読み取り専用モードに移行します。トリガーとなるのは残りの空き容量です。

読み取りは引き続き機能しますが、書き込みは標準の Postgres エラー cannot execute INSERT in a read-only transaction で失敗します。空き容量が減少し続けると、すべてのセッションに読み取り専用設定を反映させるため、既存の接続が切断されます。クライアントが再接続すれば、読み取りは再び機能します。空き容量が回復すると、読み取り専用モードは自動的に解除されます。通常は、スケールアップの切り替え完了直後に解除されます。

1024 GB のストレージを持つインスタンスで、書き込み負荷の高いワークロードを実行している場合:

1. 使用量が 870 GB (85%) に達すると、ストレージに関する通知を受け取ります。
2. 使用量が 922 GB (90%) に達すると、オートスケーリングが開始されます。2048 GB のストレージを持つ置換サーバーがプロビジョニングされ、インスタンスが引き続きトラフィックを処理している間に最新のバックアップから復元されます。
3. 置換サーバーの同期が完了すると、切り替えが実行されます。接続は 1 分未満中断されますが、アプリケーションは同じホスト名に再接続し、使用量は約 45% に戻ります。
4. 切り替えが完了する前に空き容量が 2% (約 20 GB) を下回ると、インスタンスは読み取り専用になります。より大きなディスクへの切り替えが完了すると、書き込みは自動的に再開されます。

• 設定と構成
• 読み取りレプリカ
• 高可用性