ApsaraDB RDS for SQL Server インスタンスにおいて、I/O スループットが高くなるとクエリパフォーマンスが低下します。I/O パフォーマンスは、IOPS と I/O スループットの 2 つの要因によって決まります。ほとんどの場合、IOPS がパフォーマンスボトルネックになることは少なく、I/O スループットが上限に達した際に問題が発生しやすくなります。本トピックでは、根本原因の特定方法および適切な対処方法について説明します。
I/O スループット制限
最大 I/O スループットは、インスタンスにアタッチされたストレージタイプによって異なります。
プレミアムローカル SSD
プレミアムローカル SSD を使用する RDS インスタンスは、物理ホストのストレージを同一ホスト上の他のインスタンスと共有します。各インスタンスには最大 IOPS 制限がありますが、I/O スループットはインスタンス単位で制限されません — スループットは 1 GB/s を超える場合があります。ただし、インスタンスが基盤となるストレージを共有しているため、I/O リソースを競合することがあります。I/O リソースを専有する場合は、専用ホストインスタンスファミリーをご利用ください。詳細については、「ApsaraDB RDS の主なインスタンスタイプ」をご参照ください。
クラウドディスク
クラウドディスクは各インスタンスに専用のストレージであるため、インスタンス間で I/O リソースを競合することはありません。クラウドディスクを使用するインスタンスの最大 I/O スループットは、以下の 2 つの要因によって決まります：
コンピューティングリソース：「ECS g6 インスタンスファミリーの仕様」で定義されます。
ストレージの種類と容量: RDS は、標準 SSD および ESSD をサポートしています。スループットは、ストレージの種類と容量によって異なります。
I/O 負荷の種類を特定する
RDS インスタンスの I/O 負荷には、主に以下の 2 つの構成要素があります：
データファイルの読み取り：クエリ実行およびバックアップ時のデータページの読み取り。
トランザクションログの読み取りおよび書き込み：ログの読み取りは主にバックアップ操作から発生します。ログの書き込みは、DML（データ操作言語）および DDL（データ定義言語）操作から発生します。
高 I/O スループットの原因となっている負荷の種類を特定するには、Performance Insight タブで以下のメトリックをモニターします：
| メトリック | I/O タイプ | 説明 |
|---|---|---|
| Page_Reads | 読み取り | キャッシュで対応できない場合に、データファイルから 1 秒あたりに読み取られるデータページ数 |
| Page_Write | 書き込み | データファイルに 1 秒あたりに書き込まれるデータページ数 |
| Log_Bytes_Flushed/sec | 書き込み | トランザクションログファイルに 1 秒あたりに書き込まれるバイト数 |
| Backup_Restore_Throughput/sec | 読み取り | バックアップおよびリストア操作中に、データファイルおよびトランザクションログファイルから 1 秒あたりに読み取られる、または書き込まれるバイト数 |
各データページは 8 KB です。
下記の表を用いて根本原因を特定し、該当するセクションにジャンプしてください：
| 上昇したメトリック | 根本原因 | 参照先 |
|---|---|---|
| Page_Reads | キャッシュ不足（ディスクからのデータページ読み取り） | データページ読み取りによる高 I/O |
| Page_Write、Log_Bytes_Flushed/sec | DML または DDL ワークロードの過重化 | 書き込み操作による高 I/O |
| Backup_Restore_Throughput/sec | バックアップ活動 | バックアップによる高 I/O |
I/O スループットメトリックの表示
この手順は、クラウドディスク上で SQL Server 2008 R2 を実行しているインスタンスには適用されません。
「インスタンス」ページに移動します。上部ナビゲーションバーで、ご利用のインスタンスが配置されているリージョンを選択します。該当インスタンスを見つけ、その ID をクリックします。
左側ナビゲーションウィンドウで、自律サービス ＞ パフォーマンス最適化 を選択します。表示されたページで、Performance Insight タブをクリックします。
右上隅の カスタムメトリック をクリックします。ダイアログボックスで I/O スループット を選択し、OK をクリックします。I/O スループット を選択すると、チャートに以下のメトリックが追加されます：
IO_Throughput_Read_Kb：ディスク読み取り操作における 1 秒あたりの I/O スループット。
IO_Throughput_Write_kb：ディスク書き込み操作における 1 秒あたりの I/O スループット。
IO_Throughput_Total_Kb：読み取りおよび書き込みの合計 I/O スループット（1 秒あたり）。
特定の負荷タイプを詳しく分析するには、再度 カスタムメトリック をクリックし、「I/O 負荷の種類を特定する」の表に記載されたメトリックを追加します。
ケース分析
以下に、異なるタイムウィンドウにおける I/O スループットデータの解釈例を示します。
全体の読み取り負荷は書き込み負荷を上回っています。スループットは 08:00～22:00 の間安定しており、01:00～03:00 および 22:00～24:00 にピークが見られます。
約 01:00 のピーク — データページ読み取りが約 50,000 ページ/秒（約 400 MB/s）まで急増しています。これは、キャッシュプレッシャーによりディスク読み取りが発生していることを示唆します。
02:00～03:00 のピーク — 4 つの要因が重なり、合計で約 150 MB/s のピークを形成しています：
| ソース | スループット |
|---|---|
| データページ読み取り | 約 40 MB/s |
| データページ書き込み | 約 40 MB/s |
| トランザクションログ書き込み | 約 30 MB/s |
| ログバックアップ | 約 50 MB/s |
08:00～22:00 の定常状態 — 比率の高い順に 3 つの要因があります：
| ソース | スループット |
|---|---|
| データページ読み取り | 80～100 MB/s |
| データページ書き込み | 約 30 MB/s |
| トランザクションログ書き込み | 約 5 MB/s |
22:00～24:00 のピーク — バックアップ活動のみであり、220 MB/s を超えるスループットが継続しています。
データページ読み取りによる高 I/O のトラブルシューティング
過剰なデータページ読み取りは、ApsaraDB RDS for SQL Server インスタンスにおける高 I/O の最も一般的な原因です。バッファープールが頻繁にアクセスされるデータを保持するには小さすぎる場合、SQL Server はキャッシュミスごとにディスクからデータページを読み取らなければなりません。
PLE を用いたキャッシュプレッシャーの診断
Page Life Expectancy (PLE) は、データページがバッファープール内に保持される平均時間（秒）を測定します。PLE の低下は、キャッシュプレッシャーの増大を示します。
健全な PLE の最低しきい値は 300 秒です。メモリ量が多いインスタンスの場合、推奨しきい値は以下の式で算出します：
推奨 PLE しきい値 = （バッファープールのメモリ量（GB） ÷ 4） × 300例：RAM 16 GB のインスタンスでは、バッファープールに最大 12 GB が割り当てられます。
推奨 PLE しきい値 = （12 ÷ 4） × 300 = 900 秒PLE がしきい値を継続的に下回る場合、ワークロードに対してバッファープールが小さすぎます。このメトリックに関する背景情報については、「SQL Server における Page Life Expectancy (PLE)」をご参照ください。
データページ読み取りによる高 I/O の解決
主な対策は、インスタンスのメモリ仕様をスペックアップすることです。読み取り負荷が高い I/O 問題に対処するために、ディスクパフォーマンスレベル（PL）をアップグレードしないでください — より大きなバッファープールを設定することで、ディスク読み取りを根本的に削減できます。
さらに、読み取る必要のあるデータページの総数を削減するには、以下の操作を行います：
既存データのアーカイブまたは削除。
大規模テーブルでのデータ圧縮の有効化。
価値の低いインデックスの削除。
インデックスの断片化を軽減するためのインデックス再構成（デフラグ）。
書き込み操作による高 I/O のトラブルシューティング
高書き込み I/O は、DML または DDL 操作によって引き起こされます。自律サービスを用いて、高 I/O 期間中に実行されていた操作を確認します。
DML 操作による書き込み I/O を生成するものには、INSERT、DELETE、UPDATE、MERGE があります。DDL 操作には、CREATE INDEX および ALTER INDEX が含まれます。
DML 操作による高 I/O
まず、DML 活動が通常のワークロードか、一時的なタスクかを判断します。
非通常ワークロード（例：大量データのアーカイブやワンタイムのデータ処理）：これらの操作は、業務トラフィックと競合しないよう、非ピーク時間帯にスケジュールしてください。
通常ワークロード：ディスクパフォーマンスレベル（PL）をアップグレードします。たとえば、ESSD を PL1 から PL2 へアップグレードします。また、インデックス構造を見直し、不要となった非クラスター化インデックスを削除します。不要なインデックスは書き込み増幅を増加させるためです。
DDL 操作による高 I/O
インデックス作成および再構築などの DDL 操作は、通常メンテナンスタスクです。これらは非ピーク時間帯にスケジュールしてください。
CREATE INDEX または ALTER INDEX を実行する際には、SQL ステートメント内で最大並列処理の次数（MAXDOP）を指定します。MAXDOP を設定すると、使用される並列スレッド数が制限され、操作によって生成されるピーク I/O スループットが低減します — ただし、実行時間が長くなるというトレードオフがあります。
バックアップによる高 I/O のトラブルシューティング
ApsaraDB RDS for SQL Server では、バックアップはプライマリインスタンスでのみ実行されるため、プライマリインスタンスの I/O 負荷が増加します。完全バックアップが最も影響が大きく、ログバックアップが最も影響が小さいです。
ご利用のインスタンスのバックアップ持続時間を確認するには、ApsaraDB RDS コンソールの バックアップおよびリストア ページに移動します。
ピーク時間帯を避けてバックアップをスケジュールする
バックアップ開始時刻およびバックアップサイクルを設定し、業務ピーク時間帯との重複を最小限に抑えます。詳細な設定手順については、「ApsaraDB RDS for SQL Server インスタンスのバックアップ」をご参照ください。
例 1：完全バックアップの所要時間は約 6 時間です。業務ピーク時間帯は 09:00～21:00 であり、バックグラウンド処理ジョブは 22:00～01:00 に実行されます。バックアップ開始時刻を 01:00～02:00 に設定します。各バックアップは 08:00 前に完了します。復元のベースラインを最新に保ち、ポイントインタイム復元を高速化するために、バックアップサイクルを毎日実行するように設定します。
例 2：完全バックアップの所要時間は約 15 時間であり、平日のワークロードに毎回干渉します。バックアップサイクルを土曜日および日曜日のみに設定します。ただし、完全バックアップの頻度が低くなると、より多くのログバックアップを再生する必要があるため、ポイントインタイム復元に要する時間が長くなる可能性があります。
スケジューリングだけでは不十分な場合
バックアップスケジュールの調整だけではワークロードとの競合が解消されない場合は、以下の対策を検討してください：
ディスクパフォーマンスレベル（PL）のアップグレード：より高いディスク PL は、より多くの I/O スループットを提供し、バックアップおよびワークロード双方に余裕を与えます。
データを複数のインスタンスに分割する：インスタンスごとのデータセットを小さくすることで、バックアップの所要時間およびバックアップ実行時の I/O をともに削減できます。