注目の記事

8/23東京リージョン障害中の当ブログ稼働を紹介します

2019.08.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSチームのすずきです。

日本時刻の2019年8月23日 12:36、東京リージョンのアベイアビリティゾーン(ID:apne1-az4)で障害が発生し、EC2やEBSが影響を受ける障害が発生しました。

当ブログ(Devlopers.IO)のCMSは AWS東京リージョンのEC2、RDS上で稼働しており、 障害が発生していたアベイアビリティゾーンも利用する構成でした。

この環境で発生した障害内容と、当日実施していた暫定対応について紹介させていただきます。

障害内容

8月23日 日本時間の 13:30から15:25にかけ、当ブログ Devlopers.IO宛の一部のリクエストが、 5XXのエラー応答となり、ブログ記事の表示不良が発生していました。

時間帯別に確認された5XXエラーの発生状況は以下の通りでした。

時間帯 エラー数 総リクエスト数 エラー率 (%)
12時台 0 4755 0
13時台 936 5306 18
14時台 1710 5367 32
15時台 146 5016 3
16時台 0 4541 0

発生原因

ap-northeast-1a(ID:apne1-az4) に設置されたELBのノードが、5XXのエラー応答を戻していました。

暫定対処

ELB(ALB) で利用していたAWS WAFの保護設定を一時的に解除、ELB_5XXエラーが抑制された事を確認しました。

対応経緯

14:20

  • チャットの通知より、DevloppersIOのブログ基盤から HTTP 5XX の発生している事を確認

14:30

  • ElasticBeanstalkのダッシュボードの「WARN」イベントより、HTTP 5xx の発生状況を確認

  • CloudWatchの ALB ダッシュボードより、HTTP 5XX の発生状況を確認

  • ALBのCloudWatchメトリックより、ELBに起因する「ELB_5XX」エラーである事と、 AZ別のメトリックより ap-northeast-1a(ID:apne1-az4)、アベイアビリティゾーン障害のあったゾーンでエラーが記録されている事を確認。

  • EC2、RDS(Aurora)については、正常稼働中である事を確認した後、ELBの重点調査を開始

15:00

5XXエラー発生時のELB(ALB)のアクセスログより、「actions_executed: waf-faild」と示されているレコードが6割以上の比率で存在する事を確認。

ELBアクセスログの抜粋

{
  "type": "https",
  "timestamp": "2019-08-23T05:53:50.767192Z",
  "elb_status_code": "500",
  "target_status_code": "-",
  "request": "GET https://dev.classmethod.jp:443/cloud/aws/insufficientinstancecapacity/ HTTP/1.0",
  "ssl_protocol": "TLSv1.2",
  "actions_executed": "waf-failed"
}

15:20

  • DDoS対策として導入していたAWS WAF、稼働状況より直近に過度のリクエスト集中が発生していない事を確認。

15:30

  • ELBの AWS WAF保護を一時的に無効化。(WAFのACL設定よりELBを除外)

15:40

  • CloudWatchのメトリックより、ELB_5XXの発生が収束したことを確認。

まとめ

8月23日の東京リージョンの障害中にDevlopers.IOで発生した障害は、AWS WAFの無効化で回復した事から、ELB(ALB)とAWS WAF間の連携に何らかの問題があったと推測される状況でした。

障害発生前後のCloudWatch情報や、アクセスログの解析をすすめ、 類似の問題が発生した場合の早期検出方法や、影響を最小限に留める事が期待できる構成などを検討の上、 効果が確認できた成果、恒久対策については改めて紹介させて頂きたいと思います。