パスワードを忘れた? アカウント作成
13989805 story
クラウド

AWS東京リージョンで大規模障害、原因は冷却システムの故障 103

ストーリー by hylom
設備系はなかなか予想しづらいところ 部門より

Anonymous Coward曰く、

8月23日の昼頃から数時間にわたり、クラウドサービス「Amazon Web Services(AWS)」の東京リージョンで大規模な障害が発生、多数の企業のサービスに影響が出るトラブルとなった(ITmediaITmediaの続報ASCII.jp日経xTECHEngadget日本版)。

AWSの東京リージョンは4つのデータセンター(アベイラビリティーゾーン)から構成されているとのことだが、Amazonの発表によると、そのうち1つで空調設備の管理システムに傷害が発生。その結果一定数のサーバーが過熱によって停止したという。冷却装置は15時21分に復旧し、その後18時半ごろには大部分のサーバーが復旧したという。

空調設備の管理システムは冗長化されていたが、管理システムのロジックにバグがあり、制御ホストの切り替え時に制御システムが応答しなくなる事態になったという。また、制御システムに傷害が発生した場合は冷却システムは最大冷却になるよう設計されていたが、データセンターの一部でこの構成に移行できず停止。さらに、問題になるデータセンターのエリアで冷却システムを「パージ」モードに切り替えて熱風を排出することを試みたものの、これも失敗したという。最終的に不具合のあった制御システムのリセットで対応を行ったという。

クラウドの普及によりAWSを使うサービスは多岐にわたっており、今回の障害では決済アプリのPayPayが使用できなくなったほか、dTVやローソンアプリ、Backlog、各種ソーシャルゲーム、果てはシェアサイクルの返却ができなくなるなど、大きな影響が出た模様である。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • AWS「ギャアアアア!」 (スコア:5, おもしろおかしい)

    by Anonymous Coward on 2019年08月26日 23時29分 (#3675660)

    GCP「AWSがやられたようだな」
    アリババ「奴はクラウド四天王の中でも・・・最強!」
    Oracle「やばいじゃん」
    IBM「つーか四天王って何人いるの」
    さくら「さくら大明神」

    だいたいこんな情景を妄想して遊んでたクラウド技術者は多いはず

  • by Anonymous Coward on 2019年08月27日 8時44分 (#3675752)

    Impressの記事が凄い良くまとまってたので、じゃあどういう構成にすべきかとか考えてる人に読んでもらいたい。

    AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか [impress.co.jp]

    重要なのは、「どのサービスがどのレベルの稼働率を維持しないといけないのか」という点だ。

    世の中には、絶対に落ちては困るサービスがある。消えては困るデータもある。

    一方で、費用対効果を考えると、数年に一度あるかないかの大規模障害に備える必然性はない、というサービスもあるはずだ。

    決済サービスとゲームで同じレベルを維持するのは、一般論でいって過剰だ。また同じサービスの中でも、課金やデータの保持に関わる部分と、告知に関わる部分、クーポンなどの提供に関わる部分とでは、必要な稼働率も異なるはずだ。

    クラウドを使うか使わないか、クラウドを使うとしてマルチリージョンやマルチAZなどの対策をどう使うかは、まさにシステム構築のポリシーとビジネス設計に関わる部分だ。そこを均質に語るのは現実的ではないし、そうすべきでもない。

    むしろ今回の件で注目すべきは、「落ちるべきではないサービスも障害で落ちている」点である。決済系や認証系サービスは、そうしたものの中に含まれるのではないか。落ちるとしても、「なぜ落ちているかをユーザーが理解できる」「重要性の低い部分は落ちているがコアな認証や支払いなどは落ちづらい」という仕組みが必要になる。

    • by Anonymous Coward on 2019年08月27日 10時08分 (#3675810)
      >決済サービスとゲームで同じレベルを維持するのは、一般論でいって過剰だ。
      そりゃ金の支払いなんかいくらでも待ってもらえばいいだけだけど、
      こっちは遊びでやってんじゃないからね。
      親コメント
    • サービス維持にお金をどれだけ出せるかですね。
      マルチリージョン化すると、リージョン数分のお金が必要になるし。

      >むしろ今回の件で注目すべきは、「落ちるべきではないサービスも障害で落ちている」点である。決済系や認証系サービスは、そうしたものの中に含まれるのではないか。

      金勘定関わると対策は必須ですよね、動画配信やゲームだと割り切りそう。

      親コメント
  • いや、セキュリティ上ヒミツなのはわかるけどアマゾンのデータセンターって大手町とかの結節点に近いとこにぶら下がってるのかな
    それとも幕張とかの土地が広く取れるとこに置いてるんだろうか

  • by Anonymous Coward on 2019年08月26日 23時22分 (#3675658)

    > 設備系はなかなか予想しづらい

    とはいえ、ニュースになる規模の大規模障害は意外と設備系だったりしますね。

    某社のUPS障害 [it.srad.jp]しかり、某社の自家発電障害 [srad.jp]しかり。

  • by jizou (5538) on 2019年08月27日 1時20分 (#3675684) 日記

    何度も繰り返して書かれているのが気になりますね...

    空調が止まるような状況になったときって、サーバーはどういう動きをするのが正解なんでしょう。
    パフォーマンスを低下させてでも、止まらないようになっていると嬉しいかなぁ。

    • by Anonymous Coward on 2019年08月27日 2時51分 (#3675694)

      1ラック10kW×100ラックとか当たり前のDCで空調が止まったら、室内温度が急上昇して冷却が追いつかなくなります。
      気密性が良ければ50℃~60℃とかに到達するかも・・・その前にサーバーが停止するでしょうけど。

      サーバーの冷却は冷却ファンでCPUのヒートシンクを通過した空気と、CPUとの温度差で冷却しますが、
      取り込む室内の空気の温度とCPUの温度との間に温度差が無くなると、いくらファンを回しても全く冷却できないのであとは停止するだけです。

      サーバーはどういう動きをするのが正解

      温度上昇の検知により、シャットダウン信号を入力して正常にシャットダウンするのが正解ではないでしょうか。

      止まらないようになっていると嬉しい

      止まらないようにするとしたら、強制冷却ではなく自然放熱で設計されていないと難しいでしょうね。
      データセンターほど高密度の環境では無理でしょう。

      親コメント
      • by bero (5057) on 2019年08月27日 21時45分 (#3676315) 日記

        >止まらないようになっていると嬉しい
        仮想マシンだったら動的マイグレーションして正常DC内PCに移動、ってのが理想だと思いますが、
        理論上その設計だが、複数マシンが一気に移動しようとしてどっかで詰まって、正常マシンまで動かなくなってマイグレーションしようとしてさらに詰まる、とかありそう

        親コメント
      • >> 止まらないようになっていると嬉しい

        > 止まらないようにするとしたら、強制冷却ではなく自然放熱で設計されていないと難しいでしょうね。

        外気温がCPU温度に追い付く前で、CPUを強烈にスロットリングする、があると嬉しいけど
        だとしてもまあ現実的じゃないだろうなあ...

        むしろ処理が間に合わない系とかネットワーク応答のタイムアウトで生き残るから、やっかいな問題になりそう
        # サーバ本体よりはラック上ルータが通信ブッツリ切ってもいいかも > 緊急時温度のときは

        --
        M-FalconSky (暑いか寒い)
        親コメント
    • >パフォーマンスを低下させてでも、止まらないようになっていると嬉しいかなぁ。

      処理パフォーマンス低下させると、IOリクエストに対応しきれなくて結局ロックアウトしそうですね。

      親コメント
    • by Anonymous Coward on 2019年08月27日 9時43分 (#3675790)

      HPEの一般市場向けサーバーについてはデフォルト設定では以下の温度(いずれも摂氏)で警告/シャットダウンです。
      ●室温(を計っているセンサー):42度/50度
      ●CPU:70度/(搭載CPUの限界温度)
      ●マザーボード115度/120度
      データセンター専用設計にしているとしても基本的にはあまり変わらないでしょうから、室温50度が限界かなと。
      パフォーマンスはぎりぎりまで落として排熱量を減らすとしても限界があるので、AWSレベルでは冷房停止時は30分も持たないでしょう。

      #ちなみにたいていのメーカーのサーバーの動作保証室温は5度-35度です。このレンジ外すと保証対象から外れます。冷却は十分に考慮しましょう。

      親コメント
  • by Anonymous Coward on 2019年08月26日 22時33分 (#3675629)

    ので、paypalにログインして問題ないじゃんと思った(笑)
    一方、NTTドコモのシェアサイクルは「原因調査中」のメールを見た瞬間に「AWSか!」と反応。
    ※なぜそうなるのか?

    • by Anonymous Coward on 2019年08月26日 22時47分 (#3675639)

      ゲームぐらいならともかく、PayPayみたいなシステム組むなら別リージョンにわけた冗長化するのが常識じゃないの?
      7pay程じゃないにせよ、ナントカPay業界って、雑魚いアーキテクチャにしなきゃいけない縛りでもあるんだろうか。

      親コメント
      • Re:Paypalと空目した (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2019年08月26日 23時50分 (#3675671)

        まあPayPayというかバーコード決済なんて消費者にとってはポイント還元率のみがメリットで、そのために現金と同等の面倒くささを許容して使ってるから。
        稀に起きる障害のために金をかけるくらいならバラ撒きキャンペーンの原資に回した方がみんなハッピーだろう。

        親コメント
        • by Anonymous Coward on 2019年08月27日 0時06分 (#3675676)

          まったくもって同意。

          障害が無くてポイントバックのあるpay >>> 障害が有ってポイントバックのあるpay >>>越えられない壁>>> 障害が有ろうがなかろうがポイントバックのないpay

          親コメント
      • by Anonymous Coward on 2019年08月27日 8時23分 (#3675741)

        激同。ゲームやら他のアプリは、まあそこまで冗長性要求されてないんでしょ、で別に済む話だけど、PayPayだけは仮にも決済アプリなんだから、いざお会計となったときに使えませんでは困る。
        別リージョンまでするかはともかく、せめてAWS推奨のマルチAZぐらいはしていてもらわないと。

        親コメント
      • by Anonymous Coward

        PayPayのシステムはインド企業のものがベースなので、コスト優先なのかも。

  • by Anonymous Coward on 2019年08月26日 22時37分 (#3675632)

    >設備系はなかなか予想しづらいところ 部門より

    たしかに、空調設備の管理システムに生じた傷害は予想しづらいな。事件じゃん。
    #傷害が生じる空調設備、とは。
    #大勢のおっちゃんが風車まわしてるのかな

    • Re:部門名、正しいな (スコア:4, おもしろおかしい)

      by JN1RNY (48245) on 2019年08月26日 22時52分 (#3675644) ホームページ 日記

      ♪力と技の風車が回る

      // 父よ母よ妹よ〜

      --
      死して屍 拾う者なし
      親コメント
    • by Anonymous Coward

      大勢の設備おっちゃんに送風逆回転してくれとか、室温計ありったけ
      出せとか、警備のおっちゃんにあけっぱのドアみはっててくれとか、
      掃除のおばちゃんに扇風機ありったけ貸せとか頼みまくって復旧に
      10時間翻弄されたおれが通りますよ。 チラーのマイコンが壊れちゃ
      ってねー。

    • by Anonymous Coward

      はーたらけー!
      ってムチで打つんですよ。

  • by Anonymous Coward on 2019年08月26日 22時51分 (#3675642)

    手動操作できればすぐ復旧できたように読める。

  • by Anonymous Coward on 2019年08月26日 23時08分 (#3675653)

    どうしてアマゾンはデータセンターって言わないの?

  • by Anonymous Coward on 2019年08月26日 23時32分 (#3675663)

    △傷害
    ○障害

typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...