インスタンスタイプと柔軟性
- コンピュート、メモリ、ストレージ最適化構成全体で 50 種類以上のインスタンスタイプ を利用可能
- すべてのインスタンスタイプで NVMe ベースのストレージ を採用し、一貫した高性能なディスク I/O を実現
- リソースの個別スケーリング: ワークロードに応じて、CPU、メモリ、ストレージの適切なバランスを選択可能
適切なインスタンスタイプの選択
スケーリングの仕組み
スケーリングプロセス
- スタンバイのプロビジョニング: ターゲットのインスタンスタイプ (CPU、メモリ、ストレージ構成) で新しいスタンバイインスタンスが作成されます
- S3 バックアップからの復元: スタンバイは、S3 に保存されている最新のバックアップから復元されて初期化されます
-
並列 WAL リプレイ: スタンバイは、WAL-G を利用した並列復元メカニズムによって、バックアップ以降のすべての Write-Ahead Log (WAL) の変更を適用します
- WAL-G により、高速な並列リストア操作が可能になります
- WAL-G の開発者は、当社が提携している Ubicloud チームの一員であり、深い専門知識と最適化が確保されています
- レプリケーションのキャッチアップ: スタンバイは、継続中の WAL の変更をストリーミングして適用することで、プライマリに追いつきます
-
フェイルオーバー: スタンバイが完全に同期されると、制御されたフェイルオーバーによってスタンバイが新しいプライマリに昇格します
- ダウンタイムが発生するのはこのステップだけです (約 30 秒)
- フェイルオーバー中は、すべてのアクティブな接続が中断されます
- フェイルオーバーの完了後、クライアントは再接続する必要があります
- 古いインスタンスの廃止: 元のインスタンスは、フェイルオーバーの完了後に廃止されます
スケーリングにかかる時間
- バックアップの復元: 最新のフルバックアップを S3 から新しいインスタンスに復元するのにかかる時間
- WAL のリプレイ: 最後のフルバックアップ以降のインクリメンタルな WAL の変更をリプレイするのにかかる時間
- 並列復元: WAL-G の並列復元機能により、このプロセスは大幅に高速化されます
WAL-G による並列復元
- 並列ダウンロードと解凍: 複数のバックアップセグメントを S3 から取得し、同時に解凍します
- 効率的な WAL リプレイ: インクリメンタルな WAL の変更を、可能な場合は並列に適用します
- 最適化されたストリーミング: 中間コピーを作成せずに、S3 ストレージから直接ストリーミングします
- 高速な復元: 全体の所要時間はデータ量に依存しますが、並列化されたアプローチにより復元は非常に高速になります
スケーリングの開始
- インスタンスの Settings タブに移動します
- スケーリング セクションで Service size までスクロールします
- 変更先のインスタンスタイプを選択します
- 変更内容を確認し、“Apply changes” をクリックします
スケーリング戦略
垂直スケーリング
- きめ細かな制御: 50 種類以上のインスタンスタイプから選択し、CPU、メモリ、ストレージを細かく調整できます
- ワークロードの最適化: 特定のワークロード (コンピュート、メモリ、またはストレージ集約型) に最適化された構成を選択できます
- コスト効率: 過剰なプロビジョニングを避けつつ、必要なリソースに対してのみ料金を支払えます
水平スケーリング向けの読み取りレプリカ
- 読み取りクエリを専用の読み取りレプリカ インスタンスにオフロードする
- 各読み取りレプリカは、それぞれ独自のコンピュートとメモリを備えた、完全に独立した Postgres インスタンスです
- 読み取りレプリカは、効率的なレプリケーションのためにオブジェクトストレージから WAL の変更をストリーミングします
ClickHouse 連携向け CDC (変更データキャプチャ) のスケーリング
- CDC ワーカーは 1 ～ 24 CPU コアまでスケール可能
- メモリは CPU コア数の 4 倍に自動でスケール
- ClickPipes OpenAPI でスケーリングを調整可能