Slackは過去1年半の間に、重要なユーザー向けサービスの大半をモノリシックからセルベースのアーキテクチャに移行した。この移行は、単一のアベイラビリティ・ゾーンに影響を及ぼすネットワーク停止の影響により、ユーザーに影響を与えるサービス低下が引き金となった。新しいアーキテクチャでは、5分以内に影響を受けたアベイラビリティゾーンからすべてのトラフィックを段階的に排出できる。
Slackはグローバルにインフラを展開しているが、コアプラットフォームは米国東海岸地域（us-east-1）でホスティングされている。同社は障害隔離のためにアベイラビリティ・ゾーン（AZ）を使用しているが、それでも断続的な問題によって分散環境におけるコンポーネントの可用性の判断が困難になり、エンドユーザーに影響を与えるようなグレー障害の発生があった。2021年6月30日、AZの1つでネットワーク機器に断続的な障害が発生した。
SlackのシニアスタッフエンジニアであるCooper Bethea氏は、分散システムにおける障害検知が問題となる理由をこう説明した。
結局のところ、分散システムでの障害検知は難しい問題だ。ユーザーからの1つのSlack APIリクエスト（例えば、チャンネルにメッセージをロードする）は、サービス・バックエンドへの数百のRPCに広がるかもしれない。我々のサービス・フロントエンドは継続的に失敗したバックエンドを検出し、除外しようと試みているが、失敗したサーバーを除外する前に、いくつかの失敗を記録しなければならない！
Slackのチームは、各AZが完全にサイロ化されたバックエンドのデプロイメントを含み、コンポーネントが単一のAZに制約されるセルベースのアプローチを採用を試みた。トラフィックは、Envoy/xDSを使用するレイヤーによって、AZにスコープされたセルにルーティングされる。サイロ化されたアプローチは、Slackのプラットフォームが多くの言語スタックとサービス・ディスカバリー・インターフェイスを使用する異機種混在型であるため、バックエンド・サービス間で複雑なルーティング・ロジックを導入するのは非常に面倒であることが動機となっている。
影響を受けるセルからトラフィックがルーティングされるサイロ化されたアーキテクチャ（出典：Slack Engineering Blog)
新しいアーキテクチャでは、設定変更が数秒以内に反映されるため、問題が発生しているセルからトラフィックを素早くシフトできる。トラフィックは徐々に（1％の単位で）、そして緩やかに（すべてのインフライト・リクエストは排出されるセルで完了する）シフトできる。
Slackの進路は、AWSが示したガイダンスに従っている。クラウドネイティブアーキテクチャシリーズでは、コンテナベースのコンピュートサービスを利用して、クラウドワークロードのスケーラビリティと回復力を向上させるためのさまざまなツールやテクニックを紹介している。AWSのアーキテクトは、ブラック・スワン・イベントに備え、予期せぬ障害の影響を最小化するために、クラウドアーキテクチャにおける強力な障害隔離境界を主張している。
EKSによるセルベースのアーキテクチャ（出典：AWS Architecture Blog）
Slackのセルベースアーキテクチャの採用は、コミュニティで大きな議論を呼んだ。賑やかなHNスレッドに寄せられた数多くのコメント（そのほとんどがややオフトピックだった）の中で、ユーザーのtedd4uはセルベースアーキテクチャは少なくとも10年前から存在していると指摘した。また、ignoreamousというユーザー（自称元AWS社員）は、セルベースアーキテクチャに関するガイダンスは、クラウドで回復力を提供するためのAmazon とAWS自身の取り組みに基づいていることを強調した。
最近、Roblox もセルベースアーキテクチャへの道のりと、プラットフォームの耐障害性をさらに向上させる将来計画を共有 した。