AWS RDS MySQLに対して、いくつかの異なるクエリワークロードをテストしているときに、興味深い問題に遭遇。最初に気づいた問題は、クエリのワークロードに変化がないのに、トータルな時間でトップのクエリが以前より遅くなっていることです。ここでは、クエリパフォーマンスがgp2ボリュームのサイズにどのように影響されるかを説明します。
上図のスクリーンショットでは、トップクエリの速度が低下した時間帯を、レイテンシーの低い前時間帯と比較しています。変更列では、総時間が86%増加しています。次に、CountとAverage Latencyの列を見ると、興味深いことがわかりました。カウントは大幅に減少していましたが、平均レイテンシは3倍になっていました。
次に、2時間全体のCPU使用率を見てみました。レイテンシーが増加すると、CPU使用率は減少しました。CPU使用率は、変化しないか、増加すると思っていたので、減少したのは予想外の行動でした。
対象となるクエリはUPDATEなので、Write IOPSを調べてみました。ここでも、Write IOPSの増加が見られると予想されましたが、大きな落ち込みがありました。低下する前は、IOPS数に多少のばらつきがありましたが、低下している間は、Write IOPSは100でプラトー状態になっています。
書き込み IOPS が低下したため、ディスクにボトルネックがあるのかどうかを確認したいと思いました。Disk Queue Depth のグラフを見ると、ディスクで待機している I/O に明らかな変化が見られます。Write IOPSとCPU使用率が減少しているのに、Disk Queue Depthとクエリーレイテンシーが増加したのは、何かが変化したからでしょうか？
DPMのダッシュボードをスキャンして、説明につながるパターンを探したところ、CloudWatch Disk Burst Balanceというチャートに気づきました。見ての通り、この値は時間とともに減少し、ゼロになると問題が発生しました。
これは直面している問題の論理的な根本原因です。では、Disk Burst Balanceとは一体何なのでしょうか？ テストしているRDSインスタンスは、プロビジョニングされたIOPSの代わりに20GBのgp2ボリュームを使用しています。AWSはボリュームのサイズに基づいてgp2のIOPS量を決定し、最小値は100IOPSであることが判明しています。このため、100IOPSにプラトーしていることが説明できます。問題の前にパフォーマンスが向上した理由は、AWSがボリュームサイズに関係なく540万I/Oクレジットでボリュームをスタートさせるからです。クレジット（ディスクバーストバランス）を使い切ると、インスタンスはクレジットが補充されるまで、ボリュームサイズの最大ベースIOPSしか得られません。
この制限を理解することは、Provisioned IOPSの代わりにgp2を使用しているAWS RDSインスタンスを監視する際に非常に重要です。gp2 と Provisioned IOPS を比較する負荷テストを行う場合は、テスト中にワークロードを理解し、適切なワークロードを再現して、本番でこの問題を見逃さないようにすることが重要です。本番環境でこの問題が発生した場合は、ボリュームサイズを大きくして、RDS の I/O パフォーマンスを向上させることができます。
関連したトピックス
- 仮想化されたデータベース：パフォーマンス監視の考慮事項
- DBMotoのレプリケーションパフォーマンスを向上させる方法
- Microsoft SQL Serverのバックアップとリストア手法
- DB2 LUWのトランザクションログを利用したミラーリング【リアルタイムレプリケーションツールDBMoto】
- MySQLでのutf8で文字化けの対応方法【リアルタイムレプリケーションツールDBMoto】
- MySQLで大文字のテーブル名を扱う＆サーバ文字コード変更
- 3つのレプリケーションモードと対応DB【リアルタイムレプリケーションツールDBMoto】
- PostgreSQLとMySQLのデータベースとしての機能の違い
- DBMotoレプリケーションに必要なMySQLユーザ権限
- log上のwarningメッセージのdisable方法【リアルタイムレプリケーションツールDBMoto】
RSSフィードを取得する
