1セグメント全断の土曜日 Part2 @Words4MyRegret
これは 本番環境でやらかしちゃった人 Advent Calendar 2020 の22日目です。昨日はreal_yaruoさんによる消しちゃった系のお話でした。私も消えちゃった系の対応をさせられたことがあります。そんな時のためにsash(stand-alone shell)いいですよ、sash。
さて本記事は昨年の記事の続編となります。
tl;dr 兼 原因と対策
CDNを使ってもオリジンサーバーにアクセスはそれなりに来る。来る時は来る。
来てもいいようにレートリミットと帯域確保を行っておくこと。
経過
予兆
10年以上前のお話です。たぶんフィクションです。
木曜日にお客様から「週末ちょっとトラフィック増えるかも」というご連絡がありました。
発生
何事も無く始まった土曜日… 昼過ぎになって出かけていた私の携帯電話が鳴りました。
「第2セグメントのサーバー2台の監視が断続的にエラーになっています。」
確かに接続しにくい状態になっていたのでオンサイトの準備を始めた時に再び電話が鳴ります。「第1セグメントのサーバーすべての監視が通りません！」
昨年はこの第1セグメントについて書きました。
さて第1セグメント全断の対応をしている間も最初に連絡のあった”第2セグメントのサーバーたち”は断続的にエラーを出し続けていました。
…そしてついに「第2セグメントのサーバーすべての監視が通りません！」という連絡が来てしまうのです。
調査
すでに各種アラート通知でメールボックスはあふれかえっています。読み解くのも時間がかかりそうなのでまずは第2セグメントのサーバーがあるラックの現地へ向かいます。
断続的なエラーを上げていたサーバーにコンソールをつないで確認するとコネクションがあふれかえっています。そうこうしているうちにコンソールに kmem_alloc のエラーメッセージまで
帯域使用率を確認するとそちらもほぼ輻輳していることが分かりました。
原因特定
元々アクセスの多いサイトだったのでCDNも挟んでいたのですが、CDNのエッジサーバー群からオリジンサーバーへのリクエストさえさばききれない規模の大量のリクエストが来ていたようです。
(この時いわゆるヤ○ートップ砲も相まって想定をはるかに上回るアクセスがきていたようでした。)
CDNを挟んでいたので第1セグメントの対応をしている間はギリギリ耐え切れていたとも言えます。
対応
スケールアウトしながら時間を稼ぎました。予備系サーバーを起動し、ネットワークの増速とレートリミットを調整しながらトラフィックを回避させて凌ぎつつ、徐々にアクセスを捌いていきました。
できていなかった対策、行った対策
CDNに安心しきってオリジンサーバー側基盤のキャパシティ見積もりができていませんでした。サーバー単独では無くセグメントを巻き込んでしまったのは完全にキャパシティもしくはレートリミットの設計ミスと言えるでしょう。対策としてアクセスポートとアグリゲーションポートの帯域バランスに基づいたレートリミットを安全側に寄せた閾値で見直しを行いました。
また元々トラフィックの多いサイトでしたので、今回のような緊急時には軽量のSorryページへ切り替えるなどの対策も事前に検討しておくべきでした。
補足
予兆のところを思い出してみます。
木曜日にお客様から「週末ちょっとトラフィック増えるかも」というご連絡がありました。
全然”ちょっと”じゃねーよ、という思いを抱えながら対応していたのを今でも思い出します。
さてここまで手探りしながら一連の対応をする中で、実は余計なこともしてしまっていました。
そう、この日はさらにもう1つのセグメントが全断するのですが
それを記すには余白とSAN値と応援が足りません――
単語メモ
- sash(stand-alone shell)：UNIXのシェルで、システム復旧に用いられることを考えて設計されています。
- アグリゲーションポート：普通は1本の線で繋ぐ機器を複数の線で引いて、複数の線をまとめて1本の線っぽく扱う技です。