😇
Auroraバージョンアップした話
所感、大変だった、、、
遡ること、夏の終わり、
アサインされてお願いされたのはAuroraのバージョンアップの話だった。
ざっくり調べてみるとどうやら大変そうだと。。。
簡単に違い
| Aurora Serverless v2 | Aurora Serverless v1 | |
|---|---|---|
| ACU | 最小：0.5ACU最大256ACU | 最小：1ACU最大128ACU |
| 料金 | ※1ACUあたり0.20USD/時間 | ※1ACUあたり0.20USD/時間 |
| 特徴 | 最小増分で自動処理が可能、クエリ実行中でも自動処理が可能、マルチAZ | 一定時間アクセスがない場合、自動停止可能、シングルAZ |
| 課題 | 1ACUあたりの費用が2倍、自動停止できない | 初回起動が遅い、シングルAZ、クエリ実行中は自動処理できない |
※ACUとは、Aurora Serverlessで用いられる容量のことです。1ACUあたり約2GiB(ギビバイト)のメモリ・CPU・ネットワークが組み合わされます。
その他のあれやこれ
lambdaから接続するためには同じVPC配下に配置する必要がある
正確に言うと、auroraに設定したvpcのサブネットをpublicな設定にしてあげて、そこ経由でアクセスすることができるらしい。だけど、セキュリティ的にまずいよねって話。
今回はこんな構成にした（まぁ一般的か）
MySQL5.7も使えるけど、8.0推奨だよ〜
その通りなんですわ、EOLも切れているし8にしようねって話
スケーリングの違い
設定にはよるが、スケーリングが頻繁に行われるので接続が一時的に切断される可能性がある。その際に再接続するようになっていないとapiでは500エラーになる可能性がある。
同時接続が多くなるとコストが増える可能性がある
v2はacuを使ってリソースをスケールする。Acuはdbのワークロード（cpu,メモリ,I/O)に応じて調整されるが、同時接続が増えるとacuも増加する傾向にある。つまりdbの処理するクエリが増えるとリソースも自動で増加するのでコストも高まる
コスト最適化どうしましょう
- 必要以上なスペックは積まないようにしよう〜
- 夜間のACUは低くするとかも検討しよう〜
- シングルAZにしよう（ちょっと怖いけど、コスト最適化・・・）
- データはアーカイブしよう〜
- 定期的に新しいサービスとか構成とかシステムとか見直ししよう〜
RDS Data APIも使えるらしい（バージョンによるけど）
試していないので引用のみ
謝辞。まじ助かりました。この記事のおかげで生きてます
大変だったぁあああああ
いつもawsについて聞ける人がいる環境で仕事していたので、これっていいんだっけ？とかこれなんとかできないかな〜とか気軽に聞いてたけど今回は自分で調べて一からやらないとダメだったので改めてインフラエンジニアの方々はすごいなと思いました（これを機に勉強しようとも思いました（n回目)
Discussion