GKEを活用した、社内生成AI基盤の利用ログ対応

ツール導入前の課題

GKE導入前のワンキャリア上のコンテナオーケストレーションツールは、多くがECSに依存していました。その結果、ECSに関する知識は蓄積されましたが、他のプラットフォームに関する知識が不足しており、技術の選択肢が制限されていました。将来的な展望を考え、技術スタックを広げて選択肢を増やす必要がある状況でした。

どんな状態を目指していたか

 

インフラリソースの分離：

Kubernetesを活用すると、インフラのリソースとアプリケーションのリソースを明確に分離することができます。ネットワークレベルの低レイヤーはTerraformで管理し、アプリケーションレベルの高レイヤーはKubernetesで管理することで、アプリケーションエンジニアがネットワークレイヤーに関与せずアプリケーション開発を行うことができます。
 

より迅速なリリースの実現：

KubernetesのDeployment機能を活用することで、アプリケーションの自動デプロイが可能になります。このデプロイでは、コンテナの公開ポート、環境変数、起動パス、そしてデプロイ戦略（ロールアウトなど）など、アプリケーションに近いレイヤーの設定を行うことができます。一方で、DeploymentリソースはVPCなどのネットワークレイヤーの変更は行えません。そのため、「アプリケーション開発に近い部分のみを管理するリソース」と捉えることができます。この特徴により、リリースのリスクを抑えた状態で素早くリリースすることができ、迅速なリリースサイクルを実現できます。

• AWS ECS
• AWS EKS
• GKE

（※応用的な活用方法となります）

AI利用ログの計測という課題に対し、OSS（オープンソースソフトウェア）を改修することなく、Google CloudのGKE、IAP、OpenRestyを駆使して低コストかつ安全な監査ログ基盤を構築した事例についてご紹介します。

社内生成AI基盤におけるログ計測の課題

ワンキャリアでは、DifyといったOSSを社内の生成AI基盤として導入しています。

これらのOSSは非常に高機能である一方で、ユーザーごとの詳細な利用ログ（入力したプロンプトなど）を記録する機能や、社内アカウントへのアクセス制限機能が備わっていません。

この課題を解決するために、最初はOSSのコードを直接改修し、Google Workspaceの2段階認証を導入するといったアプローチを取っていました。

しかし、この方法ではOSSのアップデートの度に対応する必要があり、保守コストが年間200時間にも及ぶなど、莫大となっていました。

この経験から、「OSSに一切手を加えることなく、インフラレイヤーで利用ログを記録し、かつ安全に利用できる基盤」の構築を目指すことにしました。

解決策の検討：3つのアプローチ

ログ計測の要件を満たすために、以下の3つの方法を検討しました。

① Google Cloud Audit Logsの導入
・メリット：「誰が」「どのモデルを」利用したかを最も簡単に把握できる

・デメリット： ユーザーが「どんなデータを入力したか」までは分からない

 


② Request Response Loggingの導入
・メリット: 「どんなデータが入力・出力されたか」をBigQueryに記録できる

・デメリット: 「誰が」そのリクエストを送ったのかが分からない

③ GKE / IAP / OpenRestyを活用した監査ログ体制の導入
・メリット: 「誰が」「どんなデータ」を入力したかを特定できる

・デメリット: 上記2つに比べて設定が複雑になる


今回の目的である「入力情報の追跡」と「社内のAI活用度の可視化」 を達成するためには、「誰が」と「どんなデータ」の両方を紐づけて記録する必要がありました。

そのため、3つ目の「GKE / IAP / OpenRestyを活用した監査ログ体制の導入」を選択しました。

構築した監査ログ基盤の全体像

今回構築したシステムの全体像は以下の通りです 。

ユーザーからのリクエストは、LB、IAP、OpenResty Serverを経由してAIアプリケーション（Dify）に到達します。

① Identity-Aware Proxy (IAP)
ユーザーをGoogle Workspaceアカウントで認証し、許可されたドメインのユーザーのみアクセスできるようにします。認証後、ユーザー情報を含んだJWT（JSON Web Token）をリクエストヘッダーに付与します。

② OpenResty (K8s Service)
IAPから付与されたJWTをLuaスクリプトでデコードし、ユーザーのメールアドレスを取得します。そして、リクエストボディ（ユーザーが入力したプロンプト）とユーザーのメールアドレスを組み合わせ、構造化されたJSON形式でCloud Loggingに出力します。

また、OpenRestyがリクエストを受け取ると、サービスディスカバリーの機能を使って別 Namespace にデプロイされているDifyにリバースプロキシするようにしています。


③ Dify (K8s Service)
OSSのAIアプリケーション本体です。OpenRestyからプロキシされたリクエストを処理します。こちら側には一切手を加えていません。

④Cloud Logging
OpenRestyから出力されたコンテナログを一元的に収集・管理します。

この構成により、OSSのコードを一切変更することなく、AIの利用状況を詳細に記録できるようになりました。

導入効果と今後の展望

今回この監査ログ基盤を導入したことで、以下のような効果を得ることができました。

保守運用のコスト削減

OSSのアップデート追従にかかっていた作業が不要になり、年間200時間から10時間未満に大幅削減されました。

トレーサビリティと活用度の可視化

「誰が」「どんなデータ」を入力したかを記録できるようになったことで、トレーサビリティを担保しつつ、Cloud LoggingやBigQueryを活用して利用状況を詳細に分析できるようになりました。

隠れたAI活用人材の発見

ログデータを分析することで、これまで把握できていなかったAIのヘビーユーザーを発見し、社内のAI活用推進施策に巻き込むといった副次的な効果も生まれています。
IAPによる認証とOpenRestyによるリクエスト情報の動的な加工・ログ出力を組み合わせることで、アプリケーション本体に手を加えることなく、低コストで監査ログ基盤を構築することが可能になります。

導入の初期コスト（特に学習コスト）は高いですが、Kubernetesのエコシステムやコミュニティに便乗することで導入を加速させるツールが数多く存在します。そのポテンシャルを食わず嫌いせずに、まずは試してみるという姿勢が重要です。技術の選択肢を組織内で広げ、特定のインフラ環境に依存し続けることによる将来的なリスクを回避するためにも挑戦する価値は十分にあると考えます。

今後は、組織全体でKubernetes クラスターの管理を担うエンジニアを増やし、より多くのメンバーがインフラ管理に携われるように広めていきたいです。特にログ基盤の構築においては、Kubernetesのサービスディスカバリー機能を活用することで、リバースプロキシの仕組みなど、本来ネットワーク系で実装が必要な部分を非常に楽に構築できたという実績もあります。Kubernetesの機能をさらに活用することで、開発スピードの向上を実現できると考えています。