クラウドベンダーの詳細：MicrosoftAzure上のPostgreSQL

最近Microsoftをフォローしている場合、競合するデータベース製品のプロバイダーであるSQLServerもPostgreSQLの流行に乗ったのは当然のことです。 60,000件の特許をOINにリリースすることから、PGConでプラチナスポンサーになることまで、MicrosoftはPostgreSQLの企業支援組織の1つです。あらゆる機会を利用して、MicrosoftでPostgreSQLを実行できるだけでなく、その逆も当てはまります。Microsoftは、クラウドサービスを通じてPostgreSQLを実行できることを示しました。この声明は、Citus Dataの買収と、Hyperscaleという名前でのAzureCloudでの主力製品のリリースによってさらに明確になりました。 PostgreSQLの採用は拡大しており、今ではそれを選択する理由がさらに増えていると言っても過言ではありません。

Azureクラウドの旅は、競合他社に会うランディングページから始まりました。シングルサーバーと、Hyperscale（Citus）のプレビュー（つまり、SLAが提供されていない）リリースです。このブログは前者に焦点を当てます。この旅の途中で、オープンソースとは何かを実践する機会がありました。コミュニティに還元することです。この場合、ドキュメントにフィードバックを提供することで、Microsoftの功績により、フィードバックを直接パイプすることで非常に簡単になります。 Githubに：

PostgreSQLとAzureの互換性

バージョン管理

製品ドキュメントによると、シングルサーバーはn-2メジャー範囲のPostgreSQLバージョンを対象としています：

パフォーマンスのために構築されたソリューションとして、100GBのデータセットにはシングルサーバーをお勧めします以上。サーバーは予測可能なパフォーマンスを提供しました—データベースインスタンスには、事前定義された数のvCoreとIOPS（プロビジョニングされたストレージのサイズに基づく）が付属しています。

拡張機能

サポートされている拡張機能はかなりの数あり、そのうちのいくつかはすぐにインストールできます：

[email protected]:5432 postgres> select name, default_version, installed_version from pg_available_extensions where name !~ '^postgis' order by name;

            name             | default_version | installed_version

------------------------------+-----------------+-------------------

address_standardizer         | 2.4.3 |

address_standardizer_data_us | 2.4.3           |

btree_gin                    | 1.2 |

btree_gist                   | 1.5 |

chkpass                      | 1.0 |

citext                       | 1.4 |

cube                         | 1.2 |

dblink                       | 1.2 |

dict_int                     | 1.0 |

earthdistance                | 1.1 |

fuzzystrmatch                | 1.1 |

hstore                       | 1.4 |

hypopg                       | 1.1.1 |

intarray                     | 1.2 |

isn                          | 1.1 |

ltree                        | 1.1 |

orafce                       | 3.7 |

pg_buffercache               | 1.3 | 1.3

pg_partman                   | 2.6.3 |

pg_prewarm                   | 1.1 |

pg_qs                        | 1.1 |

pg_stat_statements           | 1.6 | 1.6

pg_trgm                      | 1.3 |

pg_wait_sampling             | 1.1 |

pgcrypto                     | 1.3 |

pgrouting                    | 2.5.2 |

pgrowlocks                   | 1.2 |

pgstattuple                  | 1.5 |

plpgsql                      | 1.0 | 1.0

plv8                         | 2.1.0 |

postgres_fdw                 | 1.0 |

tablefunc                    | 1.0 |

timescaledb                  | 1.1.1 |

unaccent                     | 1.1 |

uuid-ossp                    | 1.1 |

(35 rows)

AzureでのPostgreSQLモニタリング

サーバーの監視は、カスタムダッシュボードを作成するために適切にグループ化できる一連のメトリックに依存しています。

GraphvizまたはBlockdiagに精通している人は、エクスポートのオプションを高く評価する可能性があります。ダッシュボード全体をJSONファイルに：

さらに多くのメトリックをアラートにリンクできます（リンクする必要があります）。

クエリ統計は、クエリストアを使用して追跡し、クエリパフォーマンスを使用して視覚化できます。洞察。そのためには、いくつかのAzure固有のパラメーターを有効にする必要があります。

[email protected]:5432 postgres> select * from pg_settings where name ~ 'pgms_wait_sampling.query_capture_mode|pg_qs.query_capture_mode';

-[ RECORD 1 ]---+------------------------------------------------------------------------------------------------------------------

name            | pg_qs.query_capture_mode

setting         | top

unit            |

category        | Customized Options

short_desc      | Selects which statements are tracked by pg_qs. Need to reload the config to make change take effect.

extra_desc      |

context         | superuser

vartype         | enum

source          | configuration file

min_val         |

max_val         |

enumvals        | {none,top,all}

boot_val        | none

reset_val       | top

sourcefile      |

sourceline      |

pending_restart | f

-[ RECORD 2 ]---+------------------------------------------------------------------------------------------------------------------

name            | pgms_wait_sampling.query_capture_mode

setting         | all

unit            |

category        | Customized Options

short_desc      | Selects types of wait events are tracked by this extension. Need to reload the config to make change take effect.

extra_desc      |

context         | superuser

vartype         | enum

source          | configuration file

min_val         |

max_val         |

enumvals        | {none,all}

boot_val        | none

reset_val       | all

sourcefile      |

sourceline      |

pending_restart | f

遅いクエリと待機を視覚化するために、クエリパフォーマンスウィジェットに進みます：

長時間のクエリ

待機統計

AzureでのPostgreSQLロギング

標準のPostgreSQLログをダウンロードするか、Log Analyticsにエクスポートして、より高度な解析を行うことができます。

Azureを使用したPostgreSQLのパフォーマンスとスケーリング

vCoreの数は簡単に増減できますが、このアクションによりサーバーの再起動がトリガーされます：

ダウンタイムをゼロにするには、アプリケーションが一時的なエラーを適切に処理できる必要があります。。

クエリを調整するために、Azureは、プリロードされたpg_statementsおよびpg_buffercache拡張機能に加えて、パフォーマンスの推奨事項をDBAに提供します。

Azureでの高可用性とレプリケーション

データベースサーバーの高可用性は、ノードベースのハードウェアレプリケーションによって実現されます。これにより、ハードウェア障害が発生した場合でも、数十秒以内に新しいノードを起動できます。

Azureは、リージョン内のすべてのデータベースサーバーのネットワーク接続エンドポイントとして冗長ゲートウェイを提供します。

AzureでのPostgreSQLセキュリティ

デフォルトでは、ファイアウォールルールはPostgreSQLインスタンスへのアクセスを拒否します。 Azureデータベースサーバーはデータベースクラスターと同等であるため、アクセスルールはサーバーでホストされているすべてのデータベースに適用されます。

IPアドレスに加えて、ファイアウォールルールは仮想ネットワークを参照できます。これは、汎用およびメモリ最適化層でのみ使用可能な機能です。

ファイアウォールのWebインターフェイスに特有の1つのこと—ナビゲートできませんでした変更が保存されている間、ページから離れる：

保存データはサーバー管理キーを使用して暗号化され、クラウドユーザーは暗号化できません暗号化を無効にします。転送中のデータも暗号化されます—必要なSSLは、データベースサーバーの作成後にのみ変更できます。保存データと同様に、バックアップは暗号化されており、暗号化を無効にすることはできません。

Advanced Threat Protectionは、セキュリティリスクと見なされる多数のデータベースアクセス要求に関するアラートと推奨事項を提供します。この機能は現在プレビュー中です。実例を示すために、パスワードブルートフォース攻撃をシミュレートしました：

~ $ while : ; do psql -U $(pwgen -s 20 1)@pg10 ; sleep 0.1 ; done

psql: FATAL:  password authentication failed for user "AApT6z4xUzpynJwiNAYf"

psql: FATAL:  password authentication failed for user "gaNeW8VSIflkdnNZSpNV"

psql: FATAL:  password authentication failed for user "SWZnY7wGTxdLTLcbqnUW"

psql: FATAL:  password authentication failed for user "BVH2SC12m9js9vZHcuBd"

psql: FATAL:  password authentication failed for user "um9kqUxPIxeQrzWQXr2v"

psql: FATAL:  password authentication failed for user "8BGXyg3KHF3Eq3yHpik1"

psql: FATAL:  password authentication failed for user "5LsVrtBjcewd77Q4kaj1"

....

PostgreSQLログを確認してください：

2019-08-19 07:13:50 UTC-5d5a4c2e.138-FATAL:  password authentication failed

for user "AApT6z4xUzpynJwiNAYf"

2019-08-19 07:13:50 UTC-5d5a4c2e.138-DETAIL:  Role "AApT6z4xUzpynJwiNAYf" does not exist.

   Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"

2019-08-19 07:13:51 UTC-5d5a4c2f.13c-LOG:  connection received: host=173.180.222.170 port=27248 pid=316

2019-08-19 07:13:51 UTC-5d5a4c2f.13c-FATAL:  password authentication failed for user "gaNeW8VSIflkdnNZSpNV"

2019-08-19 07:13:51 UTC-5d5a4c2f.13c-DETAIL:  Role "gaNeW8VSIflkdnNZSpNV" does not exist.

   Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"

2019-08-19 07:13:52 UTC-5d5a4c30.140-LOG:  connection received: host=173.180.222.170 port=58256 pid=320

2019-08-19 07:13:52 UTC-5d5a4c30.140-FATAL:  password authentication failed for user "SWZnY7wGTxdLTLcbqnUW"

2019-08-19 07:13:52 UTC-5d5a4c30.140-DETAIL:  Role "SWZnY7wGTxdLTLcbqnUW" does not exist.

   Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"

2019-08-19 07:13:53 UTC-5d5a4c31.148-LOG:  connection received: host=173.180.222.170 port=32984 pid=328

2019-08-19 07:13:53 UTC-5d5a4c31.148-FATAL:  password authentication failed for user "BVH2SC12m9js9vZHcuBd"

2019-08-19 07:13:53 UTC-5d5a4c31.148-DETAIL:  Role "BVH2SC12m9js9vZHcuBd" does not exist.

   Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"

2019-08-19 07:13:53 UTC-5d5a4c31.14c-LOG:  connection received: host=173.180.222.170 port=43384 pid=332

2019-08-19 07:13:54 UTC-5d5a4c31.14c-FATAL:  password authentication failed for user "um9kqUxPIxeQrzWQXr2v"

2019-08-19 07:13:54 UTC-5d5a4c31.14c-DETAIL:  Role "um9kqUxPIxeQrzWQXr2v" does not exist.

   Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"

2019-08-19 07:13:54 UTC-5d5a4c32.150-LOG:  connection received: host=173.180.222.170 port=27672 pid=336

2019-08-19 07:13:54 UTC-5d5a4c32.150-FATAL:  password authentication failed for user "8BGXyg3KHF3Eq3yHpik1"

2019-08-19 07:13:54 UTC-5d5a4c32.150-DETAIL:  Role "8BGXyg3KHF3Eq3yHpik1" does not exist.

   Connection matched pg_hba.conf line 3: "host all all 173.180.222.170/32 password"

2019-08-19 07:13:55 UTC-5d5a4c33.154-LOG:  connection received: host=173.180.222.170 port=12712 pid=340

2019-08-19 07:13:55 UTC-5d5a4c33.154-FATAL:  password authentication failed for user "5LsVrtBjcewd77Q4kaj1"

2019-08-19 07:13:55 UTC-5d5a4c33.154-DETAIL:  Role "5LsVrtBjcewd77Q4kaj1" does not exist.

メールアラートは約30分後に届きました：

データベースサーバーへのきめ細かいアクセスを可能にするために、AzureはRBACを提供します。これはクラウドネイティブのアクセス制御機能であり、PostgreSQLCloudDBAの武器庫にあるもう1つのツールです。これは、ユビキタスなpg_hbaアクセスルールにできるだけ近いものです。

AzureでのPostgreSQLのバックアップとリカバリ

料金階層に関係なく、バックアップは7〜35日間保持されます。価格階層は、データを復元する機能にも影響します。

ポイントインタイムリカバリは、Azure PortalまたはCLIを介して、最大5分までの詳細なドキュメントに従って利用できます。ポータルの機能はかなり制限されています。今日サーバーを作成しましたが、日付ピッカーウィジェットには、選択可能な日付として過去7日間が盲目的に表示されます。また、回復目標時間に対して実行された検証はありません—回復間隔外の値を入力するとエラーが発生し、ウィザードを続行できなくなると予想しました：

復元プロセスが開始されると、エラーが発生します。範囲値の、約1分後にポップアップします：

…しかし、残念ながら、エラーメッセージはあまり役に立ちませんでした：

最後に、バックアップストレージは最大7日間の保存期間で無料です。これは、開発環境にとって非常に便利であることがわかります。

ヒントとヒント制限単一サーバーの制限に慣れてください。

接続性

接続が正しいデータベースサーバーにルーティングされるようにするには、常に接続文字列を使用してください。

レプリケーション

ディザスタリカバリのシナリオでは、ペアになっているリージョンの1つでリードレプリカを見つけます。

ロール

AWSやGCloudの場合と同様に、スーパーユーザーアクセスはありません。

GUC

サーバーの再起動またはスーパーユーザーアクセスを必要とするパラメーターは構成できません。

スケーリング

自動スケーリング中、アプリケーションは新しいノードが起動するまで再試行する必要があります。

メモリ量とIOPSは指定できません—メモリはvCoreあたりGB単位で、最大320GB（32vCores x 10GB）まで割り当てられ、IOPSはプロビジョニングされたストレージのサイズに依存します。最大6000IOPS。現時点では、Azureは最大20,000IOPSの大容量ストレージプレビューオプションを提供しています。

基本層で作成されたサーバーは、汎用またはメモリ最適化にアップグレードできません。

ストレージ

自動拡張機能が有効になっていることを確認します—データ量がプロビジョニングされたストレージスペースを超えると、データベースは読み取り専用モードになります。

ストレージはスケールアップのみ可能です。他のすべてのクラウドプロバイダーと同様に、ストレージの割り当てを減らすことはできず、説明もありませんでした。最先端の機器を考えると、ビッグクラウドプレーヤーは、LVMオンラインデータ再配置と同様の機能を提供しない理由はないはずです。最近のストレージは本当に安いので、次のメジャーバージョンのアップグレードまでスケールダウンを考える理由はありません。

ファイアウォール

場合によっては、ファイアウォールルールの更新が反映されるまでに最大5分かかることがあります。

サーバーはアプリケーションサーバーと同じサブネットにあり、適切なファイアウォールルールが適用されるまで到達できません。

仮想ネットワークルールではクロスリージョンアクセスが許可されていないため、dblinkとpostgres_fdwを使用してAzureクラウド外のデータベースに接続することはできません。

VNet /サブネットアプローチは、接続がパブリックIPアドレスから発信されているため、Webアプリには適用できません。

サービスエンドポイントが有効になっている間、大規模な仮想ネットワークは利用できなくなります。

暗号化

サーバー証明書の検証が必要なアプリケーションの場合、ファイルはDigicertからダウンロードできます。 Microsoftはそれを簡単にし、2025年まで更新について心配する必要はありません：

~ $ openssl x509 -in BaltimoreCyberTrustRoot.crt.pem -noout -dates

notBefore=May 12 18:46:00 2000 GMT

notAfter=May 12 23:59:00 2025 GMT

侵入検知システム

Advanced Threat Protectionのプレビューリリースは、基本層インスタンスでは使用できません。

バックアップと復元

リージョンのダウンタイムを許容できないアプリケーションの場合は、地理的に冗長なバックアップストレージを使用してサーバーを構成することを検討してください。このオプションは、データベースサーバーの作成時にのみ有効にできます。

PITR操作後にクラウドファイアウォールルールを再構成するための要件は特に重要です。

データベースサーバーを削除すると、すべてのバックアップが削除されます。

復元後、実行する必要のある特定の復元後のタスクがあります。

パフォーマンスを向上させるために、一括挿入にはログに記録されていないテーブルをお勧めしますが、複製されません。

監視

指標は毎分記録され、30日間保存されます。

ロギング

クエリストアはグローバルオプションです。つまり、すべてのデータベースに適用されます。読み取り専用のトランザクションと6,000バイトを超えるクエリには問題があります。デフォルトでは、キャプチャされたクエリは7日間保持されます。

パフォーマンス

Query Performance Insightの推奨事項は、現在、インデックスの作成と削除に限定されています。

不要な場合はpg_stat_staementsを無効にします。

uuid_generate_v4をgen_random_uuid（）に置き換えます。これは、PostgreSQLの公式ドキュメントの推奨事項と一致しています。uuid-osspの構築を参照してください。

高可用性とレプリケーション

5つの読み取りレプリカの制限があります。レプリケーションメカニズムは非同期であるため、書き込みを多用するアプリケーションでは、リードレプリカの使用を避ける必要があります。これにより、アプリケーションが許容できる必要のある遅延が発生します。リードレプリカは別のリージョンに配置できます。

REPLICAサポートは、サーバーの作成後にのみ有効にできます。この機能にはサーバーの再起動が必要です：

リードレプリカはマスターノードからファイアウォールルールを継承しません：

レプリカの読み取りのフェイルオーバーは自動ではありません。フェイルオーバーメカニズムはノードベースです。

リードレプリカを構成する前に確認する必要のある考慮事項の長いリストがあります。

比較的小さなデータセットでテストした場合でも、レプリカの作成には長い時間がかかります。

バキューム真空

Azure Database for PostgreSQLにはアップストリームバキュームのデフォルト値が付属しているため、主要なパラメーターを確認してください。

[email protected]:5432 postgres> select name,setting from pg_settings where name ~ '^autovacuum.*';

               name                 | setting

-------------------------------------+-----------

autovacuum                          | on

autovacuum_analyze_scale_factor     | 0.05

autovacuum_analyze_threshold        | 50

autovacuum_freeze_max_age           | 200000000

autovacuum_max_workers              | 3

autovacuum_multixact_freeze_max_age | 400000000

autovacuum_naptime                  | 15

autovacuum_vacuum_cost_delay        | 20

autovacuum_vacuum_cost_limit        | -1

autovacuum_vacuum_scale_factor      | 0.05

autovacuum_vacuum_threshold         | 50

autovacuum_work_mem                 | -1

(12 rows)

アップグレード自動メジャーアップグレードはサポートされていません。前述のように、これは自動拡張ストレージを縮小することによるコスト削減の機会です。

PostgreSQLAzureの機能強化

時系列

TimescaleDBは拡張機能として利用できます（PostgreSQLモジュールの一部ではありません）が、数回クリックするだけです。唯一の欠点は古いバージョン1.1.1ですが、アップストリームバージョンは現在1.4.1（2019-08-01）です。

[email protected]:5432 postgres> CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;

WARNING:

WELCOME TO

_____ _                               _ ____________

|_   _(_)                             | | | _ \ ___ \

| |  _ _ __ ___   ___ ___ ___ __ _| | ___| | | | |_/ /

| | | |  _ ` _ \ / _ \/ __|/ __/ _` | |/ _ \ | | | ___ \

| | | | | | | | |  __/\__ \ (_| (_| | |  __/ |/ /| |_/ /

|_| |_|_| |_| |_|\___||___/\___\__,_|_|\___|___/ \____/

               Running version 1.1.1

For more information on TimescaleDB, please visit the following links:



1. Getting started: https://docs.timescale.com/getting-started

2. API reference documentation: https://docs.timescale.com/api

3. How TimescaleDB is designed: https://docs.timescale.com/introduction/architecture




CREATE EXTENSION



[email protected]:5432 postgres> \dx timescaledb

                                    List of installed extensions

   Name     | Version | Schema |                            Description

-------------+---------+--------+-------------------------------------------------------------------

timescaledb | 1.1.1   | public | Enables scalable inserts and complex queries for time-series data

(1 row)

ロギング

PostgreSQLのログオプションに加えて、Azure Database for PostgreSQLは、追加の診断イベントを記録するように構成できます。

ファイアウォール

Azureポータルには、ポータルにログインしているIPアドレスからの接続を許可するための便利な機能が含まれています。

開発者とシステム管理者が簡単にできる機能であることに気づきました許可してください。AWSでもGCloudでも提供されていない機能として際立っています。

結論

Azure Database for PostgreSQL Single Serverはエンタープライズレベルのサービスを提供しますが、これらのサービスの多くはまだプレビューモードです：クエリストア、パフォーマンスインサイト、パフォーマンス推奨、高度な脅威保護、大容量ストレージ、クロスリージョンレプリカを読む。

AzureクラウドでPostgreSQLを管理するためにオペレーティングシステムの知識は不要になりましたが、DBAは、データベース自体に限定されないスキル（Azureネットワーキング（VNet）、接続セキュリティ（ファイアウォール））を習得することが期待されています。）、ログビューアと分析、KQL、便利なスクリプト用のAzure CLI、そしてリストは続きます。

最後に、PostgreSQLワークロードをAzureに移行することを計画している場合は、PostgreSQLの主要なスポンサーおよび貢献者の1つであるCredativを含むAzureパートナーの選択リストとともに利用可能なリソースが多数あります。