前回ではPaaSを利用することで運用コストの大幅な削減が可能な点を記載しました。今回はAzure Database for PostgreSQLの特長を記載します。
価格レベル
Azure Database for PostgreSQLの価格レベル
Azure Database for PostgreSQLは価格レベルによって、スペックが異なるので注意が必要です。
価格レベルとスペックに関しては以下のとおりです。
| Basic | 汎用 | メモリ最適化 | |
|---|---|---|---|
| 仮想コア | 1,2 | 2,4,8,16,32,64 | 2,4,8,16,32 |
| 仮想コアあたりのメモリ | 2GB | 5GB | 10GB |
| ストレージサイズ | 5 GB ~ 1 TB | 5 GB ~ 16 TB | 5 GB ~ 16 TB |
| データベースバックアップのリテンション期間 | 7 ~ 35日間 | 7 ~ 35日間 | 7 ~ 35日間 |
| ストレージの増分サイズ | １GB | １GB | １GB |
| IOPS | 変数 （IOPSは保証されない） |
3 IOPS/GB 最小 100 IOPS 最大 20,000 IOPS |
3 IOPS/GB 最小 100 IOPS 最大 20,000 IOPS |
例えば、価格レベルが汎用の場合、2コアから64コアまでコア数が用意されています。1コア当たりのメモリ容量も決まっており、1コアあたり5GBなので、2コアで10GBとなります。
IOPSも特徴的で、ディスク1GB当たり3IOPSとなります。例えば100GBのディスクで構成した場合300IOPSがディスクのスペックとなります。
ストレージの拡張機能
ディスクは自動拡張機能がついており、最大16TBまで自動で拡張を行ってくれます。
割り当て容量が100GB未満 ：空き容量が1GBまたは10％のどちらか大きい方を下回った場合、5GB単位で拡張
割り当て容量が100GBより大きい：空き容量が5%を下回った場合、割り当てディスクの5％単位で拡張
また、ディスクはスケールアップのみでスケールダウンできない事に注意が必要です。自動拡張がOFFの場合は以下の条件で読み取り専用となってしまいます。
・割り当て容量が100GB未満の場合は空き容量が512MBあるいは5%を下回る場合
・割り当て容量が100GBより多き場合空き容量が5GBを下回る場合
最大接続数
Azure Database for PostgreSQLでは最大接続数が定義されています。
以下の表に記載されている接続数以上の接続は基本的にできないので注意が必要です。
| 仮想コア | 最大接続数 | 最大ユーザ数 | |
|---|---|---|---|
| Basic | 1 | 55 | 50 |
| Basic | 2 | 105 | 100 |
| 汎用 | 2 | 150 | 145 |
| 汎用 | 4 | 250 | 245 |
| 汎用 | 8 | 480 | 475 |
| 汎用 | 16 | 950 | 945 |
| 汎用 | 32 | 1500 | 1495 |
| 汎用 | 64 | 1900 | 1895 |
| メモリ最適化 | 2 | 300 | 295 |
| メモリ最適化 | 4 | 500 | 495 |
| メモリ最適化 | 8 | 960 | 955 |
| メモリ最適化 | 16 | 1900 | 1895 |
| メモリ最適化 | 32 | 1987 | 1982 |
Azure Database for PostgreSQLの監視用に5接続は確保される。
セキュリティ
セキュリティに関してもデフォルトで様々な設定を行ってくれます。
クライアントとの接続は基本的には暗号化による通信が行われます。また、ディスク上ではデータが常に暗号化されており、バックアップデータももちろん暗号化されています。また、これら保存中のデータは原則として暗号化を無効にすることはできません。
- Azure Database for PostgreSQLとクライアント間は規定で暗号化（SSL/TLS)が適用。
- 保存中のデータ（クエリ実行中の一時ファイルを除く）はディスク上で常に暗号化される。
- バックアップに含まれるデータは基本的には暗号化される。
- 保存中のデータの暗号化を無効にすることはできない。
接続
VNET サービスエンドポイントを使用し、VNETの特定のサブネットからのインターネットを経由せずに通信を許可することが可能。（価格レベルが汎用、メモリ最適化のみ）
バックアップとGeoレプリケーションバックアップ
バックアップは自動で取得されます。各価格レベルごとに、推定復旧時間(ERT)と目標復旧時点(RPO)が定められています。
同一のリージョンであればバックアップは保存期間内の任意のポイントに復元することが可能です。
またAzure Database for PostgreSQLでは地理的な数百キロ離れた場所へバックアップを取得しリストアすることも可能です。このバックアップの事をGeoレプリケーションバックアップ、リストアの事をGeoリストアといいます。この場合でも、推定復旧時間は12時間以内、目標復旧時点は1時間以内にて復旧を行う事が可能です。
| Basic | 汎用 | メモリ最適化 | |
|---|---|---|---|
| バックアップからのポイントインタイムリストア | リテンション期間内の任意の復元ポイント | リテンション期間内の任意の復元ポイント | リテンション期間内の任意の復元ポイント |
| Geo レプリケーション バックアップからの geo リストア | サポートされない | ERT < 12 時間 RPO < 1 時間 |
ERT < 12 時間 RPO < 1 時間 |
バックアップの頻度
バックアップの頻度はストレージの容量によって変わります。4TB以下は完全バックアップを毎週取得し、差分バックアップは1日2回取得します。
4TB以上のストレージとなるとバックアップはスナップショットバックアップが取得さるようになり、少なくともスナップショットは1日に1回実行されます。
トランザクションログのバックアップは5分毎に取得します。
- 最大ストレージが4TB の場合 ：完全バックアップは毎週、差分バックアップは1日に2回。
- 最大ストレージが4TB より大きい：スナップショットバックアップを少なくとも1日に1回実行。
- トランザクションログバックアップ：５分毎にバックアップ。
監視
Azure Database for PostgreSQLではデフォルトで以下のメトリックが使用可能な状態となっています。
| メトリック | 説明 |
|---|---|
| cpu_percent | 使用されている CPU使用率 |
| memory_percent | 使用されているメモリ使用率 |
| io_consumption_percent | 使用されている IO使用率 |
| storage_percent | 使用されているストレージ使用率 |
| storage_used | 使用されているストレージ容量 データベースファイル、トランザクションログ、サーバーログ含む |
| storage_limit | 最大のストレージ容量 |
| serverlog_storage_percent | 使用されているログストレージの使用率 |
| serverlog_storage_usage | ログストレージの使用量 |
| serverlog_storage_limit | 最大のログストレージ |
| active_connections | アクティブ接続する |
| connections_failed | 接続失敗数 |
| network_bytes_egress | ネットワーク送信量 |
| network_bytes_ingress | ネットワーク受信量 |
| backup_storage_used | バックアップストレージの使用量 |
| pg_replica_log_delay_in_bytes | マスターと最も遅れているレプリカの間のバイト単位でのラグ |
| pg_replica_log_delay_in_seconds | 最後に再生されたトランザクションからの時間 |
Query Performance Insight
Azure Portalより確認可能なパフォーマンスの可視化ツールが容易されており、長時間実行クエリや待機イベントの確認が可能です。パフォーマンス分析する際には非常に重宝するツールとなります。使用にはクエリストアを有効にする必要があります。（Azure PortalのAzure Database for PostgreSQLで設定可能）
最後に
Azure Database for PostgreSQLでは、ユーザのデータベース運用コストを削減できるような様々な機能が搭載されているように思います。
次回は
Oracle DatabaseからAzure Database for PostgreSQLへの移行について検討していきたいと思います。