GenAIプラットフォームにおける認証・承認の課題と解決策

はじめに

GenAI（Generative AI）プラットフォームは、大規模言語モデル（LLM）を活用した高度なAIサービスを提供する重要な技術基盤です。しかし、このようなプラットフォームでは、認証（Authentication）と承認（Authorization）の実裝が、スケーラビリティやセキュリティにおいて大きな課題となります。本記事では、CNCF（Cloud Native Computing Foundation）の技術スタックを活用したGenAIプラットフォームにおける認証・承認の課題と、その解決策を解説します。

技術スタックとプラットフォームの構成

GenAIプラットフォームは、以下の3つの主要なモジュールで構成されています。

トレーニングモジュール：ユーザーがカスタムコンテナイメージとGPUリソースを提供し、Kubernetesノード上でモデルをトレーニング。結果はS3に保存。
サービスモジュール：事前にトレーニングされたモデルを用いて推論を実行。Kubernetes GPUノード上で実行。
生成AIモジュール：40以上のLLMを統合し、ユーザーが獨自モデルやパートナーモデルを統合可能。

技術スタックには、Gardener（Kubernetesクラスタ管理）、ISTIO（トラフィック管理とセキュリティ）、Argo Workflows（トレーニングフロー管理）、KServe（モデルサービス）、LLMサービス（自社モデルとパートナーモデル）が採用されています。

認証・承認の課題と解決策

1. Ingress GatewayにおけるJWT処理のパフォーマンス問題

課題：JWTによるユーザー識別で、高負荷下で60msの遅延が発生し、RPSが20未満に低下。
解決策：Envoyを導入し、外部gRPCサービスでJWT解析を実行。Goのネイティブ処理によりパフォーマンスを向上。
教訓：Envoy Filterは中低負荷で効果的だが、高負荷では外部プロセスの導入が必要。

2. JWKS URIクエリのパフォーマンスとリソース消費

課題：各ユーザーが異なるJWKS URIを使用し、Authorization Policyによる管理がSidecarのリソース消費（16GBメモリ＋5コア）を引き起こす。
解決策：OPA（Open Policy Agent）を導入し、ポリシーロジックを外部化。データベースクエリとキャッシュを併用。
教訓：大量の承認ポリシーはリソース浪費と遅延を招くため、外部ポリシーエンジンの導入が推奨。

3. LLMサブスクリプションとルーティングルールの拡張性問題

課題：LLMサブスクリプション時にIDでモデル情報を検索するが、Virtual ServiceによるルーティングがEnvoyのリソース消費と遅延を引き起こす。
解決策：外部データベースでID対応情報を検索し、リクエストヘッダーに注入。
教訓：ルーティングルール數と遅延は線形関係にあるため、データベースクエリによる最適化が必須。

4. ログシステムのMTLSと暗號化パフォーマンス

課題：MTLSによる通信で高負荷（1TB/日）下で不安定。MTLSを無効化するとシステムは正常だがセキュリティリスクが生じる。
解決策：Ambientを導入し、暗號化をネットワーク層（L4）に下げる。Sidecarの暗號化負荷を迴避。
教訓：高吞吐量システムではSidecarの暗號化を避けて、原生プロトコル（Ambient、WireGuardなど）を採用。

5. トレーニングフローのノードリソース競合

課題：Kubernetes Jobが並列実行時にCNI初期化とPod起動の競合條件が発生。主コンテナが完了してもSidecarが終了していないためJobが完了と判定されない。
解決策：
- 方法1：KubernetesのネイティブSidecar（Init Container）を採用し、主コンテナ終了前にSidecarを起動。
- 方法2：ISTIO Ambientモードを採用し、Sidecarコンテナを完全に削除。
教訓：Sidecarと主コンテナの並列実行を避けるため、Init ContainerまたはAmbientモードを採用。

6. モデルサービスの初期化順序衝突

課題：KServeのInit Containerがモデルをダウンロード中にSTO Proxy Sidecarが起動していないため、外部リソース（S3）へのアクセスが失敗。
解決策：
- 方法1：Init Containerの実行順序を調整し、STO Proxy Sidecarを先に起動。
- 方法2：Ambientモードを採用し、Sidecarコンテナを削除。
教訓：初期化順序の衝突はTaints/Tolerationsで調整するか、無Sidecarアーキテクチャに移行。

主な教訓

標準構成の高負荷下での調整が必要：中低負荷では良好だが、高負荷ではカスタマイズが必要。
初期化順序の競合リスク：ISTIOとワークロードの初期化順序が予期せぬ挙動を引き起こす可能性があるため、Taints/Tolerationsで調整。
一時的な解決策のリスク：現在の解決策（例：ポート443の開放）はセキュリティリスクを伴うため、長期的な最適化が求められる。
原生解決策の優先：長期的にはKubernetesのネイティブSidecarまたはAmbientモードを採用。
技術の継続的な更新：リリースノートに記載された改善點やベストプラクティスを定期的に確認。

結論

GenAIプラットフォームにおける認証・承認の課題は、スケーラビリティとセキュリティの両立を求める技術的挑戦です。CNCFの技術スタック（ISTIO、Gardener、Argo Workflowsなど）を活用し、パフォーマンスとセキュリティを両立させるための最適なアプローチを検討することが重要です。今後の技術進化に合わせて、原生な解決策や新しいアーキテクチャ（例：Ambientモード）への移行を検討してください。