2019年度WG3活動成果報告
クラウド検証編
Azure PostgreSQL PaaS検証
PostgreSQL エンタープライズコンソーシアム
WG3 パブリッククラウド検証チーム
日鉄ソリューションズ株式会社 伊藤 春

アジェンダ◼ 活動概要◼ Microsoft AzureにおけるPostgreSQL PaaSについて◼ 非機能要件の達成度(抜粋版)◼ ベンチマークテスト結果(抜粋版)

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

2

責任範囲
◼

本資料は、PGEConsが独自に検証した結果であり、結果はPGEConsの責任の元、公開しています。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

3

活動概要

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

4

検証の背景◼

近年、パブリッククラウドを利用する企業が増加しており、クラウド上でPostgreSQL等を利用したRDBを構築・運用する機会も増えてきている。

◼

各クラウドベンダはPostgreSQLを利用したPaaS/SaaS を提供しているが、クラウドベンダごとに独自の仕様となっている項目もあり、導入にあたってはサービス仕様の調査や性能評価等を通してサービス自体の評価を事前に行う事が必要になる場合が多い。

◼

この流れの中、パブリッククラウド班では2018年にAWSの検証に着手。
また2019年にMicrosoft Azureの検証に着手。


近年、Microsoft Azureを採用するケースも増えている中、AzureにおいてもPaaS型
PostgreSQLサービスが複数提供されていることから、これらの特徴を整理・比較することがサービス利用時の敷居を下げPostgreSQLの導入推進に繋がると想定。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

5調査・検証内容◼ Azure×PostgreSQLとしてどんな選択肢があるのか？
 サービスメニューの種類
 各メニューの特徴 等◼ 非機能要件の達成度は？
 可用性、拡張性、運用保守性 等◼ 性能は？
 ベンチマークの実行結果 等

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

6

補足◼ 結果の詳細については、後日公開される成果物をご参照ください。
◼ 検証結果は、Microsoft社にもご確認頂き、指摘・コメントを反映した内容となります。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

7

Microsoft AzureにおけるPostgreSQL PaaSについて
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

8

AzureにおけるPostgreSQL PaaS
◼ 2020年8月時点、AzureにおけるPostgreSQL PaaSであるAzure Database for PostgreSQLでは、2種類のデプロイオプションが利用可能
 SingleServer◼ ベーシックなマネージドRDBサービス

 Hyperscale(Citus)◼ Citus社が提供している、PostgreSQLサーバを分散DB化(シャーディング)させる拡張モジュール「citus」が組み込まれたサービス◼ 2020年8月時点で、SingleServerは全リージョンで、Hyperscaleは特定リージョンでのみ利用可能(東日本リージョンはリクエストベースで利用可能)
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

9

SingleServer◼

Azure Service Fabric上のWindowsコンテナ上で動く、PostgreSQLのマネージドサービス。

◼

コンテナ上で動いているため、障害時の復旧(切替)も高速だが、その分性能面では少しデメリットもある◼

利用者には、DBアクセス用のエンドポイントしか公開されておらず、サーバ・コンテナへの接続は出来ない。
接続アーキテクチャ◼

クライアントからの接続経路は、各DBコンテナへのアクセスを振り分ける
ゲートウェイを経由した接続となる
接続時に指定されたゲートウェイのIP
アドレス、DB名、ユーザ名 を元にゲートウェイがコンテナへと振り分ける。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

10

Hyperscale(citus)◼

Hyperscale(citus)とは？
 Citus Data社が提供している拡張モジュールである「citus」を組み込んだ、シェアードナッシング型のマネージド分散DBサービス。
 データは複数ノードに分散配置(シャーディング)され、また処理実行ノードをスケールアウト方式で拡張する事が可能
 司令塔となり、ワーカノードへクエリを振り分けるコーディネータノードと、データが格納され、SQLクエリが実行されるワーカノードとに分かれる
コーディネータノード・フロントアプリケーションとワーカーノードとを繋ぐ司令塔役
・対象データが格納されたワーカへのSQL投入、結果集約＋ソー
ト処理 等を担当
・アーキテクチャ上、シングルポイントではあるが、HAモードをONにすることで二重化が可能(後述)・拡張はスケールアップのみ対応(リクエストベース)

ワーカノード・データが実際に格納され、抽出・更新等の処理もこちらで実行される・データは、分散キーに指定されたカラムの値で格納先が判別される
・最低2台、最大20台までスケールさせることがが可能(※データリバランスによる負荷増は考慮が必要)
だが、一度増やしたノードを縮小する事は出来ない・リクエストベースで、スケールアップも可能
・可用性向上のためデータを複数ノードに重複し持たせることも可能。

フロントアプリケーションからの接続は、すべてコーディ
ネータノードを経由して行われる。また、直接ワーカーに接続することは出来ない点は、Azureならではの仕様。
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

11

Hyperscale(citus)◼ 以下3種類のテーブルを用途にあわせて利用する
項目

分散テーブル

参照テーブル

ローカルテーブル

概要

分散キーに指定したカラムの値を元に、ワーカーノードに分散配置(シャーディング)されるテーブル

全てのワーカーノードに、テーブル上の全データが複製配置されるテーブル

分散も複製もされず、コーディネータノード上に配置されるテーブル

用途

大規模トランザクション系テーブル等

マスタ系テーブル全般
件数規模が小さく、分散テーブルと頻繁に結合されるテーブル 等

運用管理系テーブル 等

補足

・DDLも自動で全ワーカーにカスケードされる・分散キー列の値の更新は不可
・オプションで、ワーカーノード間でデータを複製配置させることも可能(可用性向上のため)・分散テーブルと結合させて利用する事が多いマスタ系テーブルを、参照テーブルとして全ワーカにあらかじめ配置しておけば、ノードを跨いだ結合処理が起きず、パフォーマンス向上となる・テーブル作成時に分散or参照テーブルの指定が無いと、ローカルテーブルとしてコーディネータ上に作成されるコーディネータ

コーディネータ
ワーカー

ワーカー
全データが全ワーカに配置される

col1(分散キー)ごとにデータが配置
col1

col2

01

AA01

BB

col1
02

col2
CC

col1
03
03
03

コーディネータ

col2
DD
EE
FF

col1

col2

01

AA

コーディネータ上に配置される
ワーカー

col1

col2

col1

col2

col1

col2

01

AA

01

AA01

AA

01

BB01

BB01

BB

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

12非機能要件の達成度(サマリ版)

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

13可用性
項目

比較の観点

継続性

復元可能な直近の時間は 障害発生の5分前まで復元出来ることを保証。
何分前か
HA構成における切り替え時間の目安

SingleServer

ダウンタイムの目安(数値)について公開されている情報は無いが、対象インスタンスが稼働するコンテナを別のホストで起動し直し、GWのルーティングを変更する形での切替となるため、短時間での切替は可能とのこと

SLAとして年間何%の稼働 99.99% (SLAとして公表)率を規定しているか

耐障害性

災害対策

Hyperscale
2020年4月時点で、自動バックアップサービスは未実装。
SingleServerと同等の機能になるように、実装を検討中
高可用性オプションをONにすることで、コーディネータ/ワーカー各ノードが二重化される。
この際、データストレージ層はサーバから分離して構築されており、障害時にはストレージのアタッチ先を切り替える形で切替を実現する。切替時間の目安について公開されている情報は無し。
99.95% (SLAとして公表)

高可用性(HA)モードをONにすることで、サーバー グルーHAとしてサーバを多重化す コンテナ層は多重化されておらず、設定変更等で多る仕組みは何があるか重化させることも出来ない。そのため、障害時には別 プ内の全ノードを二重化することが可能。ノードがダウンすると、Hyperscale は、障害が発生したノードからそのスノードでの再起動が必要となる。
タンバイノードに受信接続を切り替える。これは数分で完了する。
データの多重化の仕組み
として何があるか実データが格納されるストレージ層は、データ同期方式で三重化されている。

高可用性(HA)モードをONにすることの他に、ワーカー側は同じデータを複数ノードに複製・配置することも可能。
(citus.shard_replication_factor パラメータを変更する)

広域圏災害における、DRの方式は何が用意されているか・リードレプリカを別リージョンに作成しておき、有事に リージョンをまたいだ切替・バックアップの仕組みは未実は手動で切り替える(自動切替機能は未実装)
装。
・GEO冗長バックアップをONにし、有事には別リージョンでインスタンスを手動リストアする

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

14

運用・保守性項目

比較の観点

SingleServer

Hyperscale

バックアップ

実行可能なバックアップ
方式についてAzureサービス側での自動バックアップサービスあり。 2020年4月時点で、自動バックアップサービスは未実装。
・対象はデータファイルとトランザクションログ
SingleServerと同等の機能になるように、実装を検討中
・頻度は、フルバックアップは週1回、スナップショット とのこと。
バックアップは1日1回～2回となる(サイズにより変わ pg_dumpでの手動バックアップは対応可能。バックアップる)
データは、全ワーカーのデータが集約された状態で取得さ・バックアップデータの冗長化サービスあり。(ローカル れる。
/GEO) GEOを選択すると、別リージョンにバックアップデータが保存される。

リストア

実行可能なリストア方式について

上記バックアップを用いて、バックアップのリテンション期間内の任意の時点へ、ポイントインタイムリカバリが可能。
別リージョンにリストアするためには、バックアップデー
タの冗長化でGEOを選択する必要があり。

障害監視

障害監視の実現方式につ サーバダウン等の障害を検知～通報してくれるサービスは無いが、Azureモニターの閾値監視を利用すれば、インスタンスの死活監視は可能。
いて例) DBへの接続エラー数(Failed Connection)が一定数を超過した場合、アラートメールを送信するように閾値監視の設定を入れる 等

性能管理

性能管理の実現方式につ CPU,メモリ,IO といったリソース監視は、Azureモニタ
いて―で監視可能。

CPU,メモリ,IO といったリソース監視は、Azureモニタ―で監視可能。

クエリ ランタイム統計や待機イベントといったDB層の クエリ ランタイム統計や待機イベントといったDB層の性性能監視は、Query Performane Insightで監視可能。 能監視は、Query Performane Insightで監視可能。ただ
ただしクエリストア機能を事前にONにしておく必要が しクエリストア機能を事前にONにしておく必要があるためあるため注意が必要。
注意が必要。
計画停止

計画停止の有無・タイミングなどについて月一回程度、計画停止によるコンテナのマイグレーションが発生。事前に通知は来るが、アラートが飛ぶ
停止タイミングの調整は不可能。ダウンタイムは1分程度。

計画停止は無し。動作するVMのセキュリティパッチ適用など、緊急性の高いメンテナンスが必要になった場合は事前に通知が来る。停止タイミングの調整も可能。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

15

コミュニティ版PostgreSQLとの違い/制約事項
項目

比較の観点

SingleServer

Hyperscale

VACUUM/ANALY VACUUM/ANALYZEの実
ZE
行方法、実行タイミングなど
インデックスリビ
ルド

psql

アプリケーション
接続
パラメータ設定

実行方法や実行周期・起動トリガなど、すべてコミュニ 実行方法や実行周期・起動トリガなど、すべてコミュニティ
ティ版Postgresと同様。autovacuumも実行可能だが、 版Postgresと同様。autovacuumのON/OFFも切り替え
逆にautovacuumをOFFにすることは出来ない。(パラ 可能。
メータ変更不可)REINDEXやpg_repackの利 reindexコマンドは実行可能。
reindexコマンドは実行可能。
用可否など
pg_repackは未サポート。
pg_repackは未サポート。

psqlによる接続の可否、利 コミュニティ版Postgres同様、利用可能だが、接続先 コミュニティ版Postgres同様利用可能だが、接続先は用制約、注意事項など
ホスト名・DB名・ユーザ名は接続時に明示的に指定す コーディネータノードに限られる。(コミュニティ版Citusのよる必要がある。(対話式が未対応)
うに、ワーカーノードに直接ログインすることは出来ない)→ 全利用者で共通のGWを経由して振り分けられる
ため
アプリケーションからの接 エンドポイントURLを指定する以外、コミュニティ版
エンドポイントURLを指定する以外、コミュニティ版
続方法、接続用ドライバ等 PostgreSQLとの違いは特にない
PostgreSQLとの違いは特にない
設定方法
変更可能なパラメータは「サーバーパラメータ」として用意されており、AzurePortalからはもちろん、Azure CLIからも変更可能。ただしALTER SYTEMコマンドは実行不可能。
コミュニティ版との違い/制 WALアーカイブをOFFに出来ないなど、バックアップ運約事項
用を決定するようなパラメータは軒並み変更不可。まコーディネータ/ワーカーそれぞれに対して「PostgreSQL」
たautovacuumもOFFに出来ない、shared_bufferが変のパラメータと「Citus」のパラメータ設定が可能だが、い更出来ないなど、全体的にAWSのPaaSと比較するとずれも設定可能なパラメータは制限されている。
変更可能なパラメータはやや少ない(104個のみ)

EXTENSION

EXTENTIONの対応状況

適用可能なextension、およびそのバージョンは、MS社サイトに公開されている情報、もしくはpg_available_extensionsビューを参照すれば確認可能。
適用にはcreate extensionを用いる。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

16

ベンチマークテスト結果(概要)Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

17

実機検証計画(性能測定)◼

ベンチマークテストの概要は以下の通り
 ベンチマークシナリオ、実行方法、パラメータ設定等の条件は、AWS検証時の内容を流用

項目

SingleServerHyperscale

ベンチマーク種別/ツール

単純参照、単純更新 ：pgbench
業務トランザクション(TPC-C) ：HammerDB(2020年度に実施予定)

CPU/メモリ

メモリ最適化タイプ
8コア80GB
32コア320GB

ストレージ

500GB(IO上限：1500IOPS)

多重度

１，４，１６，３２、６４，９６

PostgreSQL Ver

10.6

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

18

検証結果
◼ pgbench(参照系)検証
7000

8vCPU(TPS) 32vCPU(TPS)

189.73353

167.3619

4303.5597

752.7121

16705.5004

3069.27232

737.6824

5668.561

64728.0791

6452.567

96718.3075

6391.86

6000
5000

TPS

多重度

参照系

4000
3000

2000
1000
0
1

416326496

多重度8コア32コア◼

多重度に比例しスループットも増加。8コアでは多重度16近辺、32コアでは多重度32～64近辺を上限にスループットの上昇が止まり、それ以上は減少へと向かう◼

スループットの限界地点でCPU使用率が100%付近に達しており、単純参照処理としての性能は、この多重度が上限ラインになると考えられる。
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

19

検証結果
◼ TPC-C(HammerDB)検証
TPC-C

多重度

8vCPU(TPM)

32vCPU(TPM)

13585.667

3294

90000
80000
70000

411113.67

11467.67

1637962.33

37968.67

325055443617.67

64

55976

69821.679664452.67

79063

TPM

60000
50000
40000
30000
20000
10000
0
14166496

多重度
8コア

◼

3232コア

多重度と共にスループットは上昇し続けたが、96多重まで上げても頭打ちとなることは無かった。また64多重までの間は8コアと32コアとの間でスループットに差が見られなかった。


32コア側のリソース使用率を確認すると、CPU使用率にはまだ余裕があったが、IO使用率は60～80%に近い値で推移(瞬間的に100%を記録することもあり)していた。このことから、IOネックになっていた可能性が高く、再試験を実施。(次項)
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

20

再検証結果◼ TPC-C(HammerDB)検証

I/O制限を外した状態で再試験(ストレージサイズを6667GBに変更)
TPC-C

多重度

32vCPU(TPM)
500GB

32vCPU(TPM)
6667GB

13294-

411467.67-

1637968.67

39022

140000120000TPM

100000
80000
60000
40000

3243617.6765309

6469821.67-9679063

126668

20000

0
1

4

326496

多重度
8コア◼

16

32コア_500GB

32コア_6667GB

I/O制限がかかっていた状態と比べると、32多重以降で大きくスループット値が上昇した。この事から、I/Oネックでスループットが伸び悩んでいたことが明確であり、SingleServer利用時にはデータサイズだけでなく、I/O制限の事も考慮したストレージサイジングが重要であることが分かった。
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

21

結果まとめ◼ Microsoft AzureにおけるPostgreSQL PaaSの種類、特徴等について、Microsoft社の協力の下色々な視点で確認をすることが出来た。
 非機能要件の達成度としては、他のパブリッククラウドサー

ビスと比べ同等な面もあれば、達成度が異なる点も見られるため、事前に差異を確認・認識しておくことが望ましい。
 性能面(SingleServer)においては概ね予想通りの結果となったが、IOPSの上限値がストレージサイズによって決まる点は注意が必要。またより高スループットを目指す場合はHyperscale(citus)の採用や今後GA予定のSingleServer
Gen2を選択肢の一つとして考慮する事が望ましい。
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

22