Azure Database for MySQL のストレージ IOPS - フレキシブル サーバー
適用対象: 
Azure Database for MySQL - フレキシブル サーバー
ストレージ IOPS (1 秒あたりの I/O 操作数) は、ストレージ システムが 1 秒あたりに実行できる読み取り/書き込み操作数を指します。 IOPS 値が高いほど、ストレージのパフォーマンスが向上し、データベースでより多くの読み取り/書き込みの同時操作を処理できるようになり、データ取得が高速化され、全体的な効率が向上します。 IOPS の設定が低すぎると、データベース サーバーで要求の処理に遅延が発生し、パフォーマンスが低下し、スループットが低下する可能性があります。 一方、IOPS の設定が高すぎると、不必要なリソースの割り当てにつながり、パフォーマンスが大幅に向上することなくコストが増加する可能性があります。
Azure Database for MySQL フレキシブル サーバーには現在、事前プロビジョニングされた IOPS と自動スケーリング IOPS という IOPS 管理用の 2 つの設定が用意されています。
事前プロビジョニングされた IOPS
Azure Database for MySQL フレキシブル サーバーには、事前プロビジョニングされた IOPS が用意されているため、Azure Database for MySQL フレキシブル サーバー インスタンスに特定の数の IOPS を割り当てることができます。 この設定により、ワークロードの一貫した予測可能なパフォーマンスが保証されます。 事前プロビジョニングされた IOPS を使用すると、ストレージ ボリュームの特定の IOPS 制限を定義できるため、1 秒あたりの一定数の要求を処理できるようになります。 これにより、信頼性が高く、確実なレベルのパフォーマンスが得られます。
さらに、事前プロビジョニングされた追加の IOPS とは、サーバーに関連付けられているストレージ ボリュームのプロビジョニングされた IOPS を柔軟に増加させることを意味します。 既定のプロビジョニング レベルを超えて追加の IOPS を追加するオプションがあり、ワークロードの要件に合わせていつでもパフォーマンスをカスタマイズできます。
IOPS の自動スケーリング
自動スケーリング IOPS により、オンデマンドで IOPS を柔軟にスケーリングできるため、1 秒あたりの一定の IO 量を事前にプロビジョニングする必要がなくなります。 自動スケーリング IOPS を有効にすると、サーバーはワークロードの要件に基づいて IOPS を自動的に調整します。 この IOPS の自動スケーリング機能を使用すると、サーバーがワークロードのニーズに応じて IOP を自動的にスケールアップまたはスケールダウンするため、Azure Database for MySQL フレキシブル サーバーでの IO 管理を安心して行うことができます。 各サービス レベルとコンピューティング サイズの "サポートされている最大 IOPS" の詳細については、サービス レベルのドキュメントを参照してください。 自動スケーリング IOPS は、ワークロードのパフォーマンスを最適化するために、これらの制限にスケールアップされます。
動的スケーリング: 自動スケーリング IOPS は、ワークロードの実際の需要に基づいて、データベース サーバーの IOPS 制限を動的に調整します。 これにより、手動による介入や構成なしで最適なパフォーマンスが保証されます。
ワークロードの急増への対応: 自動スケーリング IOPS を使用すると、アプリケーションのパフォーマンスを損なうことなく、お使いのデータベースでワークロードの急増や変動をシームレスに処理できます。 この機能により、使用量がピークになる期間であっても、応答にばらつきがなくなります。
コスト削減: IOPS が事前プロビジョニングされる場合、固定の IOPS 制限が指定され、使用量に関係なく支払われるが、それとは異なり、自動スケーリング IOPS では、使用した I/O 操作の数だけ支払います。 この機能を使用すると、サーバーで実際に使用される IO に対してのみ課金され、不要なプロビジョニングや使用率の低いリソースに対する費用を回避できます。 これにより、コスト削減と最適なパフォーマンスの両方が保証されるため、データベース ワークロードを効率的に管理するためのスマートな選択肢になります。
ストレージのパフォーマンスを監視する
ストレージ IOPS の使用状況の監視は、監視で使用できるメトリックで簡単に行えます。
概要
選択した期間の IO 使用率の包括的なビューを取得します。 Azure Database for MySQL フレキシブル サーバーの [概要] ブレードの下にある Azure portal で [監視] に移動します。
拡張メトリック ブック
- Azure portal の [監視] セクションで [ブック] に移動します。
- "拡張メトリック" ブックを選択します。
- ブックの [概要] セクションで、[ストレージ IO の割合] メトリックを確認します。
[監視] の [メトリック]
- Azure portal の [監視] セクションで [メトリック] に移動します。
- "メトリックの追加" オプションを選択します。
- 使用可能なメトリックのドロップダウンから [ストレージ IO の割合] を選択します。
- 使用可能なメトリックのドロップダウンから [ストレージ IO 数] を選択します。
![[監視] メトリックのスクリーンショット。](media/concepts-storage-iops/3-metrics.png#lightbox)
最適な IOPS 設定の選択
IOPS の使用状況を効果的に監視する方法を学習したので、サーバーに最適な設定を調べることができるようになりました。 Azure Database for MySQL フレキシブル サーバー インスタンスの IOPS 設定を選択するとき、いくつかの重要な要因を考慮する必要があります。 これらの要因を理解することで、ワークロードに最適なパフォーマンスとコスト効率を確保するために、十分な情報に基づいた意思決定を行うことができます。
パフォーマンスの最適化
自動スケーリング IOPS を使用することで、ストレージのスロットリングや IOPS を追加するための手動操作の問題が発生することなく、予測可能なワークロードに対して一貫した要件を満たすことができます。 ワークロードのスループットが一貫しているか、一貫した IOPS が必要な場合は、事前プロビジョニングされた IOPS が推奨される場合があります。 予測可能なパフォーマンス レベルが提供され、IOPS の固定割り当ては指定された制限内のワークロードと相関します。 通常の要件より高いスループットが必要な場合は、事前プロビジョニングされた IOPS を使用して追加の IOPS を割り当てることもできますが、手動操作とスループットの増加時間を把握しておくことが必要です。
調整の影響
調整がワークロードに与える影響を考慮してください。 調整による潜在的なパフォーマンス低下が懸念される場合、自動スケーリング IOPS はワークロードの急増を動的に処理し、調整のリスクを最小限に抑え、パフォーマンスを最適なレベルに維持できます。
最終的には、自動スケーリングと事前プロビジョニングされた IOPS のどちらを選択するかは、特定のワークロード要件と期待されるパフォーマンスに応じて異なります。 ワークロード パターンを分析し、コストの影響を評価し、調整の潜在的な影響を考慮して、優先順位に合った情報に基づいた選択を行います。 トラフィックの変動、クエリ パターン、パフォーマンス要件など、データベース ワークロードの特性を考慮することで、自動スケーリングと事前プロビジョニングされた IOPS の選択に関する十分な情報に基づいた意思決定を行うことができます。
| ワークロードに関する考慮事項 | 事前プロビジョニングされた IOPS | IOPS の自動スケーリング |
|---|---|---|
| 一貫性のある予測可能な I/O パターンを持つワークロード | プロビジョニングされた IOPS のみを使用する場合に推奨されます | 互換性があり、IOPS の手動プロビジョニングは必要ありません |
| さまざまな使用パターンを持つワークロード | 使用状況の多い期間は、効率的なパフォーマンスが得られない可能性があるため、推奨されません。 | さまざまなワークロードを処理するように自動的に調整されるため、推奨されます |
| 動的な増加またはパフォーマンス ニーズの変化を伴うワークロード | 変更する IOPS 要件に従って一定の調整が必要であるため、推奨されません | 特定のスループット要件に対して追加の設定は必要ないため、推奨されます |
コストに関する考慮事項
ピークが予測できず、ワークロードが変動する場合は、自動スケーリング IOPS を選択した方がコスト効率が高い場合があります。 これにより、ピーク時に使用される高い IOPS に対してのみ支払いが発生し、柔軟性とコスト削減を実現します。 事前プロビジョニングされた IOPS は、一貫性のある最大 IOPS を提供する一方で、ワークロードによってはコストが高くなる場合があります。 サーバーに必要なコストとパフォーマンスのトレードオフを考慮してください。
テストと評価
最適な IOPS 設定がわからない場合は、自動スケーリング IOPS と事前プロビジョニングされた IOPS の両方を使用してパフォーマンス テストを実行することを検討してください。 結果を評価し、ワークロードの要件と期待されるパフォーマンスを満たす設定を決定します。
ワークロードの例: e コマースの Web サイト
年間を通じてトラフィックの変動が発生する e コマースの Web サイトを所有している場合。 通常期間のワークロードは中程度ですが、ホリデーシーズンや特別なプロモーション期間は、トラフィックが指数関数的に急増します。
自動スケーリング IOPS: 自動スケーリング IOPS を使用すると、データベースはピーク期間のワークロードの増加に対応するように IOPS を動的に調整できます。 Black Friday のセール期間など、トラフィックが急増した場合、自動スケーリング機能を使用することで、データベースは需要に合わせて IOPS をシームレスにスケールアップできます。 これにより、スムーズで中断のないパフォーマンスが保証され、速度低下やサービスの中断を防ぐことができます。 ピーク期間が過ぎ、トラフィックが沈静化すると、IOPS がスケールダウンし、急増時に使用されるリソースに対してのみ支払いが発生するため、コスト削減が可能になります。
事前プロビジョニングされた IOPS: 事前プロビジョニングされた IOPS を選択する場合は、ワークロードの最大容量を見積もり、それに応じて固定数の IOPS を割り当てる必要があります。 ただし、ピーク時は、ワークロードが事前定義された IOPS 制限を超える可能性があります。 その結果、ストレージ I/O が調整され、パフォーマンスに影響を与え、ユーザーに遅延またはタイムアウトが発生する可能性があります。
ワークロードの例: レポート /Data Analytics プラットフォーム
ユーザーが複雑なクエリと大規模なデータ処理タスクを送信するデータ分析に Azure Database for MySQL フレキシブル サーバーを使用しているとします。 ワークロード パターンは比較的一貫しており、1 日を通して安定したクエリの流れがあります。
事前プロビジョニングされた IOPS: 事前プロビジョニングされた IOPS では、予想されるワークロードに基づいて適切な数の IOPS を選択できます。 選択した IOPS が毎日のクエリ数を適切に処理する限り、調整やパフォーマンス低下のリスクはありません。 このアプローチでは、コストの予測可能性が得られ、動的スケーリングの必要なくリソースを効率的に最適化できます。
自動スケーリング IOPS: この場合、自動スケーリング機能には大きな利点がない可能性があります。 ワークロードは一貫性があるため、需要を快適に満たす固定数の IOPS でデータベースをプロビジョニングできます。 追加の IOPS を必要とするほどの突然のアクティビティのバーストがないため、自動スケーリングは必要ない可能性があります。 事前プロビジョニングされた IOPS を使用すると、スケーリングの必要なく予測可能なパフォーマンスが得られ、コストは割り当てられたストレージに直接関連付けられます。
よく寄せられる質問
事前プロビジョニングされた IOPS から自動スケーリング IOPS に移行するにはどうすればいいですか?
- Azure portal にアクセスし、関連する Azure Database for MySQL フレキシブル サーバーを見つけます。
- [設定] ブレードに移動し、[コンピューティングとストレージ] セクションを選択します。
- [IOPS] セクションで、[IOPS の自動スケーリング] を選択し、設定を保存して変更を適用します。
変更後、自動スケーリング IOPS はどれくらいのタイミングで有効になりますか?
Azure Database for MySQL フレキシブル サーバーに対して自動スケーリング IOPS を有効にし、設定を保存すると、リソースへのデプロイが正常に完了した直後に変更が有効になります。 これは、自動スケーリング IOPS 機能が遅延なくデータベースに適用されることを意味します。
ポイントインタイム リストア (PITR) 操作は IOPS の使用量にどのように影響しますか?
Azure Database for MySQL - フレキシブル サーバーでの PITR 操作の間に、新しいサーバーが作成されて、ソース サーバーのストレージから新しいサーバーのストレージにデータがコピーされます。 このプロセスにより、ソース サーバーでの IOPS 使用量が増えます。 IOPS 使用量のこの増加は通常の出来事であり、ソース サーバーまたは PITR 操作に関する問題を示すものではありません。 PITR 操作が完了すると、ソース サーバーでの IOPS 使用量は通常のレベルに戻ります。 PITR の詳細については、「Azure Database for MySQL - フレキシブル サーバー」ドキュメントの「バックアップと復元」セクションを参照できます。
サーバーで自動スケーリング IOPS 機能を使用している場合、IOPS がスケールアップおよびスケールダウンされたタイミングを知るにはどうすればいいですか? または、サーバーの IOPS 使用状況を監視できますか?
「ストレージ パフォーマンスの監視」セクションを参照してください。これは、サーバーが特定の時間枠中にスケールアップまたはスケールダウンされたかどうかを特定するのに役立ちます。
自動スケーリング IOPS と事前プロビジョニングされた IOPS を後で切り替えることができますか?
はい。[設定] ブレードの [コンピューティングとストレージ] セクションで、事前プロビジョニングされた IOPS を選択することで、事前プロビジョニングされた IOPS に戻すことができます。
Azure Database for MySQL フレキシブル サーバーにどの程度の IOPS が使用されているか知るにはどうすればいいですか?
[概要] セクションの下にある [監視] に移動するか、[監視] ブレードの下にある [IO カウント メトリクス] に移動します。 IO カウント メトリックでは、選択した時間枠にサーバーで使用された IOPS の合計を確認できます。