Skip to main content
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 秒程度です。
最小限のダウンタイムスケーリング処理全体にどれだけ時間がかかっても、アプリケーションのダウンタイムはフェイルオーバー時のおよそ 30 秒のみです。復元と追従の処理はすべて、スタンバイインスタンス上でバックグラウンドで実行されます。

​
WAL-G による並列復元

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 エンドポイントなど、読み取り比率の高いアプリケーションに最適です。

​
ClickHouse 連携向け CDC (変更データキャプチャ) のスケーリング

ClickPipes を使用して ClickHouse にデータをレプリケーションしている場合は、CDC (変更データキャプチャ) パイプラインを個別にスケールできます。
  • CDC ワーカーは 1 ～ 24 CPU コアまでスケール可能
  • メモリは CPU コア数の 4 倍に自動でスケール
  • ClickPipes OpenAPI でスケーリングを調整可能
これにより、Postgres インスタンスのリソースとは別に、レプリケーションのスループットを最適化できます。

​
オートスケーリング

ClickHouse Managed Postgres はディスク使用量を監視し、インスタンスの容量不足を防ぐためにストレージを自動的にスケーリングします。
  • ディスク使用量 85%: Cloud Console とメールで通知が届きます。
  • ディスク使用量 90%: オートスケーリングが開始されます。ストレージは、インスタンスファミリーで利用可能な次に大きいサイズに増量されます。現在のインスタンスサイズでより大きなディスクがサポートされていない場合を除き、CPU とメモリは変わりません。サポートされていない場合は、インスタンスサイズも増やされます。読み取りレプリカもプライマリとともにスケーリングされます。
  • ディスク使用量 95%: 設定済みのメンテナンスウィンドウはスキップされ、新しいサーバーの準備ができ次第、切り替えが実行されます。
インスタンスがすでに利用可能な最大構成の場合、オートスケーリングでそれ以上拡張することはできません。ディスク容量を確保するか、サポートにお問い合わせください。

​
切り替えと接続

ストレージのサイズはその場で変更されません。オートスケーリングでは、手動でインスタンスタイプを変更する場合と同じスケーリングプロセスが実行されます。より大容量のストレージを備えた置換サーバーがプロビジョニングされ、最新のバックアップから復元されて WAL に追いついた後、制御された切り替えによって新しいプライマリに昇格します。高可用性構成のインスタンスでは、同じ操作の一環として新しいサイズの置換スタンバイもプロビジョニングされます。 ダウンタイムが発生するのは切り替え時のみで、通常は 1 分未満です。メンテナンスウィンドウが設定されている場合、ディスク使用量が 95% に達しない限り、切り替えはその時間帯まで待機します。切り替え中は、開いている接続が切断され、実行中のトランザクションはロールバックされます。接続文字列は変更されません。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) を下回ると、インスタンスは読み取り専用になります。より大きなディスクへの切り替えが完了すると、書き込みは自動的に再開されます。

​
関連リソース

最終更新日 2026年8月14日