オミカレにおける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のリージョン
運用とログ - 京都行きたい
アラート起因で調べるベースの運用とログの話を書いておく。 状況確認 状況確認は大事。ひとまず初動で原因が分かると嬉しいので ざっくり状況確認。 ログを読む エラーログを読む なにも出てなかったらWARNを読む メトリクスを見る 5xxエラーを見る どのサービスがダメになってる？ 状況別調査 状況別に自分が見ているところをざっくりメモベースで書いておいた。 変なレスポンスが返っている ログを見る リクエストに紐付いた一意なIDを元にログで処理を追いかける 外部通信した時はこの一意なIDと一緒にログに出力しておきたい レスポンスが遅い レスポンスタイムを見る 特定のリクエストだけ遅い場合があるので、基本的にAverageじゃなくてPercentileを使う 依存先のサービスも見る サービスのCPU使用率見る 特定のインスタンスのCPU使用率を見る RDBやバックエンドのCPU使用率を見る IO
AWS でいままで起きた大規模障害を振り返る - Qiita
目的 2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ使っているリージョンで同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。 所感 毎年どこかのリージョンで大規模な障害が起きている ap-northeast-1 で起きていないのはたまたま、運がいいだけ AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの ステータスダッシュボードは時に嘘をつく クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある Chaos Monkey の思想は必須 報告書読むの面白い AWS の中身がすこし透けて見えてきます 前回データセンターについて調べたことが役に立った AWS のデータセンターに侵入する（妄想で） - Q
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
