はじめに
この記事は 本番環境でやらかしちゃった人 Advent Calendar 2020 の7日目の記事です。
注意事項
まじでTwitterのトレンドに載ったので、特定は控えてください。。
あくまでも事象を共有して、この世から本番環境の事故を無くそうという強い想いです。
特定対策として多少なりフェイクを織り交ぜます
そして現職の話ではないです。
背景
- 遠い過去の話
- 開発者ワイだけ
- EC2の構築は別会社に委託
- 「コードレビュー??甘えるな感じろ!!」な職場
- Twilio API触るの初めて
はじまり
ある暑い夏の日、あるプロジェクトを1人で開発することになりました（まぁいつものこと）
要件はある条件化で発生するリクエストに対してTwilio API (以降はTwilio) でリクエストを受け取り、
そのリクエストを自身が開発したAPIサーバーで処理してレスポンスを返すというもの
Twilioは使ったことないけど、ドキュメント揃ってるし、要件のボリューム的にも普通に期限内には間に合うなという印象でした。
この時、まさかTwitterのトレンドに載ることになるとは予想もしていなかった。
開発期間
当初想定していた通りに開発自体は順調に進んでいました。
EC2サーバーの構築は別会社に頼んでいたので、自分はLaravelでせこせことAPIサーバーを構築してTwilioを設定するだけでした。
EC2サーバーの構築が完了したと報告があり、納品書を受け取りました。
これがめちゃくちゃ分かりづらい...
しかし、ステージングサーバーと本番サーバーがあるのか、、
くらいの認識で該当部分だけをコピペしてメモしただけで終わりました。
ある問題
TwilioではダッシュボードでAPIの向き先の設定やAPIのコール数やコール日時などが細かく確認することができます。
APIの向き先を納品書からコピペメモしたステージングサーバーの情報を記入していき、着々と開発が進んでいました。
しかし、今回のプロジェクトは少し特殊で上でも少しだけ触れた様にある条件化でしかAPIのコールができない、という仕組みになっていました。
その仕組みというのが一つの端末から1リクエストしか行えないという物で、負荷のテストに限度があるという物でした。
ですが、これまた特殊で今回のプロジェクトはある時間にしかレスポンスを返さない（リクエストはもちろん受けるけど）という内容だったのでそこまで負荷がかかる事はないだろうとタカをくくり負荷テスト見送ることにしました。
本番（リリース）
上の様な問題はありつつも、一通りのテストを終えてついに本番リリース日になりました。
TwilioのダッシュボードでAPIの向き先を本番サーバーに変えて、ちゃんとレスポンスが返ってくるのを確認していざリリースの時間
リリースと同時にユーザーとしてアクセスし、リクエストを送る
.........................................................
.........................................................
.........................................................
.........................................................
.........................................................
.....レスポンスが返ってこない（ここでゆっくり死を悟る）
問題発生
震える手で恐る恐るTwilioのダッシュボードからAPIコール状況を確認する。
なんと開始1秒にも満たない時間でサーバーから503エラーを返している。
つまりサーバーがリリースと同時にDOWNしたということ、
これは大晦日の山本KID選手の4秒KO勝ちよりも早い
そして予想外の出来事がもう一つ、
アクセス数が以上に多い。。。。。
503しか返さないサーバーに対してあっという間に数万リクエスト😇
ユーザーを侮っていた。。。
Twitterの反応
想定していた300倍くらい(当社比)ユーザーのアクセスがあり、
Twitter上ではアクセスできない！！のツイートの嵐
ついにはTwitterトレンドにも載り、某有名Youtuberにもネタにされてました。
いわゆるお祭り状態というやつですね
完全にネタにされてました。
原因調査
サーバーが落ちてから原因を調査していく中で、あることが頭に浮かぶ
A P I の 向 き 先 を 間 違 え て い る の で は ??
早速確認するが、納品書からコピペした本番サーバーの情報とTwilioの設定を確認する。
......うーーーん合ってる。
そしてコピペ元の納品書をもう一度よく見てみる
.........................................................
.........................................................
.........................................................
.........................................................
.........................................................
あ、今設定してるのステージングサーバーだ
つまりどういうことだってばよ
自分の認識ではステージングサーバー / 本番サーバーだけだと思っていたが、
実は開発サーバー / ステージングサーバー / 本番サーバーの3台ありました。
つまり今までステージングサーバーと思っていたのは開発サーバーで
本番サーバーと思っていたのはステージングサーバーだったということ😇
（本番サーバーはPDFが見切れたページにひっそりと載っていた）
ステージング環境では当たり前の様に冗長化は行っておらず、そこまで負荷に耐える設計ではなかった。
そのためリリース時の大量アクセスに耐えられず、一瞬でお陀仏したということでした。
その後ちゃんと
本番サーバーに設定に書き換えて、無事にアクセスできようになりました。
なぜこのような惨劇が起きたか
要因はいくつかあるが、大きくまとめるとこの4つだろうか
- Twilio環境の設定をダブルチェックしていなかった
- 納品書をよく確認していなかった
- 負荷テスト出来ない問題をどうにか対策してでもやるべきだった
- 開発を1人にまる投げされていた
惨劇が二度と起こらないように
今回はほとんどが自分の確認不足が招いた事故でした。
ダブルチェックだって誰かに頼めば良かったし、納品書だって見辛いからと良く目を通さずにコピペせずにしっかり目を通すべきでした。
必ず必要と感じたらダブルチェック!!読みづらくてもちゃんと読むor読みやすくしてくれと相手に伝える
そして想定されるケースのテストは必ず書くこと（これが一番大事）
丸投げの件は、そもそも開発者1人に丸投げする会社はまともではないので転職を考えましょう
最後に
特定を避けるために多少なりフェイクを織り交ぜています。
文章に矛盾等があればすみません
明日の担当は @HirotoKagotani さんの 管理者用初期化URLを踏んでWebサービスのデータをふっとばした話 です。