Amazon Aurora Serverless v2 が ACU0 に対応したため、分析用 DB の自動停止・再開を実現しました。
Metabase の運用環境
弊社では、経営ダッシュボードとして Metabase を利用しています。Metabase は EC2 インスタンス 上で稼働しており、本番環境の Aurora RDS クラスターには、以下の構成で DB を配置しています。
- リーダーインスタンス（通常の Aurora RDS）
- ライターインスタンス（通常の Aurora RDS）
- リーダーインスタンス（Serverless v2, 0.5 ～ 5 ACU）
分析用 DB は本番サービスとは切り離して運用したいため、カスタムエンドポイント を作成し、アクセス制御を行っています。
ACU が 0 にならない問題
さっそく、ACU を 0.5 から 0 に設定し直したものの、待てど暮せど DB は停止しませんでした。
2024/12/25 頃だったと思います。
調査したところ、1 時間に 1 度 何らかのリクエストが DB に飛んでいることが判明しました。原因は Metabase の自動スキーマ同期 です。この定期アクセスにより、ACU0 に移行しづらくなっていると考えられました。
同期頻度を 1 日 1 回 に変更して様子を見ましたが、やはり ACU0 にはなりませんでした。
試しに、Metabase の接続先を Serverless ではない DB に変更したところ、ACU は 0 になる ことを確認しました。つまり、Metabase は 一度でも同期のために DB にアクセスすると、コネクションを維持し続けているようです。
年末はダッシュボードの利用がなかったため、そのまま ACU0 の状態で放置し、年明けに改めて調査を再開しました。
（お正月🍵）
（お正月🍵）
（お正月🍵）
（お正月🍵）
（お正月🍵）
年明けに調査を再開しました。Metabase の接続先を変更すれば ACU0 になることが分かっていたため、定期的に Metabase を再起動する方法を検討しました。
--- うろ覚え:ここから ---
Metabase を再起動すると、起動時に DB への接続確認のアクセスが行われ、すぐに ACU が復活してしまいます。これを防ぐため、validationQuery を 空にすることで、DB への確認アクセスを抑制できます。
--- うろ覚え:ここまで ---
再起動のスケジューリング
Metabase の定期再起動には、以下の 2 つの方法を検討しました。
- Amazon EventBridge を使って EC2 インスタンスを自動起動・停止
- EC2 インスタンス内で Cron を設定
EventBridge を使うと、深夜帯は EC2 を完全に停止できるためコスト削減に有効ですが、海外にいる際や深夜帯にアクセスするユーザーにとっては不便です。
今回はコストが大きな問題ではなかったため、Cron を使用することにしました。
sudo yum install cronie -y
sudo systemctl start crond.service
sudo systemctl enable crond.service
sudo crontab -e
10 9,13,17,21 * * * docker restart metabase # UTC基準
Metabase の自動同期のタイミングやユーザーアクセスが落ち着くタイミングに合わせて、restart を実行することで、不要な DB 接続をリセットし、ACU0 に移行しやすくなります。
運用と効果
運用面では、「急ぎでないなら午後にダッシュボードにアクセスするとコスト削減につながるよ〜」 という旨をチームに周知しました。
また、ACU0 の状態からダッシュボードを開く場合、SQL 発行と描画に 10～20 秒程度 かかるものの、ユーザー体験を大きく損なうことはありませんでした（アクティブ時は3秒程度）。
結果的に、約 60% のコスト削減に成功しました 🎉
※2024/11 に下がっているのは価格改定の影響です。
※後日談：分析用 DB で Serverless を試しつつ、本番サービスでも利用できればと検証を進めていましたが、逆効果で実現しませんでした。
株式会社Kivaのテックブログです。Kivaではモダンな技術を活用し「proteger」「uniweb」「AI多言語翻訳」「コブラウジング」など様々なサービスの開発を行っています。
Discussion