Azure Database for PostgreSQL - フレキシブル サーバーでのリソースのスケーリング
適用対象: 
Azure Database for PostgreSQL - フレキシブル サーバー
Azure Database for PostgreSQL - フレキシブル サーバーでは、垂直方向と水平方向の両方のスケーリング オプションがサポートされています。
垂直方向のスケーリング
Azure Database for PostgreSQL フレキシブル サーバー インスタンスにリソースを追加して、インスタンスを垂直方向にスケーリングできます。 それに割り当てられた CPU とメモリの数を増減できます。
インスタンスのネットワーク スループットは、CPU とメモリに対して選択した値によって異なります。
Azure Database for PostgreSQL フレキシブル サーバー インスタンスが作成された後、次のものを個別にスケーリングできます。
- コンピューティング レベルと SKU。
- ストレージ レベルとサイズ。
- バックアップの保有期間。
コンピューティング レベルは、バースト可能、汎用、メモリ最適化の間でスケールアップまたはスケールダウンでき、ワークロードのニーズに合わせて調整できます。 これらの各レベルには、ハードウェアの豊富な選択肢があり、異なる世代、異なる CPU 数、異なるメモリ量で事前に構成されています。 その幅広い選択肢から、運用コストを低く抑えつつ、ニーズに合わせて調整して、リソース要件をサポートするものをいつでも選択できます。
仮想コアの数と搭載されているメモリは、増やしたり減らしたりできます。 ストレージ レベルも、ワークロードで求められるスループットと IOPS の要件に対応するように、増やしたり減らしたりして構成できます。 ストレージ サイズは増やすことのみ可能です。 また、要件に応じて、バックアップ保持期間を 7 日から 35 日の間で増減できます。
これらのリソースは、複数のインターフェイスを使ってスケーリングできます。 たとえば、Azure portal または Azure CLI を使用できます。
Note
インスタンスに割り当てられるストレージのサイズを大きくした後で、小さいサイズに縮小することはできません。
水平スケーリング
インスタンスの水平スケーリングは、読み取りレプリカを作成して行うことができます。 読み取りレプリカを使用すると、読み取りワークロードを個々の Azure Database for PostgreSQL フレキシブル サーバー インスタンスにスケーリングできます。 プライマリ インスタンスのパフォーマンスと可用性には影響しません。
水平方向のスケーリングのセットアップでは、プライマリ インスタンスと読み取りレプリカを垂直方向にスケーリングすることもできます。
仮想コアの数またはコンピューティング レベルを変更すると、インスタンスが再起動され、割り当てられた新しいハードウェアでサーバー ワークロードの実行が開始されます。 この間、システムは新しいサーバーの種類に切り替えます。 新しい接続を確立できず、コミットされていないすべてのトランザクションがロールバックされます。
サーバーの再起動にかかる全体的な時間は、クラッシュ復旧プロセスと再起動時のデータベース アクティビティによって異なります。 通常、再起動には 1 分もかかりませんが、数分かかる場合もあります。 タイミングは、再起動が開始されたときのトランザクション アクティビティによって異なります。
アプリケーションが、コンピューティングのスケーリング中に発生する可能性がある処理中のトランザクションの損失に影響する場合は、トランザクション再試行パターンを実装することをお勧めします。
ストレージのスケーリングではほとんどの場合、サーバーを再起動する必要はありません。 詳しくは、Azure Database for PostgreSQL - フレキシブル サーバーでのストレージ オプションに関する記事をご覧ください。
バックアップ保持期間の変更はオンライン操作です。
再起動時間を短縮するには、ピーク時以外の時間帯にスケーリング操作を実行することをお勧めします。 それにより、データベース サーバーの再起動に必要な時間が短縮されます。
低ダウンタイム スケーリング
低ダウンタイム スケーリングは、ストレージとコンピューティングのレベルの変更時に、ダウンタイムが最小になるように設計された機能です。 仮想コアの数を変更したり、コンピューティング層を変更したりすると、新しい構成を適用するためにサーバーは再起動されます。 この新しいサーバーへの移行中には、新しい接続を確立することができません。
一般的に、このプロセスには通常のスケーリングで 2 から 10 分かかる場合があります。 低ダウンタイム スケーリング機能を使うと、この期間が 30 秒未満に短縮されます。 リソースのスケーリング中のダウンタイムの短縮により、データベース インスタンスの全体的な可用性が向上します。
しくみ
スケーリング シナリオで Azure Database for PostgreSQL フレキシブル サーバー インスタンスを更新すると、サービスによって、更新された構成でサーバー用の新しい仮想マシンが作成されます。 その後、現在インスタンスを実行している仮想マシンと同期されてから、短時間の中断の後に新しい仮想マシンに切り替わります。 その後、古い仮想マシンはバックグラウンド プロセスによって削除されます。 このプロセスはすべて追加料金なしで行われます。
このプロセスにより、ダウンタイムを最小限に抑え、コスト効率を保ちながら、シームレスな更新が可能になります。 このスケーリング プロセスは、ストレージおよびコンピューティング レベルに変更が加えられたときにトリガーされます。 この機能を使用するためにお客様のアクションは必要ありません。
プライマリ サーバーと 1 つ以上の読み取りレプリカで構成される水平スケーリング構成の場合、データの一貫性を保ち、ダウンタイムを最小限に抑えるため、スケーリング操作は特定のシーケンスに従う必要があります。 そのシーケンスについて詳しくは、読み取りレプリカを使うスケーリングに関する記事をご覧ください。
Note
低ダウンタイム スケーリングが、操作の "既定" の種類です。 次の制限に該当した場合、システムは通常のスケーリングに切り替わり、低ダウンタイム スケーリングと比べてダウンタイムが長くなります。
ダウンタイムの正確な予測
- ダウンタイム期間: ほとんどの場合、ダウンタイムは 10 から 30 秒の範囲になります。
- その他の考慮事項: スケーリング イベントの後、約 30 秒の固有の DNS
Time-To-Live(TTL) 期間があります。 スケーリング プロセスでは、この期間は直接制御されません。 これは DNS 動作の標準部分です。 アプリケーションの観点から見ると、スケーリング中に発生したダウンタイムの合計は、40 から 60 秒の範囲になる可能性があります。
考慮事項と制限事項
- 低ダウンタイム スケーリングを機能させるには、仮想ネットワーク統合ネットワークを使うときに、委任されたサブネット内の IP アドレス間の受信と送信接続をすべて許可します。 これらの接続が許可されていない場合、低ダウンタイム スケーリング プロセスは機能せず、スケーリングは標準のスケーリング ワークフローで行われます。
- サブスクリプションにリージョンの容量制約またはクォータ制限がある場合、低ダウンタイム スケーリングは機能しません。
- 低ダウンタイム スケーリングは、プライマリ サーバーでのみサポートされるため、レプリカ サーバーでは機能しません。 レプリカ サーバーの場合、スケーリング操作は通常のプロセスで自動的に行われます。
- 仮想ネットワーク挿入サーバーが委任されたサブネット内に十分な使用可能 IP アドレスを持っていない場合、低ダウンタイム スケーリングは機能しません。 スタンドアロン サーバーがある場合は、1 つの追加の IP アドレスが必要です。 高可用性が有効にされているインスタンスの場合、2 つの追加 IP アドレスが必要です。
- 低ダウンタイム フェールオーバー イベントの間、論理レプリケーション スロットは維持されません。 論理レプリケーション スロットを維持し、スケール操作後にデータの整合性を確保するには、pg_failover_slot 拡張機能を使用します。 詳しくは、フレキシブル サーバーでの拡張機能の有効化に関する記事をご覧ください。
- 低ダウンタイム スケーリングは、ログされないテーブルでは機能しません。 いずれかのデータにログされないテーブルを使っている場合、低ダウンタイム スケーリングの後で、それらのテーブル内のデータはすべて失われます。
Azure Database for PostgreSQL 製品チームと提案やバグを共有します。
Azure Database for PostgreSQL 製品チームと提案やバグを共有します。