マネージドサービス部 佐竹です。
Amazon Aurora I/O-Optimized オプション (Aurora I/O 最適化) を本番環境に適用することで、Aurora のコストを大きく減額することに成功しました。そのために行った調査・対応とその結果をまとめてご報告します。
はじめに
Amazon Aurora I/O-Optimized（Amazon Aurora I/O 最適化）は、2023年5月頃に発表されたアップデートです。
このアップデートは、Amazon Aurora で請求される「I/O 料金」を削減するためのオプションで、特に I/O の高いワークロードに適した「コスト最適化」オプションです。
本ブログでは、この機能について掘り下げます。
Amazon Aurora I/O-Optimized とは何か
本機能の理解には、まず Aurora の料金体系について知る必要があります。
以下は Amazon Aurora の料金ページから抜粋した「データベースストレージおよび I/O 別の料金」についての表です。
| コンポーネント | Aurora Standard | Aurora I/O 最適化 |
|---|---|---|
| ストレージ料金 | USD 0.12/毎月の GB あたり | USD 0.27/毎月の GB あたり |
| I/O 料金 | USD 0.24/100万リクエスト | 利用料に含まれる*1 |
2023年5月までは表の左側にある「Aurora Standard」のみが存在しており、100万リクエストあたり $0.24 が請求されるのが Aurora の仕様でした。これは Aurora 登場時からの料金仕様です。
まずこの Aurora Standard について少し掘り下げます。
I/O リクエストが請求で問題になる場合
Aurora ではなく、通常の Amazon RDS には、この I/O リクエストへの請求がありません。
このため、メンテナンスや使い勝手の都合を鑑みて*2、Amazon RDS for MySQL (PostgreSQL) から Aurora MySQL (PostgreSQL) に移管をされた一部のお客様で「I/O リクエスト」のために維持費用が増加してしまったという実例があります。
この I/O リクエストにかかる費用はリザードインスタンス (RI) のようなコスト最適化オプションもなく、利用者は I/O リクエストの費用は「仕方がない」ものとして払わざるを得ませんでした。つまりは、Amazon RDS から Amazon Aurora への切り替えにおける大きな課題として、長らく「I/O リクエストによる費用の増大」が存在していました。
Aurora I/O-Optimized で I/O リクエストのコスト削減が可能に
Aurora I/O-Optimized は、この「I/O リクエストによる費用の増大」を回避することができるオプションです。つまり I/O リクエストが大きな Aurora Cluster 向けの機能です。
どのような費用体系かご説明しますと「Aurora Cluster に割り当てられたストレージの費用が 2.25 倍に増える代わりに I/O リクエスト費用が無料になる」というものです。計算式としては「$0.27/$0.12=2.25」倍であり、「現在の料金($0.12)＋1.25倍($0.15)」とも書けます。
このため「現在の I/O リクエスト費用 ＞ Standard ストレージ費用×1.25」であれば本オプションによりコスト最適化が可能という計算式が一旦成り立ちそうです。
具体的な例として、100GB のストレージを持つ Aurora Cluster を考えます。そして仮にリクエスト料金が毎月 $500 ある Aurora Cluster と $5.0 ある Cluster をそれぞれ考えるとしましょう。
| コンポーネント | Aurora Standard | Aurora I/O 最適化 | 差額 | 損得 |
|---|---|---|---|---|
| ストレージ料金 | $0.12 * 100GB = $12 | $0.27 * 100GB = $27 | +$15 | - |
| I/O 料金が大きい場合 | $500 | 請求されない ($0) | -$500 | $485 の得 |
| I/O 料金が小さい場合 | $5.0 | 請求されない ($0) | -$5.0 | $10 の損 |
このように、I/O 料金が大きい場合には月額が削減できることがわかります。反対に、I/O 料金が低い Aurora Cluster ではこの設定により費用が増えてしまいます。
今回の例であれば、ストレージ費用が現在 $12 のため、「現在の I/O リクエスト費用 ＞ Standard ストレージ費用×1.25」で考えると、「現在の I/O リクエスト費用 ＞ $15」になります。ですので、I/O リクエストが恒常的に $15 以上請求されているのであれば切り替えの判断になりそうに見えます。
なのですが、次に Aurora のランニング費用を確認していきます。
ただし、インスタンスのランニング費用が RI 含め 30% 増加する
Amazon Aurora の料金ページ から抜粋しますが、オンデマンドインスタンスにおける「Aurora I/O 最適化」の費用は、「Aurora Standard」と比較して 30% 増加します。赤枠で囲った箇所に、Aurora Standard に1.3倍した金額が表示されている通りです。
これは、同料金ページ下部にあるリザーブドインスタンスに関する説明欄にも 30% 増の補足がされています。
Aurora I/O 最適化での Aurora Standard リザーブドインスタンスの使用例
Aurora I/O 最適化で既存の Aurora Standard リザーブドインスタンス (RI) を再利用できます。Aurora I/O 最適化の RI 割引のメリットを最大限に活用するには、現在の RI と同じ RI を 30% 追加購入できます。
本説明からわかるように、RI によるコスト最適化を実施する場合、通常の Aurora Standard と比較して 30% RI の追加購入が必要となります。
これはつまり、Aurora DB インスタンス（例えば db.r6g.large）が10台ある場合、この全てが Aurora I/O-Optimized であるならば、RI を10台ではなく13台分購入する必要が出ることになります*3。
Aurora DB クラスター設定の柔軟性
Aurora はこれらの構成間の価格差を自動的に計算します。 Aurora I/O-Optimized では、1 時間あたりの正規化ユニットの消費量が Aurora Standard より 30% 増えます。
上記抜粋の通り、AWS 公式ドキュメントにも記載がありますため、こちらも合わせてご確認ください。
さて、この点を加味すると「現在の I/O リクエスト費用 ＞ Standard ストレージ費用×1.25」であれば本オプションによりコスト最適化が可能という計算式が一旦成り立ちそう、でしたが実際はインスタンス利用料の増加を加味して判断が必要です。
ここで先程と同様、リクエスト料金が毎月 $500 ある Aurora Cluster と $5.0 ある Cluster を継続して考えてみます。I/O 料金が大きい場合、先ほどは $485 の得となりました。ここにオンデマンド料金を加味してみましょう。
オンデマンド料金を「X (定価)」とすると、これが「X × 1.3」になるため、「0.3 × X」が「$485」よりも安ければ得をすることになります。少々計算がややこしいですね。
ここはお手間となりますが、個別に手元で計算してご判断いただく必要があるかと存じます。
ここまでの Amazon Aurora I/O-Optimized に関する費用のまとめ
- Aurora Cluster に割り当てられたストレージの費用が 2.25 倍になる代わりに、I/O リクエスト費用を無料できる
- ランニングコストが Aurora DB インスタンスの Standard と比較して 1.3 倍となる（オンデマンド、RI 共に）
- 上記2点を加味しても、I/O リクエスト費用が無料になることによるコスト最適化効果が大きい場合は、Aurora I/O-Optimized 構成を選択する方が良い
Cost Explorer で切り替えの判断を行う
ここから Cost Explorer を用いて切り替えの判断をしていきます。
東京リージョンでは以下の2つの Usage type が Aurora のスタンダードストレージ料金と I/O 料金を表します。
- APN1-Aurora:StorageIOUsage
- APN1-Aurora:StorageUsage
各 Aurora Cluster 単位で費用を確認するには、事前に Cluster（及び Aurora DB インスタンス）にコスト配分タグを付与しておくとよいでしょう。
Cost Explorer で「APN1-Aurora:StorageIOUsage」と「APN1-Aurora:StorageUsage」を表示し、Dimension でそれらを Name タグごとに表示してみました。明らかに1台、費用が高額な Aurora Cluster が存在しています。
先ほど発見した Name タグでさらにフィルターし、Dimension を Usage type に変更します。利用料を確認すると、2023年10月分において APN1-Aurora:StorageIOUsage が「$1,201.25」、そして APN1-Aurora:StorageUsage が「$23.53」であることがわかりました。
先ほどの表で考えると、$23.53 の 1.25 倍となる $29.4125 を追加で支払えば「$1,201.25」が0円になる計算です。これはつまり $1,201.25 - $29.4125 = $1,171.8375 の月額ストレージ費用削減になるということを示しています。なんとストレージと I/O の料金の 97.6% がコストカットできることがわかりました。
DB インスタンスのランニングコストを計算する
ただし、ランニングコストが Aurora Standard と比較して 1.3 倍となる点には留意が必要です。サンプルとした Aurora Cluster は db.r5.2xlarge の DB インスタンスが2台で構成されています。
Amazon Aurora I/O-Optimized は「Aurora Cluster 単位」での設定になっているため、上記2台の DB インスタンス共に 1.3 倍の影響を受けます。
db.r5.2xlarge のオンデマンド利用料は1時間あたり $1.40 であり、これが変更後に $1.82 へと増加します。差額は +$0.42 ×2 台/h となります。月額に換算すると、$0.42 × 2 × 730 hr = $613.2 程度です*4。先に記載した通り、月額 $1,171.8375 のストレージ費用を削減できることになりますが、$613.2 がさらに追加されるため、コスト最適化効果は $558.6375 に留まります。
既に RI を購入している場合
同様の例のまま、もし db.r5.2xlarge の2台分の RI を購入済の場合でも「追加される 30% 分は、RI が適用されない限りはオンデマンド料金での差額となる」ためオンデマンドの場合と同様に、設定変更後に追加請求される料金は +$0.42 ×2 台/h となります*5。
これを RI で最適化する場合は、追加で 30% 分の RI を購入する必要がありますが、db.r5.2xlarge × 2台 の30%は、db.r5.large 2.4台分です。db.r5 ファミリーの最小単位は db.r5.large であり、さらに RI は1台単位でのみ購入可能なため、今回の場合では2台分を追加することで完全ではないもののコスト最適化が可能でしょう。しかし、0.4 台分はオンデマンド料金のまま利用することとなる想定です。
設定方法
では、早速設定方法をお伝えしますが、注意事項があるので以下に記載します。
1. 対応 DB インスタンス
AWS の News 記事に追記された情報を確認するに db.t3、db.t4g、db.r5、db.r6i、db.r6g、db.x2g、db.r7g が対応しているとのことです。
これはつまり、2023年11月現在の東京リージョンで利用が可能な全ての DB インスタンスクラスで利用が可能と考えて頂いて問題なさそうです。
2. 対応 DB エンジンバージョン
対応しているバージョンについては、AWS の公式ブログに記載があります。
Aurora I/O-Optimized configuration is available in the latest version of Aurora MySQL version 3.03.1 and higher, Aurora PostgreSQL v15.2 and higher, v14.7 and higher, and v13.10 and higher.
[翻訳]
Aurora I/O-Optimized は、最新バージョンの Aurora MySQL バージョン 3.03.1 以降、Aurora PostgreSQL v15.2 以降、v14.7 以降、および v13.10 以降で利用できます。
補足ですが、2023年11月現在の Aurora MySQL の最新バージョンは v3.05.1 (compatible with MySQL 8.0.32) で、Aurora PostgreSQL は v15.4、v14.9、v13.12 です。リリース当時の最新バージョンが上記の通りでした。
このため、Amazon Aurora I/O-Optimized に対応していないバージョンをご利用されている場合、本機能によるコスト最適化を行うには事前にマイナーバージョンアップが必要です。
3. 切り替えは30日に1回のみ
AWS 公式ドキュメントに記載されているのですが、Cluster storage configuration を Aurora I/O-Optimized へ切り替えるには制限があります。
- Aurora I/O-Optimized から Aurora Standard へは、いつでも切り替える（元に戻す）ことが可能です
- Aurora Standard から Aurora I/O-Optimized へは、30日ごとに1回の切り替えが可能です
以上はドキュメントの該当部分の和訳です。
またこの制限については、AWS マネジメントコンソールで設定を変更する場合にも注意書きとして表示されます*6。
そしてマネジメントコンソールにおいては注意書きが「You can't switch back to Aurora I/O-Optimized until next month. (来月まで Aurora I/O-Optimized に戻すことはできません)」となっています。これが正しいのであれば先に記載のあった「30日ごとに1回の切り替え」というのは「毎月1回（月を跨ぐとリセットされる）」という意味に捉えてしまいそうになりますが、AWS サポートに念のため確認を取ったところ「30日に1回ごと」が正しい理解とのことでした。
4. 切り替え時にダウンタイムは発生しない
以下の公式ドキュメントに、Aurora Cluster で設定を Modify する場合に再起動が発生するかどうか記載があります。
「An outage doesn't occur during this change.」と記載がある通り、サービス停止（ダウンタイム）は発生しません。
ただし、先に記載した通り Aurora Cluster のマイナーバージョンアップが先に必要な場合は、そのタイミングでのダウンタイムが発生する可能性がある点に注意してください。
I/O-Optimized へ変更する
対象の Aurora Cluster を選択し「Modify」を選択した後「Cluster storage configuration」から設定が可能です。
デフォルトは「Aurora Standard」となっているため、「Aurora I/O-Optimized」を選択し、「Continue」を押下して進みます。
Aurora Standard → Aurora I/O-Optimized となっていることを確認しタイミングに問題がなければダウンタイムもありませんため「Apply immediately」で適用します。「Modify cluster」を押下して反映を待ちます。
また特定の Aurora Cluster の Cluster storage configuration が「Aurora I/O-Optimized」かどうかは「Configuration」のタブから確認が可能です。
変更に関する留意事項
Aurora Cluster のマイナーバージョンアップが必要な場合、まずは検証環境やステージング環境でマイナーバージョンアップを試してください。
恐らく「本番環境でのみ I/O リクエストが多い」というケースが大半でしょう。このため、検証環境やステージング環境に「I/O-Optimized」は設定が不要という判断になるはずです。
ですが、マイナーバージョンアップの影響を先に確認しておく必要はあります。
このため検証環境やステージング環境ではマイナーバージョンアップのみを行います。その後、問題が無ければ本番環境をマイナーバージョンアップします。そしてマイナーバージョンアップの影響が本番でもないことの確認が取れた後「Amazon Aurora I/O-Optimized」を設定ください。
コスト削減結果
お待ちかねの、コスト最適化（削減）の結果です。AWS Cost Explorer で確認します。比較に必要なのは先の2つに「APN1-Aurora:IO-OptimizedStorageUsage」を加えた以下の3つの Usage です。
- APN1-Aurora:StorageIOUsage
- APN1-Aurora:StorageUsage
- APN1-Aurora:IO-OptimizedStorageUsage
APN1-Aurora:IO-OptimizedStorageUsage は I/O-Optimized で請求されるスタンダードの 2.25 倍となるストレージの費用です。
先ほどと同様に月額で表示してみましたが、11月の途中で変更したので分かり難いですね。
ということで、Daily 表示にすると明らかですが、Aurora Cluster のストレージの費用が激減しています。
11月の Daily では変更前は毎日 StorageUsage が「$0.79」でしたが、これが IO-OptimizedStorageUsage となり「$1.78」に増えました ($0.79 × 2.25 = $1.7775)。そして StorageIOUsage が消えて請求がなくなりました。
このように、Aurora Cluster のストレージ及び I/O リクエストの費用がおおよそ 97.6% 削減できるということが実際にわかりました。
ただし Aurora DB インスタンスのランニング費用月額も加味しなければなりません。今回は「$0.42 × 2 × 730 hr = $613.2 程度」が加算もされるため、$1,171.8375 - (0.42 × 2 × 730) = $558.6375 が実際の月額削減効果と想定されます。
$558.6375 の月額費用の削減は、1年間でおおよそ「$6,703.65」となり、これを150円レートで日本円換算とするとおおよそ100万円/年となります。このように本機能を利用することで、年間100万円程度のコスト削減が実現できました。
InstanceUsage の表記が変わる
余談ですが、I/O-Optimized を利用すると、その Aurora Cluster における InstanceUsage の名称も変更されます。
画像の通りですが APN1-InstanceUsage:db.r5.2xl が APN1-InstanceUsageIOOptimized:db.r5.2xl になっていました。
名称に「InstanceUsageIOOptimized」が付与されることに念のためご留意ください。またこれによりオンデマンド利用料も元のインスタンスの 1.3 倍が請求されることとなります。
まとめ
本ブログでは、Amazon Aurora I/O-Optimized オプションを本番環境に適用することで、Aurora のコストを年間100万円以上も減額することに成功した事例について紹介させて頂きました。
以下はブログ中ほどに掲載した内容の再掲です。
- Aurora Cluster に割り当てられたストレージの費用が 2.25 倍になる代わりに、I/O リクエスト費用を無料できる
- ランニングコストが Aurora DB インスタンスの Standard と比較して 1.3 倍となる（オンデマンド、RI 共に）
- 上記2点を加味しても、I/O リクエスト費用が無料になることによるコスト最適化効果が大きい場合は、Aurora I/O-Optimized 構成を選択する方が良い
また運用上の注意点もいくつか紹介しました。特に「対応している DB エンジンバージョン」と「I/O-Optimized への切り替えは30日に1度に限られている」という点にはご注意ください。
そしてこのように「Aurora Cluster は I/O リクエストの費用が高いから使いたくない」という話は過去のものになりました！
I/O-Optimized を有効活用し、コスト最適化に配慮した Aurora Cluster の利用をして頂ければ嬉しく思います。
では、またお会いしましょう。
*1:左記をより正確に記載するのであれば「(I/O 料金はストレージの)利用料に含まれる(ようになるため個別には請求がされません)」となるでしょう
*2:Aurora には ZDP や Multi-AZ 構成で Reader にアクセスが可能などの複数のメリットがあります
*3:台数によってはランニング費用を 100% RI でカバーするのが無理な場合もあります
*4:AWS の月額は、24 × 365 ÷ 12 =730 計算されます
*5:RI から足が出ている部分はオンデマンド＝定価で請求されるため
*6:この画面は「Aurora I/O-Optimized」から「Aurora Standard」へ変更する場合に表示されるものです
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
