Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2019年8月23日 13時頃に発生した AWS東京リージョンの障害に関してのご報告[第3報]

5b7514eee4e25d83486d6a5cd0996b17?s=47 SWXMarketing
August 30, 2019

2019年8月23日 13時頃に発生した AWS東京リージョンの障害に関してのご報告[第3報]

障害の概要と今後ビジネスに影響を及ぼさないための対策をまとめたホワイトペーパーはこちら:https://info.serverworks.co.jp/l/310441/2019-09-04/cwmjk6

5b7514eee4e25d83486d6a5cd0996b17?s=128

SWXMarketing

August 30, 2019
Tweet

Transcript

  1. 株式会社サーバーワークス 2019年8⽉23⽇ 13時頃に発⽣した AWS東京リージョンの障害に関しての報告 第3報 2019年8⽉30⽇

  2. 本書について 2 拝啓 時下ますますご清祥のこととお慶び申し上げます。 平素は、格別のお引き⽴てを賜り厚くお礼申し上げます。この度はAWS東京リージョンの⼤規模障害 につきまして、ご迷惑をおかけしました事を深くお詫び申し上げます。 本書は、AWSの提供する SERVICE HEALTH DASHBOARD(SHD)のアナウンス及びSHDに対する当

    社⾒解を記したものです。 尚、本障害においてAWSの正式な概要が発表されました(詳細はP.10を御覧ください)が、今後も情 報開⽰の可能性があります。このため本書の当社⾒解は暫定的なものであり、更新をさせて頂く可能 性がある事、予めご了承ください。
  3. 本件障害の概要 3 ▸発⽣⽇時︓2019年8⽉23⽇(⾦) 12:50頃から 同 20:36頃 ▸ ※当社監視システムでの検知及びSHDによる⼤部分の復旧 ▸ ※上記発⽣⽇時は、AWS基盤の障害時刻を⽰すものです。後述する障害対象リソースの停⽌に伴いまして、

    お客様のアプリケーションやその他システムに何らかの影響が継続している可能性があります。 ▸影響範囲 ▸ EC2のステータスが0/2となる(使⽤不能) ▸ シングルAZのRDSが使⽤不可となる、またはマルチAZ配置のRDSにてフェイルオーバーに伴う⼀時的な 通信断が発⽣ ▸ EBSのパフォーマンス低下発⽣ ▸原因 ▸ AWS側の冷却システム故障によるものとなります。 ▸ 特定のAZ(AZ ID: apne1-az4)に於いて発⽣しました。
  4. 拝啓 貴社ますますご盛栄のこととお喜び申し上げます。 SHDの経緯抜粋及び、当社⾒解について

  5. 5 SHDの経緯︓1 【EC2】9:18 PM PDT We are investigating connectivity issues

    affecting some instances in a single Availability Zone in the AP-NORTHEAST-1 Region. 【RDS】10:22 PM PDT We are investigating connectivity issues affecting some instances in a single Availability Zone in the AP-NORTHEAST-1 Region. EC2 13:18 RDS 14:22 上記時刻にそれぞれに於いて、インスタンスの接続障害についての初報が報じられています。 尚、当社監視システムは12:50頃に同事象を検知し始めております。また、同時刻頃より、当社監 視システムに於いて、お客様EC2及びRDSの死活監視の失敗アラートが多数発報されました。 当社⾒解 SHDによるアナウンス SHD: https://status.aws.amazon.com/
  6. SHDの経緯︓2 6 【EC2】10:27 PM PDT We have identified the root

    cause and are working toward recovery for the instance impairments and degraded EBS volume performance within a single Availability Zone in the AP-NORTHEAST-1 Region. 【RDS】11:25 PM PDT We have identified the root cause of instance connectivity issues within a single Availability Zone in the AP-NORTHEAST-1 Region and are working toward recovery. SHDによるアナウンス EC2 14:27 RDS 15:25 上記時刻にそれぞれに於いて、原因の特定がされ、障害対応の進⾏がアナウンスされています。尚、 当社運⽤に於いて、該当EC2及びRDSの停⽌/起動を試みましたところ、起動するケース(後に再 度停⽌するケース)⼜は、停⽌中が続くケースが散⾒されております。 当社⾒解 SHD: https://status.aws.amazon.com/
  7. SHDの経緯︓3 7 【EC2】 11:40 PM PDT We are starting to

    see recovery for instance impairments and degraded EBS volume performance within a single Availability Zone in the AP-NORTHEAST- 1 Region. We continue to work towards recovery for all affected instances and EBS volumes. 【RDS】 12:01 AM PDT We are starting to see recovery for instance connectivity issues within a single Availability Zone in the AP-NORTHEAST-1 Region. We continue to work towards recovery for all affected instances. SHDによるアナウンス EC2 15:40 RDS 16:01 上記時刻にそれぞれに於いて、除々に復旧がアナウンスされております。当社お客様環境の幾つか に於いても、⾃然復旧及び、停⽌起動処理で正常化した事が確認出来ております。 当社⾒解 SHD: https://status.aws.amazon.com/
  8. SHDの経緯︓4 8 【EC2】Aug 23, 2:39 AM PDT The majority of

    impaired EC2 instances and EBS volumes experiencing degraded performance have now recovered. We continue to work on recovery for the remaining EC2 instances and EBS volumes that are affected by this issue. This issue affects EC2 instances and EBS volumes in a single Availability Zone in the AP-NORTHEAST-1 Region. 【RDS】Aug 23, 4:46 AM PDT The majority of instance connectivity issues have now recovered. We continue to work on recovery for the remaining instance connectivity issues within a single Availability Zone in the AP-NORTHEAST-1 Region. SHDによるアナウンス EC2 18:39 RDS 20:46 上記時刻にそれぞれに於いて、⼤部分の復旧がアナウンスされております。当社ほとんどのお客様 環境に於いて、復旧が確認出来ております。(※監視の正常性確認作業は継続されている場合があ ります) 当社⾒解 SHD: https://status.aws.amazon.com/
  9. AWSサポートの案内 9 ⽇本時間 2019年8⽉23⽇ 12:36 より、AP-NORTHEAST-1 の単⼀のアベイラビリティゾーンで、 ⼀定の割合の EC2 サーバのオーバーヒートが発⽣しました。この結果、当該アベイラビリティゾー

    ンの EC2 インスタンス及び EBS ボリュームのパフォーマンスの劣化が発⽣しました。 このオーバーヒートは、影響を受けたアベイラビリティゾーン中の⼀部の冗⻑化された空調設備の管 理システム障害が原因です。⽇本時間 15:21 に冷却装置は復旧し、室温が通常状態に戻り始めまし た。温度が通常状態に戻ったことで、影響を受けたインスタンスの電源が回復しました。⽇本時間 18:30 より⼤部分の EC2 インスタンスと EBS ボリュームは回復しました。 我々は残りの EC2 インスタンスと EBS ボリュームの回復に取り組んでいます。少数の EC2 インス タンスと EBS ボリュームが電源が落ちたハードウェア ホスト上に残されています。我々は影響をう けた全ての EC2 インスタンスと EBS ボリュームの回復のための作業を継続しています。 早期回復の為、可能な場合残された影響を受けている EC2 インスタンスと EBS ボリュームのリプ レースを推奨します。いくつかの影響をうけた EC2 インスタンスはお客様側での作業が必要になる 可能性がある為、 後ほどお客様個別にお知らせすることを予定しています。
  10. AWSによる本件の概要 10 ▸本件に於けるAWSの正式な概要が発表されました。( https://aws.amazon.com/jp/message/56489/ ) 2019年8⽉26⽇ 第2報として追記 ⽇本時間 2019年8⽉23⽇ 12:36

    より、東京リージョン (AP-NORTHEAST-1) の単⼀のアベイラビリティゾーンで、オーバーヒートにより⼀定の割合の EC2 サーバの停⽌が発⽣しました。この結果、当該アベイラビリティゾー ンの EC2 インスタンスへの影響及び EBS ボリュームのパフォーマンスの劣化が発⽣しました。このオーバーヒートは、影響を受けたアベイラビリティゾーン中の⼀部の冗⻑化された空調設備の管理システム障害が原因です。⽇ 本時間 15:21 に冷却装置は復旧し、室温が通常状態に戻り始めました。室温が通常状態に戻ったことで、影響を受けたインスタンスの電源が回復しました。⽇本時間 18:30 までに影響を受けた EC2 インスタンスと EBS ボ リュームの⼤部分は回復しました。少数の EC2 インスタンスと EBS ボリュームは、電源の喪失と過⼤な熱量の影響を受けたハードウェアホスト上で動作していました。これらのインスタンスとボリュームの復旧には時間がかか り、⼀部につきましては基盤のハードウェアの障害によりリタイアが必要でした。 EC2 インスタンスと EBS ボリュームへの影響に加えて、EC2 RunInstances API にも影響が発⽣しました。⽇本時間 2019年8⽉23⽇ 13:21 に、影響の発⽣したアベイラビリティゾーンでの EC2 インスタンスの起動、および冪 等性トークン(複数のインスタンスを起動させる危険なく、インスタンスの起動をリトライする機能)を使⽤して RunInstances API を東京リージョンで実⾏した場合に、エラー率の上昇が発⽣しました。その他の EC2 API や冪 等性トークンを使⽤しない EC2 インスタンスの起動は正常に動作しておりました。この問題は、冪等性トークンを使⽤する Auto Scaling グループからのインスタンスの新規起動も阻害しました。⽇本時間 14:51 に、エンジニア は、冪等性トークンと Auto Scaling グループの問題を解決しました。影響の発⽣したアベイラビリティゾーンでの、新しい EC2 インスタンスの起動についてのエラー率向上は、EC2 コントロールプレーンサブシステムのリスト アが完了した⽇本時間 16:05 まで継続しました。影響の発⽣した EBS ボリュームのスナップショットの作成も、この期間にエラー率の上昇が発⽣しました。 今回の事象はデータセンターで使⽤されるいくつかの冷却システムの制御と最適化に使⽤されるデータセンター制御システムの障害によって引き起こされました。制御システムは、⾼可⽤性を実現するために複数のホストで実⾏さ れます。この制御システムには、ファン、冷却装置、温度センサーなどのサードパーティ製デバイスとの通信を可能にするサードパーティ製のコードが含まれていて、直接または組み込みプログラマブルロジックコントローラ (PLC)を介して通信し、実際のデバイスと通信します。今回の事象発⽣の直前に、データセンター制御システムは、制御ホスト群から制御ホストの 1 つを外す処理を⾏なっていました。このようなフェイルオーバーの間、新し い制御ホストがデータセンターの最新状況を保持する為に、制御システムは、他の制御システムおよび制御するデータセンター機器 (データセンター全体の冷却装置および温度センサーなど) と情報を交換する必要があります。 サードパーティ製の制御システムにおけるロジックのバグにより、この情報交換が制御システムとデータセンターのデバイス間で過度に発⽣し、最終的には制御システムが応答しなくなりました。AWS のデータセンターは、デー タセンターの制御システムに障害が発⽣した場合、制御システムの機能が回復するまで冷却システムが最⼤冷却モードになるよう設計されています。これはデータセンターのほとんどで正常に機能していましたが、データセンター のごく⼀部で冷却システムがこの安全な冷却構成に正しく移⾏できず停⽌しました。追加の安全策として、AWS のデータセンターオペレータは、データセンター制御システムを迂回し冷却システムを「パージ」モードにすること で故障に際しての熱⾵を素早く排出する能⼒を持っています。運⽤チームは、影響のあるデータセンターのエリアで冷却システムを「パージ」モードにしようとしましたが、これも失敗しました。この時点で、データセンターの影 響を受けるエリアの温度が上昇し始め、サーバーの温度が許容限度を超え、サーバーの電源が停⽌し始めました。データセンター制御システムが利⽤できなかったため、データセンターオペレータはデータセンターと冷却システム の健全性と状態に対する可視性が最⼩限に限定されていました。この状況を改善されるためにはオペレータは影響を受けるすべての機器を⼿動で調査してリセットし、最⼤冷却モードにする必要がありました。これらの対応時に⼀ 部の空調ユニットを制御する PLC も応答しないことが⾒つかりました。これらの PLC はリセットする必要があり、またこの障害によりデフォルトの冷却モードと「パージ」モードが正常に動作していないことが確認できました。 これらのコントローラがリセットされると、影響のあったデータセンターのエリアへ冷却が⾏われ室温が低下し始めました。 現在も、サードパーティのベンダーと協⼒し、制御システムと応答がなくなった PLC の両⾯を引き起こしたバグ、並びにバグによる影響の詳細な調査を進めております。並⾏して、事象の再発を防ぐため、バグを引き起こした制 御システムのフェイルオーバーモードを無効にしました。また、もし万が⼀事象が再現しても対策が取れるよう、オペレータにこの度の事象の検知⽅法と復旧⽅法のトレーニングを実施しました。これにより、もし同様の事象が発 ⽣しても、お客様への影響が発⽣する前に、システムのリセットが可能になっております。その他にも、「パージ」モードが PLC を完全にバイパスできるよう、空調ユニットを制御する⽅法を変更するよう作業を進めております。 これは、最新のデータセンターで使⽤している⽅法で、PLC が応答がなくなった際でも「パージ」モードが機能するようにするための⽅法です。 この度の事象発⽣時、異なるアベイラビリティゾーンの EC2 インスタンスや EBS ボリュームへの影響はございませんでした。複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発⽣中も可⽤性 を確保できている状況でした。アプリケーションで最⼤の可⽤性を必要とされるお客様には、この複数アベイラビリティゾーンのアーキテクチャに則ってアプリケーションを稼働させることを引き続き推奨します(お客様にとって ⾼可⽤性に課題を⽣じ得る全てのアプリケーションのコンポーネントは、この耐障害性を実現する⽅法の下で稼働させることを強く推奨します)。 この度の事象により、ご迷惑をおかけしましたことを⼼よりお詫び申し上げます。AWS サービスがお客様ビジネスに極めて重要である点を理解しております。AWS は完全ではないオペレーションには決して満⾜することはあり ません。この度の事象から学ぶために出来得る全てのことを⾏い、AWS サービスの向上に努めてまいります。
  11. AWSによる本件の続報 11 2019年8⽉30⽇ 第3報として追記 ▸8⽉28⽇、本件に於ける続報が発表されました。( https://aws.amazon.com/jp/message/56489/ ) ▸今回東京リージョンの1つのアベイラビリティゾーン(AZ)の⼀部にで置きた障害の影響は当該 AZ の

    Amazon EC2 および Amazon EBS のリソースに対するものであるが、基盤としている EC2 イ ンスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache お よび Workspaces 等)にも影響があった ▸調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働し ていたお客様のアプリケーションにも、予期せぬ影響があったことが確認された ▸ 例) Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせ てご利⽤しているお客様の⼀部で、想定されるより⾼い割合でリクエストが Internal Server Error を返 す ▸AWS では、個別の問題についての詳細な情報を影響を受けたお客様に直接、共有を⾏う予定であ る
  12. 拝啓 貴社ますますご盛栄のこととお喜び申し上げます。 本障害の有効な対策について

  13. お客様への障害ご連絡につきまして(検知につきまして) 13 ▸当社お客様に対しては、13:30頃に初報を送付いたしました(運⽤代⾏サービスに於いては、 12:54頃より死活監視異常を検知し、アラートの発報を⾏っております) ▸当社Webサイトにて、継続的に障害状況をご案内いたしました。 ▸ ご参考︓https://www.serverworks.co.jp/news/20190823_aws_news.html

  14. AZ IDについて 14 ▸当社Webサイトでの障害状況報告では、2019年8⽉23⽇14:54時点で障害発⽣AZについて訂正を いたしました。 ▸ <障害対象> 【誤】AWSの東京リージョンのAZの⼀つ(ap-northeast-1a) 【正】AZ ID︓apne1-az4

    ▸AZ IDを記載した理由 ▸ AZは、リージョンコードとそれに続く⽂字識別⼦によって表されます (us-east-1a など)。リソースが リージョンの複数のAZに分散するように、AZは各 AWS アカウントの名前に個別にマップされます。 ▸ たとえば、AWS アカウントのAZ us-east-1a は別の AWS アカウントのAZ us-east-1a と同じ場所には ない可能性があります。アカウント間でAZを調整するには、AZの⼀意で⼀貫性のある識別⼦である AZ ID を使⽤する必要があります。たとえば、use1-az1 は、us-east-1 リージョンの AZ ID で、すべての AWS アカウントで同じ場所になります。 ▸ 参考︓リージョンとアベイラビリティーゾーン ▸ https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability- zones.html#concepts-regions-availability-zones 2019年8⽉26⽇ 第2報として追記
  15. 早急に復旧する為に⾏える⼿段 15 ▸まだ、基盤障害が継続しており、停⽌起動の復旧が⾏えない場合 ▸ 取得したAMIを本障害の対象であるAZ以外のAZに新規構築を⾏う ▸ ※普段の運⽤に於いて、AMIスナップショットの取得及びAMIからの新規構築を許容出来る構成が必要に なります。 ▸除々に復旧中であり、停⽌起動による復旧が⾏える場合 ▸

    対象サーバの停⽌起動処理を実施頂く ▸ ※参考︓http://blog.serverworks.co.jp/tech/2019/07/31/post-72458/ ▸ ※当社運⽤代⾏サービスをご利⽤のお客様の場合、サポートへのご連絡で同様の処理を代⾏いたします。 ▸ Auto Recovery 機能が設定されている環境の場合、障害の復旧時に合わせて停⽌起動処理が成功し、復旧 出来る可能性があります。
  16. 当社からの提⾔ 16 1. Multi-AZ構成の推奨 ▸ 本障害は、特定のAZ(AZ ID: apne1-az4)において発⽣した障害です。リソースを複数のAZに冗⻑化配置 (Multi-AZ構成)する事で、今回の様に単⼀AZで発⽣した障害に伴うシステム停⽌を回避出来る可能性が あります。

    ▸ また、2AZ構成で運⽤されている場合は、3AZ構成にしてAZ障害時にAZを切り離す戦略も有⽤です。より ⾼い可⽤性が求められるシステムをAWS上に展開する場合、3AZ構成への設計変更もご検討ください。 ▸ AZの変更については、詳細な設計が必要になります。ご要望に応じて別途ご案内させて頂きます。 (お問い合わせ窓⼝ https://www.serverworks.co.jp/contact/aws.html) 2. バックアップ戦略の再検討 ▸ EBSは通常の物理ディスクと同様にバックアップが必要です。当社が提供するSaaS(Cloud Automator) 等により、定期的なバックアップを確実に取得できるようになります。バックアップ計画の⾒直し、再検 討を推奨致します。(詳細 https://cloudautomator.com/autojob/) 3. マネージドサービスの監視 ▸ AWSのマネージドサービスに関しても監視が有効です。今回の障害ではEC2だけでなく、ALBやRDSなど のマネージドサービスについても⼀部影響がありました。こうしたサービスについて監視・障害時の連絡 等を迅速に⾏うことで影響を最⼩限にとどめられた可能性があります。当社にてこうしたマネージドサー ビスの監視・運⽤も承っております。 2019年8⽉26⽇ 第2報として追記
  17. 改定履歴 17 ▸2019年8⽉24⽇ 第1報 ▸2019年8⽉26⽇ 第2報 ▸2019年8⽉30⽇ 第3報 ▸今後、新たな情報などが開⽰されましたら後報いたします。