Spannerの「権限」を解体する：IAMがデータベースエンジン内部で果たす不可視の役割
世の中の多くのエンジニアは、IAMを単なる「門番」だと考えている。Cloud SpannerにおけるIAMも、Cloud Consoleの権限設定画面でポチポチと設定するものだと思っているかもしれない。
だが、Spannerのアーキテクチャを深く理解する者にとって、IAMは単なるアクセス制御層ではない。それは分散トランザクションの整合性を担保する、分散型メタデータ・カタログへのゲートウェイである。
今日は、SpannerのIAMロールとFine-grained access control（FGAC）の裏側にある、「なぜそれがデータベースの性能と直結するのか」という極限の視点から解説する。
—
1. 階層構造の真実：インスタンスとDBを分かつレイテンシの壁
Spannerの権限管理は、IAMプロジェクトレベル、インスタンスレベル、そしてデータベースレベルという階層を持つ。アーキテクトがここで意識すべきは、「認証・認可のラウンドトリップが、どのクエリパスで発生するか」だ。
- インスタンスレベルの権限: Spannerのコントロールプレーンに直結する。ノードの増減や設定変更を司るこの権限は、データプレーンのクエリ実行には直接関与しない。
- データベースレベルの権限: ここが極めて重要だ。Spannerのクエリ実行エンジンは、各クエリの開始時にそのセッションが持つ権限セット（Permission Set）をバリデーションする。
もし、アプリケーションの接続ごとに無駄な認可チェックが重なる設計にすれば、分散クエリのオーバーヘッドに数ミリ秒単位の「認可ラグ」が加算される。Spannerはこれを最適化するために、認可メタデータをローカルノードのメモリ上にキャッシュする仕組みを持っている。このキャッシュヒット率こそが、大規模並列アクセスの肝である。
—
2. Fine-grained access control (FGAC) の内部メカニズム
FGACは、単に「テーブルやカラムに制限をかける」機能ではない。これは、クエリプランナーに対する静的/動的なフィルタリング注入である。
通常、Spannerがクエリをパースする際、クエリプランナーは最適なアクセスパス（Splitの選択）を計算する。FGACを有効にすると、プランナーはクエリを実行する前に、そのユーザーのロールに紐付いた `WHERE` 句の制約を抽象構文木（AST）に注入する。
— 通常のクエリ
SELECT FROM Users WHERE region = ‘US’;
— FGACが有効な場合、エンジンは内部的にこう書き換える
— これはSQLリライトではなく、論理実行プランの生成段階で適用される
SELECT FROM Users
WHERE region = ‘US’
AND (tenant_id = CURRENT_USER_TENANT_ID());
この「プランナーレベルでの制約付与」により、認可違反のデータを走査してから破棄するような無駄なメモリ消費（メモリ・リークに近い挙動）を、エンジンレベルで根絶している。
—
3. パフォーマンスを極限まで引き出すための「IAM設計の鉄則」
多くの現場で見られるアンチパターンは、IAMロールを細分化しすぎて、認可メタデータのフェッチ頻度を上げることだ。以下の最適化手法を胸に刻んでほしい。
① サービスアカウントの集約と認可キャッシュの温存
各マイクロサービスごとに無制限にサービスアカウントを生成するのは、管理コストだけでなく、Spanner側のキャッシュ空間を圧迫する。認可情報をキャッシュするメモリ領域はノードごとに有限だ。ロールをある程度グルーピングし、IAMキャッシュの局所性を高めること。
② IAM条件（IAM Conditions）の慎重な利用
IAM条件でリクエスト属性を評価させると、Spannerのフロントエンド（Spanner Front-end: SF）が毎回Googleのグローバル認可インフラと通信する必要が生じる可能性がある。これはレイテンシに直結する。
「動的な制御」が必要なら、IAM条件よりも、データベース内部のFGAC（ロールとフィルタリング）を優先して使うべきだ。なぜなら、FGACはクエリ実行エンジンの一部として最適化されているからだ。
—
4. 最後に：エンジニアが守るべき「境界線」
Spannerにおいて、セキュリティとパフォーマンスは背反しない。むしろ、正しく設計されたFGACは、不要なデータへのスキャンを抑制するため、結果としてI/O負荷を下げ、メモリ効率を向上させる。
もし君が大規模なマルチテナントシステムを設計しているなら、アプリケーションコードで権限を制御しようとするのは今すぐやめろ。それは車輪の再発明であり、かつ非効率だ。Spannerのメタデータエンジンを信頼し、その抽象化層に制御を委ねる。それこそが、伝説級のアーキテクトが辿り着く「Spannerの真の活用法」である。
—
次回の考察:
次は、この認可キャッシュがノードフェイルオーバー時にどう再構築されるか、その際の「ウォームアップ・コスト」について深く掘り下げる予定だ。準備しておけ。
コメント