Azure Database for PostgreSQLを使い始めるにあたって

オープンソースソフトウェア（OSS）のリレーショナルデータベース管理システム（RDBMS）は、クラウドコンピューティングで使用度が増しています。人気のあるOSSリレーショナルデータベースの1つであるPostgreSQLと、このデータベースをMicrosoft Azureクラウドで利用する時のオプションについてです。これらの製品は大規模で細かい部分も多いので、このブログは各製品のざっくりとした説明です。

1 Azure Database for PostgreSQLは：
2 Azure Database for PostgreSQL-Single Server
3 Azure Database for PostgreSQL-Flexible Server
4 Azure Database for PostgreSQL-Hyperscale
5 PostgreSQLに適したAzure PaaSの選択

Azure Database for PostgreSQLは：

Azure Database for PostgreSQLは、Azureクラウドプラットフォーム上でホストされる、リレーショナルデータベースPostgreSQLのMicrosoft platform as a service（PaaS）実装である。Microsoft PaaSプラットフォーム上で動作するPostgreSQL製品は、OSS開発者にオンプレミス版のPostgreSQLとほぼ完全に同等の機能を提供し、リレーショナルデータベース管理者の日常タスクの大部分を自動化します。

PaaSサービスの最大の利点の1つは、管理という大変な作業のほとんどをクラウドプロバイダが代行してくれることです。例えば、RDBMSのPaaSサービスでは、通常バックアップを行い、何らかの高可用性、セキュリティ、メンテナンス、ロギングを提供します。PaaSは日常的な管理のほとんどを引き受けてくれるため、DBAや開発者はビジネス価値のある時間に集中することができます。

PaaSサービスのもう一つの利点は、必要に応じてリソースのスケールアップとスケールバックを行えることです。例えば、年末年始の繁忙期に仕事を完了させるために、より多くの処理リソースが必要になるなど、アプリケーションに周期的な使用パターンがある場合、これは非常に便利です。

Azureでは、Azure VMにPostgreSQLエンジンをインストールし、自分のデータセンターでサーバを管理するように、管理と日々のニーズを処理するオプションもあります。このIaaS（Infrastructure as a service）アプローチの利点は、マシンとデータベースサービスをどのように管理するかについて、依然として最高度の制御が可能であることです。PostgreSQLデータベースエンジンの管理だけでなく、基盤となるOS（Linux？）に対する必要なパッチ適用にも責任を負います。

VMの高可用性はAzureによって提供され、Azureの基礎となるストレージシステムにもアクセスすることができます。これにより、高い可用性とシステムに必要なだけのスループット、そしてセキュリティと冗長性を実現します。

Azure Database for PostgreSQL-Single Server

Azure Database for PostgreSQL Single Server（以下、Single Server）は、AzureがPaaSプラットフォームで提供する初のPostgreSQLです。Single Serverでは、データベースと基盤となるOSの定期的な管理のほとんどを代行してくれます。例えば、バックアップは自動で行われ、必要に応じてデータベースをある時点に復元することも可能です。

基礎となるOS（Windows for Single Server）はユーザのために管理され、管理者であるユーザはアクセスすることはできません。

Single Serverを構成する際には、3つの価格帯を選択することができます。

1. ベーシック – ベーシックは、サービスの使用感を確認したり、アプリケーションを開発したりするのに適しています。ベーシック – ベーシックは、サービスの使用感を確認したり、アプリケーションを開発したりするのに適しています。アプリケーションがほとんど動作しない場合を除いて、この階層を本番レベルのアプリケーションに使用することはあまりありません。

2. 汎用 – 本番環境のワークロードに適しています。

3. Memory Optimized(メモリ最適化) – Memory Optimized層は、より多くの仮想コアが利用可能で、仮想コアあたりのメモリがより多い、より高速なVMセット上にあります。また、本番環境のワークロードに適しています。

汎用層とメモリ最適化層の主な違いは、製品での利用可能なリソースです。

現在Single Serverの大きな問題の1つは、Single Serverへの接続は、データベースサービスの物理的な場所へのルーティングを担当するゲートウェイを経由して確立されることです。このゲートウェイ・サービスは、データベース・サービスへの接続を確立するための追加作業であるため、接続によっては速度が低下する可能性があります。

しかし、Single Serverサービスの最も大きな制限は、Azureアプリケーション層をデータベース層と同じ物理的な場所（Availability Zoneと呼ばれる）に併設できないことだと考えられます。理想的には、アプリケーションとデータベースが同じデータセンターにあることで、両者間の通信のレイテンシーを極限まで小さくすることができます。残念ながら、Single Serverではこれを指定するオプションがないため、パフォーマンスの問題が発生する可能性があります。

オンプレミスのPostgreSQLやクラウド事業者のVM上で動作するPostgreSQLからAzure PostgreSQLへの移行は、PostgreSQLデータベースをダンプしてSingle Serverにリストアするか、データベース移行サービスを利用するかのいずれかを選択することになる。

Azure Database for PostgreSQL-Flexible Server

Azure Database for PostgreSQL Flexible Serverは、PostgreSQLデータベースエンジンの構成をより細かく制御でき、Single Serverにはない便利な機能も備えています。Flexible Serverを選択する主な利点の1つは、アプリケーションを実行しているVMをPostgreSQLデータベースエンジンと同じ場所に配置できることです。この機能は、上で説明したパフォーマンスの問題を回避できるため、Flexible Serverを利用する最も魅力的な機能です。

pgBouncerはPostgreSQL専用のコネクションプーリングサービスで、PostgreSQLエンジンが再利用のために接続のプールを維持するための軽量なメカニズムを提供します。PostgreSQLの接続はリソースが高いことで知られており、pgBouncer（もしくは他の接続プーラ）を使用することは、データベースへの多くの接続を確立し維持する必要があるアプリケーションにとって重要です。

Flexible Serverには、PostgreSQLデータベースの定期的なパッチ適用と定期的なメンテナンスを行うための設定可能なメンテナンスウィンドウもあり、アプリケーションのスケジュールに合わせて設定することができます。これにより、管理者はこれらの更新を適用する特定の日付と時間のウィンドウを選択することができます。一般に、データベースへのトラフィックが少ない時間帯に適用されるので、メンテナンス発生時のアプリケーションの中断を最小限に抑えることができます。

Flexible Serverの主な欠点は、ストレージのサイズが16TBに制限されていることです。ほとんどのアプリケーションはこの大きなサイズ制限に近づくことはありませんが、特にOracleからPostgreSQLへの移行を考えているアプリケーションでは、16TBの制限がネックになるものもあります。そこで、PostgreSQLの最終層であるHyperscaleの出番となるわけです。

Azure Database for PostgreSQL-Hyperscale

2019年初めに、MicrosoftはCitus Dataという会社を買収し、PostgreSQLデータベースエンジンの拡張機能を作成して、データベーステーブルを水平方向にスケールするようにしました（シャーディングと呼ばれることもあるアクティビティです）。この機能は、Azure Database for PostgreSQL Hyperscaleと改名され、データベース開発者は、データの一部がトポロジー内の異なるワーカーノード（つまりサーバ）に分散されるようにテーブルを設計し、単一サーバーで可能な処理能力を超えることができるようになりました。

分散される各テーブルについて、1つの分散カラムを選択し、テーブルから異なるノードに値を決定論的にマッピングする方法を決定するために使用する必要があります。この分散カラムはテーブルごとに指定する必要があるため、オンプレミスやクラウド版のPostgreSQL、OracleからAzure Database for PostgreSQL Hyperscaleへの移行は簡単な作業ではありません。Hyperscaleの構成に関わるノード（サーバーグループとも呼ばれる）は2種類あります。

1. Coordinatorノード: Hyperscaleクラスタへの入口となるノードです。アプリケーションの接続を受け付け、アプリケーションから送信されたSQLクエリをさまざまなワーカーノードに中継し、その結果をエンドユーザーに返します。

2.Worker(ワーカ)ノード: 分散されたデータを保存するサーバーグループのノードです。クエリーエンジンは、データが異なるワーカーノードにどのように分散されているかを把握し、発行されるクエリーを満たすために必要な情報を各ノードからコーディネータノードに引き出します。需要の増加に応じて、既存のワーカーノードのリソースを拡張したり、必要に応じてワーカーノードを追加したりすることができます。Azureポータルを通じて、最大20ノードまでワークロードをスケールアウトすることができ、Microsoftと直接連携すれば、さらに多くのノードに拡張できる可能性があります。

Hyperscaleの高可用性は、スタンバイ・レプリカへのレプリケーションによって実現されます。これを有効にすると、各ノード（コーディネータノードと各ワーカーノード）は、データのレプリケーション先となるスタンバイレプリカを受け取ります。トポロジーに関わるサーバーの台数が2倍になるため、コストも2倍になることに注意してください。

また、Azure PostgreSQL Hyperscaleには3種類のテーブル分類があり、どのテーブルタイプをいつ使うかを理解することが重要です。

1. 分散テーブル：異なるワーカーノード間で水平にパーティショニングされ、各ノードがテーブル内のデータのサブセットを持ちます。テーブルを分散させるには、テーブルを定義する際に分散カラムを選択する必要があります。分散カラムの値は異なるワーカーノードにマッピングされるため、分散カラムを定義する際には十分な注意が必要です。カラムの選択が不適切だと、結合のコロケーションがうまくいかず、テーブル間の結合の際にかなりの量のデータ移動が必要になることを意味します。ほとんどのアプリケーションでは関連するテーブルが存在するため、これは Azure Database for PostgreSQL Hyperscale を使用する際の最大のハードルの 1 つになるかのしれません。

２．参照テーブル：これは一般的に、より大きなテーブルに頻繁に結合される小さなルックアップシステムテーブルで、各ワーカーのノードにコピーされます。データは複製されますが、他のワーカーノードからのデータを必要としないローカルな結合であることが利点です。

3.ローカルテーブル：コーディネータノードにのみ存在し、ワーカーノードには存在しないテーブルです。例えば、他のテーブルと結合することのない小規模な管理テーブルなどです。

PostgreSQLに適したAzure PaaSの選択

Azure Database for PostgreSQLに移行する場合、適切なPaaSの導入オプションを選択することが非常に重要です。Single Serverは、高度なスループットを必要としない小規模なアプリケーションを対象としています。Flexible Serverは、Single Serverよりも全体的な処理能力が高く、Windowsへのパッチ適用など管理の柔軟性が高く、pgBouncerなどの機能が組み込まれている新しい、より高度なサービスです。Hyperscaleは水平方向のスケールアウトで、データはワーカーノードに分散され、コーディネーターノードがワーカーノードに対してクエリを発行して結果を調整し、エンドユーザにデータを返します。

ユーザのPaaSの導入オプションが何であれ、クライムはPostgreSQLパフォーマンス監視ソリューションを提供し、クエリチューニング、I/Oチューニングなどを支援します。