Technology

中央セッション管理で複数クラウドの反復ログインを55%削減

この記事のポイント

  1. 実現したこと

    共通セッションを検証し、複数の実行環境へ信頼済みのユーザー情報を引き継ぐことができる。

  2. 実現の仕組み

    中央ゲートウェイがRedisにセッションを保持し、ステートレスな地域ゲートウェイが共有APIを介して検証する。

  3. 得られた結果

    AWSとOCIにまたがる社内開発基盤で、反復ログインが社内測定により55%減少した。

  4. 従来との違い

    ゲートウェイごとのセッション所有から、中央でのセッション所有と地域でのリクエスト強制を分離する構成へ切り替わった。

中央の共有セッション基盤から複数の地域ゲートウェイへ信頼済みのユーザー情報が分岐し、各クラウド実行環境へ渡される構成を描いた編集イラスト
AI生成画像

中央で保持する共通セッションを地域ゲートウェイが検証し、分散した実行環境へ信頼済みのユーザー情報を渡す。NVIDIAによると、この構成を採用した複数クラウドの社内基盤では、反復ログインが55%減少したという。

入口の認証を分散した実行先へ引き継ぐ

シングルサインオン(SSO)は入口でユーザーを認証するが、その結果が別のクラスタやデータプレーンで自動的に信頼されるユーザー情報になるわけではない。ノートブック、カタログAPI、クエリーエンジンなどが異なる実行環境に分かれる場合、各環境にはリクエスト元を共通の方法で識別する経路が必要になる。

NVIDIAが説明する中央アイデンティティゲートウェイ構成では、中央側がプラットフォームセッションを所有する。データプレーンのゲートウェイは共有APIを介してそのセッションを検証するため、入口で成立した認証状態を分散した実行先へ引き継げる。

ログインとセッション状態を中央へ集約する

中央アイデンティティゲートウェイは、OpenID Connect(OIDC)によるログインを処理し、その後のセッション状態、トークン更新、ログアウトも管理する。認証状態の所有者を中央に定めることで、地域ごとのゲートウェイがそれぞれログイン処理を持つ必要がなくなる。

セッション状態は、明示的な有効期限を設定したRedisベースの共有セッションストアに保持される。中央ゲートウェイはこの共通状態を基に、地域側から届く検証要求へ応答する。

地域ゲートウェイが検証結果を下流へ渡す

地域ゲートウェイは独自のセッションを所有しないステートレスな構成で、中央側へのセッション検証とローカル環境でのリクエスト強制を担う。セッションの保管や更新ではなく、実行先へ入るリクエストの検証に役割を絞る。

検証されたユーザー情報は、下流サービスが利用できる信頼済みヘッダーまたはクレームへ変換される。各サービスは生のトークンを受け取って個別に解釈する代わりに、ゲートウェイが生成した共通形式のユーザー情報を利用できる。

通信経路と識別情報の信頼境界を固定する

中央ゲートウェイと地域ゲートウェイの通信は、相互TLSまたはワークロードIDで保護する。セッションの検証を要求するゲートウェイ自体を認証し、検証APIへ接続できる主体を制限するための境界となる。

地域ゲートウェイは、リクエストに含まれていた識別情報ヘッダーを除去してから、検証済みの信頼できるヘッダーを注入する。共有セッションストアを利用できない場合のリクエスト処理も明示的に定め、セッションを検証できない状態での挙動を固定する。

個別セッションからプラットフォーム単位の管理へ切り替える

ゲートウェイごとにセッションを所有する構成では、ログイン、トークン更新、ログアウトがサービスやクラスタ単位に分かれる。セッションを中央で所有すると、トークン更新を一元的に調整し、一つのセッション記録を通じてログアウトをプラットフォーム全体へ反映できる。

上流のアイデンティティプロバイダーが受ける負荷の増え方も変わる。分散構成ではユーザー、ツール、クラスタの組み合わせに応じて処理が増えるのに対し、中央集約型では主にアクティブユーザー数に応じて増える設計となる。

NVIDIAは、この構成をAWSとOCIのKubernetesクラスタにまたがる社内開発者向け基盤へ適用したとしている。NVIDIAの社内測定では、利用者に繰り返し求めていたログインが55%減少した。