Slackは最近、新しいロール管理システムのソフトウェアアーキテクチャの詳細な説明を投稿した。Slackは、以前よりも柔軟なシステムを構築する必要があった。Slackは、カスタムコンテナ化されたGoベースのパーミッションサービスを開発した。これは、gRPCを介して既存のシステムと統合される。その結果、顧客の管理者は、ユーザが実行できることをきめ細かく制御できるようになった。
SlackのエンジニアであるJake Byman氏、Aish Raj Dahal氏、Jose M. Medina氏が、新しいロール管理システムを作成する動機について説明している。
私たちが顧客に提供した標準的な役割の種類は広すぎました。一般的な管理者の役割を委譲すると、誰かに過度の権限を与える可能性があります。特定のユーザだけが特定のチャネルを管理できるようにしたい場合はどうでしょうか。管理者にすると、意図した目的の範囲を超えてさまざまなアクションを実行できます。（...）より柔軟で、きめ細かいアクセス許可ができるシステムを構築する必要がありました。
Slackは、ロールベースのアクセス制御（RBAC）システムを作成することを選択した。このシステムでは、管理者がロールを定義する。ロールは、システム内のアクションに対するアクセス許可の集合である。次に、特定のコンテキストまたはエンティティ（組織、ワークスペースなど）でこれらのロールの1つ以上をユーザに付与する。Slackは、ユーザがアクションを実行するときに、パーミッションサービスを使って常にアクセス許可チェックを行い、ユーザがそのアクションを実行できることを確認する。
一方、Slackクライアントでの表示は、アクセス許可セットのコピーで権限のないものをベースとしている。バックエンドでは、このアクセス許可セットをSlackのフランネルエッジキャッシュに保持し、ほぼリアルタイムで更新する。クライアントは、低遅延にするための最適化として、このキャッシュからアクセス許可情報を読み取る。
出典: https://slack.engineering/role-management-at-slack/
下位互換性は、slackエンジニアにとって重要な考慮事項であった。このアクセス許可システムをデプロイする方法について、ユーザを混乱させるリスクを減らすために、Slackのエンジニアは段階的なデプロイ方法を選択した。まず、SlackのWebアプリ内にあるループバックgRPCサービスを作成した。彼らはこの変更を社内のワークスペースに展開し、次にパイロット顧客に展開した。
この変更が安全であることが確認されると、実際の外部サービスから「ダークモード」で読み取りを開始した。このモードでは、新しいサービスと既存のWebアプリの両方からアクセス許可チェックの結果を読み取るが、新しいサービスの結果は使わない。結果が一致しなかった場合は、さらに調査できるようにアラートが表示される。新しいサービスに十分に納得できたら、「ライトモード」での読み取りに切り替えると、その結果が唯一の信頼できる情報源として使われる。
ロール情報はVitessデータストアに保持される。Slackのエンジニアは、「ウェブアプリのモノリスで使われているのと同じVitessストアからパーミッションサービスの読み取りと書き込みを行うことを選択した」と述べている。彼らは、単一の集中型データストアを持ち、データのドリフトを回避するという、この設計上の決定を下した。Vitessデータベースは、システム全体に対する信頼できる情報源として機能する。