> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# スケーリング

> 柔軟な VM タイプとリソースの個別スケーリングにより、ClickHouse が管理する Postgres インスタンスを垂直スケーリング

export const Image = ({img, alt, size}) => {
  return <Frame>
      <img src={img} alt={alt} />
    </Frame>;
};

export const galaxyOnClick = eventName => () => {
  try {
    if (typeof window !== "undefined" && window.galaxy && eventName) {
      window.galaxy.track(eventName, {
        interaction: "click"
      });
    }
  } catch (e) {}
};

export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
  if (link) {
    return <a href={link} target="_blank" rel="noopener noreferrer" className="betaBadge" onClick={galaxyTrack && galaxyEvent ? galaxyOnClick(galaxyEvent) : undefined}>
                <Icon />
                <span>Beta</span>
            </a>;
  }
  return <div className="betaBadge">
            <Icon />
            <span>
                Beta feature. 
                <u>
                    <a href="/docs/beta-and-experimental-features#beta-features">
                        Learn more.
                    </a>
                </u>
            </span>
        </div>;
};

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

<div id="instance-types">
  ## インスタンスタイプと柔軟性
</div>

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

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

<Image img="https://mintcdn.com/private-7c7dfe99-fix-nav-issues/qT0j4CNmQubVqREl/images/managed-postgres/instance-types.png?fit=max&auto=format&n=qT0j4CNmQubVqREl&q=85&s=b5ae96396ca472077a73928ab19162d5" alt="インスタンスタイプ" size="md" border width="1442" height="3288" data-path="images/managed-postgres/instance-types.png" />

<div id="choosing-instance">
  ### 適切なインスタンスタイプの選択
</div>

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

| ワークロードタイプ                      | CPU | メモリ | ストレージ | 推奨インスタンス                 |
| ------------------------------ | --- | --- | ----- | ------------------------ |
| **コンピュート最適化**                  | 高   | 中   | 中     | コンピュート最適化 (vCPU 数が多い)    |
| **メモリ最適化** (大規模なワーキングセット)      | 中   | 高   | 中     | メモリ最適化 (メモリ対 CPU の比率が高い) |
| **ストレージ最適化** (大規模データセット、高 I/O) | 中   | 中   | 高     | ストレージ最適化 (NVMe 容量が大きい)   |

<div id="how-scaling-works">
  ## スケーリングの仕組み
</div>

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

<Image img="https://mintcdn.com/private-7c7dfe99-fix-nav-issues/qT0j4CNmQubVqREl/images/managed-postgres/scaling-settings.png?fit=max&auto=format&n=qT0j4CNmQubVqREl&q=85&s=78dca1f87d35e96121e231cb6201533e" alt="スケーリング設定" size="md" border width="2478" height="1742" data-path="images/managed-postgres/scaling-settings.png" />

<div id="scaling-process">
  ### スケーリングプロセス
</div>

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

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

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

3. **並列 WAL リプレイ**: スタンバイは、[WAL-G](https://github.com/wal-g/wal-g) を利用した並列復元メカニズムによって、バックアップ以降のすべての Write-Ahead Log (WAL) の変更を適用します
   * WAL-G により、高速な並列リストア操作が可能になります
   * WAL-G の開発者は、当社が提携している Ubicloud チームの一員であり、深い専門知識と最適化が確保されています

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

5. **フェイルオーバー**: スタンバイが完全に同期されると、制御されたフェイルオーバーによってスタンバイが新しいプライマリに昇格します
   * **ダウンタイムが発生するのはこのステップだけです** (約 30 秒)
   * フェイルオーバー中は、すべてのアクティブな接続が中断されます
   * フェイルオーバーの完了後、クライアントは再接続する必要があります

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

<div id="scaling-duration">
  ### スケーリングにかかる時間
</div>

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

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

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

<Warning>
  **最小限のダウンタイム**

  スケーリング処理全体にどれだけ時間がかかっても、アプリケーションのダウンタイムはフェイルオーバー時のおよそ 30 秒のみです。復元と追従の処理はすべて、スタンバイインスタンス上でバックグラウンドで実行されます。
</Warning>

<div id="parallel-restore">
  ### WAL-G による並列復元
</div>

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

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

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

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

<div id="initiating-scaling">
  ### スケーリングの開始
</div>

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

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

<div id="scaling-strategies">
  ## スケーリング戦略
</div>

<div id="vertical-scaling">
  ### 垂直スケーリング
</div>

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

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

<div id="read-replicas">
  ### 水平スケーリング向けの読み取りレプリカ
</div>

読み取り負荷の高いワークロードでは、読み取り容量を水平にスケールさせるために、[読み取りレプリカ](/ja/products/managed-postgres/read-replicas)の利用を検討してください。

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

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

<div id="cdc-scaling">
  ### ClickHouse 連携向け CDC (変更データキャプチャ) のスケーリング
</div>

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

* CDC ワーカーは 1 ～ 24 CPU コアまでスケール可能
* メモリは CPU コア数の 4 倍に自動でスケール
* [ClickPipes OpenAPI](/ja/integrations/clickpipes/postgres/scaling) でスケーリングを調整可能

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

<div id="autoscaling">
  ## オートスケーリング
</div>

ディスク使用率が90%に達すると、より大きなインスタンスタイプに変更されます。

<div id="resources">
  ## 関連リソース
</div>

* [設定と構成](/ja/products/managed-postgres/settings)
* [読み取りレプリカ](/ja/products/managed-postgres/read-replicas)
* [高可用性](/ja/products/managed-postgres/high-availability)