これを読んだ。
感想
データセンター単位の大規模障害が発生した場合に「何をすべきか」、「どのようなことを心がけておく」のかをしめしてくれていた。
記事を書いた人がMySQLの管理人っぽいのでMySQL管理者目線での対応概要を記しているが、応用できる程度にざっくり書いてくれていたのでこれくらいの粒度でいいかなと思う。
以下、ブログの章立てにあわせて感想文をメモ。
データセンター単位の大規模障害
はじめに
ラックが1本落ちたとか、ラックが数本落ちたとかそういう単位で障害が発生した場合を例に挙げている。
ネットワーク機器が故障したことも書いてあったが、ブレーカーがトリップしたとかもあったのかな？と勝手に想像。ラック複数本一度に落ちるとかそれくらいでしか想像できないわ。
DC間の通信の異常とかも含まれると思うのだがそのあたりの言及はなかったのでざっくり大規模障害と認識して読み進めた。
mysqld管理者目線での障害対応
普段使っているツール類は、大規模障害時には機能しないことを想定しておく
いいことを書いている。MySQL関係なく認識しておくべき。
ツールが機能していない＝上がるべきアラートが上がらない、自動化の処理が滞っているという可能性があることは想定しておくべき。ツールの棚卸が必須だな。大変だな。
トリアージ（緊急度に応じて対応優先度の決定という意味かな）
show global status like ‘uptime’;
コロナ禍でよく出てくる言葉。最初に行うことはトリアージとのこと。これも同感。
MySQL関係なく障害時の対応全般に言えること。そのために実施するのが以下のコマンド。
MySQLデーモンの起動時間を確認できるらしい。
show global status like ‘uptime’;このコマンドを実施後、uptimeが異常に短い場合は障害の影響を受けた可能性が高い、調査が必要ということ。
サーバーの障害対応と同じだな。
DRを想定してDC間でAct/Stby組んでいたなら、DC間の障害の影響で両Actになってしまっていないかとか考慮は必要そう。
show process list; で Binlog Dump Thread の有無を確認する
MySQLクラスタ構成のSource側サーバーに接続し以下のコマンドでバイナリログダンプスレッドを確認する。このあたりの確認後にサービス影響の判定を行うのかな？確認は相当面倒くさそうだし、報告内容にも気を使いそう。
show process list; 以下関連情報かな。
Stby（待機系）の状態確認
Source/Replica側の両サーバーで状態確認して、切り替わってないやつがいたら対処するわけですな。
わがまま言うなら、この辺りはもう少し細かい対応手順を書いて欲しかったけれど、そこまで開示するのは無理か。
概要をアウトプットすることが目的であって、情報を社外に開示することは目的ではないからなあ。
SHOW {REPLICA|SLAVE} STATUS の結果を記録する
トリアージ後の確認
ここでようやくログとゾンビプロセスの確認。ゾンビプロセスを止めることができない場合はOS再起動。
error log を確認する、 mysqld が zombie process になっていないか確認する
ログは最初に見るものだと思うけれど復旧優先でこういうフローを行うのだろうなあ。
会社によってやり方が異なるんだな、GREE（もしくはこの人）はこういう対処をするんだなという印象。
最後はまとめで終わり。
結論
大規模障害が発生したときに対応できるようにみんな頑張って準備しておけよという注意喚起と理解。
とりわけツールが機能しなくなった場合に備えて常日頃から以下を認識しておく必要があるわけだと感じた。
１．全ツールの処理内容を把握し、明文化する。それらは管理者に周知、教育しておく。
※特にDC間で冗長構成組んでいる機器の情報を明文化する。
２．全ツールの稼働を監視し、失敗時にはアラートを上げる。
３．ツールが停止した場合の復旧優先度を明示、記載する。
４．全ツールが処理を停止した場合、（最悪の想定ではあるが）手動で処理を代行できる資料を準備しておく。
全編通対応マニュアルを抜粋したような内容で分かりやすかった。楽しく読み進めることができた。
蛇足
自分はDCでの業務経験が豊富で、OSI参照モデルでいうところ１層~３層の領域ばっかりで仕事をしてきたので、「データセンター単位（またぎ）の障害」についてもう少し詳細を掘り下げてほしかった。
でも、DCを管理する側ではなく利用する側の記事だと思うし、言えないこともあると思うのでこのあたりは仕方ないかな。
コメント