この記事では、Azure Database for PostgreSQL フレキシブル サーバー エラスティック クラスターに対して水平スケーリング操作を実行する手順について説明します。
Azure Database for PostgreSQL エラスティック クラスターでは、クラスターにワーカー ノードを追加することで、水平方向のスケーリングが提供されます。 PostgreSQL エラスティック クラスターをスケーリングする場合は、データベースに並列クエリ処理用のリソースまたはノードを追加することで、拡張を処理できます。 これらの利点はすべて、最小限のダウンタイムと組み込みのシャード管理で得られます。
スケールアウト手法
ワークフローと自動化のニーズに応じて、複数の方法のいずれかを使用して、Azure portal、Azure CLI、ARM テンプレートと API を使用した自動化など、エラスティック クラスターにワーカー ノードを追加します。 以降のセクションでは、ポータルと CLI の詳細な手順と、スケール後の再調整について説明します。
Azure portal を使用して以下を実行します。
リソースを開きます。Azure portal で、Azure Database for PostgreSQL - フレキシブル サーバーエラスティック クラスターに移動します。
[コンピューティング + ストレージ] に移動します。[設定] セクションで、[コンピューティングとストレージ] を選択します。 このページには、クラスターのノードの現在の構成が表示されます。
![エラスティック クラスターの [概要] ページを示すスクリーンショット。](media/how-to-scale-out/overview.png)
ノード数の調整: [ノード数] フィールドを見つけます。 必要な合計ノード数に増やします (GA のほとんどのクラスターでは 2 ~ 20 個)。 たとえば、4 つのノード クラスターを 8 ノードに 2 倍にするには、スライダーを 8 に増やします。 Azure では、この数に達するために追加のワーカー ノードがプロビジョニングされます。
![[コンピューティングとストレージ] ページを選択する方法を示すスクリーンショット。](media/how-to-scale-out/scale-out.png)
変更を適用する: [保存] を選択します。 プロンプトが表示されたら、スケールアウト操作を確認します。 Azure がクラスターへのノードの追加を開始します。 この操作はオンラインで実行され、通常は既存の接続やクエリを中断しません。 デプロイには数分かかることがあります。 ポータルの通知で進行状況を監視できます。 完了すると、クラスターのノード数に新しい値が反映されます。
![エラスティック クラスターの [概要] ページを示すスクリーンショット。](media/how-to-scale-out/overview.png#lightbox)
![[コンピューティングとストレージ] ページを選択する方法を示すスクリーンショット。](media/how-to-scale-out/scale-out.png#lightbox)
注
既存のデータをすべてのノードに再配布できるようにするには、シャードの再調整バックグラウンド プロセスを明示的にトリガーする必要があります。 この操作では、読み取りと書き込みのダウンタイムは発生しません。
リバランス
クラスターにノードを追加した後、新しいデータ変更または新しく追加された分散テーブルでは、使用可能なすべてのノードが使用されます。 既存のデータ シャードは、再配布されるまで、その場所にとどまります。 オンライン再調整により、データの移動中にアプリケーションからの読み取りと書き込みが最小限の中断で続行されます。
エラスティック クラスターをスケールアウトすると、クラスターを再調整することで、既存のデータが完全に分散され、データベースで使用可能なすべてのノードが使用されるようになります。 citus_rebalance_start関数を使用して、再調整プロセスを開始します。 この操作により、既存のデータがすべてのノードに均等に分散されます。
SELECT citus_rebalance_start();
並列再調整
既定の再調整操作では、複数のシャード移動が順番に実行されます。 場合によっては、コンピューティング、メモリ、ネットワーク帯域幅などのより多くのリソースを使用する代わりに、より速く再調整することをお勧めします。 このような状況では、多数のシャード移動を並列で実行するように再調整操作を構成できます。
citus.max_background_task_executors_per_node パラメーターを使用すると、シャードの再調整などのタスクを並列に動作できます。 並列処理を向上させるために、既定値 (1) を必要に応じて増やすことができます。
ALTER SYSTEM SET citus.max_background_task_executors_per_node = 2;
SELECT pg_reload_conf();
さらに、 citus_rebalance_start 関数を構成して、データベースのワークロードに最適なさまざまな戦略に従ってシャードを再調整することもできます。 今やバックグラウンドタスクの実行ツールを追加したので、並列ワーカーを使用してシャードを再調整する例を以下に示します。
SELECT citus_rebalance_start(parallel_transfer_colocated_shards := true, parallel_transfer_reference_tables := true);
考慮事項
スケーリング後にクラスターを監視する: エラスティック クラスターの Azure portal の監視グラフで、CPU 使用率、メモリ使用量、IO 消費量を確認します。 スケールアウト操作の後、ノードを追加すると、ワークロードに応じてスループットと応答時間のメトリックの改善が反映されることを確認します。 必要に応じてさらに調整します。
エラスティック クラスターのスケーリングは、リソースを使用してコストに線形的に影響します。 ノードを追加すると、コンピューティング コストとストレージ コストにノードの数が乗算されます。 たとえば、2 つの仮想コアを持つ 4 ノード クラスターでは、4 台のサーバーを実行しているため、1 つの 2 仮想コア サーバーのコストの約 4 倍のコストがかかります。 ポータルで価格への影響を常に確認します。 見積もりコストは、予算を満たすように保存する前に構成を変更すると、Azure portal で更新されます。
高可用性: クラスターでゾーン冗長高可用性が有効になっている場合、スケーリング操作では、新しいノードのスタンバイ リソースもプロビジョニングされます。 Azure サービスはこれを自動的に処理します。 追加されたノードごとに HA レプリカを設定するため、スケールアウトには少し時間がかかることが予想されます。 プロセスとダウンタイムの特性はほぼ同じままで、プライマリとスタンバイのペアに乗算されます。
読み取りレプリカ: クラスターが読み取りレプリカを使用するように構成されている場合は、クラスターにノードを追加するときに、特定の操作の順序に従う必要があります。 まず、プライマリ クラスターにノードの数を追加し、変更を保存します。 正常に完了したら、読み取りレプリカ環境に対応する変更を行い、変更を保存します。 プライマリ クラスター上の新しいノードは、プライマリ レプリカ環境と読み取りレプリカ環境の両方が更新および同期されるまで、クラスター操作の対象になりません。
注
エラスティック クラスター (スケールイン) からノードを削除する機能はまだ使用できません。
上記のスケーリング手法を使用することで、Azure Database for PostgreSQL エラスティック クラスターを使用すると、需要の増加に応じて、小規模なデータベースを柔軟に開始し、シームレスにデータベースを拡張できます。 分散 Postgres インフラストラクチャの機能により、単一のエンドポイントのシンプルさが得られます。 Elastic Clusters の機能とスケーリングのベスト プラクティスに関する最新の更新プログラムについては、引き続き Azure のドキュメントを監視してください。