コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第150回　Googleのサービス群を支える認証システム：Zanzibar（パート1）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第150回　Googleのサービス群を支える認証システム：Zanzibar（パート1） (中井悦司) 2023年5月

はじめに

　今回からは、2019年に公開された論文「Zanzibar: Google's Consistent, Global Authorization System」に基づいて、Googleのサービス群を支える認証システム「Zanzibar」を紹介していきます。カレンダー、ドライブ、YouTube、そして、Google Cloudなど、Googleが提供するサービスは、Googleアカウントによるシングルサインオンの機能が提供されており、ドライブに保存したファイルやGoogle Cloudで使用する計算リソースなど、さまざまなリソースに対して、個別にアクセス権限を設定することができます。Zanzibarは、これらのアクセス権限の情報を保存するバックエンドシステムで、上述のようなさまざまなサービスが共通に利用しています。この論文では、Zanzibarのアーキテクチャーが解説されており、アクセス権限の情報を取り扱う上で求められるデータの一貫性と、膨大な情報を取り扱うためのスケーラビリティを両立する工夫が紹介されています。

Zanzibarの設計目標

　上述のように、Zanzibarは、Googleのさまざまなサービスにおけるアクセス権限の管理に使われており、論文公開時点で、1兆件を超える権限レコード（ACL）が登録されており、1秒間に数百万件の認証リクエストを処理しています。リクエストの応答時間は、95パーセンタイルで10ミリ秒以下を実現しています。また、このような高いスケーラビリティを実現するだけではなく、認証システムとして求められる処理の正確性も担保する必要があります。そして、複数のサービスから共通に利用するシステムのため、さまざまなタイプのアクセス権限に対応する柔軟性も必要です。つまり、スケーラビリティ、正確性、および、柔軟性を同時に実現することが、Zanzibarの設計目標となります。
　柔軟性については、比較的シンプルなデータモデルをベースにして、設定言語によって、Zazibarを利用するサービスごとに、使用するデータの構成がカスタマイズできるようになっています。正確性については、強い整合性を持ったトランザクションが可能なデータベースであるSpannerをバックエンドとして、タイムスタンプを用いて処理の前後関係を正しく取り扱う仕組みを採用しています。この点の詳細は次回以降に説明することにして、ここではまず、データモデルと設定言語の概要を説明します。

ACLの基本構成

　Zanzibarが保存するのは、「何に対して（object）」「どのような関係・権限を（relation）」「誰が持つのか（user）」という関係を表す、「<object>#<relation>@<user>」という形式のレコード（ACL）です。<object>の部分は、より詳しくは「<namespace>:<object_id>」という形式になっており、Zanzibarを使用するクライアント（サービス）ごとに独自の名前空間（namespace）を持つことができます。使用する<relation>は名前空間ごとに定義しますが、典型的には、「owner（所有者）」「editor（編集者）」「viewer（閲覧者）」などが用いられます。<user>の部分は、Googleアカウントに対応するユーザーID、もしくは、ユーザーグループ（userset）を指定します。この際、ユーザーグループの構成もACLとして定義します。具体的には、<object>にユーザーグループ名、<relation>に「member」を指定したACLを用いて、「group:eng#member@11」のように表現します。これは、「ユーザー"11"はグループ"group:eng"に所属する」という意味になります。論文内では、図1のような例が紹介されています。

fig01

図1 Zanzibarが保存するACLの例（論文より抜粋）

relationの個別定義

　先ほど、使用する<relation>は名前空間ごとに定義すると説明しました。「owner」「editor」「viewer」などが具体的にどのような権限を持つのか（指定のobjectに対してどのような操作ができるのか）は、Zanzibarを使用するサービス側で実装することになりますが、それとは別に、「ownerはeditorとviewerの権限を含む」といったrelationごとの「親子関係」を定義できると便利な場合があります。これは、Zanzibar側で設定することができて、名前空間ごとの設定ファイルを使用して、明示的に記録されたACLから、新しいACLを演繹的に導くことができます。
　図2は、論文内で紹介されている設定例ですが、「すべてのownerはeditorにもなる」「すべてのeditorはviewerにもなる」という関係が定義されており、結果的に、「ownerはeditorとviewerの権限を含む」という前述の関係が実現されます。また、この設定ファイルでは、「親フォルダーのviwerは、フォルダー内のファイルのviewerでもある」という関係も定義されており、サービスごとのユースケースに合わせた柔軟な設定ができることがわかります。

fig02

図2 名前空間ごとの設定ファイルの例（論文より抜粋）

次回予告

　今回は、2019年に公開された論文「Zanzibar: Google's Consistent, Global Authorization System」に基づいて、Googleのサービス群を支える認証システム「Zanzibar」のデータモデルの概要を説明しました。Zanzibarを利用するサービスは、今回説明した構造のACL情報をZanzibarに保存した後、再度、Zanzibarから読み出して利用していきます。この際、Zanzibarに保存されるACLの情報はリアルタイムに更新されていくため、誤って古い情報を返さないことが大切になります。次回は、このようなデータの整合性を担保する仕組みを解説します。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡