AzureのマネージドPostgreSQLサービス「Azure Database for PostgreSQL Flexible Server」において、Premium SSD v2が一般提供（GA）に到達しました。対応リージョンは48に広がり、これまでとは根本的に異なるストレージ設計が正式に利用可能となっています。
Premium SSD v2が変えること
これまでのAzureストレージでは、IOPSを増やすためにはディスクサイズを拡張するか、より上位のSKUへ移行するしかありませんでした。Premium SSD v2はこの制約を取り払い、ストレージ容量・IOPS・スループットを互いに独立してスケールできる設計になっています。
主な仕様は以下の通りです。
項目 最大値
IOPS 80,000 IOPS
スループット 1,200 MiB/s
ストレージ容量 64 TiB
従来のPremium SSDでは、1 TiBのディスクで得られるIOPSはおよそ5,000程度でした。それ以上が必要なら容量を増やすかUltra Diskへ移行するしかなく、「容量は十分なのにIOPSのためだけに費用を払う」という非効率な状況が生まれがちでした。Premium SSD v2では、1 TiBのままで20,000 IOPSを設定するといった組み合わせが可能になります。
どんなワークロードに有効か
Microsoftが特に推奨しているのは次のケースです。
- OLTP（オンライントランザクション処理）：小さなトランザクションが大量に並列発生するシステム。ECサイトの注文処理、金融系のリアルタイム処理など
- SaaSアプリケーション：多数のテナントが同時アクセスするマルチテナント構成
- 高並列ワークロード：多数のコネクションが同時に読み書きを行うシステム
逆に、バッチ処理中心や読み取り比率が非常に高いシステムでは、従来のPremium SSDでも十分な場合があります。ワークロードの特性をまず把握することが先決です。
実務への影響
コスト設計の見直し機会
日本のシステムでよく見られるのが「念のため大きめのディスクを確保する」という設計です。これはコスト過剰を生みやすいパターンでした。Premium SSD v2では容量とIOPSを切り離せるため、実際の要件に合わせた細かい最適化が可能になります。
移行は段階的に
既存のFlexible Serverインスタンスであれば、ダウンタイムを最小限に抑えた移行手順が用意されています。まず開発・ステージング環境で試し、pg_stat_bgwriterやpg_stat_ioなどでI/Oパターンを計測してから本番移行を検討するのが現実的です。
監視設計も合わせて見直す
IOPSをプロビジョニングで制御できるということは、上限設定のミスが性能問題に直結するリスクも意味します。Azure Monitorでdisk_iops_consumed_percentageなどのメトリクスをきちんと監視し、閾値アラートを設定しておくことを強くお勧めします。良い武器も使い方を誤ると逆効果になります。
筆者の見解
Azureのデータベースサービスは、派手さはないものの着実に進化を続けています。Premium SSD v2のGAは地味な発表に見えますが、PostgreSQLで大規模な業務システムを動かしているエンジニアにとっては「ようやく来た」と感じる機能のひとつでしょう。
特に評価したいのは「容量と性能の分離」というコンセプトです。クラウドの強みは柔軟なスケールにあるはずなのに、ストレージだけが「容量を増やさないとIOPSが増やせない」という制約で縛られていたのは、長年の設計上の課題でした。この解決は、エンジニアが本来やりたかった「要件に応じた最適化」を現実的な選択肢にするという意味で、本質的な改善です。
一方で、こうした細かいパラメータを適切に設定・監視するには相応の知識が必要です。「とりあえずv2に変えれば速くなる」というわけではなく、ワークロードの特性をきちんと把握した上で使わないとコストが無駄になります。プラットフォームが進化すればするほど、使う側の設計力も問われる——そのことは忘れないようにしたいところです。
Azureのデータサービスが持つポテンシャルは本物です。あとは、こういった良い機能をユーザーが迷わず使いこなせるよう、ドキュメントやベストプラクティスの充実に引き続き力を入れてほしいところ。良いものを作っても届かなければもったいない——そこへの期待は変わりません。
出典: この記事は Premium SSD v2 Is Now Generally Available for Azure Database for PostgreSQL の内容をもとに、筆者の見解を加えて独自に執筆したものです。