オミカレにおけるAWS SQS/Lambda/CloudWatchの障害対応｜uedy
2020年4月20日18:58頃に発生したSQS/Lambda/CloudWatchの障害への対応 20時12分に対応を開始。それからリリース、動作確認が取れたのが21時25分でした。 オミカレでもAWSのSQS/Lambda/CloudWatchを利用している。主にメールやPush通知を送信しており、これが止まれば 会員登録・予約 などの様々なユーザー体験が損なわれる。 なので対応を議論していたところ 天才的ひらめきですぐに移すことに取り掛かった。 結果から行くとSQSとLambdaのリージョンを移行するという手で解決できた。 移行先は近場、白羽の矢は香港か、シンガポールでした 距離で行くと香港だというはなしでしたが、香港に行くとリージョンの有効化から始めないといけないしなにかのwarningが出ているのでシンガポールにすることにした。 SQSの障害だけ察知していたのでSQSのリージョン
DC/クラウド/通信事業者サービスの障害事例よせあつめ - # cat /var/log/stereocat | tail -n3
はじめに データセンタ障害の話題がちらほら流れておりますが、その中で見かけた「データセンタでそんな障害あったら意味ねえじゃん」みたいなコメントにちょっと引っかかるところがありまして。まあ確かに電源の二重化云々とかいろいろ災害やトラブルに対する対策はしてますよ。してますけど、でもデータセンタ・オーダーの障害とかも実際あるんですよね。落ちるときは落ちるんですよデータセンタだろうと。信頼性は高いけど100%じゃない。 ということで、じゃあ過去どんな事例があったのか、ざっと事例を挙げてみようと思いました。基本的には過去の私のツイートとかはてブとかネットをざーっと検索して出てくるものを取り上げています。「データセンタ使ってるからオールオッケー」みたいな話ではなくて、その上で・さらにこういうこともあるんだ、という話を見るのに参考にしてもらえれば良いかと思います。 なお、ここで取り上げている事例は、特定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
