はじめに
ビジネスチャットで有名なSlackに昨夜(2018/6/27)接続障害が起こっていたそうです。現在は復旧していますが、状況をまとめておきます。
状況
2018年6月27日 22時33分(日本時間)に世界的に接続障害が発生。現象は同28日1時49分に復旧しました。原因は公開されていません。
Slackからのレポート
下記に時系列がSlackから発表されています。
https://status.slack.com/2018-06-27
時系列(日本語訳)
私たちは問題を切り分けたので、ワークスペースが再び接続できるはずであることを報告できてうれしいです。一部の人は、リフレッシュする必要があるかもしれません(Ctrl + RまたはCmd + R)。それでも問題が解決しない場合はfeedback@slack.comまでご連絡ください。
1:49 JST
問題を切り分け、接続を再開するための作業が進行中です。ご辛抱いただきましてありがとうございます。
1:33 JST
私たちは解決策に近づいていますが、まだ完全に解決できたわけではありません。
1:03 JST
ありがとうございます。私たちはこれがあなたの一日の大きな混乱であることを知っています。私たちは、この問題に対して全力で対応し正常に戻します。
0:33 JST
私たちはまだ新しい情報を共有することはできませんが、私たちは引き続き努力しています。あなたの忍耐は本当に感謝しています。
0:03 JST
我々は、人々に影響を与えている接続の問題を解決するために引き続き作業しています。私たちは、問題をできるだけ早く解決することを願っています。
23:33 JST
私たちのチームは引き続き接続問題の原因を検討しており、今後も進捗状況をお知らせします。
23:03 JST
私たちは、すべてのワークスペースがSlackに接続することが難しいという報告を受けました。現在、問題を調査しており、間もなく更新が予定されています。
22:33 JST
Slackのインフラ
SlackはAWSとGoogle(おそらくGoogle Cloud)を利用しているという記載があります。
ただ、SlackがAWSのUS-EAST-1(米国東部:バージニア北部)リージョンを利用しているのは間違いありません。過去、上記リージョン障害のときにSlackは影響を受けています。ただ今回は、AWSでの異常は何も認められないため、AWSのインフラの問題では無さそうです。
もっと深堀してみます。slackを使うと自分のワークスペースのためのURLが与えられます。例えば、https://aaaaa.slack.comというURLです。このaaaaa.slack.comというURLに紐づけられたIPアドレスを調べていくと、AWS cloudfrontというCDNで配信されていることが分かります。
結論としては、サーバー自体はアメリカのリージョンにあり、CDNにて世界へ配信しているというインフラ構成になります。したがって、サーバーの異常により世界同時に障害が発生しても不思議ではないと思います。
SlackのSLA(サービスレベルアグリーメント)
Slackは、サービスレベルアグリーメントを公開しています。
・Slack のサービス品質保証契約 (SLA) は、プラスプラン以上を利用するお客様に、月間99.99%のアップタイムを保証します。1
・Slack の SLA は、Slack 稼働状況 ページに公表した情報を基に、明確でシンプルな内容に作成されています。
・アップタイムが保障されている99.99%を下回った場合、プラスプラン以上を利用するお客様に、Slack を利用できなかった時間分のワークスペース料金の100倍を金額を払い戻しいたします。
かなり良心的とは思いますが、99.99%を上回ることを約束しているわけではないことを注意してください。返金されることと、可用性向上には直接の関係はありません。可用性の低下に直接財務上のリスクを負うことで中の人が真剣に可用性向上に向き合っているという姿勢を表しているという意味になります。
考察
今回は、日本は深夜時間帯だったのであまり話題にはなっていませんが、日中時間帯であれば騒ぎになっていたでしょう。
Slackはだんだん社会インフラ化してきています。
ビジネスコラボレーションツール「Slack」は、2017年11月に日本語版を公開。日本では現時点で50万人以上の日間アクティブユーザーがおり、Slack全体では世界第2位の規模。その中の15万人以上が有料プランユーザーだ。都道府県別で見ると、東京都だけで30万人以上のユーザーがいるという。
この記事が出た直後に今回の障害なので、Slackに業務を完全に依存することは、リスクになることをおさえなければいけません。
もちろん、Slack System Statusを見る限り、99.8~100%の可用性を保っているのですが、もし業務上の大切なタイミングで数時間でも停止したら大きな影響を受けることはあり得る話です。
クラウドサービスを利用することを標準化する場合、そのクラウドサービスが使えなかったときの対応まで標準化することがリスクマネジメントにつながると思います。アウトソーシングすればリスクが移転できると考えてしまうのは罠です。移転したと思った先でリスクが発現したときに、それが許容できるのか今一度考える必要があります。Slackの回避先が電話、メールだと、大混乱すること必至です。
追記 2018/7/2 8:45
原因が公開されています。日本語にて翻訳しておきます。
お客様の忍耐に感謝します。
すべてがバックアップされ、実行されているので、何が起こったかの概要を伝えたいと考えました。
6月27日22時33分から28日1時49分までスラックは、ユーザーがワークスペースに接続できなかい障害を経験しました。ネットワークの問題がデータのオフラインバッチ処理に含まれるバグによって引き起こされ、予期せぬネットワークの急増を招き、すべての顧客が切断され、再接続できなくなりました。
問題を特定した後新しい接続を制限し、余分な容量をプロビジョニングしました。午前1時24分にサービスは制限され、1時44分までにはすべての顧客が再びスラックに再接続しました。
Node.jsとPythonを使ったSlack API 活用術 - チャットボットの活用で仕事効率化