Azure Database for PostgreSQL でのリソースのスケーリング

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 portal または Azure CLI を使用できます。

水平スケーリング

Azure Database for PostgreSQL エラスティック クラスターを使用すると、データベースを水平方向にスケールアウトして、1 つのデータベース インスタンスの機能を超えるデータ ワークロードをサポートできます。 また、エラスティック クラスターを使用すると、クラスター内のすべてのノードで並列操作を同時に実行でき、スループットが大幅に向上し、待機時間が大幅に短縮されます。 エラスティック クラスターには、行ベースのシャーディングとスキーマベースのシャーディングという 2 つのテーブル シャーディング モデルが用意されています。

読み取りレプリカのスケーリング

インスタンスを水平方向にスケーリングするもう 1 つの方法は、 読み取りレプリカを作成することです。 読み取りレプリカを使用すると、読み取りワークロードを個々の 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 個の仮想コアのコンピューティング サイズから、またはこのサイズに対してサーバーのコンピューティングをスケーリングする場合、ほぼゼロの値は機能しません。

関連コンテンツ

• Azure Database for PostgreSQL の管理