Managed Postgres では、ワークロード要件に応じて柔軟にスケーリングできます。50 種類以上の NVMe 対応インスタンスタイプから選択でき、CPU、メモリ、ストレージをそれぞれ個別にスケーリングして、用途に応じてパフォーマンスとコストを最適化できます。
Managed Postgres では、さまざまなワークロード特性に合わせて最適化された幅広いインスタンスタイプを提供しています。
- コンピュート、メモリ、ストレージ最適化構成全体で 50 種類以上のインスタンスタイプ を利用可能
- すべてのインスタンスタイプで NVMe ベースのストレージ を採用し、一貫した高性能なディスク I/O を実現
- リソースの個別スケーリング: ワークロードに応じて、CPU、メモリ、ストレージの適切なバランスを選択可能
ワークロードの種類によって、適したリソース構成は異なります。
| ワークロードタイプ | CPU | メモリ | ストレージ | 推奨インスタンス |
|---|
| コンピュート最適化 | 高 | 中 | 中 | コンピュート最適化 (vCPU 数が多い) |
| メモリ最適化 (大規模なワーキングセット) | 中 | 高 | 中 | メモリ最適化 (メモリ対 CPU の比率が高い) |
| ストレージ最適化 (大規模データセット、高 I/O) | 中 | 中 | 高 | ストレージ最適化 (NVMe 容量が大きい) |
-
スタンバイのプロビジョニング: ターゲットのインスタンスタイプ (CPU、メモリ、ストレージ構成) で新しいスタンバイインスタンスが作成されます
-
S3 バックアップからの復元: スタンバイは、S3 に保存されている最新のバックアップから復元されて初期化されます
-
並列 WAL リプレイ: スタンバイは、WAL-G を利用した並列復元メカニズムによって、バックアップ以降のすべての Write-Ahead Log (WAL) の変更を適用します
- WAL-G により、高速な並列リストア操作が可能になります
- WAL-G の開発者は、当社が提携している Ubicloud チームの一員であり、深い専門知識と最適化が確保されています
-
レプリケーションのキャッチアップ: スタンバイは、継続中の WAL の変更をストリーミングして適用することで、プライマリに追いつきます
-
フェイルオーバー: スタンバイが完全に同期されると、制御されたフェイルオーバーによってスタンバイが新しいプライマリに昇格します
- ダウンタイムが発生するのはこのステップだけです (約 30 秒)
- フェイルオーバー中は、すべてのアクティブな接続が中断されます
- フェイルオーバーの完了後、クライアントは再接続する必要があります
-
古いインスタンスの廃止: 元のインスタンスは、フェイルオーバーの完了後に廃止されます
スケーリングに必要な総時間は、主にデータベースのサイズと、バックアップからリプレイする必要がある WAL データの量によって決まります。
- バックアップの復元: 最新のフルバックアップを S3 から新しいインスタンスに復元するのにかかる時間
- WAL のリプレイ: 最後のフルバックアップ以降のインクリメンタルな WAL の変更をリプレイするのにかかる時間
- 並列復元: WAL-G の並列復元機能により、このプロセスは大幅に高速化されます
復元時間は数分から数時間に及ぶ場合がありますが、メンテナンス時間やダウンタイムは非常に短く、約 30 秒程度です。
最小限のダウンタイムスケーリング処理全体にどれだけ時間がかかっても、アプリケーションのダウンタイムはフェイルオーバー時のおよそ 30 秒のみです。復元と追従の処理はすべて、スタンバイインスタンス上でバックグラウンドで実行されます。
- 並列ダウンロードと解凍: 複数のバックアップセグメントを S3 から取得し、同時に解凍します
- 効率的な WAL リプレイ: インクリメンタルな WAL の変更を、可能な場合は並列に適用します
- 最適化されたストリーミング: 中間コピーを作成せずに、S3 ストレージから直接ストリーミングします
- 高速な復元: 全体の所要時間はデータ量に依存しますが、並列化されたアプローチにより復元は非常に高速になります
これらの最適化により、新しいスタンバイインスタンスを立ち上げるまでの時間が大幅に短縮されます。最も重要なのは、復元が完全にバックグラウンドで行われることです。アプリケーションでダウンタイムが発生するのは、約 30 秒の短いフェイルオーバー時間だけです。
Managed Postgres インスタンスをスケールするには、次の手順に従います。
- インスタンスの Settings タブに移動します
- スケーリング セクションで Service size までスクロールします
- 変更先のインスタンスタイプを選択します
- 変更内容を確認し、“Apply changes” をクリックします
垂直スケーリング (インスタンスタイプの変更) は、Managed Postgres でリソースを調整する主な方法です。この方法には、次のような利点があります。
- きめ細かな制御: 50 種類以上のインスタンスタイプから選択し、CPU、メモリ、ストレージを細かく調整できます
- ワークロードの最適化: 特定のワークロード (コンピュート、メモリ、またはストレージ集約型) に最適化された構成を選択できます
- コスト効率: 過剰なプロビジョニングを避けつつ、必要なリソースに対してのみ料金を支払えます
読み取り負荷の高いワークロードでは、読み取り容量を水平にスケールさせるために、読み取りレプリカの利用を検討してください。
- 読み取りクエリを専用の読み取りレプリカ インスタンスにオフロードする
- 各読み取りレプリカは、それぞれ独自のコンピュートとメモリを備えた、完全に独立した Postgres インスタンスです
- 読み取りレプリカは、効率的なレプリケーションのためにオブジェクトストレージから WAL の変更をストリーミングします
この方法は、レポート用ダッシュボード、分析クエリ、読み取り負荷の高い API エンドポイントなど、読み取り比率の高いアプリケーションに最適です。
ClickHouse 連携向け CDC (変更データキャプチャ) のスケーリング
