# Slack Technologies ## 概要 Slack Technologies はクラウドベースのビジネスコミュニケーションプラットフォームを開発・運営する企業（現 Salesforce 傘下）。数百万人のユーザーが利用する SaaS として、高度な信頼性要件のもと大規模なオブザーバビリティインフラを運用してきた。 本 wiki では 2020 年 5 月 12 日の完全サービス停止インシデント（48 分間のアウテージ）を経験から、MELT(Metrics/Events/Logs/Traces)データ管理の産業事例研究の主題として登場する([[@2021__SIGMOD Record__Towards Observability Data Management at Scale]])。 2018年9月には自己誘発型の障害が連続する「reliability crisis」に見舞われ、これを契機にリリースツール刷新(Deploy Commander 制・段階的カナリアロールアウト)・Service Ownership 移行・Incident Management プログラム構築の3本柱の改革を行った([[Brent Chapman]]、[[@2021__SREcon21__Evolution of Incident Management at Slack]])。 同じ2020年5月12日のアウテージは、[[Suman Karumuri]] が共著者に加わったメトリクスストレージエンジン論文 [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]] の冒頭でも、オブザーバビリティの重要性を示す事例として言及されている。同論文は Slack が1日あたり40億のユニークソースから毎秒1200万サンプルを収集し、最大12TBの圧縮データを生成するという規模感を、大容量メトリクスストレージの動機として引用する。 2018 年初頭からは、[[Richard Crowley]] が考案した障害注入の演習プロセス「惨劇シアター(Disasterpiece Theater)」を実運用している。開発環境で成功した演習のみ本番環境へ進むという段階的ゲート、専用チャンネル(#disasterpiece-theater)でのアナウンス、書記担当による記録という手順で 20 回以上の演習を重ね、Memcached のインスタンス入れ替えにおけるキャッシュ非一貫性バグや、社内システム Confabulator の緊急モードにおけるタイムアウト欠如バグなどを本番影響が出る前に発見してきた([[@2022__OReillyJapan__カオスエンジニアリング - Chapter 4 Slackの惨劇シアター]])。 ## 代表的な規模感(2020 年時点) - Metrics: 4B 時系列/日、12M samples/秒、12TB/日(圧縮)、30 日保持 - Events: 250TB/日(生)、70PB 超を蓄積、3〜24 ヶ月保持 - Logs: 90TB/日(生)、7 日保持 - Traces: 2TB/日(生)、14 日保持 - Prometheus プール約 100 運用、20 超のソフトウェアコンポーネント ## 関連 - 関係者: [[Suman Karumuri]] / [[Richard Crowley]] - [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 4 Slackの惨劇シアター]] — 惨劇シアター(Disasterpiece Theater)プログラムの一次記録 - 概念: [[カオスエンジニアリング]] ## 出典 - [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]](§3 Observability at Slack) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 4 Slackの惨劇シアター]](Richard Crowley 本人の記録)