インスタンスサイズを「上げた」のに、Auroraのコストが「下がった」話 - Timee Product Team Blog

はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 「インスタンスサイズを上げたらコストが下がりました」と言うと、だいたい「？」という顔をされます。スペック上げたらお金かかるに決まってるだろ、と。自分もそう思っていたので気持ちはわかります。 この記事では、Amazon Aurora のReaderインスタンスを db.r7g.8xlarge から db.r7g.12xlarge にスケールアップした結果、I/Oコストが大幅に減り、トータルのAuroraコストがむしろ下がった話を書きます。バッファプールの仕組みと、判断の経緯もあわせて紹介します。 前提：私たちのAurora構成 まず、当時のAurora（MySQL互換）クラスターの構成を簡単に紹介します。 インスタンス クラス vCPU メモリ プロセッサ 役割 reader-1 d

[daishi_n]

I/O課金がヘビーならI/O最適化かサイズアップのどちらかだけど、局所読み取りヘビーならメモリ増量でキャッシュヒット率上げるのは一案。ライターでの変更はリーダーにメモリコピーされるから読み直しは最小限

[taruhachi]

Aurora I/O 最適化が効きそうだけど、そもそもCPUも逼迫してるならスケールアップするべきか。スケールアップだけならRI購入とも相性いいし。

[sonots]

ナルホド🧐

[kenzy_n]

ボリュームディスカウント。

[nguyen-oi]

AWSのI/O課金トラップをサイズアップで解決するの、直感に反するけど理にかなってて面白いな