Auto scaling の概要
Auto scaling は、使用量が設定した閾値を超えたときに database のリソースを引き上げるため、使用状況を見張って手動でサイズ変更する必要がありません。これは vertical scaling であり、node が増えるのではなく同じ database により大きい flavor またはより大きいディスクが割り当てられます。
compute と storage は個別にスケールする
2 つは独立して設定し、片方だけを使うこともできます。
| Compute scaling | Storage scaling | |
|---|---|---|
| 増えるもの | より大きい flavor への変更による vCPU と RAM | データディスクの容量 |
| 発動条件 | CPU または RAM の平均が閾値を超えたとき | storage 使用率が閾値を超えたとき |
| 追加される量 | 指定した順序の次の flavor | 現在の容量に対する割合 |
| サービスへの影響 | ほとんどの engine ではなし。PostgreSQL、OpenSearch、ClickHouse では手動の再起動まで反映されません | なし。拡張はオンラインで実行されます |
| 元に戻せるか | はい。サイズを下げれば戻せます | いいえ。 拡張は取り消せません |
判断の仕組み
Compute scaling は設定した tracing interval ごとに使用状況をサンプリングし、その区間の平均を CPU と RAM の閾値と比較します。瞬間的なピークではなく平均が判断材料になるため、短時間のバーストではサイズ変更は起きません。
閾値を超えると、システムは List Flavor Scaling の次の flavor へ、指定した順序で移行します。その後も閾値を超えたままなら、さらに次へ移行します。このリストが上限であり、最後の要素で scaling は止まります。
scaling は quota でも止まります。VPC の利用可能な quota を使い切ると、閾値の設定にかかわらずそれ以上は引き上げられません。
有効にする前に
先に通知先が存在している必要があります。backup サービスにも同じ要件があり、メールアドレスか Telegram チャネルが 1 つ以上設定されるまで console はダイアログで有効化をブロックします。アラートの管理 を参照してください。
閾値の決め方
- compute の閾値は 60% 以上に保ってください。これより低いと通常のトラフィック変動でも scaling が発動し、1 回ごとに費用が発生します。後からサイズを下げても取り戻せません。
- storage の閾値は 70% 以上にしてください。storage は縮小できないため、一時的なピークで発動する閾値は請求額を恒久的に押し上げます。
- flavor のリストには余裕を持たせてください。要素が 1 つだけでは最初の 1 段で scaling が止まり、結局は手動でのサイズ変更に戻ります。
警告
storage の拡張は一方通行です。自動でも手動でも小さいディスクに戻す手段はなく、拡張後の容量がそれ以降課金されます。
次のステップ
- Auto scaling の設定。具体的な手順を確認します
- database リソース構成の変更。手動でサイズを変更する場合はこちらです
- FMON による database の監視。閾値の根拠となる使用状況の推移を確認します