Slack、1月の大規模障害の原因を説明。「AWS Transit Gateway」がトラフィックの急上昇に対応できず、AWSはアルゴリズムを見直すと

Slack、1月の大規模障害の原因を説明。「AWS Transit Gateway」がトラフィックの急上昇に対応できず、AWSはアルゴリズムを見直すと AWSのネットワーク基盤の一部が飽和していた 1月4日、サービス内部のエラー率上昇によって始まったSlackの障害は、太平洋標準時の午前6時ごろからはSlackのWeb層の負荷が高まり、パケットロスを発生しはじめるなど徐々に深刻化。7時頃にはついにサービス停止にまで発展してしまいます。 負荷の解消のためにWeb層をスケールアウトさせるなどの対処を行い、なんとかサービスが復旧し始めたころに、AWSから障害の引き金となった現象についての報告が次のようになされたとのこと。 「Slack’s Outage on January 4th 2021」から引用します。 By the time Slack had recovered, engineers

[NOV1975]

これをリスクと捉えるのか「手動でキャパシティを増やした」で迅速に対応されてすげーと捉えるのか。後者と考えたほうが幸せ。オンプレで類似の事象が起きたときにこの速さで解決するとは到底思えない。

[mysql8]

GCPにしとけとあれほど言ったのに...

[katzchang]

“できるだけ迅速に問題を発見し解決を図るため、きめこまかなシステムのモニタリングと問題の切り分けなどが重要になる”

[iekusup]

ほー。

[shinyapple]

“and”

[gomer-pyle]

処理してる負荷の量を考えると高給なのも頷けるわな

[momonga1123]

もうなんでもAWSだな GAFAの影響力を改めて感じる

[k-saiki]

Transit Gatewayとか使ってるの意外だった。

[i43s]

“AWSのエンジニアはこのパケットドロップに関するアラートを内部モニタリングシステムから受け取とり、手動でキャパシティを増やした”

[m50747]

便利なインフラサービスは自分のところのサービス規模に応じて止めるのも判断だよな。大変だけど。Amazonのせいだと客は納得できない。

[iwanofsky]

これ、VPC間のピア接続になるようにちゃんとアドレス設計してたら（まぁそこまで計画的にするのが無理なんだろうが）どうだったんかなぁ。

[helldeath]

AWSもこの失敗を糧にするだろう。

[vesikukka]

TransitGatewayは便利だけど、そんなリスクがあるのね。まあ自分の担当範囲では知れているけど。

[boxshiitake]

slackの負荷にawsが耐えられなかったか

[reiki4040]

AWS側の要因だったんだ