Azure Database for PostgreSQL の概要

19 分

Azure Database for PostgreSQL はマルチサーバーバージョンで使用できます。

あなたは、オンプレミスの PostgreSQL インストールの実行と管理を長年にわたって経験しているデータベース開発者として、Azure Database for PostgreSQL ではその機能がどのようにサポートおよびスケーリングされるかを調べておく必要があります。

このユニットでは、Azure Database for PostgreSQL の価格、バージョンサポート、レプリケーション、およびスケーリングのオプションについて説明します。

Azure Database for PostgreSQL

Azure Database for PostgreSQL サービスは、PostgreSQL のコミュニティバージョンを実装したものです。このサービスは、地理空間サポートやフルテキスト検索など、一般的な PostgreSQL システムで使用される共通の機能を提供します。

Microsoft は Azure プラットフォーム向けに PostgreSQL を採用しており、多くの Azure サービスと密接に統合されています。 Azure Database for PostgreSQL サービスは、Microsoft によって完全に管理されています。 Microsoft は、ソフトウェアの更新プログラムと修正プログラムを処理し、99.99% の可用性の SLA を提供します。これは、サービスを使用すると、実行されているデータベースとアプリケーションにのみ集中できることを意味します。

このサービスの各インスタンスに複数のデータベースを配置できます。

価格レベル

Azure Database for PostgreSQL サービスのインスタンスを作成するときに、価格レベルを選択して、割り当てたいコンピューティングリソースとストレージリソースを指定します。価格レベルは、仮想プロセッサコアの数、使用可能なストレージの量、およびさまざまなバックアップオプションを組み合わせたものです。割り当てるリソースが多いほど、コストが高くなります。

Azure Database for PostgreSQL サービスはストレージを使用して、データベースファイル、一時ファイル、トランザクションログ、およびサーバーログを保持します。必要に応じて、現在の容量に近づくと、ストレージを増やすことができるように指定することもできます。このオプションを選択しない場合、記憶域が不足しているサーバーの実行は継続しますが、読み取り専用として動作します。

Azure portal では、価格レベルが次の 3 つの範囲にグループ化されています。

Basic は、小規模なシステムおよび開発環境に適していますが、I/O パフォーマンスは可変です。
汎用は、プロセッサコアの数と使用可能なストレージ領域に応じて、最大 6000 IOPS で予測可能なパフォーマンスを提供します。
メモリ最適化は、最大 32 のメモリ最適化仮想プロセッサコアを使用し、最大 6000 IOPS の予測可能なパフォーマンスも提供します。

また、Microsoft では、大規模ストレージ オプションもプレビューで利用できます。これにより、最大 16 TB のストレージをプロビジョニングし、最大 2 万 IOPS をサポートできます。

必要なプロセッサコアとストレージの数は微調整できます。処理リソースのスケールアップとダウンを行うことができますが、ストレージはスケールアップのみでダウンはできません。データベースを作成した後に、必要に応じて、汎用とメモリ最適化の価格レベルを切り替えることができます。支払いは必要な分だけで済みます。

Note

プロセッサコアの数を変更すると、Azure はこのコンピューティングの割り当てを使用して新しいサーバーを作成します。サーバーが実行されると、クライアント接続が新しいサーバーに切り替わります。この切り替えには、最大 1 分かかることがあります。この間、新しい接続を作成することはできず、すべてのインフライトトランザクションはロールバックされます。

バックアップオプションのストレージサイズのみを変更した場合、サービスが中断されることはありません。

価格レベルと、割り当てられた処理リソースによって、サービスがサポートするコンカレント接続の最大数が決まります。たとえば、汎用価格レベルを選択し、64 仮想コアを割り当てる場合、サービスは 1900 のコンカレント接続をサポートします。 Basic レベルでは、2 つの仮想コアを使用して、最大 100 のコンカレント接続を処理します。 Azure 自体では、サーバーを監視するために、これらの接続のうち 5 つが必要です。使用可能な接続数を超えると、クライアントは "FATAL: sorry, too many clients already" というエラーを受信します。

価格は変化する可能性があります。最新情報については、「Azure Database for PostgreSQL の価格」を参照してください。

サーバーパラメーター

オンプレミスでインストールされた PostgreSQL では、postgresql.conf ファイルにサーバー構成パラメーターを設定します。 [サーバーパラメーター] ページで構成パラメーターを変更するには、Azure Database for PostgreSQL を使用します。オンプレミスでインストールされた PostgreSQL のすべてのパラメーターが Azure Database for PostgreSQL に関連しているわけではないため、[サーバーパラメーター] ページには、Azure に適したパラメーターのみが表示されます。

"動的" としてマークされているパラメーターでは、加えた変更がすぐに有効になります。静的パラメーターでは、サーバーを再起動する必要があります。サーバーを再起動するには、ポータルの [概要] ページにある [再起動] ボタンを使用します。

高可用性

Azure Database for PostgreSQL は、高可用性のサービスです。エラー検出とフェールオーバーのメカニズムが組み込まれています。ハードウェアまたはソフトウェアの問題が原因で処理ノードが停止した場合は、代わりに新しいノードに切り替えられます。現在そのノードを使用しているすべての接続は切断されますが、新しいノードに対して自動的に開かれます。失敗したノードによって実行されているトランザクションはすべてロールバックされます。このため、失敗した操作を検出して再試行するようにクライアントが構成されていることを必ず確認してください。

サポートされている PostgreSQL のバージョン

現在、Azure Database for PostgreSQL サービスでは、PostgreSQL バージョン 9.5 からバージョン 11 がサポートされています。サービスのインスタンスを作成するときに使用する PostgreSQL のバージョンを指定します。 Microsoft は、新しいバージョンの PostgreSQL が使用可能になったときにサービスを更新することを目標としており、以前の 2 つのメジャーバージョンとの互換性を維持します。

Azure では、PostgreSQL のマイナーバージョン間でのデータベースへのアップグレードが自動的に管理されますが、メジャーバージョンは管理されません。たとえば、PostgreSQL バージョン 10 を使用するデータベースがある場合、Azure によってデータベースをバージョン 10.1 に自動的にアップグレードできます。バージョン 11 に切り替えるには、現在のサービスインスタンスのデータベースからデータをエクスポートし、Azure Database for PostgreSQL サービスの新しいインスタンスを作成して、この新しいインスタンスにデータをインポートする必要があります。

コーディネーターとワーカーノード

データはシャード化され、ワーカーノード間で分散されます。コーディネーターのクエリエンジンでは、複雑なクエリを並列化して、処理を適切なワーカーノードに導くことができます。ワーカーノードは、処理中のデータを保持しているシャードに応じて選択されます。次に、コーディネーターでは、クライアントに送信する前に、ワーカーノードからの結果が集約されます。より単純なクエリは、1 つのワーカーノードのみを使用して実行できます。クライアントはコーディネーターとも接続し、ワーカーノードと直接通信することはありません。

必要に応じて、サービス内でワーカーノードの数を増減できます。

データの分散

分散テーブルを作成することにより、ワーカーノード間でデータを分散します。分散テーブルはシャードに分割され、各シャードはワーカーノードのストレージに割り当てられます。列を分散列として定義することで、データを分割する方法を指定します。データは、この列のデータの値に基づいてシャード化されます。分散テーブルを設計するときは、分散列を慎重に選択することが重要です。関連する行をグループ化するために通常使用される、多数の個別の値を持つ列を使用する必要があります。たとえば、顧客の注文に関する情報を格納する e コマースシステムのテーブルでは、顧客 ID が妥当な分散列である場合があります。特定の顧客のすべての注文は同じシャードに保持されますが、すべての顧客の注文はシャードに分散されます。

また、参照テーブルを作成することもできます。これらのテーブルには、市区町村の名前や状態コードなどの検索データが含まれています。参照テーブル全体がすべてのワーカーノードにレプリケートされます。参照テーブル内のデータは、比較的静的である必要があります。各変更には、テーブルのすべてのコピーを更新する必要があります。

最後に、ローカル テーブルを作成できます。ローカルテーブルはシャード化されませんが、コーディネーターノードに格納されます。結合によって要求される可能性が低いデータを含む小さいテーブルを保持するには、ローカルテーブルを使用します。例としては、ユーザーの名前やログインの詳細などがあります。

Azure Database for PostgreSQL でデータをレプリケートする

読み取り専用レプリカは、読み取りを集中的に行うワークロードを処理する場合に便利です。クライアント接続はレプリカ間に分散させることができるため、サービスの 1 つのインスタンスでの負担が軽減されます。クライアントが世界各地のさまざまな地域に配置されている場合は、リージョン間のレプリケーションを使用して、クライアントの各セットの近くにデータを配置し、待機時間を短縮します。

また、ディザスターリカバリーのためのコンティンジェンシー計画の一環としてレプリカを使用することもできます。マスターサーバーが使用できなくなった場合でも、レプリカに接続できる可能性があります。

注意

マスターが失われたり削除されたりすると、代わりに読み取り専用のすべてのレプリカが読み取り/書き込みサーバーになります。ただし、これらのサーバーは互いに独立しているため、あるサーバーのデータに加えられた変更は、残りのサーバーにはコピーされません。

レプリカの確立

読み取り専用レプリカには、元のサーバー (マスターと呼ばれます) に保持されているデータベースのコピーが含まれています。マスターのレプリカを作成するには、Azure portal または CLI を使用します。

読み取り専用レプリカを作成すると、Azure では Azure Database for PostgreSQL サービスの新しいインスタンスが作成され、マスターサーバーから新しいサーバーにデータベースがコピーされます。レプリカは読み取り専用モードで実行されます。データを変更しようとすると失敗します。

レプリカのラグ

レプリケーションは同期的ではなく、マスターサーバー内のデータに加えられた変更は、レプリカに表示されるまでに時間がかかることがあります。レプリカに接続するクライアントアプリケーションでは、このレベルの結果整合性に対処できる必要があります。 Azure Monitor を使用すると、Max Lag Across Replicas (レプリカ間の最大ラグ) と Replica Lag (レプリカラグ) メトリックを使用して、レプリケーションのタイムラグを追跡できます。

管理と監視

pgAdmin などの使い慣れたツールを使用して Azure Database for PostgreSQL に接続し、データベースの管理と監視を行うことができます。ただし、サーバーの管理と保守は Microsoft によって行われるため、サーバーに重点を置いた一部の機能 (サーバーのバックアップや復元など) は使用できません。

Azure Database for PostgreSQL を監視するための Azure ツール

Azure には、サーバーとデータベースのパフォーマンスを監視し、問題のトラブルシューティングを行うために使用できる広範なサービスが用意されています。これらのサービスを使用すると、割り当てた Azure リソースを PostgreSQL でどのように利用されているかを確認できます。この情報は、システムのスケーリング、データベース内のテーブルとインデックスの構造の変更、および実行時統計やその他のイベントの視覚化が必要かどうかを評価するために使用します。使用可能なサービスは次のとおりです。

Azure Monitor。 Azure Database for PostgreSQL には、CPU とストレージの使用率、I/O 率、メモリの占有率、アクティブな接続の数、レプリケーションの遅延などの項目を追跡するためのメトリックが用意されています。
サーバーログ。 Azure では、各 PostgreSQL サーバーでログを使用できるようになります。これらは、Azure portal からダウンロードします。
クエリストアと Query Performance Insights。 Azure Database for PostgreSQL サーバーでは、サーバー上でデータベースに対して実行されたクエリに関する情報を保管し、それを query_store スキーマの azure_sys という名前のデータベースに保存します。 query_store.qs_view ビューをクエリしてこの情報を表示します。既定では、Azure Database for PostgreSQL では小さなオーバーヘッドが発生するため、クエリ情報はキャプチャされませんが、pg_qs.query_capture_mode サーバープロパティを ALL または TOP に設定することによって追跡を有効にすることができます。

また、クエリストアを構成して、待機時間を費やすクエリに関する情報を取得します。別のクエリによるテーブルのロックが解放されるまで、またはクエリが大量の I/O を実行しているか、メモリが不足している場合、クエリの待機が必要になる場合があります。この情報は、query_store.runtime_stats_view ビューに表示されます。

SQL ステートメントを実行するのではなく、これらの統計情報を視覚化したい場合は、Azure portal で Query Performance Insight を使用します。
パフォーマンスに関する推奨事項。 Azure portal でも使用できるパフォーマンスの推奨事項ユーティリティでは、アプリケーションにより実行されているクエリを調べます。また、データベース内の構造を確認し、データを整理する方法と、インデックスの追加または削除を検討する必要があるかどうかをお勧めします。

クライアント接続

Azure Database for PostgreSQL は、ファイアウォールの内側で実行されます。サービスおよびデータベースにアクセスするには、クライアントの接続 IP アドレス範囲に関するファイアウォール規則を追加する必要があります。 Azure App Services を使用して実行されているアプリケーションなど、Azure 内からサービスにアクセスする必要がある場合は、Azure サービスへのアクセスも有効にする必要があります。

ファイアウォールを構成する

ファイアウォールを構成する最も簡単な方法は、Azure portal でお使いのサービスの [接続のセキュリティ] 設定を使用することです。クライアントの IP アドレス範囲ごとに規則を追加します。また、このページを使用して、お使いのサービスへの SSL 接続を強制します。

ツールバーの [クライアント IP の追加] をクリックして、お使いのデスクトップコンピューターの IP アドレスを追加します。

読み取り専用レプリカを構成している場合は、クライアントがアクセスできるように、各レプリカにファイアウォール規則を追加する必要があります。

クライアント接続ライブラリ

独自のクライアントアプリケーションを作成する場合は、適切なデータベースドライバーを使用して PostgreSQL データベースに接続する必要があります。これらのライブラリの多くは、プログラミング言語に依存しています。これらは独立したサードパーティによって管理されます。 Azure Database for PostgreSQL では、Python、PHP、Node.js、Java、Ruby、Go、C# (.NET)、ODBC、C、および C++ 用のクライアントライブラリがサポートされています。

クライアント再試行ロジック

前述のように、高可用性復旧中のフェールオーバー、CPU リソースのスケールアップなど、一部のイベントでは接続が短時間失われる可能性があります。進行中のトランザクションはすべてロールバックされます。 Azure Database for PostgreSQL では、接続されているクライアントが作業中のノードに自動的にリダイレクトされますが、その時点でクライアントによって実行されているすべての操作ではエラーが返されます。これが発生した場合、一時的な例外として扱う必要があります。アプリケーションコードは、これらの例外をキャッチして再試行するように準備する必要があります。

Azure Database for PostgreSQL でサポートされる PostgreSQL 機能

Azure Database for PostgreSQL では PostgreSQL データベースで一般的に使用されるほとんどの機能がサポートされていますが、いくつかの例外があります。サポートされていない機能が必要な場合は、データベースとアプリケーションコードを修正してこの依存関係を削除するか、仮想マシンで PostgreSQL を実行することを検討する必要があります。後者の場合は、サーバーの管理と保守を行う必要があります。

Azure Database for PostgreSQL でサポートされる拡張機能

PostgreSQL の多くの機能は拡張機能にカプセル化されています。拡張機能は、サーバーに格納されている SQL オブジェクトとコードのパッケージであり、CREATE EXTENSION コマンドを使用してデータベースに読み込むことができます。現在、Azure Database for PostgreSQL には、次の一般的に使用されるさまざまな拡張機能が用意されています。

データの種類
関数
フルテキスト検索
インデックス (ブルーム、btree_gist、btree_gin)
plpgsql 言語
PostGIS
多くの管理機能

dblink と postgres_fdwパッケージを使用して、1 つの PostgreSQL サーバーを別のサーバーに接続します。これにより、あるサーバーのコードから別のサーバーに保持されているデータにアクセスできるようになります。 Azure Database for PostgreSQL では、Azure Database for PostgreSQL を使用して作成されたサーバー間でのみ接続できます。オンプレミスや仮想マシンなど、他の場所でホストされている PostgreSQL サーバーへの送信接続を作成することはできません。

注意

サポートされている拡張機能の一覧は継続的に確認され、変更される可能性があります。次のクエリでサポートされている拡張機能の一覧を生成します。独自のカスタム拡張機能を作成して Azure Database for PostgreSQL にアップロードすることはできないことに注意してください。

SELECT * FROM pg_available_extensions;

Azure Database for PostgreSQL には、TimescaleDB データベースがオプションの拡張機能として含まれています。このデータベースには、時系列ワークロードをサポートする時間指向の分析関数やその他の機能が含まれています。このデータベースを使用するには、shared_preload_libraries パラメーターで [TIMESCALEDB] オプションを選択し、サーバーを再起動します。

ストアドプロシージャとトリガーの言語サポート

plpgsql 以外の言語のサポートでは、通常、ストアドプロシージャをコンパイルするか、コードを個別にトリガーして、コンパイル済みライブラリをサーバーにアップロードする必要があります。主に、セキュリティ上の理由から、Azure Database for PostgreSQL ではこれを行えません。他の言語で記述されたコードがある場合は、plpgsql に移植する必要があります。

続行