【2020/4/20】Amazon Web Service(AWS)で障害発生!影響サービスについて

IT

Amazon Web Service(AWS)は最近、IT業界で注目されているクラウドサービスです。

今までだと各企業でデータセンターに購入したサーバーをおいてシステム構築をしてきましたが、機器の購入/保守が不要でシステム導入までがスピーディーに済むため人気が出てきていました。

AWSが公開する国内で導入している企業を見ると有名企業がたくさんいます。

放送系では「テレビ東京」や「フジテレビ」、市町村でも導入が進んでおり横浜市では粗大ごみの画像をもとに手数料を割り出すシステムの導入事例が載っています。

AWS国内導入事例

横浜市の導入事例

そんなAWSに2020年4月20日の19:40頃からシステム障害が発生してしまったので詳細をまとめてみます。

障害発生サービス

障害が発生したサービスは以下の4つになります。

  • AWS CloudWatch
  • AWS Lambda
  • AWS SQS
  • AWS CloudFormation

AWS CloudWatchの障害影響

AWS CloudWatchは、AWS上に構築したシステムが正常に動いているのかを処理のログやCPU・メモリ・ディスク容量などを監視してくれるサービスです。

このサービスのおかげでシステムがおかしくなってしまったことをすぐに検知できるというものです。

今回起きた障害では、AWS CloudWatchサービスが監視するシステムにて異常が発生した際に発するアラームの処理に遅延が発生してしまったようです。

AWS CloudWatchサービスでシステム監視を行っている場合は、障害が発生していたと思われる以下の時間で異常がなかったかをCloudWatchのメトリクスをさかのぼって確認しておいたほうが良いでしょう。

■障害時間
 2020/4/20 19:38 ~ 2020/4/20 11:17

AWS Lambdaの障害影響

AWS Lambdaは、作成したプログラムを実行してくれるサービスです。

今までのようにプログラムを実行してくれるサーバーを構築しなくても、プログラムだけ書けば実行してくれるというもので、サーバーレスアーキテクチャーでよく使われるサービスです。

サーバーレスシステムを構築している場合は、大きな影響があるかもしれません。

障害状況としては、東京リージョンのAWS Lambdaにて非同期呼び出しおよびコントロールプレーンAPIでエラー上昇が検知されたようです。

ちょっとどういう障害なのかイメージがわかないですね・・・。

Lambdaの非同期呼び出しというのは、実行する際に結果を持たない実行形式のことですね。

例えば、AWS S3にデータを送る場合を想像すると、AWS Lambdaがデータを送る処理を開始だけして終了を待たずに処理を完了させる実行形式です。

大きいデータだと送りきるまで待つと数十分かかることもあるので、開始だけして正常に完了したかを見ないということですね。

この処理は非常によく使われるのでこの非同期呼び出しがでエラー上昇=失敗が増えたということだと、影響が大きいかもしれません。

AWS LambdaはAWS CloudWath Logsに実行ログを出力しているはずなので、以下の時間で失敗してないかを確認しておくべきでしょう。

■障害時間
 2020/4/20 19:45 ~ 2020/4/20 11:15

もう一つ書かれているコントロールプレーンAPIの失敗は、AWS LambdaでFunctionの作成や更新といったプログラム部分のコントロールをつかさどる部分なのでそこまで影響はなさそうかなといったところですね。

AWS SQSの障害影響

AWS SQSは、メッセージキューサービスと呼ばれていて、データを処理するサーバーに流す前に一度蓄えてくれるサービスです。

このサービスがあることで処理するサーバーを並列に配置して、効率よくデータ処理を行うことができます。

AWS SQSもサーバーレスアーキテクチャーではわりとよく使われるので、影響が気になるところです。

障害状況を確認してみると、データの送受信操作でエラー上昇が検知されているようです。

AWS SQSはデータを受け取って(受信)流す(送信)ことを目的としたサービスなのでこのエラー上昇はサービス影響が大きそうです。

我が家の自宅システムではSQSを使っていないので影響度合いがわからないのですが、送受信エラーが発生したとなるとSQSにデータが溜まって処理が流れていない可能性もあります。

SQSに溜まっているジョブを確認しておくべきですね。もし溜まっているようなら処理側のシステムを一時的に増強するなどの対応が必要になってくる可能性もあります。

一応、障害時間は以下のようです。

■障害時間
 2020/4/20 19:42 ~ 2020/4/20 11:12

AWS CloudFormationの障害影響

AWS CloudFormationは、AWS環境の構築において指示書(テンプレート)を書いてあげると自動でくみ上げてくれるサービスです。

同じような環境をたくさん作るときなどは、一度指示書(テンプレート)を書くと全部自動で構築してくれるので便利なサービスだったりします。

あくまで私見になるのですが、このサービスは構築期間によく使われるイメージでサービス提供しているシステムではあまり影響はなさそうなのかな、と思ったりします。

障害状況としては、AWS CloudFormationのスタック操作でエラー上昇および遅延が発生したようです。

スタック操作ということは、テンプレートからCloudFormationが組み上げるシステムのことを指すので自動構築中にエラー=失敗や遅延が発生したということでしょう。

AWS CloudFormationは、作成に失敗するとロールバック(=作り始める前に戻す)するので、そこまで大きな影響はないのではないでしょうか?

また、CloudFormationを動かしなおさなきゃいけないので面倒そうではありますが・・・。

障害の発生時間は以下のようです。

■障害時間
 2020/4/20 20:09 ~ 2020/4/20 22:24

影響確認方法(AWS PersonalHealthDashboard)

今回の障害で自分が使用しているAWSアカウントに影響があったのかを簡単に確認する方法があります。

それが、AWS Personal Health Dashboardです。

このサービスは発生した障害の状況とアカウント内で影響があるリソースをチェックしてくれます。

AWSアカウントにログインして、サービスのところで「Personal Health Dashboard」で検索すると出てきます。

特に事前に設定しておく必要があるわけではないので、どなたのAWSアカウントでも使用可能だと思います。

是非、確認してみてください。

まとめ

今回の障害はEC2ではなかったので、EC2でサービス提供している人だとあまり影響がなかったかもしれませんね。

監視機能のCloudWatchの遅延や、AWS LambdaとAWS SQSなどのサーバーレスシステムでのメインサービスで障害が発生したのは大きな影響になりかねません。

障害自体は大体2.5時間くらいで終息していますが、これが早いのか遅いのかはシステム毎の影響度合いによってきそうです。

じゃあ、どうやって今回のような障害に対応していくかが今後の課題になりそうですね。

コメント

タイトルとURLをコピーしました