Azure Database for PostgreSQL フレキシブル サーバーでのリソースのスケーリング

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

Azure Database for PostgreSQL フレキシブル サーバーでは、垂直方向と水平方向の両方のスケーリング オプションがサポートされています。

垂直スケーリング: インスタンス割り当て CPU とメモリの数を増やすなど、Azure Database for PostgreSQL フレキシブル サーバー インスタンスにリソースをさらに追加することで、垂直方向にスケーリングできます。 インスタンスのネットワーク スループットは、CPU とメモリに対して選択した値によって異なります。

Azure Database for PostgreSQL フレキシブル サーバー インスタンスが作成された後、以下を個別に変更できます。

• CPU (仮想コア)。
• ストレージの量。
• バックアップの保有期間。

仮想コアの数はスケールアップまたはスケールダウンできますが、ストレージ サイズは増やすことのみ可能です。 バックアップ保有期間を 7 から 35 日の範囲でスケールアップまたはスケールダウンすることもできます。 リソースは、Azure portal や Azure CLI などの複数のツールを使用してスケーリングできます。

水平スケーリング: 読み取りレプリカを作成することで、水平方向にスケーリングできます。 読み取りレプリカを使用すると、読み取りワークロードを個々の Azure Database for PostgreSQL フレキシブル サーバー インスタンスにスケーリングできます。 プライマリ インスタンスのパフォーマンスと可用性には影響しません。

仮想コアの数またはコンピューティング レベルを変更すると、インスタンスが再起動され、新しいサーバーの種類が有効になります。 この間、システムは新しいサーバーの種類に切り替えます。 新しい接続を確立できず、コミットされていないすべてのトランザクションがロールバックされます。

サーバーの再起動にかかる全体的な時間は、クラッシュ復旧プロセスと再起動時のデータベース アクティビティによって異なります。 通常、再起動には 1 分もかかりませんが、数分かかる場合もあります。 タイミングは、再起動が開始されたときのトランザクション アクティビティによって異なります。

アプリケーションが、コンピューティングのスケーリング中に発生する可能性がある処理中のトランザクションの損失に影響する場合は、トランザクション再試行パターンを実装することをお勧めします。

ストレージのスケーリングではほとんどの場合、サーバーを再起動する必要はありません。 同様に、バックアップ保有期間の変更はオンライン操作です。 再起動時間を短縮するには、ピーク時以外の時間帯にスケーリング操作を実行することをお勧めします。 それにより、データベース サーバーの再起動に必要な時間が短縮されます。

ほぼゼロのダウンタイムのスケーリング

ほぼゼロのダウンタイムのスケーリングは、ストレージおよびコンピューティング レベルの変更時に、ダウンタイムが最小になるように設計された機能です。 仮想コアの数を変更したり、コンピューティング層を変更したりすると、新しい構成を適用するためにサーバーは再起動されます。 この新しいサーバーへの移行中には、新しい接続を確立することができません。

一般的に、このプロセスには通常のスケーリングで 2 から 10 分かかる場合があります。 新しいほぼゼロのダウンタイムのスケーリング機能では、この期間は 30 秒未満に短縮されます。 リソースのスケーリング中のダウンタイムの短縮により、データベース インスタンスの全体的な可用性が向上します。

しくみ

スケーリング シナリオで Azure Database for PostgreSQL フレキシブル サーバー インスタンスを更新すると、更新された構成でサーバー (VM) の新しいコピーが作成されます。 現在のものと同期させ、30 秒の中断で新しいコピーに切り替えます。 その後、古いサーバーを廃止します。 このプロセスはすべて追加料金なしで行われます。

このプロセスにより、ダウンタイムを最小限に抑え、コスト効率を確保しながら、シームレスな更新が可能になります。 このスケーリング プロセスは、ストレージおよびコンピューティング レベルに変更が加えられたときにトリガーされます。 この機能は非 HA サーバーでのみ使用でき、すべての Azure リージョンで有効になります。 この機能を使用するためにお客様のアクションは必要ありません。

読み取りレプリカ構成サーバーの場合、データの整合性を確保し、ダウンタイムを最小限に抑えるために、スケーリング操作は特定のシーケンスに従う必要があります。 そのシーケンスの詳細については、読み取りレプリカによるスケーリングに関するページを参照してください。

ダウンタイムの正確な予測

• ダウンタイム期間: ほとんどの場合、ダウンタイムは 10 から 30 秒の範囲になります。
• その他の考慮事項: スケーリング イベントの後、約 30 秒の固有の DNS Time-To-Live (TTL) 期間があります。 この期間は、スケーリング プロセスによって直接制御されません。 これは DNS 動作の標準部分です。 アプリケーションの観点から見ると、スケーリング中に発生したダウンタイムの合計は、40 から 60 秒の範囲になる可能性があります。

考慮事項と制限事項

• ほぼゼロのダウンタイムのスケーリングを機能させるには、仮想ネットワーク統合ネットワークを使用するときに、委任されたサブネット内の IP 間の受信/送信接続をすべて有効にします。 これらの接続が有効になっていない場合、ほぼゼロのダウンタイムのスケーリング プロセスは機能せず、スケーリングは標準のスケーリング ワークフローを通じて行われます。
• ほぼゼロのダウンタイムのスケーリングは、お客様のサブスクリプションにリージョンの容量制約またはクオータ制限があると機能しません。
• ほぼゼロのダウンタイムのスケーリングは、レプリカ サーバーでは機能しません。これはプライマリ サーバーでのみサポートされるためです。 レプリカ サーバーの場合、通常のスケーリング プロセスが自動的に実行されます。
• 委任されたサブネットを持つ仮想ネットワークが挿入されたサーバーに十分な使用可能な IP アドレスがない場合、ほぼゼロのダウンタイムのスケーリングは機能しません。 スタンドアロン サーバーがある場合は、1 つの追加の IP アドレスが必要です。 HA 対応サーバーの場合は、2 つの追加の IP アドレスが必要です。
• ほぼゼロのダウンタイム フェールオーバー イベント中は、論理レプリケーション スロットは保持されません。 論理レプリケーション スロットを維持し、スケール操作後にデータの整合性を確保するには、pg_failover_slot 拡張機能を使用します。 詳細については、フレキシブル サーバーでの拡張機能の有効化に関する記述を参照してください。
• ダウンタイムがほぼゼロのスケーリングは、ログされないテーブルでは機能しません。 ログされないテーブルをデータに使っている場合、ダウンタイムがほぼゼロのスケーリングの後で、それらのテーブル内のすべてのデータが失われます。
• 現在、高可用性 (HA) が有効なサーバーでは、ダウンタイムがほぼゼロのスケーリングはサポートされていません。

関連するコンテンツ

• ポータルで Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成する。