初投稿です！
いえらぶアドベントカレンダー 18日目
1年目インフラエンジニアが自社にあるRedisサーバー移管でやらかしたお話しをします。
関係各所には多大なるご迷惑をおかけしたうえ、復旧作業にもご協力いただきまして感謝と申し訳なさでいっぱいです。
本当にありがとうございました。
結論
よく分かってないものを分からないまま触らない
そもそもRedisとは
- NoSQLデータベースの1つ
- 馴染み深いMySQLのようなRDBとはデータの保存形式が違う
- RDBが1レコードに複数のカラムを紐づけて保存するのに対し、Redisはkey-value型でデータを保存する
- keyを指定することでvalueを呼び出す
- データがすべてメモリに乗っているため爆速
やらかし詳細
縁あってRedisサーバーを移管することに。
これまでにもサーバー移管は何度か対応していたうえ、自社ではRedisが冗長構成ということもあってそこまで心配ないだろうと思っていた。
そしてその時はやってきた
今までの対応通り、対象のサーバーをシャットダウン。
続きの作業に取り掛かっていたその時、社内の方から突然の連絡。
「サーバーで何か異常ありませんか？」
「このページが映らないんですけど...。」
見事にRedisを使用しているページである。
((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
すぐに自分でも教えてもらったページを確認
→ 映らない
同じサーバー構成の別ページを確認
→ 映らない
「え、絶対Redisだよね。。。あれ、冗長化してるんじゃないの！？」
落としていないはずのRedisサーバーを見たところ起動はしている
ただ負荷が低すぎる。。。
「どゆこと...？？？？？？？？？？」
とりあえず落としていたRedisをすぐに起動し、復旧作業へ
何が起きていたか
復旧中・復旧後の調査などから分かったRedisの特性
・Redisはクラスター(cluster)という形で冗長化を図っている
・ポート違いで1台のサーバーにマスター, スレーブを持つことが可能
・マスターが落ちた場合は対応するスレーブが昇格する
・クラスター内で互いにpingを飛ばしあい、生存確認をし続けている
・マスターの数が保てなくなるとクラスターごと落ちる
上記特性を踏まえ、こんなことが起こっていたのではないかというシナリオ
・サーバーシャットダウン時にそのサーバー内のRedis(マスター、スレーブ両方)が落ちる
・別サーバーのRedisから生存確認のpingが送られてくるが生存反応がない
・落ちたマスターに対応するスレーブは別サーバーにあるため、そちらをマスターに昇格させようとしたが、サーバーごと落ちているためマスターから「自分、死にました」のpingさえ来ず昇格しようにもできない
・クラスター全体で見たときにマスターの数が保てなくなり無事死亡
多分こうすればよかった
・サーバーシャットダウン前にクラスター内でのマスター、スレーブの関係を確認
・Redisを停止し、対応するスレーブが昇格していることを確認
・上記確認後にサーバーシャットダウン
まとめ
- ソフトウェア、ミドルウェア、ハードウェアの別に関わらず、作業前には構成をしっかりと把握する
- 似たような作業はやったことがあるかもしれないけどその作業はやったことがないと自覚する
- 手順書をさぼらず書く。
- 慢心しない。油断しない。日々勉強。
調査時に参考にさせていただいた記事
Redis Cluster検証: https://qiita.com/ono-soic/items/a41044c977da5231297b