Premium SSD
Azure Premium SSD は、入出力 (IO) 負荷の高いワークロードを備えた仮想マシン (VM) に対して、高パフォーマンスで待機時間の短いディスク サポートを提供します。 Premium SSD ユニットは、ミッションクリティカルな運用アプリケーションに適しています。 Premium Storage ディスクをプロビジョニングすると、容量、IOPS、スループットが保証されます。 たとえば、P40 ディスクを作成した場合、Azure では、そのディスクに対して 2,048 GB のストレージ容量、7,500 IOPS、250 MB/秒のスループットがプロビジョニングされます。 アプリケーションでは、容量とパフォーマンスのすべてまたは一部を使用できます。 Premium SSD は、1 桁のミリ秒の遅延と、前出の表に示した目標 IOPS とスループットを、99.9% の確率で提供するように設計されています。
サポートされる最大ストレージ サイズは Premium SSD で 32 TiB であるため、最大 20,000 IOPS と 900 MB/秒のスループットをスケールアップできます。 Premium SSD v2 に切り替えることで、80,000 IOPS と 1,200 MB/秒のスループットをサポートして、最大 64 TiB にスケールアップできます。
プロビジョニングするストレージは、Azure Database for PostgreSQLフレキシブル サーバーで使用できるストレージ容量です。 このストレージは、データベース ファイル、一時ファイル、トランザクション ログ、PostgreSQL サーバー ログ用に使用されます。 プロビジョニングするストレージの合計容量によって、ご利用のサーバーで使用できる I/O 容量も決まります。
仮想マシンの種類によっても IOPS の制限が発生します。 サーバーの種類とは別に任意のストレージ サイズを選択できますが、特にいくつかの仮想コアを持つサーバーを選択する場合は、ストレージが提供するすべての IOPS を使用できない場合があります。 詳細については、 Azure Database for PostgreSQL のコンピューティング オプションに関するページを参照してください。
注
インスタンスに割り当てるストレージの種類にかかわらず、ストレージは拡張のみ可能で、縮小はできません。
I/O 使用量の監視は、Azure portal 内、または Azure CLI コマンドを使用して行うことができます。 監視すべき関連メトリックは、容量の上限、ストレージの割合、ストレージの使用量、および I/O の割合です。
ストレージの自動拡張 (Premium SSD)
ストレージの自動拡張を使用すると、サーバーで常に十分な空き領域を利用可能な状態に保つことができ、ストレージ使用量が 95% に達した場合や、使用可能な容量が 5 GiB 未満になった場合にサーバーが読み取り専用になるのを防ぐことができます。 ストレージの自動拡張を有効にすると、ワークロードに影響を与えずにディスク サイズが増加します。 ストレージの自動拡張は、Premium SSD ストレージ層でのみサポートされます。
プロビジョニングされたストレージが 1 TiB を超えるサーバーの場合、使用可能な領域が合計容量の 10% または 64 GiB を下回ると、2 つの値のうちいずれか小さい方がストレージ自動拡張メカニズムがアクティブになります。 逆に、記憶域が 1 TiB 以下のサーバーの場合、このしきい値は、使用可能な空き領域の 20% または 64 GiB に調整されます。これらの値のうちどれが小さいかによって異なります。
例示の例として、ストレージ容量が 2 TiB (1 TiB を超える) のサーバーを考えてみましょう。 この場合、自動拡張の制限は 64 GiB に設定されます。 この選択は、2 TiB の 10% (約 204.8 GiB) と比較すると、64 GiB の方が小さい値であるためです。 これに対し、ストレージ サイズが 128 GiB (1 TiB 未満) のサーバーでは、残りの領域が 25.8 GiB しかない場合に自動拡張機能がアクティブになります。 このアクティブ化は、割り当てられたストレージの合計 (128 GiB) の 20% のしきい値に基づきます。これは 64 GiB よりも小さな値であるためです。
既定の動作では、ディスク サイズが次の Premium SSD ストレージ サイズに増加します。 この増加は、ストレージのスケーリング操作を手動で開始するかストレージ自動拡張を使用するかに関係なく、サイズとコストの両方で常に 2 倍になります。 ストレージの自動拡張を有効にすることは、予測できないワークロードを管理する場合に重要です。これは、低ストレージの状態を自動的に検出し、それに応じてストレージをスケールアップするためです。
ディスク サイズが 4,096 GiB の境界を越える必要がある場合を除き、ストレージのスケーリングプロセスはダウンタイムを発生させることなくオンラインで実行されます。 この例外は、 Azure マネージド ディスクの制限です。 その場合、ストレージ自動拡張設定がサーバーに対して有効になっている場合でも、自動ストレージ スケーリング アクティビティはトリガーされません。 このような場合は、ストレージを手動でスケーリングする必要があります。 このシナリオ (4,096 GiB 境界に到達または交差) では、手動スケーリングはオフライン操作です。 ビジネス ニーズに合わせてこのタスクをスケジュールすることをお勧めします。 その他の操作はすべてオンラインで実行できます。 割り当てられたディスク サイズが 8,192 GiB 以上になると、ストレージの自動拡張が再び自動的にトリガーされ、割り当てられたディスクの最大容量 (32,768 GiB) に達するまで、後続のすべてのストレージ拡張操作がオンラインで実行されます。
注
インスタンスに割り当てるストレージの種類にかかわらず、ストレージは拡張のみ可能で、縮小はできません。
ストレージ自動拡張の制限事項と考慮事項
ディスク スケーリング操作は、通常、4,096 GiB の境界を越える特定のシナリオを除き、オンラインで実行されます。 これらのシナリオには、4,096 GiB の制限に達または超過することが含まれます。 たとえば、2,048 GiB から 8,192 GiB にスケーリングすると、オフライン操作がトリガーされます。 Azure portal で、4,095 GiB と表される 4 TiB に移行すると、操作がオンラインで維持されます。 ただし、Azure CLI など、4 TB を 4,096 GiB として明示的に指定した場合、スケーリング操作はオフライン モードで完了します。これは、4,096 GiB の制限に達するためです。 通常、Oflline スケール操作には 2 ~ 10 分かかります。 ダウンタイムの スケーリング機能が減ると、この期間は 30 秒未満に短縮されます。 リソースのスケーリング中のダウンタイムの短縮により、データベース インスタンスの全体的な可用性が向上します。
ホスト キャッシュ (ReadOnly および Read/Write) は、4,096 GIB または 4 Tib 未満のディスク サイズでサポートされています。 最大 4,095 GiB までプロビジョニングされたディスクは、ホスト キャッシュを利用できます。 ホスト キャッシュは、4,096 GiB 以上のディスク サイズではサポートされていません。 たとえば、4,095 GiB でプロビジョニングされた P50 Premium ディスクではホスト キャッシュを利用できますが、4,096 GiB でプロビジョニングされた P50 ディスクではホスト キャッシュを利用できません。 低いディスク サイズから 4,096 GiB 以上に移行した場合、ディスク キャッシュを使用できなくなります。
この制限は、手動でのディスク スケーリング操作が必要な、基になる Azure マネージド ディスクが原因です。 この制限に近づくと、ポータルに情報メッセージが表示されます。
WAL 使用率が高い場合、ストレージの自動拡張はトリガーされません。
注
ストレージの自動拡張はオンライン ディスクのスケーリングに依存するため、ダウンタイムは発生しません。
IOPS スケーリング
Azure Database for PostgreSQL では、追加の IOPS のプロビジョニングがサポートされています。 この機能を使用すると、無料の IOPS 制限を超えて、より多くの IOPS をプロビジョニングできます。 この機能を使用すると、プロビジョニングされた IOPS の数を増減して、ワークロードの要件に合わせていつでも調整できます。
選択したコンピューティング サイズによって、最小 IOPS と最大 IOPS が決まります。 コンピューティング サイズあたりの最小 IOPS と最大 IOPS の詳細については、 コンピューティング サイズに関するページを参照してください。
Important
最小および最大 IOPS は、選択したコンピューティング サイズによって決まります。
IOPS のスケールアップとスケールダウンについて説明します。