ペイ・ガガーリン「コンソールは白かった」 @pei0804
稀によくあるアラートで始まる朝
ある日の朝、いくつかあるマイクロサービスの内の一つが稀によくある一部のメトリクスが取れてない趣旨のアラートが大量に飛んでいた形跡を発見した。
この稀によくあるアラートの原因として考えられるのは、一部のサーバーの調子悪いか、監視サービスが不調のどちらかだった。
ここで簡単にサービスの構成を説明しよう。
よくあるロードバランサーにいくつかのインスタンスがぶら下がってる系のもので、負荷が高まったらスケールアウトして、負荷が低くなればスケールインするいい感じのやつ。某AWSではオートスケーリンググループと呼ばれるもの。
インスタンスは使い捨て可能で、サーバーが不調になれば、自動でいい感じに殺すため、大体アラートが出ていても、朝起きた時には直ってることが多い。
加えて早朝にローリングデプロイを実行することで、インスタンス入れ替えを毎日行うため、ほとんど悲惨なことは起きない。
そして、この時の朝もアラートは落ち着いていた。
どうせいつも通り、勝手に生き返ってるなと確認するだけになるだろうと思っていた。
余裕をかましながら、おもむろに某AWSコンソールを開いた。
コンソールは白かった
ペイ・ガガーリンは言った「コンソールは白かった」
そう。インスタンス一覧が白いのだ。つまり？
誰も動いてないのである！！！！！！！！！！！！！
全ては虚無になった
虚無ローリングデプロイ
どういうこと？
おまえ、毎朝ローリングデプロイし直すよな？
ん？ローリングデプロイ？
0台入れ替えは、入れ替えても0台！！！！！！
負荷も虚無
何が起きている？リクエスト増えて負荷が上がったらインスタンスって増えるよな？
ん？負荷？
動いてないから、負荷が上がらないのである！！！！！！！！！!
原因
察しが良くなくてもここまで読めば分かると思う。 オートスケーリンググループのインスタンスの必要数が0になっていた。
原因が分かってしまえ単純な話だけど、この手の設定は最初しかやらない。設定者が気づかずやってしまうと、事が起きるまで気づかない。
恐らく、わちゃわちゃ移行期間があった時に行った設定だったので、後で設定しようとかで、今回の様な設定になっていたんだろうなと思っている。
人間は悪くない設定が悪い。
まとめ
キャパシティ設定はサービス継続に必要な設定にしましょう。
負荷がわからない時は、最低でも1台は確保するように設定しましょう。1台もないといい感じにならない。
- 最低限必要数とかも考慮した方がよい（1台だとスパイクに耐えれないとか）
- 0台になっていたサービスを急に動かし始めると、関連したサービスのキャパシティが足りなくなってる可能性があるので注意
- 0台になると実行時エラーが発生しなくなるため、動いていない状況に気づける仕組みが必要
という夢を見た。
単語メモ
- メトリクス（metrics）：韻律学という意味の英単語で、ソフトウェアにおいては、ソースコードの品質を数値化して定量的に評価することをさします。
- スケールイン：システムを構成する仮想マシンの台数を減らすことをさすます。反対に増やすことをスケールアウトと言います。
- オートスケーリンググループ：オートスケール対象（インスタンスの数を自動で増減できたり、数の最小・最大を指定できます）のEC2インスタンスグループの管理単位です。
- ローリングデプロイ：複数の稼働中サーバーに対して一定数の新しいアプリケーションをデプロイ・リリースしていく方法です。
- コンソール：PC全般の入力・出力用の装置をさします。主にキーボードやディスプレイのことをいい、遠隔的なもの以外にPC本体に直接接続するものも含みます。