![](https://cdn-ak-scissors.b.st-hatena.com/image/square/6ef2f286e1afc4a8b0fc34321b383c822fd13bce/height=288;version=1;width=512/https%3A%2F%2Fwww.publickey1.jp%2F2021%2Fslack2021jan_outage.gif)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント16件
- 注目コメント
- 新着コメント
![NOV1975 NOV1975](https://cdn.profile-image.st-hatena.com/users/NOV1975/profile.png)
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
Slack、1月の大規模障害の原因を説明。「AWS Transit Gateway」がトラフィックの急上昇に対応できず、AWSはアルゴリズムを見直すと
Slack、1月の大規模障害の原因を説明。「AWS Transit Gateway」がトラフィックの急上昇に対応できず、AW... 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
2021/02/10 リンク