Slack、セルラーアーキテクチャへ移行

• Slackは過去1年半にわたり、冗長性を高め、サイト障害の影響を限定するため、単一構成からセルベースの構成（Cellular Architecture）へ移行
• 2021年6月のネットワーク障害によりSlackの顧客にサービス低下が発生した事案を受け、Slackサービスのレジリエンス向上の必要性に後押しされたもの
• セルラー構成では、各サービスが可用性ゾーン（AZ）ごとに1つの仮想サービスとして動作するため、あるAZでの障害が他のAZに影響しない
• 問題のあるAZからトラフィックをドレインする機能も含まれており、それをシステムの他の部分から効果的に隔離
• ドレインのメカニズムは、高速で、エラーがなく、段階的で、ドレイン対象AZのリソースに依存しないよう設計
• セルラー構成への移行にはサイロ化（Siloing）という戦略も含まれ、サービスが自分のAZ内でのみトラフィックを受信・送信するようにした。これは単一AZ内のあらゆる障害を封じ込めるのに役立つ
• トラフィック移動メカニズムの実装は、ユーザーのクエリを中核サービスへルーティングするシステムに重点を置いた
• 新しい構成は、Envoyの機能であるweighted clustersと、RTDSによる動的な重み付け割り当てを活用してAZドレインをサポート
• この移行はSlackの運用方法とサービス構築方法を変え、トラフィック管理と障害緩和のための強力な新しいツールを提供
• 今後のブログ記事で技術実装の詳細をさらに深く扱い、新しい構成がSlackの運用にどのような影響を与えたかを議論する予定

[GN⁺]

Hacker Newsの意見

• Slackのセルラーアーキテクチャへの移行は、その独特な運用および監視アプローチのため注目を集めました。
• 同社の戦略は、単一のAWSアベイラビリティゾーン（AZ）内でリクエストを完結させ、運用を簡素化し、監視を容易にすることです。
• このアプローチにより、クラスター間でメトリクスを比較することで、単一クラスターでのインシデントを容易に検知し緩和できます。
• しかしこの戦略では、ほとんどのサービスを複数クラスターで実行する必要があるため、コンピュートやキャッシュなどで重複が発生します。
• 一部のユーザーは、SlackのAPIリクエストシステムの効率性に疑問を呈しており、これはサービスバックエンドに対して数百のRPCへファンアウトする可能性があります。
• AWSのアベイラビリティゾーンアフィニティを使うことと、上位のルーティングポイントでダウンしたAZを単に切り離すことの違いをめぐる議論があります。
• AWSのUSE1ですべてを実行することの冗長性に対する懸念が示されており、USE1に関連する問題が複数のサービスに影響を及ぼす可能性があります。
• このアーキテクチャでユーザーデータがどのように処理されるのか、特にAZ障害時について疑問が提起されました。
• 一部のユーザーは、過去に携わった類似アーキテクチャ、たとえばMetal Cellという分散オペレーティングシステムを回想しています。
• 新たなユーザーリクエストが到着しなくても、リソースを大量消費するジョブが分離されたAZで無期限に実行され続ける可能性という問題について議論があります。
• ユーザーたちは、現在のSlackがどのプログラミング言語で書かれているのか、今でもHack/PHPなのかを気にしています。
• 一部のユーザーはSlackのパフォーマンスに失望を表明し、Discordのような他のチャットアプリと比べて見劣りすると述べています。