コラム

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

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

CTC 教育サービス

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

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

はじめに

　前回に続いて、2019年に公開された論文「Zanzibar: Google's Consistent, Global Authorization System」に基づいて、Googleのサービス群を支える統合認証システム「Zanzibar」を紹介していきます。今回は、Zanzibarのシステム構成など、システム全体のアーキテクチャーを解説します。

Zanzibarのアーキテクチャー

　前回の記事で触れたように、Zanzibarは地理的に離れた複数のデータセンターで稼働しており、クライアントは地理的に近い場所のZanzibarにアクセスします。すべての地域に同一のデータがレプリケーションされており、どの場所のZanzibarにアクセスしても基本的には同じ情報を取得することができます。Zanzibarのシステム構成は、図1のようになります。これと同じ構成のシステムが複数のデータセンターで稼働する形になります。

fig01

図1 Zanzibarのアーキテクチャー（論文より抜粋）

　図1の下部には、ACLの情報を保存するデータベース（Spanner）がありますが、図に示されているように、名前空間によるシャーディングが行われています。また、変更ログ（changelog）を記録するための専用のデータベースも用意されています。データベースの上部にある「aclserver」がクライアントからのAPIリクエストを受け付けて、データベースに対するACL情報の読み書きを行います。aclserverは、複数サーバーによるクラスタリングが行われており、クライアントは任意のサーバーに対してAPIリクエストを送信することができますが、リクエストに対する実際の処理は、複数のaclserverによる並列処理が行われます。中央にある「watchserver」は、クライアントからの「Watchリクエスト」を処理するためのもので、指定期間のACLの変更ログをまとめて返します。
　右上の「Leopard Indexing system」は、検索のインデックス情報を提供する、インデックスサーバーのシステムです。Zanzibarでは、ユーザーグループを定義する際に、他のユーザーグループをメンバーとして含めることができるため、グループの階層が深くなると、あるグループに含まれる実際のユーザーを網羅的に検索する時間が長くなります。そこで、Leopard Indexing systemは、前述のWatchリクエストでACLの変更ログを取得して、ユーザーとグループの関係を高速に検索するためのインデックスを定期的に更新して保持します。aclserverは、必要に応じて、このインデックス情報を取得して利用します。

応答性能を高めるための工夫

　上述のように、Zanzibarでは、複数のaclserverが並列処理を行う事で、クライアントからのリクエストを高速に処理できるように設計されていますが、論文の中では、次の3つの点がチューニングのポイントとして紹介されています。

(1) Request hedging
(2) Hot-spot mitigation
(3) Performance isolation

　(1)は、データベース、および、インデックスサーバーの応答が遅い場合の対策で、データベースとインデックスサーバーは、1つの地域において、少なくとも2つのレプリカを用意しておきます。aclserverがこれらにリクエストを送信した後、一定時間内に応答がない場合は、他のレプリカに同じリクエストを送信して、先に帰ってきた方の応答を利用して処理を継続します。
　(2)は、特定の名前空間にアクセスが集中して、該当の名前空間を扱うデータベースが高負荷になることを避けるための対策で、aclserver群を分散キャッシュとして利用します。aclserverは、データベースから読み出した内容をスナップショットのタイムスタンプとあわせて分散キャッシュに保存することで、データベースへのアクセス負荷を低減します。特にアクセス頻度が高い<object#relation>のペアに対しては、すべてのデータを事前に分散キャッシュに読み込むなどの処理も行います。一般的な分散キャッシュでは、データの更新時にキャッシュ上のデータを無効化するという処理が必要ですが、ACL情報の読み出しは、特定時刻のスナップショットから行うため、この部分の処理は不要になります。
　(3)は、特定のクライアントからの大量のリクエストによって、他のクライアントへの応答が遅れることを防ぐための仕組みです。それぞれのクライアントに対して、個々のAPIリクエストのCPU負荷を見積もり、システム全体が高負荷になった際は、クライアントごとに許容するCPU負荷を制限するなどの仕組みが実装されています。
　図2は、2018年12月の特定の1週間における、さまざまなAPIリクエストに対する応答のレイテンシーを測定した結果になります。「Safe」はレプリケーション済みのデータで応答できる場合、「Recent」は他の地域のデータベースから最新のデータを取得する必要がある場合の結果になります。当然ながら、Recentの方がレイテンシーが長くなる傾向がありますが、実際のリクエスト数としては、Recentは、Safeの100分の1以下だということです。「Expand」は特定のユーザーグループに属するすべてのユーザーをまとめて取得するリクエストになります。この表より、「Safe」リクエストについては、すべてのAPIにおいて、95パーセンタイルで10ミリ秒以下のレイテンシーを実現していることが読み取れます。

fig02

図2 APIリクエストごとのレイテンシーの測定結果（論文より抜粋）

次回予告

　今回は、2019年に公開された論文「Zanzibar: Google's Consistent, Global Authorization System」に基づいて、Googleのサービス群を支える統合認証システム「Zanzibar」のシステムアーキテクチャーを紹介しました。
　次回からは、Google Cloudで提供されるモバイルアプリケーション対応のデータベースである、Firestoreのアーキテクチャーを紹介していきます。

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