AWS東京リージョンで大規模障害、原因は冷却システムの故障 103
設備系はなかなか予想しづらいところ 部門より
Anonymous Coward曰く、
8月23日の昼頃から数時間にわたり、クラウドサービス「Amazon Web Services(AWS)」の東京リージョンで大規模な障害が発生、多数の企業のサービスに影響が出るトラブルとなった(ITmedia、ITmediaの続報、ASCII.jp、日経xTECH、Engadget日本版)。
AWSの東京リージョンは4つのデータセンター(アベイラビリティーゾーン)から構成されているとのことだが、Amazonの発表によると、そのうち1つで空調設備の管理システムに傷害が発生。その結果一定数のサーバーが過熱によって停止したという。冷却装置は15時21分に復旧し、その後18時半ごろには大部分のサーバーが復旧したという。
空調設備の管理システムは冗長化されていたが、管理システムのロジックにバグがあり、制御ホストの切り替え時に制御システムが応答しなくなる事態になったという。また、制御システムに傷害が発生した場合は冷却システムは最大冷却になるよう設計されていたが、データセンターの一部でこの構成に移行できず停止。さらに、問題になるデータセンターのエリアで冷却システムを「パージ」モードに切り替えて熱風を排出することを試みたものの、これも失敗したという。最終的に不具合のあった制御システムのリセットで対応を行ったという。
クラウドの普及によりAWSを使うサービスは多岐にわたっており、今回の障害では決済アプリのPayPayが使用できなくなったほか、dTVやローソンアプリ、Backlog、各種ソーシャルゲーム、果てはシェアサイクルの返却ができなくなるなど、大きな影響が出た模様である。
AWS「ギャアアアア!」 (スコア:5, おもしろおかしい)
GCP「AWSがやられたようだな」
アリババ「奴はクラウド四天王の中でも・・・最強!」
Oracle「やばいじゃん」
IBM「つーか四天王って何人いるの」
さくら「さくら大明神」
だいたいこんな情景を妄想して遊んでたクラウド技術者は多いはず
Re:AWS「ギャアアアア!」 (スコア:5, おもしろおかしい)
Azure「うちの方が大手なのに四天王にすら入れてもらえない・・・これがスラド補正か・・・」
Re:AWS「ギャアアアア!」 (スコア:2)
なぜかというとHAzureだからさ
Re:AWS「ギャアアアア!」 (スコア:2)
そうするとTypeScriptダメになるし、フロントエンド界隈だとツラくなってこない?
脳味噌腐乱中…
Re:AWS「ギャアアアア!」 (スコア:1)
評価もせずに「なんか不安」とかいう理由で出禁にしちゃうセンスねえ貴社の名前をお伺いしたく
クラウドの冗長構成の考え方の良まとめ (スコア:4, 参考になる)
Impressの記事が凄い良くまとまってたので、じゃあどういう構成にすべきかとか考えてる人に読んでもらいたい。
AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか [impress.co.jp]
Re:クラウドの冗長構成の考え方の良まとめ (スコア:5, おもしろおかしい)
そりゃ金の支払いなんかいくらでも待ってもらえばいいだけだけど、
こっちは遊びでやってんじゃないからね。
Re:クラウドの冗長構成の考え方の良まとめ (スコア:1)
サービス維持にお金をどれだけ出せるかですね。
マルチリージョン化すると、リージョン数分のお金が必要になるし。
>むしろ今回の件で注目すべきは、「落ちるべきではないサービスも障害で落ちている」点である。決済系や認証系サービスは、そうしたものの中に含まれるのではないか。
金勘定関わると対策は必須ですよね、動画配信やゲームだと割り切りそう。
Re:クラウドの冗長構成の考え方の良まとめ (スコア:1)
>まあ、実のところは「うまく切り替わらなかった」んだと思う。
稼働中サービスだと、実環境でその手のテストも難しそうだし。
テスト用の環境を構築するのもどこまでやるかは予算次第だろうし。
運営管理者さん達大変そう。
Re:クラウドの冗長構成の考え方の良まとめ (スコア:1)
マルチAZでも影響を受けた話 [hirokiky.org]をみると、今回みたいにAZ(az4)内の一部のみの障害だと正常に動作している部分によりかえって影響を受けて、1つのAZを切り離してみるテストが成功していたとしても今回の障害には耐えられなかった可能性もありそう。
Re:クラウドの冗長構成の考え方の良まとめ (スコア:1)
あげていただいたリンクを見る限り、ロードバランサーとしては普通に想定できる障害で、
インフラ設計にハードウェアロードバランサーを組み込んだ経験がある設計者なら「さもありなん」な感想をもつ内容かと。
ただ、問題としてはAWSだとロードバランサー自体の障害対応まで頭が回りづらい構成になっていることかねぇ。
物理機器いじくるインフラエンジニアがクラウドまで見てるとは思えないし。
物理的な場所はどこなんだろ (スコア:2)
いや、セキュリティ上ヒミツなのはわかるけどアマゾンのデータセンターって大手町とかの結節点に近いとこにぶら下がってるのかな
それとも幕張とかの土地が広く取れるとこに置いてるんだろうか
まれによくある (スコア:1)
> 設備系はなかなか予想しづらい
とはいえ、ニュースになる規模の大規模障害は意外と設備系だったりしますね。
某社のUPS障害 [it.srad.jp]しかり、某社の自家発電障害 [srad.jp]しかり。
Re:まれによくある (スコア:1)
これも電源 https://tech.nikkeibp.co.jp/it/article/NCD/20130325/465662/ [nikkeibp.co.jp]
こうしてみると電源障害が多いなあ。
やはりアット東京最強なのか。
Re:まれによくある (スコア:1)
あの変電所、都心に一番近い500kvのやつで、
中心地への電力供給ネットワークのハブの一つだから
ちょっとやそっとじゃ電気がおちないはずなのよ。
Re: (スコア:0)
きほん無人ですから発覚した時点で時すでに遅し
Re:まれによくある (スコア:2)
人がいたって、たいして変わらない気がするな。w
どうせすぐにはなおせないやろし。。。
Re:まれによくある (スコア:1)
トラブル発生するとすぐにわかるように、
twitterで自社サービスのハッシュタグと、5chの自社サービスのスレの両方を
担当者が監視してるサービスは多いとおもうよ
とくにアップデート時は重点的に監視する
サードパーティー製 (スコア:1)
何度も繰り返して書かれているのが気になりますね...
空調が止まるような状況になったときって、サーバーはどういう動きをするのが正解なんでしょう。
パフォーマンスを低下させてでも、止まらないようになっていると嬉しいかなぁ。
Re:サードパーティー製 (スコア:4, 参考になる)
1ラック10kW×100ラックとか当たり前のDCで空調が止まったら、室内温度が急上昇して冷却が追いつかなくなります。
気密性が良ければ50℃~60℃とかに到達するかも・・・その前にサーバーが停止するでしょうけど。
サーバーの冷却は冷却ファンでCPUのヒートシンクを通過した空気と、CPUとの温度差で冷却しますが、
取り込む室内の空気の温度とCPUの温度との間に温度差が無くなると、いくらファンを回しても全く冷却できないのであとは停止するだけです。
サーバーはどういう動きをするのが正解
温度上昇の検知により、シャットダウン信号を入力して正常にシャットダウンするのが正解ではないでしょうか。
止まらないようになっていると嬉しい
止まらないようにするとしたら、強制冷却ではなく自然放熱で設計されていないと難しいでしょうね。
データセンターほど高密度の環境では無理でしょう。
Re:サードパーティー製 (スコア:2)
>止まらないようになっていると嬉しい
仮想マシンだったら動的マイグレーションして正常DC内PCに移動、ってのが理想だと思いますが、
理論上その設計だが、複数マシンが一気に移動しようとしてどっかで詰まって、正常マシンまで動かなくなってマイグレーションしようとしてさらに詰まる、とかありそう
Re:サードパーティー製 (スコア:1)
>> 止まらないようになっていると嬉しい
> 止まらないようにするとしたら、強制冷却ではなく自然放熱で設計されていないと難しいでしょうね。
外気温がCPU温度に追い付く前で、CPUを強烈にスロットリングする、があると嬉しいけど
だとしてもまあ現実的じゃないだろうなあ...
むしろ処理が間に合わない系とかネットワーク応答のタイムアウトで生き残るから、やっかいな問題になりそう
# サーバ本体よりはラック上ルータが通信ブッツリ切ってもいいかも > 緊急時温度のときは
M-FalconSky (暑いか寒い)
Re:サードパーティー製 (スコア:1)
>パフォーマンスを低下させてでも、止まらないようになっていると嬉しいかなぁ。
処理パフォーマンス低下させると、IOリクエストに対応しきれなくて結局ロックアウトしそうですね。
Re:サードパーティー製 (スコア:1)
HPEの一般市場向けサーバーについてはデフォルト設定では以下の温度(いずれも摂氏)で警告/シャットダウンです。
●室温(を計っているセンサー):42度/50度
●CPU:70度/(搭載CPUの限界温度)
●マザーボード115度/120度
データセンター専用設計にしているとしても基本的にはあまり変わらないでしょうから、室温50度が限界かなと。
パフォーマンスはぎりぎりまで落として排熱量を減らすとしても限界があるので、AWSレベルでは冷房停止時は30分も持たないでしょう。
#ちなみにたいていのメーカーのサーバーの動作保証室温は5度-35度です。このレンジ外すと保証対象から外れます。冷却は十分に考慮しましょう。
Paypalと空目した (スコア:0)
ので、paypalにログインして問題ないじゃんと思った(笑)
一方、NTTドコモのシェアサイクルは「原因調査中」のメールを見た瞬間に「AWSか!」と反応。
※なぜそうなるのか?
Re:Paypalと空目した (スコア:1)
ゲームぐらいならともかく、PayPayみたいなシステム組むなら別リージョンにわけた冗長化するのが常識じゃないの?
7pay程じゃないにせよ、ナントカPay業界って、雑魚いアーキテクチャにしなきゃいけない縛りでもあるんだろうか。
Re:Paypalと空目した (スコア:2, すばらしい洞察)
まあPayPayというかバーコード決済なんて消費者にとってはポイント還元率のみがメリットで、そのために現金と同等の面倒くささを許容して使ってるから。
稀に起きる障害のために金をかけるくらいならバラ撒きキャンペーンの原資に回した方がみんなハッピーだろう。
Re:Paypalと空目した (スコア:1)
まったくもって同意。
障害が無くてポイントバックのあるpay >>> 障害が有ってポイントバックのあるpay >>>越えられない壁>>> 障害が有ろうがなかろうがポイントバックのないpay
Re:Paypalと空目した (スコア:1)
激同。ゲームやら他のアプリは、まあそこまで冗長性要求されてないんでしょ、で別に済む話だけど、PayPayだけは仮にも決済アプリなんだから、いざお会計となったときに使えませんでは困る。
別リージョンまでするかはともかく、せめてAWS推奨のマルチAZぐらいはしていてもらわないと。
Re:Paypalと空目した (スコア:1)
マルチリージョンは真面目に設計しないと結構しんどいけど、
マルチAZはそんなに難しくないのにね。
Re: (スコア:0)
PayPayのシステムはインド企業のものがベースなので、コスト優先なのかも。
Re: (スコア:0)
牛が引いて動かしてんの?
Re:Paypalと空目した (スコア:1)
零戦作ってるんじゃないんだから。
部門名、正しいな (スコア:0)
>設備系はなかなか予想しづらいところ 部門より
たしかに、空調設備の管理システムに生じた傷害は予想しづらいな。事件じゃん。
#傷害が生じる空調設備、とは。
#大勢のおっちゃんが風車まわしてるのかな
Re:部門名、正しいな (スコア:4, おもしろおかしい)
♪力と技の風車が回る
// 父よ母よ妹よ〜
死して屍 拾う者なし
Re:部門名、正しいな (スコア:1)
むしろ空調を大切断
Re: (スコア:0)
大勢の設備おっちゃんに送風逆回転してくれとか、室温計ありったけ
出せとか、警備のおっちゃんにあけっぱのドアみはっててくれとか、
掃除のおばちゃんに扇風機ありったけ貸せとか頼みまくって復旧に
10時間翻弄されたおれが通りますよ。 チラーのマイコンが壊れちゃ
ってねー。
Re: (スコア:0)
はーたらけー!
ってムチで打つんですよ。
冷却システムは手動操作できなかったの? (スコア:0)
手動操作できればすぐ復旧できたように読める。
Re:冷却システムは手動操作できなかったの? (スコア:2)
主導で操作という決断が誰にもできないとか
// あなたの会社は、誰が決めるの?
// 石原さとみさんで。
死して屍 拾う者なし
Re:冷却システムは手動操作できなかったの? (スコア:2)
ご教示、ありがとうございます。
パージ(追い出し)というネーミングから、(強制)空冷みたいなものかと想像してます。
ボイラの未燃ガス排出(プレパージ、ポストパージ)的な。
死して屍 拾う者なし
Re: (スコア:0)
強制運転ボタンが付いたビル用エアコン見たことあるか?
そもそも強制運転ボタンの存在とか知ってる?
Re:冷却システムは手動操作できなかったの? (スコア:1)
水冷式のAHUをPLCで遠隔制御だろうから、ファンの回転数と水の流量を機械室のAHUに行って1台ずつ手動設定する感じかな?
家庭用エアコンのようにお手軽ではない
あべいらびりてぃぞぉん (スコア:0)
どうしてアマゾンはデータセンターって言わないの?
Re:あべいらびりてぃぞぉん (スコア:1)
他社の件だが、1つのAZはさらに複数個所のDCで構成されてます、と。
というか、AWSのAZの説明にも書いてある [amazon.com]じゃないか。
Re: (スコア:0)
元はIBMあたりの用語じゃない?
傷害→障害 (スコア:0)
△傷害
○障害
Re:冷却システムの故障? (スコア:2)
AWSを使うメリットは、サービスが止まらないことじゃなくて、
もしサービス停止しても、
『AWSが止まったなら仕方ない』と顧客が思ってくれること。
だと思う。
もちろん、サービスのジャンルとか内容にもよるけどな。
Re:冷却システムの故障? (スコア:1)
肝を冷やしました
Re:冷却システムの故障? (スコア:1)
ほとんどの技術者はAWSなら100%安心なんて考えてないですよ。
予算を握っている部門が冗長構成の予算を渋っただけの話です。