Slack、全ユーザーが接続できなくなった大規模障害の原因はバッチ処理にバグがあったためと報告
チャットサービスを提供するSlackは、太平洋夏時間の6月27日午前6時30分（日本時間6月27日午後10時30分）頃から約3時間、全てのユーザーでSlackが利用できなくなる深刻な障害に見舞われました。
同社はその後、障害についての報告をステータスページに掲載。障害の原因が、データのバッチ処理に含まれていたバグであったことを明らかにしました。
同社の報告の一部を引用します。
On June 27th (yesterday) between 6:33 a.m. and 9:49 a.m. PDT Slack experienced an outage where people could not connect to their workspaces. The network problems were caused by a bug included in an offline batch process of data, which resulted in unexpected network spikes and led all of our customers to become disconnected and unable to reconnect.
6月27日（昨日）の太平洋夏時間午前6時33分から午前9時49分のあいだ、Slackにおいてユーザーがワークスペースに接続できなくなる障害が発生しました。このネットワーク障害は、オフラインバッチによるデータ処理に含まれるバグによるものでした。これが予期せぬネットワークのスパイクを引き起こし、全ユーザーへの接続断と再接続障害の原因となりました。
オフラインバッチ処理がどのようなものかは説明されていません。定期的なバックアップあるいはデータ分析に伴う前処理かなにかだったのでしょうか。
半年前にも数時間にわたる大規模障害
Slackは、約半年前の2017年11月にも全ユーザーが2時間以上Slackに接続できなくなる大規模障害が発生しています。
このときは定期デプロイによってサーバにデプロイされたソフトウェアに含まれていたバグが原因で障害が発生し、復旧のために急きょハードウェアの増強を行ったことが報告されています。
前回も今回も共通しているのは、何らかのソフトウェアのバグが原因であることと、その影響が全ユーザーに影響する深刻な障害に結びついていることです。
Slackはちょうど先週、日本への本格展開を宣言したばかりのタイミング。障害の発生を完全に防ぐことはできないにしても、できるだけ局所的に押さえ込むような仕組みにしてほしいところです（と書くのは簡単でも、実現するのは容易ではないと思いますが）。
あわせてお読みください
- 国内PaaS市場、シェア1位はセールスフォース・ドットコム、2位Amazonクラウド、3位マイクロソフト。年平均30％以上の成長が続く。IDC Japan
- ［速報］Amazon Aurora発表。MySQL互換で性能5倍、商用リレーショナルデータベースと同等の機能を提供するマネージドなデータベースサービス。AWS re:Invent 2014
- ［速報］マイクロソフト、「.NET server framework」のLinuxとMacOS X用オフィシャルディストリビューションを発表。.NETアプリケーションのビルド、実行が可能に
- ノイジーネイバーを遮断する新型コンテナ「Hyper-V Container」をマイクロソフトが発表。Windows Server上の新しいコンテナ実装
- カテゴリ 業務アプリケーション / Office
- タグ Slack
≪前の記事
「MongoDB 4.0」正式リリース。マルチドキュメントに対するACIDトランザクションをサポート
Junichi Niino（jniino）
