はじめに
こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。
「インスタンスサイズを上げたらコストが下がりました」と言うと、だいたい「？」という顔をされます。スペック上げたらお金かかるに決まってるだろ、と。自分もそう思っていたので気持ちはわかります。
この記事では、Amazon Aurora のReaderインスタンスを db.r7g.8xlarge から db.r7g.12xlarge にスケールアップした結果、I/Oコストが大幅に減り、トータルのAuroraコストがむしろ下がった話を書きます。バッファプールの仕組みと、判断の経緯もあわせて紹介します。
前提：私たちのAurora構成
まず、当時のAurora（MySQL互換）クラスターの構成を簡単に紹介します。
| インスタンス | クラス | vCPU | メモリ | プロセッサ | 役割 |
|---|---|---|---|---|---|
| reader-1 | db.r7g.8xlarge | 32 | 256 GiB | Graviton3 | API Reader |
| reader-2 | db.r7g.8xlarge | 32 | 256 GiB | Graviton3 | API Reader |
| reader-3 | db.r7g.8xlarge | 32 | 256 GiB | Graviton3 | API Reader |
| writer-candidate-1 | db.r5.24xlarge | 96 | 768 GiB | Intel Xeon | Writer Candidate / Reader |
| writer-candidate-2 | db.r5.24xlarge | 96 | 768 GiB | Intel Xeon | Writer |
Readerは3台構成で、3つのAZに分散配置しています。加えて、writer-candidate-1もWriter Candidateとしてフェイルオーバーに備えつつ、Readerとして読み取りクエリも処理しています。つまり、読み取りは実質4台で分散している構成です。
バッファプールとは何か
本題に入る前に、今回のキーワードである「バッファプール」について少し説明させてください。
MySQLやAurora（MySQL互換）にはInnoDB バッファプールと呼ばれるメモリ領域があります。これはデータベースが頻繁にアクセスするデータやインデックスをメモリ上にキャッシュしておく仕組みです。
データベースがクエリを処理するとき、必要なデータがバッファプールに載っていれば、メモリから直接読み取れるので非常に高速です。一方、バッファプールに載っていないデータが必要になった場合は、ストレージ（ディスク）からデータを読み込む必要があります。これがストレージI/Oです。
ここで重要なのがバッファプールヒット率という指標です。これは「データベースが必要としたデータのうち、バッファプールから取得できた割合」を示します。
- ヒット率100%：すべてのデータがメモリ上にあり、ディスクへのアクセスが発生しない理想的な状態
- ヒット率99.9%：一見ほぼ完璧に見えますが、0.1%のミスが積み重なると、秒間数千〜数万回のI/Oリクエストに化けることがあります
Aurora ではバッファプールのサイズはデフォルトでインスタンスメモリの75%が割り当てられます。つまり、256 GiBのメモリを持つ db.r7g.8xlarge では、約192 GiBがバッファプールとして使われる計算です。
そしてAuroraの料金体系において見逃せないのが、I/Oコストは従量課金であるという点です。ストレージへの読み取りリクエスト（Read IOPS）が増えれば増えるほど、課金額も増える。つまりバッファプールヒット率の僅かな低下が、じわじわとコストに効いてくるわけです。
異変に気づく：「たった0.1%」の落とし穴
事の発端は、以前から認知しつつも対応の優先度を上げきれていなかった、バッファプールヒット率の数字でした。
Readerインスタンスのバッファプールヒット率は、もともと99.9%前後で推移していて、100%には達していませんでした。「99.9%ならほぼ問題ないのでは？」という感覚で、それまで明確な対策は打てていなかった、というのが正直なところです。
しかし、弊社のサービスは非常にアクセス数が多く、それに伴うクエリの総量も膨大です。母数が大きいと、たった0.1%のバッファプールミスでも、ストレージへの問い合わせ回数は凄まじい量になります。
実際にCloudWatchで AuroraStorageReadIOsPS（Aurora ストレージへの秒間読み取りI/O数）を確認すると、reader-1では最大約13,000 IOPS、平均でも約7,488 IOPSに達していました。
そしてこの数字は1インスタンスあたりの値です。同じスペックのReaderが3台あるため、クラスター全体では単純計算で最大約39,000 IOPS、平均でも約22,000 IOPSものストレージ読み取りが発生していたことになります。AuroraのI/Oコストは従量課金なので、この3台分のI/Oがそのままコストに跳ね返っていました。
「パラメータをいじる」という選択肢はなかったのか
「バッファプールを大きくしたいなら、innodb_buffer_pool_size パラメータを変更すればいいのでは？」という発想は当然あります。
たしかに、Auroraのパラメータグループからバッファプールサイズを変更すること自体は可能です。デフォルトではインスタンスメモリの75%が割り当てられていますが、これを80%や85%に引き上げれば、インスタンスサイズを変えずにバッファプールを拡大できます。
しかし、この方法にはリスクがあります。バッファプール以外にも、MySQLの内部処理やOS、各種バックグラウンドプロセスがメモリを使用しています。バッファプールの比率を引き上げすぎると、これらに必要なメモリが不足し、最悪の場合OOM（Out of Memory）でインスタンスがクラッシュする可能性があります。
本番環境のReaderで「メモリ配分を攻めた結果、突然落ちました」では笑えません。デフォルトの75%という設定は、こうしたリスクを考慮した上での安全なバランスであり、ここを変更するのは慎重にならざるを得ませんでした。
背中を押した「CPU 100%」
パラメータ変更は避けたいが、状況は悪化していく——そんな中、事態は急変しました。
もともとパフォーマンスの良くないクエリを使う機能が存在していたのですが、それまではあまり利用されていませんでした。しかし、ビジネスサイドの施策推進により、その機能の利用が急増。約2週間のうちにDBのCPU使用率が急上昇し、ついにCPU 100%に張り付く場面が出てきたのです。
ここに至って、インスタンスサイズの引き上げを決断しました。db.r7g.8xlarge（256 GiB）から db.r7g.12xlarge（384 GiB）への変更です。
メモリが256 GiBから384 GiBに増えることで、バッファプールもデフォルトの75%換算で約192 GiBから約288 GiBへと拡大されます。vCPUも32から48に増えるため、純粋なCPU処理能力の向上も期待できます。
当然ながら、インスタンス単価は上がるので、コスト増は覚悟の上での判断でした。
予想外の結果：コストが「減った」
12xlargeへの変更後、メトリクスの変化は劇的でした。
まず、バッファプールヒット率がほぼ100%に回復しました。これは期待通りの結果です。バッファプールの容量が増えたことで、これまでキャッシュに載りきらなかったデータもメモリ上に保持できるようになったためです。
それに伴い、AuroraStorageReadIOsPS が急激に減少しました。バッファプールから直接データを返せるようになったため、ストレージへの読み取りリクエストがほとんど発生しなくなったのです。
そしてここからが本題です。具体的なコストの数字を見てみましょう。
まず、インスタンスの日額単価の比較です。
| インスタンスクラス | 日額単価 |
|---|---|
| db.r7g.8xlarge（3台分） | $383.33 |
| db.r7g.12xlarge（3台分） | $574.92 |
Reader 3台合計で見ると、インスタンス料金は約$192/日増加します。普通に考えれば「やっぱり高くなるじゃないか」という話です。
しかし、スケールアップ前のI/Oコスト（APN1-Aurora:StorageIOUsage）を見ると、毎日$350〜400ほどが発生していました。3台のReaderがそれぞれ秒間数千IOPSものストレージ読み取りを行っていた結果、I/Oの従量課金だけでこれだけの金額が積み上がっていたのです。
12xlargeへの変更後、このI/Oコストは約$80/日まで激減しました。以下のAuroraクラスター全体のコスト推移グラフを見ると、変化が一目瞭然です。
6月15日前後を境に、紫色（db.r7g.8xlarge）がオレンジ（db.r7g.12xlarge）に置き換わると同時に、それまで毎日存在していた赤色の帯——StorageIOUsageがほぼ消滅しています。インスタンス単価の上昇分よりも、I/Oコストの削減幅の方が大きかったため、結果としてAuroraのトータルコストはスケールアップ前よりも下がりました。
「スペックを上げたのにコストが下がる」という一見矛盾した結果ですが、Auroraの料金構造を考えれば理にかなっています。Auroraのコストは大きく分けて「インスタンス料金」と「I/O料金」で構成されており、I/Oが大量に発生している状態では、I/O料金がインスタンス料金を圧迫するほど膨れ上がることがあります。インスタンスサイズの引き上げでバッファプールを拡大し、I/Oを削減することで、増えたインスタンス料金以上のI/Oコスト削減が実現したというわけです。
その後の話：クエリチューニングとさらなるコスト削減の可能性
インスタンスサイズの引き上げで急場を凌いだ一方で、根本原因であるパフォーマンスの悪いクエリについても手を打ちました。DBに悪影響が出始めてから2〜3日でチューニングを実施し、現在はCPU使用率も安定した状態になっています。
こうなると面白いのが、インスタンスサイズを上げたことに加えてクエリも改善されたため、リソースに余裕が生まれているという点です。現在の負荷状況を見ると、Readerの台数を減らせる可能性すら出てきています。
整理すると、こんな流れになります。
インスタンスサイズを8xlargeから12xlargeに上げたことでI/Oコストが大幅に削減され、サイズアップ前よりもトータルコストが減少しました。さらにクエリチューニングによってCPU負荷も安定し、もしReaderの台数削減が実現すれば、インスタンス料金そのものもさらに圧縮できることになります。
台数削減についてはまだ検討段階ですが、「CPU 100%で焦っていたあの頃」から考えると、コスト削減とパフォーマンス改善の両方が実現しつつある今の状況は、結果的に良い方向に転がったと言えそうです。
なお、コスト推移のグラフを見て「なぜオンデマンドで使っているのか」と気になった方もいるかもしれません。現在、Readerインスタンスのr8g系への移行を予定しており、移行が完了したタイミングでReserved Instancesを購入する計画です。インスタンスファミリーが変わる前にRIを買ってしまうと無駄になるため、あえて今はオンデマンドのままにしています。
学んだこと
今回の経験から得られた教訓をいくつか共有します。
バッファプールヒット率の「0.1%」を甘く見ない。 99.9%と100%の差は数字の上では僅かですが、大量のリクエストを処理するシステムでは、この0.1%が秒間数千回のストレージI/Oに化けます。ヒット率が100%から僅かでも低下し始めたら、それはバッファプールの容量が限界に近づいているサインです。
コスト最適化は「安いインスタンスを選ぶ」だけではない。 クラウドの料金体系は複合的です。インスタンス料金だけでなく、I/O料金、ネットワーク転送量、ストレージ料金など、複数の要素が絡み合っています。ひとつの要素を抑えることに固執すると、別の要素が膨れ上がるケースがあります。今回のように、インスタンスコストを「上げる」ことがトータルコストの「削減」につながることもあるのです。
パラメータ変更は慎重に。 バッファプールサイズの拡大はパラメータ変更でも可能ですが、本番環境でデフォルトから逸脱した設定を入れるのは、想定外のOOMなど別のリスクを抱えることになります。インスタンスサイズの変更であればデフォルトのバランスを保ったまま全体的なリソースを増やせるため、より安全なアプローチだと考えています。
おわりに
今回は「インスタンスサイズを上げたらコストが下がった」という、やや直感に反する事例を紹介しました。
振り返ってみると、バッファプールヒット率の僅かな変化に気づき、その背景にあるI/Oコストの構造を理解していたからこそ、適切な判断ができたと思います。ただ漫然と「CPUが高いからスペックを上げよう」ではなく、メトリクスを観察し、原因を分析し、コスト構造を踏まえた上で意思決定する。地味ですが、こうした積み重ねがインフラ運用の質を上げていくのだと改めて感じました。
同じようにAuroraのI/Oコストやバッファプールヒット率で悩んでいる方の参考になれば幸いです。
