Amazonのクラウドサ－ビス、Amazon Web Service（AWS）でシステム障害……原因は冷却問題による熱暴走！？
22:00-修正更新済み。Amazon Web ServiceのヘルスダッシュボードURLをAECCにも追加し加筆。
原因はどうも冷却システムトラブルのようだ。
＜AECC（Japan）-EC2サービスの障害経過＞
障害が最初に報告されたのは、日本にあるAmazon Elastic Compute Cloud（AWSの演算サービスクラウド）のようだ。
Pacific Timeで21:18（日本時間-JSTで13時18分）から
ap-northeast-1（アジアパシフィック-北東-１-東京のこと）でインスタンス接続に関する問題が検出されたようだ。但し、サーバーのセッション数が相当程度あるはずなので、これが検出されるまでの閾値に達したのがこの時間であると考えられる。最初は日本時間で午前11時30分以降～12時台のどこかで、一部サービスに動きへの影響（リトライなどの症状）が出はじめていたと考えられる。それから約30分後、21:47（JST-13時47分）にはインスタンスの一部がロストし、Elastic Block Store（EBS）ボリュームのパフォーマンスが大きく損なわれた（低下と明記されているがいくつかのサービスで既に停止報告があるので、大きな処理低下が起きたと思われる）ようだ。上記の障害がクラスタノードやサーバーの同期マイグレーションサービス全体に波及し切り離されたのだろう。要求に対して処理出来るサービスの許容量を超えてしまったと考えられる。そこで、大半のAmazon EC2サービス（Amazon Elastic Compute Cloud）に対してエラーを返すようになったということのようだ。
ここまでに、中小規模も含めて全てのサービスがログイン不能などの症状に陥ったはずだ。だから、セッションに繋がる前に破棄する（Deny/拒否応答）に切り替えられ気が付いたところが多いと考えられる。
尚、22:27（JST-14時27分）に根本原因が特定されたようで、回復作業に入る目処が立った。
23:40（JST-15時40分）に回復作業が進みEC2の方は回復し始めたようだ。たぶん、最初のノード回復が確認されたということだ。この後、新たな不具合がなければ、順次リソースは回復するだろう。但し、EC2上にサービスをおいているメーカー側が動作テストをして回復するまでには、暫く時間が掛かると思われるので、注意して欲しい。
1:54（JST-17:54）、23:40と同一のメッセージが追加された。A_RDBも同じ周期なので2時間15分周期の機械通知のようだ。
2:39（JST-18:39）、大半のインスタンスは復旧済み。但し、まだ全ての回復はしていないとのメッセージ。残りの復旧を目指すと通知。
4:18（JST-20:18）、20時36分（日本時間12時36分）からECサーバーの一部で熱暴走によるシャットダウンが発生。（内容を見る限り空調またはシステム冷却電源の停電トラブル<故障>と思われる。冷却システムがどういうものかは不明なので、空調なのかそれとも、液冷システムなど直接的な冷却かは分からない。規模が規模なので、今後発表されるかも知れない。この場合は経験上回復とバグチェックに時間が掛かったり、中途半端にノードやマイグレーションダウンすることがあるので最悪である。）EC2インスタンスの一部でリソース低下による縮退状態へと移行した模様。23時21分（15時21分）に冷却システムが復旧し、2時30分（18時30分）までに大部分の回復を確認済み。
現在は、回復が確認された場所から順次インスタンスとボリュームの回復実行中。一部のインスタンス（環境）では、顧客対応が必要なケースがあるため、必要な場合は個別通知が行われる見込み。
（尚詳細は、上記URL確認のこと-日本語で簡易抜粋し意訳説明したものである。）
これで、たぶん解消に向かうだろう。
但し、時間が時間なので全てのシステムが今日中に回復するとは限らない。よほど海外との取引に関わったり、決済に関係するシステムなら別だが、国内だけなら明日以降（場合によっては次の営業日である来週）になるだろう。働き方改革もあるので、なかなか難しい。
下のA_RDBの方もこちらが回復すれば回復するはずだ。Amazon Web Serviceの保守をされている方には、ご苦労様と労いたい。
一方で、それに乗っかるサービスを使っている企業の管理者の方は、これからが最後の確認で本番であるデータの破損などがないことを祈っている。一番大変なのは、真面目な中間管理職の上司、またはろくでもない上司の下でこれのために待っている人が厳しい。真面目な下の勤怠管理（働き方改革があるので時間外は減らさねばならない）といけないため、これはかなり痛い。一方で、ろくでもない上司の下だと勤怠の心配もせずに、文句言いそうだ。そうなると部下の方が辛いだろう。
本当に巻き込まれた方々は、ご苦労様と言いたい。全ての解消にはもう暫く掛かるだろうが、あと一息であると奮起して欲しい。
＜A_RDBサービスの障害経過＞
回復の影響と思われるが、Amazon Relational Database Service（リレーショナルデータベース/Amazon RDB、以下ARDB）に対しても接続性の問題が出たようだ。
これは、上記のAECC問題が最初に発覚してから約1時間後（10:22 PM PDT）、日本時間14時22分に通知されている。
EC2と連動しているサービスもあると思われるので、上記のサービス低下や停止によって失われたセッションに対するキューが溜まり、Deny応答とRecall応答時間（待ち時間）を経て、破棄するキューに対して、新たにやってくるキューが多すぎて滞留した可能性が高い。
23:25（JST-15時25分）に特定から回復作業中になっているので、EC2側とRDBの間で出た（出そうな）膿を取り払うための作業でもしているのだろう。どうせ、キューを破棄するために問題のあるサーバーをノードから（またはマイグレーションサービスから分離して）剥がし、再起動と再組み込みをすれば改善するのだろうが、AECC側の性能低下の問題がある程度解消するまでは解消しないと思われる。
0:01（JST:16:01）にA_RDBの回復も最初のステートが開始されたようだ。
障害が起きた時間から考えると、短ければ、順調にいけば1時間位内（←既に経過済み）、長くても3時間以内にはパフォーマンスが戻るだろう。
2:16（JST-18:16）、上記の経過としてほぼ同等のメッセージが追加された。2時間15分周期でAECCとほぼ同じと思われる。
4:46（JST-20:46）、大部分は回復済みとなった。やはり、AECCに引っ張られていたのだろう。
ただ、金曜日のよい時間帯なので、回復しても暫くは重くなるのは間違いない。
（尚詳細は、上記URL確認のこと-日本語で簡易抜粋し意訳説明したものである。）
これを使う企業や個人にとっては、金曜日と月曜日は痛い。会社の社員向けなら、仕事が出来ない来週に持ち越しでも良いものはあるかも知れないが、外向け（コンテンツなどのサービスをAWSを通じて提供する）企業などは、AWSが回復するまで残業かな？週末に回復出来なければ、来週頭まで……なんてことにもなりかねない。頭が痛い話だ。
実際、既に2時間目に入っており、終業時間帯の17時～18時に突入している点を考えると、来週持ち越しや、土曜日出勤が今回は結構出てきそうだ。そして、回復の通知が出ないということは、結構影響範囲が大きかったのだろう。データリカバリーなどを必要とするハードウェアもあったのかもしれない。
＜蛇足-回避策と人手不足のジレンマ＞
まあ、業務への支障をある程度減らすには、日時処理で、夜間やその日の業務終了時にクラウドからバックアップする仕組みを作り、クライアント（イントラ内）側で簡易データぐらい閲覧または管理出来るようにしておくと便利だ。まあ、個人情報があるとそれが狙われることもあるので、しっかりしたセキュリティシステムが必要だし、スマホゲームなどクラウドが柱の仕事ではそれも役に立たないが、営業職や情報管理、解析などをシステムに求めているなら、クライアント側にスタンドアロンの補助サーバー（データサーバー、DWHサーバー）システムを持っておくのが妥当だろう。
フルクラウドに移行して業務に支障が出ている企業は少ないと信じたい。コスト削減を想定しているとしても、基本的に簡易参照DBをクライアントサーバーに日次処理、週次処理、築地処理で簡易版で落とす仕組みを導入している組織なら、屋外からの業務は出来なくとも、データが企業内にあるわけで、電話などを介して、社内にお願いして仮データなどを抽出する事は出来るかも知れない。
営業などで更新されていくデータや、顧客情報も来週打ち込みなどをするとして、参照DBがあれば、今の情報の確認などには困らないだろう。まあ、紙ベースなどで変更点を残して事後処理する必要があるので、教育などにコストが掛かるのだが……。
今は障害がかなり減ったので、やらないところも多いからこそ、動かないとSNSやツイッターで語られる訳だが……。これは、クラウドに夢を見すぎると忘れてしまうものである。大規模災害なども今は多いので、こういうシステムが中途半端にしか動かない場合も想定したマニュアルとシステムは構築しておかないと不味い。そのシステム管理と関係ない下が知る必要はないが、システム管理者と予算を出す人ぐらいは、そのシステムが万が一にも止まったときに、会社があたふたしない手段をちゃんと決めておくのは大事だ。
って、上に何度か言っても、その上が更に上との会議や稟議で負けて帰ってきたという苦い記憶もある。まあ、既にその部署からは外れ、担当者も既に何世代目かになっているだろうが、それが当たり前になって、管理者になると、こういうリスクに目は向かなくなる。何故なら、自分が入ってから1度も事故が起きていないなら、その事故は決して起きないと過信するからだ。大雨などの越水被害などと似ている。
まあ、例えクラウドに依存しないバックアップがあっても、動かせる余剰人員が少ない組織では、人手不足を補うためにシステムで自動化しているケースも今では多い。だから、それでも仕事にならないだけということもある。本当に、システム依存しないと仕事が成り立たないほど、人手不足になるのは困ったものである。
この記事へのコメント