こんにちは、ビデオリサーチ入社66ヵ月目のトヨシマです。
ビデオリサーチではいくつかのシステムをAWSで運用していますが、 多分に漏れず円安の影響をモロに受けています。 今日はそんな円安に負けないためのコスト削減の取り組みの一つをご紹介したいと思います。
ビデオリサーチでは現在、効果の大きな以下の3つを軸にコスト抑制を行なっています。
- ストレージクラスやタイプなど、設定変更によるコスト削減。
- Reserved Instance(RI)やSavings Plans(SP)など、契約や料金プランの活用によるコスト削減。
- ワークロードや保持データ、バックアップの削減などリソース消費量そのものを削減することによるコスト削減。
今回は1つ目の「設定変更」で行った、Amazon Aurora I/O-Optimized(以下I/O最適化)の活用についてお話ししたいと思います。 安くなるのか？ならないのか？を比較できる式を記載しているので、検討の一助になれば幸いです。
検討に至る当時の状況
ビデオリサーチのとあるシステムのデータベースはなかなかタフな環境に置かれていて、 日本全国から収集するデータをデータベース(Aurora)に昼夜を問わず書き込み続けています。 https://d1.awsstatic.com/events/jp/2021/summit-online/CUS-04_AWS_Summit_Online_2021_Video_Research.pdf
結果として多分に発生するのがI/O課金です。 Cost Explorerの使用タイプでは「APN1-Aurora:StorageIOUsage(東京リージョンの場合)」が該当します。 これはAuroraのクラスタストレージに対しデータの書き込み時、読み込み時にI/Oが発生すると課金されます。 書き込み時(INSERTやUPDATE、それ以外にもロードなど)は基本的に発生しますが、読み込み時はメモリ状況やクエリ、キャッシュによってかなり変動します。 (実際に「ナニモシテナイナニモカエテナイオレハワルクナイノニキュウニコワレタ！」的な事象に遭遇しました)
先のシステムでは月間のAuroraコストの半分以上がこのI/O課金となっていました。 Aurora自体の性能や運用性は魅力的であるものの、この課金だけを理由に通常のRDSや当該課金のない他社クラウド(Google CloudのAlloyDBなど)を検討していました。
I/O最適化プランの登場
しかしその検討真っ只中の2023年、満を持してI/O最適化プランが発表されました。 aws.amazon.com
料金体系をざっくりいうと、 インスタンス料金は3割増し、ストレージ料金は倍、その代わりI/O課金はゼロ、というものです。
I/O最適化プランの導入方法
このプランへの変更は非常に簡単で、対応したインスタンス＆バージョンのクラスタであればコンソールからダウンタイム無しで変更可能です。
I/O最適化プランの料金体系
簡単、とは言いつつも実際に変更するためには社内の様々な儀式を消化が必要ですし、下振れするにしてもどれくらいのインパクトになるのか、予実管理の観点でも算出する必要がありました。 以下はI/O最適化時の費用面の違い(というよりそれしかない)です。
- スタンダードプランと比較し、ストレージ料金が$0.12/GB→$0.27/GBと2.25倍となる
- スタンダードプランと比較し、インスタンス料金が約1.3倍となる
- I/O課金は0となる
計算式
以下の計算式で費用を算出し、比較することでI/O最適化を選択すべきか判断可能です。RIの場合は「インスタンスの時間単価」を「RIの時間あたり単価」に置き換えてください。
Aurora スタンダード
$0.12 x ストレージ利用量(GB) +インスタンスの時間単価($) x 24hours x 30.5days x インスタンス数 + I/Oカウント ÷ 1,000,000 x $0.24=スタンダード時の月額($)
Aurora I/O最適化
$0.27 x ストレージ利用量(GB) +インスタンスの時間単価($) x 24hours x 30.5day x インスタンス数 x 1.3=I/O最適化時の月額($)
試算
では、実際に当てはめてみましょう。 I/OカウントはCloudWatchのメトリクスではIOPSから、CostExplorerであればAuroraIOStorageから確認可能です。 CloudWatchのWriteIOPSやReadIOPSから算出する際は「Input/Output operations Per “Second”」なので60秒を乗算するのをお忘れなく。 例えば東京リージョンでインスタンスタイプにr6g.8xlarge 、リーダ/ライタの2インスタンス構成、ストレージを1,000GB、I/Oカウントが100億の場合は以下のようになります。
オンデマンド
このまま使うことはないと思いますが、まずはオンデマンドの場合を見てみましょう。
Aurora スタンダード
- $0.12 x 1,000GB + $5.012 x 24hours x 30.5days x 2instances + 10,000,000,000count ÷ 1,000,000 x $0.24=$9,857
Aurora I/O最適化
- $0.27 x 1,000GB + $5.012 x 24hours x 30.5days x 2instances x 1.3=$9,808
おや？あまり差がありませんね。 100億のI/Oは決して少なくありませんが、これではあえて選ぶ必要はなさそうです。
RI
では続いて、3年全額前払いのRIで比較してみましょう。3年もあればきっと俺も結婚して子供が生まれていますね。
Aurora スタンダード
$0.12 x 1,000GB + $1.871 x 24hours x 30.5days x 2instances + 10,000,000,000count ÷ 1,000,000 x $0.24=$5,259
Aurora I/O最適化
$0.27 x 1,000GB + $1.871 x 24hours x 30.5days x 2instances x 1.3=$3,830
なんということでしょう！
RIの割引によって全体に占めるインスタンスの料金の割合が減少したことでI/O最適化時のインスタンス料金1.3倍の影響が小さくなり、I/O課金の割合が相対的に上昇したことから、大きくトータルコストを削減(-27%)できています。
上記の比較だけを見ても、インスタンスの時間単価ごとに損益分岐点となるI/Oとストレージ利用量が存在することがお分かりいただけたかと思います。
これは2023年末に実際のシステム(月間I/OはI/O最適化を行なったクラスタだけで600億以上)に導入して以降の推移ですが、以下のように課金対象となるI/Oカウントを大幅に削減できています。
注意点
読み込み時のI/Oが多い場合、インスタンスタイプを上げることでメモリ容量が増加し解消される場合がありますので、書き込み時I/Oの総量やストレージコスト、信頼性なども加味しながらご検討ください。
端数問題
ちなみにRIを購入する場合、例えばr系インスタンスの正規化単位は最小でも4です。 この時、I/O最適化時に必要なRIはlargeの場合は5.2、xlargeの場合は10.4、、2xlargeの場合は20.8、4xlargeの場合は41.6、8xlargeの場合は83.2、16xlargeの場合は166.4…となります。 そのため、RI共有や他のDBがない環境下において運用する場合、インスタンスサイズとRIを組み合わせによっては最大3.6の端数が発生し、その分をオンデマンドで動かすか、RIで[4-端数]を余らせることとなります。
先ほどの例(RI,3年,I/O最適化)の場合、端数は2.4となるため実際のトータルコストは以下の通りとなります。
- 理論値: $3,830
- 端数をオンデマンド: $3,919
- 端数をRI: $4,011
スタンダードの$5,259を逆転するようなことは起きませんが、スパルタンなコスト管理をしている場合は考慮が必要です。
最後に
I/O最適化プランは目に見えて削減できるコストが最大の魅力ではありますが、もう一つメリットがあります。 それはワークロードの変動やDBの実行計画の変更によってある日突然I/Oが大量に発生しても、あくまで信頼性の観点で運用をすれば良いことです。 コスト懸念については考慮が不要となるため、運用チームの負荷を大きく軽減することができます。
クラウド提供事業者へ支払う直接的なコストだけではなく、それ以外の数字に出にくいコストやチーム全体の生産性を考えることは非常に重要で、 このプランは運用負荷を軽減するAuroraと非常に相性の良いものだと思います。
