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