ペイ・ガガーリン「コンソールは白かった」
本番環境でやらかしちゃった人 Advent Calendar 2020 14日目 の記事です。
稀によくあるアラートで始まる朝
ある日の朝、いくつかあるマイクロサービスの内の一つが稀によくある一部のメトリクスが取れてない趣旨のアラートが大量に飛んでいた形跡を発見した。
この稀によくあるアラートの原因として考えられるのは、一部のサーバーの調子悪いか、監視サービスが不調のどちらかだった。
ここで簡単にサービスの構成を説明しよう。
よくあるロードバランサーにいくつかのインスタンスがぶら下がってる系のもので、負荷が高まったらスケールアウトして、負荷が低くなればスケールインするいい感じのやつ。某AWSではオートスケーリンググループと呼ばれるもの。
インスタンスは使い捨て可能で、サーバーが不調になれば、自動でいい感じに殺すため、大体アラートが出ていても、朝起きた時には直ってることが多い。
加えて早朝にローリングデプロイを実行することで、インスタンス入れ替えを毎日行うため、ほとんど悲惨なことは起きない。
そして、この時の朝もアラートは落ち着いていた。
どうせいつも通り、勝手に生き返ってるなと確認するだけになるだろうと思っていた。
余裕をかましながら、おもむろに某AWSコンソールを開いた。
コンソールは白かった
ペイ・ガガーリンは言った「コンソールは白かった」
そう。インスタンス一覧が白いのだ。つまり？
誰も動いてないのである！！！！！！！！！！！！！
全ては虚無になった
虚無ローリングデプロイ
どういうこと？
おまえ、毎朝ローリングデプロイし直すよな？
ん？ローリングデプロイ？
0台入れ替えは、入れ替えても0台！！！！！！
負荷も虚無
何が起きている？リクエスト増えて負荷が上がったらインスタンスって増えるよな？
ん？負荷？
動いてないから、負荷が上がらないのである！！！！！！！！！!
原因
察しが良くなくてもここまで読めば分かると思う。 オートスケーリンググループのインスタンスの必要数が0になっていた。
原因が分かってしまえ単純な話だけど、この手の設定は最初しかやらない。設定者が気づかずやってしまうと、事が起きるまで気づかない。
恐らく、わちゃわちゃ移行期間があった時に行った設定だったので、後で設定しようとかで、今回の様な設定になっていたんだろうなと思っている。
人間は悪くない設定が悪い。
まとめ
キャパシティ設定はサービス継続に必要な設定にしましょう。
負荷がわからない時は、最低でも1台は確保するように設定しましょう。1台もないといい感じにならない。
- 最低限必要数とかも考慮した方がよい（1台だとスパイクに耐えれないとか）
- 0台になっていたサービスを急に動かし始めると、関連したサービスのキャパシティが足りなくなってる可能性があるので注意
- 0台になると実行時エラーが発生しなくなるため、動いていない状況に気づける仕組みが必要
という夢を見た。
いい話だったなー。
Discussion