AuroraのStandardクラスで見積もりを作るとき、インスタンス時間とストレージ容量はサイジングが決まれば計算できます。止まるのはI/Oリクエストの行です。既存のオンプレミスDBで取った平均IOPSを流用しようとしても、「その数字はAuroraのI/Oリクエストと同じものを数えているのか」と聞かれると答えに詰まります。多めに積めば金額が膨らんで稟議で差し戻され、少なめに積めば稼働後の請求額で慌てることになります。
この記事は「Aurora料金の見積もり方｜I/Oコストを実測で試算する手順」の一部を、話題を絞って書き直したものです。CloudWatchで月間I/Oリクエスト数を実測する具体的な手順や、StandardとI/O-Optimizedの選び分けは、ブログの完全版にまとめています: Aurora料金の見積もり方｜I/Oコストを実測で試算する手順
Aurora StandardのI/Oリクエストは何を数えているのか
Aurora Standardの料金は、インスタンス時間とストレージ容量、そしてI/Oリクエストの3つで構成されます。前の2つは机上で計算できますが、I/Oリクエストだけはワークロードに依存します。
このI/Oリクエストは、SQLの発行本数でも取得行数でもありません。Auroraのストレージレイヤーに対して実際に発生したI/Oオペレーションの数を数えます。ここを取り違えたまま「既存システムのディスクIOPSが平均2,000だから、Auroraでも2,000 IOPS相当だろう」と計算すると、桁が合わないことがあります。
オンプレミスのIOPS統計から換算できない理由
iostatやOracleのV$SYSSTAT、PostgreSQLのpg_stat_databaseからI/O統計は取れます。ただし、その値をAuroraのI/Oリクエスト数へ換算する計算は成立しません。ストレージアーキテクチャが根本的に違うためです。
オンプレミスの一般的な構成では、DBプロセスがデータファイルへブロック単位で読み書きします。その手前にOSのページキャッシュとストレージ側のキャッシュが挟まります。チェックポイントのたびにダーティバッファがデータファイルへ書き戻され、同じブロックが何度も書かれます。計測したIOPSに、OSキャッシュで吸収された分やストレージ側で結合された分がどう反映されるかも環境によって変わります。
Auroraはコンピュートとストレージが分離されており、DBインスタンスはデータページの書き戻しをしません。永続化のためにストレージレイヤーへ送るのはredoログだけで、ページの再構成はストレージノード側が担います。「チェックポイントでまとめてデータファイルに書く」というI/Oパターンが存在しないわけです。読み取りについても、DBインスタンスのバッファキャッシュでヒットすればストレージへ問い合わせは飛びません。
同じSQLを流してもストレージレイヤーに届くI/Oの形が変わります。既存のIOPS値に係数を掛けてAuroraの請求額を当てる発想そのものに無理があるため、見積もりは検証環境の実測から出してください。
見積もりに必要な数字は2つだけ
使うメトリクスは次の2つです。
-
VolumeReadIOPsクラスターボリュームからの読み取りI/O数 -
VolumeWriteIOPsクラスターボリュームへの書き込みI/O数
どちらもDBインスタンスではなくクラスターレベルのメトリクスで、ディメンションはDBClusterIdentifierです。Auroraはストレージをクラスター内で共有するため、I/O課金もクラスターボリューム単位で発生します。インスタンス単位のメトリクスを探しても見つかりません。
この2つを月間合計に換算し、公式料金ページのI/O単価を掛ければ月額が出ます。単価は100万リクエストあたりの価格で提示されるため、実測値の桁をそろえて計算してください。単価そのものはリージョンや改定で変わるので、見積もり時点の公式料金ページで確認するようにしてください。
計算式は単純です。見積もり作業の難所は、本番に近いワークロードをどう再現して2つの数字を取るかという段取りの側にあります。本番相当のデータ量と同時実行数を用意できるかどうかで、見積もりの精度が決まります。
元記事で扱っている内容
- CloudWatchで
VolumeReadIOPsとVolumeWriteIOPsから月間I/Oリクエスト数を実測する手順 - 見積もりでつまずきやすい誤解3つの整理
- I/Oコストを下げる打ち手と、StandardとI/O-Optimizedの選び分けの基準
- 本番稼働後にI/Oコストが急増しないための監視設計
- Aurora料金の見積もりに関するよくある質問