insufficient-capacityとの遭遇
最近、DBインスタンスタイプのdb.r3系統が廃止されると聞いて、検証環境で移行の動作確認していたところDBインスタンスが一つ落ちていることに気づく。
ワイ「は？insufficient-capacity？」
これが生産性ゼロの一週間を生むのであった。
insufficient-capacityとは
結論「AZ（アベイラビリティゾーン）のオンデマンドキャパシティが足りない場合に発生するステータス」のよう。
capacityとはオンデマンドキャパシティのことを指すっぽい。
ワイ「マジかよ。対策立てようないやん。」
というのもEC2インスタンスはオンデマンドキャパシティを予約できるが、Amazon RDSはできない。
そしてこの現象が発生する最大の要因はRDSを停止させることにある。
顧客要望によっては、運用時間を減らすことがコスト削減につながるため、夜間や非営業時間はサーバを動かさない等の対応を行う場合がある。
ましてや検証環境なんかは本番環境と違って使用頻度も少ないので、高確率でそうなることが多い。
停止させることによるリスクについては参考記事に載せている「RDSを本番環境で停止運用しないほうが良い理由について」が参考になる。
PS: 本当に助かりました。ありがとうございます。
余談だが、AZ内のオンデマンドキャパシティは時間経過とともに変化するので、落ちた場合は再起動で直る。
ただ今回の場合、aurora-mysqlでマルチAZ 2系運用の中の一つがやられたため、awscliでの再起動、停止、開始コマンドも効かない状態であった。
insufficient-capacityの対応
さてさて原因が分かったのでリカバリ対応をするわけだが、前述も申し上げた通りawscliからの再起動、停止。開始コマンドも効かない状態だったので、インスタンスを削除するしか方法が無い。
とはいえ、DBインスタンスを削除するなぞ話しても通るものでもなく。
ワイ「DBインスタンスの削除新規で対応できます！」
上司「削除するにもリスクあるよね？」
ワイ「で…でも…公式にもそう書いてあるわけですし…」
上司「削除するにもお客さんが納得できる、もしくは許可を得ることが大事だよね？」
ワイ「…そうですね」
ワイ、お客さんの説得が最高に苦手なんですが…。
まあワイが言い訳を考えるのに3日間かけた話はさておき、ワイが入っているプロジェクトはCloudFormationでRDSの設定値を管理していたので、可能あればそれで対応したいと考えたわけです。
結論、以下の手順で実施（バックアップは必ずしてネ☆）。
- 落ちたDBインスタンスを削除したテンプレートを用意し取り込む。
- 落ちたDBインスタンスが削除されたことを確認する。
- 落ちたDBインスタンスを復元したテンプレートを用意し取り込む。
- 落ちたDBインスタンスが「利用可能」ステータスになっていることを確認する。
もし4で起動できなくても再度1からやり直せばOK（多分）。
無事これで復旧完了。DBインスタンスタイプも変更し、全てが丸く収まったってわけですね。
魔の調査（2日間）+言い訳（3日間）期間が終わったわけです。
結論
- insufficient-capacityはAZ内のオンデマンドキャパシティが不足したことで発生する。
- insufficient-capacityにならないように停止期間を設けないように提案を頑張る。
- insufficient-capacityになると再起動できる場合は再起動するが、再起動、停止、起動ができない場合は削除しか対応方法が無い。
- CloudFormationで対応する場合は、テンプレートの中から落ちたDBインスタンスを消して取り込み、削除する前のテンプレートを流しなおすと立ち上がる。
これで何とかしてくれよ、兄弟。