こんにちは、インフラエンジニアの綿引です。
最近弊社サービスで急なスパイクアクセスがあり、データベースにかなりの負荷がかかってしまいました。。
そこで解決策として「Aurora のオートスケーリング」を導入しました。
今回は導入にあたって検証を行ったので、その際の設定方法と検証結果を記載していきたいと思います。
対象の方は以下のような方でしょうか。
- 急なスパイクアクセスに備えて Aurora にオートスケーリングの設定を入れておきたい
- スパイクアクセスに備えてあまり使ってない Aurora レプリカを追加している
Aurora AutoScaling とは
Aurora Auto Scaling とは「スケーリングポリシー」を設定することで Aurora のレプリカ数を自動で増やすことができる機能です。
Aurora MySQL だけでなく Aurora PostgreSQL でも使用できます。
オートスケーリングさせるトリガーは以下となります。
- Aurora レプリカの平均 CPU 使用率
- Aurora レプリカの平均接続数
また Auto Scaling で増えたレプリカに関しては負荷や接続数が減ると自動で削除もしてくれます。
トリガーも CPU 使用率・接続数と設定しやすいですし、自動で削除まで行ってくれるのはコスト的にもありがたいですね。
設定方法と検証
構成について
今回は以下の構成で実施していきます。
- クラスタ名 : autoscaling-test
- DBインスタンス1 : autoscaling-test-instance-1
- DBインスタンス2 : autoscaling-test-instance-2
DBインスタンスが2つある理由としては「プライマリインスタンスと、少なくとも1つの Aurora レプリカが必要」という Auto Scaling の制約があるからです。
DBインスタンスが1つの状態でも Auto Scaling の設定はできますが、設定後に自動でAurora レプリカが1台作成されます。
スケーリングポリシーの設定
では早速設定を行なっていきます。
まずは Amazon RDS のコンソールから対象のクラスタを選択して「アクション」→「レプリカの Auto Scaling の追加」を選択します。
次にスケーリングポリシーを設定していきます。今回はテスト用に「ターゲット値」を 1% にして以下の設定値にしました。
実際に設定する時は 80% や 90%などになるかと思います。
| 項目 | 設定値 |
|---|---|
| ポリシー名 | autoscaling-test |
| IAM ロール | ※ デフォルト |
| ターゲットメトリクス | Aurora レプリカの平均 CPU 使用率 |
| ターゲット値 | 1 % (※ テストのため) |
| スケールイン | 有効 |
| スケールインクールダウン期間 | 60 |
| スケールアウトクールダウン期間 | 60 |
| 最小キャパシティー | 1 |
| 最大キャパシティー | 3 |
実際の画面はこのような形です。
上記の設定が終わったら最後に「ポリシーの追加」を押下します。
テスト
ではテストしていきます。
ポリシーの追加後、早速2台「application-autoscaling-XXXXXXXX」という名前で作成されました。
次はポリシーの設定を変更して、追加されたレプリカが削除されるか確認します。
| 項目 | 設定値 |
|---|---|
| ターゲット値 | 1 % → 90 % |
ポリシーの変更後、まず2台あったうちの1台のステータスが「削除中」となりましたが、もう一台は「利用可能」のままです。
削除されないのか？と思ったのですが、上記の「削除中」のものが完全に削除されたら、もう一台の方が「削除中」のステータスに変わりました。
仕様なのか1台ずつ削除されるようです。
これで Aurora の AutoScaling の挙動も確認できました！これなら急なスパイクアクセスが来ても大丈夫そうですね！
最後に
今回は Aurora AutoScaling を検証しました。
非常に楽で特殊な制約もなく実現できたので、個人的にはどんどん導入していきたいなと感じました。
次は EC2 の AutoScaling もやってみます。
