運用パフォーマンスのためにAzure Database for PostgreSQLデプロイを計画する

クラウド コンピューティングによって、データベースホスティング環境が劇的に変わります。 チームは、スケーラビリティ、回復性、グローバルなリーチ、以前は手に入れなかった機能にアクセスできます。 可能な限り最大のワークロードを計画し(1日目からそのコストを運ぶことで)、かなりのコストとオーバーヘッドを発生させる代わりに、チームは必要なときに必要な正確なスケールを最適化し、需要の変化に応じて調整できるようになりました。

イントロダクション

PostgreSQL データベースのデプロイでは、リソースの適切なバランスを柔軟に選択できます。 PostgreSQL データベース ワークロードは、小規模から始まり、急速に増加し、季節的に急増したり、読み取り負荷が高いワークロードから書き込み負荷の高いワークロードに移行したり、トランザクション ワークロードからハイブリッド運用および分析システムにリアルタイムで進化したりする可能性があります。 Azure Database for PostgreSQLは、コンピューティング、ストレージ、可用性、レプリケーション、セキュリティ、バックアップ、運用管理に関する幅広い選択肢を提供することで、ソリューションがターゲットを確実に達成できるようにします。

しかし、このすべての力には、特にデプロイを計画する際に責任が伴います。 可能な限り最高のパフォーマンスを実現するには、デプロイの決定がワークロード全体の要件と一致している必要があります。

Azure Database for PostgreSQLデプロイの成功は、"必要なコアとメモリが最も多い" を選択することだけではありません。代わりに、最大の運用パフォーマンスは、アプリケーションの動作、クライアントの動作、コンピューティング、ストレージ、データベースの増加特性、およびこれらすべてが交差して相互作用する方法を理解することによって生じます。

最適なアーキテクチャは、これらの部分が意図的に配置されるアーキテクチャです。

クラウド パフォーマンス計画は共同責任です

信頼できるクラウド プラットフォームに移行する主な利点の 1 つは、共同責任モデルです。 Microsoftは、グローバル インフラストラクチャ、マネージド サービス、ハードウェア イノベーション、信頼性、セキュリティ、運用エンジニアリングを提供します。 チームは、ビジネスの重要度、ワークロードの動作、データ モデルの設計、ネットワーク トラフィック プロファイル、成長期待、回復目標、エンド ユーザー エクスペリエンスの要件など、特定のアプリケーション コンテキストの専門知識を提供します。

この 2 つの力が統一されると、最も強力な結果が生じます。

Azureは高度にスケーラブルな Postgres インフラストラクチャを提供しますが、チームは次の領域に分析情報を提供する必要があります。

• 通常の期間中とピーク時に予想される同時ユーザーの数はいくつですか?
• 最も重要な操作は、読み取り負荷が高い、書き込み負荷が高い、または混在していますか?
• 月末、四半期末、休日、打ち上げ、またはレポートウィンドウの間に需要が急増しますか?
• データセットの成長速度はどのくらいですか?
• 待機時間の影響を受けやすい操作はどれですか?
• より長いランタイムを許容できるクエリまたはジョブはどれですか?
• ワークロードは主に OLTP、OLAP、またはハイブリッドですか?
• クライアントは、データベース リージョンの近くに配置されているか、グローバルに分散されているか、1 つの地域に集中していますか?

デプロイ前にこれらの詳細を記録し、本番環境でのインシデントの後にならないようにします。 クラウドデプロイはスケーリングを容易にしますが、最もパフォーマンスが高く、コスト効率の高い設計は、依然として健全な要件の収集と適切な計画から始まります。 ほとんどの場合、これらの質問は、コンカレント接続、最大 IOPS、および必要なスループット全体の関係にまで絞り込むことができます。

パフォーマンスに複数のレイヤーがある

データベースのパフォーマンスが 1 つの設定によって決まることはめったにありません。 デプロイ エクスペリエンスの成功は、連携する複数のレイヤーによって異なります。

• アプリケーション 層のパフォーマンス。
  このレイヤーには、アプリケーション コード、クエリ パターン、インデックス カバレッジ、トリガー使用量、データ パーティション分割、接続処理、キャッシュ、再試行ロジック、プール、ORM 動作、トランザクション設計、バックグラウンド ジョブ動作が含まれます。
• クライアント層とネットワーク層のパフォーマンス。
  このレイヤーには、クライアントの配置場所、接続方法、リージョン間と可用性ゾーン間の要求、ネットワーク待機時間、TLS オーバーヘッド、接続チャーン、アプリケーションが接続プールを効率的に使用するかどうかが含まれます。
• データベース プラットフォームのパフォーマンス。
  このレイヤーには、Postgres デプロイ構成、コンピューティング サイズ、メモリ、CPU、ストレージの種類、ストレージ サイズ、ストレージ IOPS、ストレージ スループット、高可用性、レプリカ、メンテナンス操作が含まれます。

この記事では、主に 3 番目のレイヤーに焦点を当てています。コンピューティングとストレージの選択肢で必要なパフォーマンス プロファイルがサポートされるように、Azure Postgres データベースのデプロイを計画します。

Azure Database for PostgreSQLは柔軟性を提供しますが、計画は不可欠です

Azure Database for PostgreSQLフレキシブル サーバーには、次のようなさまざまな展開オプションが用意されています。

ワークロードによって必要な機能が異なるため、この柔軟性は強力です。 書き込み負荷の高いトランザクション システムでは、レポートの負荷の高いシステムと同じプロファイルは必要ありません。 グローバル SaaS アプリケーションには、内部リージョン アプリケーションと同じ設計は必要ありません。 年に 5% 増加するデータベースでは、1 か月で 200% 増加するストレージ プランと同じストレージ プランは必要ありません。

計画の目標は、ワークロード パフォーマンス プロファイルのニーズを特定し、コンピューティング オプションとストレージ オプションの両方に適切な選択肢を実装して、エンド ツー エンドのソリューションを正常に提供することです。

ワークロード プロファイルから開始する

コンピューティングまたはストレージを選択する前に、ワークロードを定義します。 便利な計画ディメンションは次のとおりです。

目標は、未来を完全に予測することではありません。 目標は、盲目的な設計を避けるためです。

3 つの主要なストレージ パフォーマンスの概念を理解する

Azureストレージのパフォーマンス計画は、通常、IOPS、スループット、待機時間という 3 つの関連する異なる概念にダウンします。 これらの要因は、アプリケーションのパフォーマンス計画の重要な要素です。

IOPS

IOPS は、1 秒あたりの入出力操作を意味します。 1 秒ごとにデータベースがストレージに送信できる読み取り操作または書き込み操作の数を測定します。

IOPS は、OLTP ワークロードにとって特に重要です。 多くの場合、これらのシステムは、挿入、更新、インデックス参照、ポイント読み取り、短いトランザクションなど、多数の小さなランダム読み取りと書き込みを実行します。 数千人の同時実行ユーザーを含むトランザクション ワークロードでは、個々の操作が小さい場合でも、高い IOPS が必要になる場合があります。

IOPS に依存する一般的なシナリオは次のとおりです。

• 大量注文処理
• ユーザー プロファイルの更新
• インベントリ システム
• イベント インジェスト
• 支払いシステムまたは課金システム
• 高度に同時実行される SaaS アプリケーション

スループット

スループット (帯域幅とも呼ばれます) は、時間の経過に伴ってストレージから読み取りまたはストレージに書き込むことができるデータの量を測定します。 MB/秒で表されます。

スループットは、操作が大量のデータを移動する場合に重要です。 分析クエリ、バックアップ、復元、バッチ ジョブ、インデックス ビルド、テーブル スキャン、ETL ワークフローでは、最大 IOPS を必要としない場合でも高スループットが必要になる場合があります。

スループットに依存する一般的なシナリオは次のとおりです。

• 大きなテーブルに関するクエリのレポート作成
• 一括インポートまたは一括エクスポート
• データ ウェアハウス形式のスキャン
• バックアップと復元の操作
• 大規模なインデックス作成または再構築操作
• バッチ処理

Latency

待機時間 は、1 つの I/O 要求が完了するまでの時間です。 待機時間の短縮は、ユーザー向けのデータベース操作に不可欠です。特に、多くの小規模な操作がトランザクション内で連結されます。

システムでは理論上の IOPS が高くなる可能性がありますが、待機時間が長い場合は遅いと感じます。 Postgres ワークロードの場合、ストレージの待機時間は、クエリの応答時間、トランザクション コミット動作、チェックポイント動作、アプリケーションの全体的な応答性に直接影響する可能性があります。

IOPS、スループット、待機時間を一緒に考慮する必要がある

IOPS とスループットが接続されています。 複数の小規模な 8 KiB 操作を発行するワークロードでは、高スループットなしで高い IOPS が発生する可能性があります。 大規模なマルチ MB 操作を発行するワークロードは、低い IOPS で高スループットを実現する可能性があります。

それについて考える簡単な方法:

IOPS x I/O サイズ = スループット

Postgres の場合、実際的な意味は、ワークロード ストレージの計画は、データベース サイズだけでなく、観察されたワークロードの動作または推定されたワークロードの動作に基づく必要があるということです。 例えば次が挙げられます。

• コンカレンシーの高い OLTP システムでは、より多くの IOPS と待機時間が必要になる場合があります。
• レポートの負荷の高いシステムでは、より多くのスループットが必要になる場合があります。
• ハイブリッド システムでは、特にピーク サイクル中に両方が必要になる場合があります。
• コンカレンシーの高い OLTP システムでは、より多くの IOPS と待機時間が必要になる場合があります。
• レポートの負荷の高いシステムでは、より多くのスループットが必要になる場合があります。
• ハイブリッド システムでは、特にピーク サイクル中に両方が必要になる場合があります。

デプロイの選択がストレージのパフォーマンスに直接影響する

一般的な間違いは、選択したコンピューティング SKU が同じパフォーマンス レベルを駆動できるかどうかを完全に考慮せずに、ターゲット パフォーマンス番号のストレージを設定することです。

Azureストレージのパフォーマンスには、複数の考慮事項があります。 次の詳細が含まれます。

• コンピューティング機能セット (コンピューティングの最大 IOPS とスループットの制限)。
• ストレージの世代 (SSD v1、SSD v2、Ultra Disk)。
• ストレージ ディスク サイズ (4,096 GB 未満の SSD v1 ディスクにはホスト キャッシュが含まれます。これにより、標準ベースラインを超える IOPS バーストが可能になります)。
• ストレージの IOPS 容量。
• ストレージのスループット容量。

実際的には、 あなたの効果的なパフォーマンスの上限は、チェーン内のあなたの最も低い関連する制限です。

ストレージ構成で 80,000 IOPS を提供できるが、コンピューティング SKU が 20,000 IOPS のみを駆動できる場合、デプロイでは 80,000 IOPS は提供されません。 逆に、VM の生成で高い IOPS がサポートされているのに、選択したストレージ層の上限が低い場合、ストレージ層は制限になります。

コンピューティングとストレージの計画は一緒に行う必要があります。

Premium SSD v1: 重要なキャッシュ動作による強力なベースライン パフォーマンス

Premium SSD v1 は、予測可能でプロビジョニングされたパフォーマンスを必要とする Postgres ワークロードAzure運用の一般的な選択肢です。 Azure Postgres SSD v1 ストレージでは、最大 32 TB 領域、20,000 IOPS、および 900 MB/秒 スループットがサポートされます。

Premium SSD v1 は、ホスト キャッシュの恩恵を受けるワークロードに適しています。 Azure Postgres では、SSD v1 ディスク サイズ 4,096 GB を超えるホスト キャッシュがサポートされます。 最大 4,095 GB までプロビジョニングされたディスクは、ホスト キャッシュの恩恵を受けることができます。 ストレージが 4,096 GB 以上でプロビジョニングされると、ホスト キャッシュはサポートされません。 その境界は重要です。 4 TB 未満の Premium SSD v1 デプロイでは、キャッシュによって読み取りパフォーマンスが向上し、読み取りの待機時間が短縮されます。 このキャッシュにより、キャッシュのしきい値を下回る読み取り負荷の高いワークロードまたは混合ワークロードに対して、優れたコスト対パフォーマンス効率が実現します。

4 TB 境界が重要な理由

Premium SSD v1 のデプロイがキャッシュでサポートされている範囲を超えると、パフォーマンス プロファイルが変更される可能性があります。

• 読み取りは、ホスト キャッシュのメリットを受けなくなりました。
• より多くの読み取り操作は、基になるディスクから直接行われます。
• ディスク IOPS とスループットの制限に対して、読み取りがカウントされます。
• 待機時間に依存する読み取りワークロードでは、動作が異なる場合があります。
• 以前は効率的だった構成では、プロビジョニングされた IOPS、スループットの向上、コンピューティングのスケーリング、クエリのチューニング、または別のストレージ オプションが必要になる場合があります。

4 TB を超過することは悪くありませんが、計画する必要があります。

データベースが 4 TB を超えると予想される場合は、アーキテクチャの設計時に将来の状態を検討してください。 キャッシュを使用して 2 TB で優れたパフォーマンスを発揮する設計では、キャッシュなしで 5 TB の別のパフォーマンス プランが必要になる場合があります。

バーストはスパイクに対処するのに役立ちますが、持続的なキャパシティを置き換えるものではありません。

Azure 4 TB 以下の Postgres Premium SSD v1 ストレージ割り当てでは、ホスト キャッシュのバーストがサポートされます。これは、次のようなシナリオで役立ちます。

• スタートアップ アクティビティ
• 短いバッチジョブ
• トラフィックの急増
• 月末処理
• 一時的なワークロードの急増

バーストは便利ですが、慎重に使用してください。 バーストは一時的なスパイクを吸収できますが、それを持続的なワークロード需要の基盤にするのは適切ではありません。 ワークロードがベースラインより上で頻繁に実行される場合は、より高いパフォーマンスレベルをプロビジョニングし、ストレージ パフォーマンス設定を調整し、コンピューティングをスケーリングするか、ワークロード パターンを再設計することをお勧めします。

計画を立てる際の良い質問は: これは一時的な急増ですか、それともこれが新たな常態ですか?

一時的なスパイクは、バーストの候補として適している可能性があります。 計画的なキャパシティ プランニングを使用して、持続的な需要を処理します。

Premium SSD v2 では、容量、IOPS、スループットが切り離されます

Premium SSD v2 では、ディスク サイズ、IOPS、スループットを切り離すことで計画モデルが変更されます。 Azure Database for PostgreSQL フレキシブル サーバー Premium SSD v2 をサポートしています。

• 32 GB から 64 TB の容量。
• 最大 80,000 IOPS。
• 最大 1,200 MB/秒の スループット。
• 容量を1 GB単位で細かく調節します。
• 柔軟な IOPS とスループットの構成。
• Premium SSD v1 よりも待機時間が短い。
• ホスト キャッシュなし。

この変更は大きな変化です。 Premium SSD v1 では、パフォーマンスはディスク サイズと密接に結び付けられます。 Premium SSD v2 を使用すると、ワークロードのニーズに関するパフォーマンスをより直接構成できます。

たとえば、トランザクションが多いデータベースでは、大量のストレージを必要とせずに高い IOPS が必要になる場合があります。 Azure Postgres は、追加料金なしでベースライン IOPS とスループットを提供し、追加の IOPS とスループットを追加料金で利用できます。 Premium SSD v2 オファー:

• 最大 399 GB のディスクは、 3,000 IOPS と 125 MB/秒のベースラインを受け取ります。
• 400 GB 以上のディスクは、 12,000 IOPS と 500 MB/秒のベースラインを受け取ります。
• ディスクは、160 GB 以上の空き領域にサイズ設定すると、最大 80,000 IOPS に達する可能性があります。
• スループットは最大 1,200 MB/秒までスケールアップできます。

Premium SSD v2 は、コストとパフォーマンスをより正確に制御する必要がある場合に魅力的です。 パフォーマンスのロックを解除するためだけにストレージ容量をスケーリングする代わりに、パフォーマンスをより意図的にプロビジョニングできます。

Ultra Disk (プレビュー): ハイエンド Azure ディスク パフォーマンス クラス

Ultra Disk は、最高パフォーマンスのディスク オプションです。 Azure Ultra Disk は、次のレベルまでのパフォーマンス レベルを提供します。

• 400,000 IOPS
• 10,000 MB/秒の スループット
• 64 TB の容量
• サブミリ秒待機時間の設計ターゲット
• 個別に構成可能な容量、IOPS、スループット

Ultra Disk ストレージは、最上位レベルのデータベース、SAP HANA、トランザクション負荷の高いシステム向けに IO 集中型ワークロードを実現するように設計されています。 この新しいストレージ オファリングは、ミッション クリティカルなワークロードに最高レベルのパフォーマンスを提供します。 ただし、チームは、デプロイを計画する際に、いくつかの主要なデプロイ機能、リージョンの可用性の制限、および構成オプションを考慮する必要があります。

• Ultra Disk を使用するサーバーでは、ストレージの自動拡張はサポートされていません
• Ultra Disk を使用するサーバーでは、カスタマー マネージド キーによるデータ暗号化はサポートされていません
• Ultra ディスクはディスク キャッシュをサポートしていません

Ultra Disk の機能は、より広範なAzureストレージ パフォーマンス環境の一部として理解しておくことが重要です。 ただし、特定の Azure Postgres ワークロードのサービスの可用性とサポートを検証する必要があります。 Azure Postgres のデプロイで Ultra Disk Preview が利用できるかどうかを、Microsoft担当者にお問い合わせください。

Ultra Disk はAzureストレージ パフォーマンスの上限を表しますが、エンド ツー エンドの Postgres 設計には、選択したコンピューティング SKU、リージョン、リリース レベルでサポートされる組み合わせが含まれている必要があります

VM の生成に関する問題: V5 と V6 のコンピューティング ストレージの上限は異なります

コンピューティングの生成は、ストレージのパフォーマンスに大きく影響する可能性があります。 Azureストレージパフォーマンスの最上位を調べるときは、"大規模なコンピューティング" が自動的に "最大ストレージ" を意味するという誤解を避けてください。選択したコンピューティング SKU を、目的のストレージ層と照らして検証する必要があります。 2 つの同様のサイズのコンピューティング世代 ( Ddsv5 と Ddsv6) を検討して、この点を説明しましょう。

Ddsv5 シリーズでは、VM ファミリ レベルでPremium Storage (キャッシュあり)、Premium SSD v2、Ultra Disk がサポートされます。 ただし、VM の集計リモート ストレージの制限によって、その VM が駆動できる上限が定義されます。 Ddsv5-series は、最大 80,000 IOPS と 2,600 MB/秒のストレージ パフォーマンスを提供します。

Ddsv6シリーズは、最大 400,000 IOPS と 12,000MB/秒の範囲の高いストレージ エンベロープを提供します。 V6 シリーズのコンピューティングでは、前の世代よりも高いスケーラビリティを提供し、最大 192 vCPU と 768 GiB のメモリを備えています。

この世代の変化は、高パフォーマンスの Postgres 設計にとって重要です。 ターゲット アーキテクチャで高いストレージ パフォーマンスが必要な場合は、集計ストレージの上限が低いコンピューティング世代を選択すると、デプロイで完全なストレージ機能が使用できなくなる可能性があります。

例: エンドツーエンドのアラインメントが重要な理由

400,000 IOPS の目標ストレージ ターゲットを持つ PostgreSQL ワークロードについて考えてみましょう。

ディスク 層では、Azure Ultra Disk はディスクあたり最大 400,000 IOPS をサポートします。 Premium SSD v2 では、ディスクあたり最大 80,000 IOPS がサポートされます。より高い集計設計では、サービスのサポートによっては、複数のディスクまたはプラットフォーム レベルの抽象化が必要になる場合があります。

ただし、ストレージ機能だけでは不十分です。

V5 シリーズの構成では、ストレージ上限がターゲットよりも低い場合があります。 前述のように、V5 シリーズ SKU では、Premium SSD のリモート ディスク スループットに対して最大 260,000 IOPS がサポートされます。 この場合、このターゲットに対して V5 シリーズのコンピューティング レイヤーを選択すると、400,000 IOPS ターゲットに到達する前の制限要因になります。

これに対し、Ddsv6 シリーズのドキュメントでは、最大 400,000 IOPS と 12,000 MB/秒を提供しています。 これにより、V6 シリーズ以降の世代は、コンピューティングとストレージを最高のストレージ パフォーマンス クラスに合わせる必要がある設計にとって戦略的に重要になります。

レッスンは簡単です。 データベースの最大パフォーマンスは、ストレージのみのプロパティではなく、エンドツーエンドのプロパティです。

安定した状態だけでなく、ビジネス サイクルを計画する

多くのシステムには、1 つのパフォーマンス プロファイルがありません。 次のような機能があります。

平均使用率に合わせてサイズ設定されたデータベースは、最も重要な時間帯に苦労する可能性があります。 逆に、1 か月に 1 回のピーク時にデータベースのサイズを永続的に設定すると、不必要にコストがかかる可能性があります。

Azureの柔軟性により、チームはより微妙な選択を行うことができます。 例えば次が挙げられます。

• Premium SSD v2 を使用して、ワークロードのニーズの進化に合わせて IOPS とスループットを調整します。
• 読み取りレプリカを使用して、必要に応じて読み取り負荷の高いワークロードをオフロードします。
• 既知のピーク期間に計算リソースをスケーリングします。
• インフラストラクチャをスケーリングする前に、クエリ、インデックス、接続プールを調整します。
• 監視機能を使用して、ボトルネックが CPU、メモリ、IOPS、スループット、ロック競合、接続負荷、またはクエリ設計であるかどうかを特定します。

最適なデプロイは、常に最大のデプロイとは限りません。 ワークロードに一致し、安全に進化できる設計です。

可観測性はアーキテクチャの一部です

パフォーマンス計画は、デプロイ時に停止しないでください。 Postgres ワークロードは時間の経過と同時に変化します。 データの増加、クエリ パターンの変化、新機能の起動、顧客のトラフィックの変化、運用ジョブの蓄積。

Azure Database for PostgreSQLドキュメントでは、Azure ポータルまたはAzure CLIメトリック (ストレージの制限、ストレージの割合、使用されているストレージ、I/O の割合など) を使用した I/O 消費量の監視について説明します。

これらのメトリックは、最も重要な運用上の質問に答えるのに役立ちます。 どのレイヤーが実際にパフォーマンスを制限していますか?

可観測性がなければ、チームは間違ったことをスケーリングする可能性があります。 クエリ プランの問題は、ストレージの問題のようになります。 接続ストームは CPU 負荷のように見える場合があります。 不足しているインデックスは、IOPS が不足しているように見える場合があります。 リージョンのクライアント配置の問題は、データベースの待ち時間のように見えることがあります。

監視は、チームが高価な推測ではなく、対象を絞った変更を行うのに役立ちます。

実用的な計画チェックリスト

運用Azure Database for PostgreSQL構成を選択する前に、次の情報をキャプチャします。

推奨される設計原則

運用パフォーマンスのために Postgres デプロイAzure計画するときは、次の原則を使用します。

• データサイズだけでなく、ワークロードの特性に合わせたサイズ。
  500 GB のデータベースは、トランザクション性と待機時間が非常に重要な場合、5 TB のデータベースよりも多くの IOPS が必要な場合があります。 サイズは重要ですが、ワークロードの動作はより重要です。
• コンピューティングとストレージを一緒に検証します。
  ディスクの制限のみに基づいてストレージを選択しないでください。 選択したコンピューティング SKU が必要な IOPS とスループットを駆動できることを確認します。
• 4 TB Premium SSD キャッシュ境界を設計マイルストーンとして扱います。
  4 TB 以下の Premium SSD デプロイは、ホスト キャッシュのメリットを得ることができます。 4,096 GB 以上では、ホスト キャッシュはサポートされていません。 増加がそのしきい値を超える場合は、将来のパフォーマンス モデルを早期に計画します。
• 柔軟なパフォーマンス チューニングを行う場合は、Premium SSD v2 を検討してください。
  Premium SSD v2 では、容量、IOPS、スループットをより細かく制御できます。 パフォーマンスのニーズが固定ディスク サイズに適切にマップされない場合は、強い適合が得られる可能性があります。
• バーストを、連続的な需要ではなく断続的な需要に使用してください。
  バーストは有効期間の短いスパイクに役立ちますが、頻繁または持続的なバーストは通常、ベースライン構成を再検討する必要があることを意味します。
• 世代を野心にマッチさせる。
  ハイエンドのパフォーマンス目標のために、v6 シリーズなどの新しいコンピューティング世代では、以前の汎用世代よりも高い集計リモート ストレージ制限が公開される可能性があります。 ターゲットが 400,000 IOPS クラスのアーキテクチャの場合は、それに応じてコンピューティング世代を選択します。
• 変更の前後を測定します。
  クラウドではスケーリングが簡単ですが、スケーリングを効果的に行うのが測定です。 ベースライン、ピーク、変更後のメトリックをキャプチャして、パフォーマンスの決定が証拠ベースになるようにします。

実際のベンチマーク: 負荷がかかっているストレージ構成を比較する

この記事で概説されている原則は理論的ではありません。 このセクションでは、コンピューティング、ストレージ、ワークロードがどのように実際にどのように相互作用するかを示すために、制御された測定された条件下でストレージ構成とコンピューティング レベルを比較する pgbench ベンチマークをまとめます。

ベンチマークのセットアップと手法

ベンチマークでは、標準の PostgreSQL ベンチマーク ツールである pgbench を使用して、5 つの異なるストレージとコンピューティング構成にわたるトランザクション ワークロードをシミュレートします。 テストは 500 個のコンカレント接続から始まり、最初の期間の後に最大 750 個のコンカレント接続が増加し、テスト ウィンドウの残りの部分でこの高い接続負荷が維持されます。 この負荷増加パターンは、トラフィックの増加に伴いどのように実際のアプリケーションが負荷を増していくかをシミュレートし、初期のスパイクと持続的な高い同時実行性に対するデータベースの応答を測定します。

すべてのベンチマークは、同じテスト データベースとワークロード プロファイルを使用して、同じリージョン内の同じ可用性ゾーン内の Azure Database for PostgreSQL フレキシブル サーバーで実行されます。 ストレージとコンピューティングを変数として分離することで、パフォーマンスの違いは、ネットワーク、アプリケーション、ワークロードの変動ではなく、実際のプラットフォーム機能を反映します。

構成の詳細

5 つの異なる構成をテストし、ストレージ層とコンピューティング サイズの両方を変更して、主要な計画の概念を示します。

構成設計からの主な観察:

• 構成 1 と構成 2: これらの構成は、ストレージ サイズ (4,095 GB と 4,096 GB) のみが異なります。 この比較では、Premium SSD v1 ディスクのホスト キャッシュ境界をテストします。
• 構成 2 と構成 3: どちらの構成でも SSD v1 が使用されますが、Config 3 は 32 TB の容量にスケーリングされ、より高い IOPS とスループットのロックが解除されます。
• 構成 3 と構成 4: どちらの構成も同じコンピューティングを使用しますが、Config 4 では、容量に関係なく Premium SSD v2 の柔軟な IOPS とスループットが示されます。
• 構成 4 と構成 5: Config 5 はコンピューティング SKU を 2 倍にして、より高いレベルのコンピューティングでより多くのストレージ パフォーマンスヘッドルームのロックを解除する方法を示します。

パフォーマンスの結果

構成 1: ホスト キャッシュを使用した 4,095 GB Premium SSD v1

構成 1 では、4,095 GB の Premium SSD v1 サイズが使用されます。Premium SSD v1 でのホスト キャッシュの利点があります。 ワークロード中、この構成は次の処理を維持しました。

• 最大 IOPS: 24,773。Premium SSD v1 では 7,500 個のプロビジョニング済み IOPS に制限され、キャッシュによって効果的なパフォーマンスが向上します。
• 最大読み取り IOPS: 21,330。読み取り負荷の高い操作ではホスト キャッシュの恩恵を受けます。
• 最大書き込み IOPS: 7,610。

ホスト キャッシュは読み取り増幅を提供するため、有効な IOPS は一時的にディスクの 7,500 個のプロビジョニング済み IOPS 制限を超え、コンピューティング ストレージの制限に達します。

構成 2: ホスト キャッシュなしの 4,096 GB Premium SSD v1

構成 2 では、4,096 GB の Premium SSD v1 サイズが使用され、キャッシュ境界を超え、ホスト キャッシュの利点が失われます。 影響は次のようになります。

• 最大 IOPS: キャッシュが失われるため、Config 1 に比べて有効な IOPS が低くなります。
• 最大読み取り IOPS: ホスト キャッシュなしで大幅に削減されます。
• 最大書き込み IOPS: 7,610、変更なし。

この構成は、4 TB のキャッシュ境界の実際的な重要性を示しています。 4,095 GB から 4,096 GB に超えると、キャッシュされた読み取りが取り除かれ、パフォーマンス プロファイルが変更されます。 このしきい値に近づくデータベースを増やす場合は、事前に計画してください。

構成 3: IOPS が高い 32 TB Premium SSD v1

構成 3 では、32 TB の容量にスケーリングすることで、Premium SSD v1 の上位 IOPS とスループットの制限に対処します。 この構成では、次の操作が行われます。

• 最大 IOPS: 20,000。
• 最大読み取り IOPS: 約 12,000。
• 最大書き込み IOPS: 約 5,000。

基になる Premium SSD v1 ストレージ容量を増やすと、IOPS とスループットが向上します。 負荷の高いワークロードについては、引き続きコンピューティング ストレージ範囲の上限に達することができます。

構成 4: 40,000 IOPS の Premium SSD v2

構成 4 では、Premium SSD v2 の柔軟なパフォーマンス構成を示し、4,095 GB の容量で 40,000 IOPS と 1,200 MB/秒のスループットをプロビジョニングします。

• 最大 IOPS: Premium SSD v2 の待機時間とスループット機能により、より高い効果的な使用率。
• 最大読み取り IOPS: Premium SSD v1 構成と比較してパフォーマンスが向上しました。
• 最大書き込み IOPS: 持続的な書き込み容量の増加。

Premium SSD v2 を使用すると、大容量のストレージ容量を必要とせずに高い IOPS をプロビジョニングできるため、トランザクション負荷の高いワークロードに対して効率的になります。

構成 5: D32ds_v5 コンピューティングで 60,000 IOPS の Premium SSD v2

構成 5 では、ストレージ パフォーマンス (60,000 IOPS) とコンピューティング (Standard_D32ds_v5 と 32 個の仮想コア) の両方がスケーリングされます。 この構成では、エンド ツー エンドのアラインメントの原則を示します。

• 最大 IOPS: 以前のすべての構成よりも大幅に高くなります。
• 最大読み取り IOPS: 追加のコンピューティング ヘッドルームによる強力な改善。
• 最大書き込み IOPS: より高い書き込み容量を維持しました。

コンピューティングとストレージの両方を高いパフォーマンス レベルに合わせることにより、この構成は最高のスループットと最小の CPU 負荷を実現します。 D32ds_v5のストレージ上限が高いほど、60,000-IOPS Premium SSD v2 ディスクをより完全に使用できます。

ベンチマークからの教訓

次の 5 つの構成は、この記事の主要な原則を示しています。

• 4 TB のキャッシュ境界が重要です。
  構成 1 と構成 2 は、ホスト キャッシュが 4 TB 未満の測定可能な読み取りパフォーマンス増幅を提供し、4,096 GB に渡るとその利点が排除されることを示しています。
• 容量はパフォーマンスではありません。
  構成 3 では 32 TB がプロビジョニングされましたが、最高の IOPS が提供されませんでした。 ストレージ容量だけでは、トランザクションのスループットは決定されません。
• Premium SSD v2 は、柔軟なパフォーマンス チューニングを提供します。
  Config 4 では、Premium SSD v2 で有効になっている分離モデルを検証して、容量が小さいため、高い IOPS が示されました。
• コンピューティングとストレージを調整する必要があります。
  構成 5 は、ストレージ パフォーマンスを最大化するには十分なコンピューティング ヘッドルームが必要であることを示しています。 60,000 IOPS プロビジョニングをより完全に使用するには、D32ds_v5の高いストレージ上限が必要でした。

ベンチマークの結果は、主要な原則を検証します。最大パフォーマンスはエンド ツー エンドのプロパティです。 ストレージ、コンピューティング、ネットワークなどの 1 つのレイヤーが結果を決定しません。 成功するには、ワークロードの進化に合わせて、すべてのレイヤー間で意図的な配置、測定された検証、継続的な観察が必要です。

結論

Azure Postgres は、クラウドでホストされる最新のデータベース ソリューションを構築するための強力で柔軟なプラットフォームを提供します。 Azureコンピューティング、ストレージ、ネットワーク、高可用性、レプリケーション、セキュリティ、および可観測性に関するエンジニアリングにより、最もパフォーマンスが高く回復性の高い Postgres アーキテクチャの一部を利用できます。

最大パフォーマンスは、誤って発生することはありません。

最大の運用パフォーマンスには、アプリケーション、クライアント、ワークロード、データ拡張プロファイル、読み取り/書き込みの組み合わせ、需要を形成するビジネス サイクルを理解する必要があります。 また、IOPS、スループット、待機時間のターゲットがエンドツーエンドで実現されるように、コンピューティングとストレージの両方の選択肢を調整する必要があります。

Premium SSD v1 は、特にホスト キャッシュが 4 TB 境界より下のデータに適用される場合に、強力な予測可能なパフォーマンスを提供できます。 Premium SSD v2 では、容量、IOPS、スループットを分離することで、より柔軟なパフォーマンス構成が追加されます。 Ultra Disk は、マネージド ディスク パフォーマンス クラスAzure最も高いクラスを表しますが、新しいコンピューティング世代では、ハイエンド アーキテクチャ用の集計リモート ストレージの上限が大幅に高くなります。

Postgres デプロイAzure最適な方法は、プラットフォームの機能と、計画的な計画、継続的な監視、および明確な運用所有権を組み合わせたものです。 適切な要件と適切なアーキテクチャにより、チームは最高のパフォーマンスを提供する世界クラスの Postgres エクスペリエンスを提供できます。

関連するコンテンツ

• Azure Premium Storage: 高パフォーマンスのための設計
• Azure ディスク バースト
• Ddv5 および Ddsv5 シリーズの VM サイズ
• Ddsv6 シリーズの VM サイズ
• Azure Database for PostgreSQL の Premium SSD ストレージオプション
• Azure Database for PostgreSQL のプレミアム SSD v2 ストレージオプション
• Azure マネージド ディスクの種類
• Azure Database for PostgreSQL でメトリックを監視する