Slack、1月の障害の原因を説明　「AWS Transit Gateway」がトラフィックの急上昇に対応できず

公開 2021年02月12日 19時39分

更新 2021年02月12日 07時36分

[ITmedia]

印刷する

この記事は新野淳一氏のブログ「Publickey」に掲載された「Slack、1月の大規模障害の原因を説明。「AWS Transit Gateway」がトラフィックの急上昇に対応できず、AWSはアルゴリズムを見直すと」（2021年2月10日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。

　米Slack Technologiesは、日本時間1月4日の深夜から1月5日かけて発生した大規模障害についての詳細説明をブログ「Slack’s Outage on January 4th 2021」で行いました。

AWSのネットワーク基盤の一部が飽和していた

　1月4日、サービス内部のエラー率上昇によって始まったSlackの障害は、太平洋標準時の午前6時ごろからはSlackのWeb層の負荷が高まり、パケットロスを発生しはじめるなど徐々に深刻化。7時ごろにはついにサービス停止にまで発展してしまいます。

　負荷の解消のためにWeb層をスケールアウトさせるなどの対処を行い、なんとかサービスが復旧し始めたころに、AWSから障害の引き金となった現象についての報告が次のようになされたとのこと。

　「Slack’s Outage on January 4th 2021」から引用します。

By the time Slack had recovered, engineers at AWS had found the trigger for our problems: Part of our AWS networking infrastructure had indeed become saturated and was dropping packets.

Slackが復旧するころには、AWSのエンジニアたちが障害を引き起こした事象を発見していた。AWSのネットワーク基盤の一部が飽和しており、パケットをドロップしていたのだ。

　SlackはAWSの上で構築されています。しかもAWS上で複数のVPC（Virtual Private Clouds）を用いており、それぞれのVPCはAWSのマネージドサービスであるAWS Transit Gatewayを通じて相互に接続されていました。

　Slackを構成するVPCを相互に接続するAWS Transit Gatewayが飽和していたというのです。

AWSのエンジニアがマニュアル操作で対応

　AWSのエンジニアはこれに関するアラートを受け取り、手動操作でキャパシティーを増やして対応しました。

Our own serving systems scale quickly to meet these kinds of peaks in demand (and have always done so successfully after the holidays in previous years). However, our TGWs did not scale fast enough. During the incident, AWS engineers were alerted to our packet drops by their own internal monitoring, and increased our TGW capacity manually. By 10:40am PST that change had rolled out across all Availability Zones and our network returned to normal, as did our error rates and latency.

私たち自身のサービスはピークに合わせて迅速にスケールしていた（これまでも連休後の対応はいつもうまくいっていた）。しかし、私たちが利用していたAWS Transit Gatewayが十分にスケールしてくれなかったのだ。

この事象が起きたときに、AWSのエンジニアはこのパケットドロップに関するアラートを内部モニタリングシステムから受け取とり、手動でキャパシティーを増やした。太平洋標準時10時40分までにこの変更が全てのアベイラビリティゾーンに適用され、ネットワークは通常の状態に戻り、エラーレートとレイテンシも戻った。

AWS Transit Gatewayのアルゴリズムを見直す

　AWSは今回のインシデントを受けて、AWS Transit Gatewayのアルゴリズムを見直すとのこと。

AWS assures us that they are reviewing the TGW scaling algorithms for large packet-per-second increases as part of their post-incident process. We’ve also set ourselves a reminder (a Slack reminder, of course) to request a preemptive upscaling of our TGWs at the end of the next holiday season.

AWSは、秒あたりのパケットが急激に増加する際のAWS Transit Gatewayのスケーリングアルゴリズムの見直しを、インシデント発生後のプロセスの一環として行っていると確約した。また、私たちが次のホリデーシーズンの終わりにはAWS Transit Gatewayのアップスケーリングをあらかじめリクエストするようにリマインダー（もちろんSlackのリマインダー）を設定した。

　Slackの今回の障害は、Slack自身ではコントロールできないAWSのマネージドサービスにおける問題がきっかけでした。これは（規模は違えども）一般のAWSユーザーにおいても何らかの形で起こりうることでしょう。

　そうなればユーザー側にできることはそれほど多くありません。できるだけ迅速に問題を発見し解決を図るため、きめこまかなシステムのモニタリングと問題の切り分けなどが重要になるのではないでしょうか。

印刷する