トップ > インフラ > LiteLLM を App Runner + CloudFront + WAF でシンプルに構築・運用してみた話

LiteLLM を App Runner + CloudFront + WAF でシンプルに構築・運用してみた話

インフラ AI

サムネイル

はじめに

こんにちは。DMMユーザーレビューグループの作田です。
本記事では、AWS App Runner + CloudFront + WAF を活用し、LiteLLM環境をセキュアかつシンプルに構築・運用している取り組みを紹介します。

ユーザーレビューグループでのAI活用が加速する中、用途別のコスト可視化と社内向けのセキュリティ制御をどう両立するかという課題に取り組んでいます。

背景

プラットフォーム開発本部のAX戦略

私たちの所属するプラットフォーム開発本部では、AX戦略（AI Transformation）を推進しています。具体的には、「人でやっていた業務の50%をAIに置き換えた（協働）うえで、開発リードタイムへの変化を観測する」という目標を掲げています。AI前提のプロセスへの作り変えに取り組んでいます。

参考: プラットフォーム開発本部のAX戦略の詳細については、以下の記事で詳しく紹介されています。developersblog.dmm.com

ユーザーレビューグループでのAI活用と課題

ユーザーレビューグループはプラットフォーム開発本部内の1グループとして、このAX戦略に沿ってAI活用事例を複数進めていました。

  • AIによるレビューの自動承認: 低リスク案件の自動承認による業務効率化
  • 業務チケットの自動生成ツール: レビュー結果からJIRAチケットを自動生成
  • Google Chrome拡張によるAIアシスタント: 開発者の日常業務支援

これらのAI活用事例は個別に進められていましたが、AIの利用コストについてAWS Cost Explorerではどのプロダクトからの利用か、用途別の内訳を分析できないという課題がありました。

参考: これらのAI活用事例の詳細については、以下の記事で詳しく紹介されています。
・レビュー自動承認: 4000万人の会員が利用するプラットフォームでレビュー承認業務の生成AIによる自動化を開始し、月150時間の工数削減を実現developersblog.dmm.com
・チケット自動生成: チケット自動生成で平均60%の時間短縮
・Chrome拡張: Google Chrome拡張によるAIアシスタントではドキュメント理解の効率化を実現developersblog.dmm.com

解決アプローチ

そこで、プロキシ的な位置づけでLiteLLMを活用し、コスト分析や利用制御を行う構成を構築するPoC（概念実証）を開始しました。

LiteLLM: 複数のLLM APIを統一的に扱える軽量プロキシ。(公式ドキュメント)
PoCの前提と目的: 短期間で最小構成を構築し、LiteLLMの効果を早期に検証する。

この取り組みは、部内でLiteLLMの活用について話題にあがったことを受け、ユーザーレビューグループが率先して取り組むことになったものです。 部内では、LiteLLMの以下の特徴に着目していました。 ユーザーレビューグループの我々が実装・検証を進めることで、組織全体のAI活用基盤の構築に貢献することを目指しています。

LiteLLMを選択した理由については以下の通りです。

  • 詳細なコスト把握: どのAIサービスをどれだけ使ったか、リクエストごとに追跡できる
  • APIインターフェースの統一: OpenAI、Claude、Bedrockなど、異なるAIサービスを同じ方法で利用できる
  • 柔軟な設定: チームや個人ごとに利用量の制限や利用可能モデル選択を設定できる

構成

LiteLLMをApp Runnerでホストしつつ、CloudFrontと2種類のWAFを用いてアクセス制御を強化しました。

セキュリティ設計: 作成したリソースは必要最低限のアクセスに留めることが基本方針となっています。ここでは主要な制限事項として、現時点では社内IPからのリクエストのみで制限する必要があることを記載しています。その他にも、認証・認可、データ暗号化、ログ監査など、包括的なセキュリティ要件が存在します。

アプリケーション実行基盤の選定理由

PoCとして素早く、シンプルな構成を検討するうえで、以下の技術選定をしました。

アプリケーション実行基盤: App Runnerを採用。

  • LiteLLMがDockerイメージで提供されており、コンテナベースのApp Runnerが適している
  • 他のAI活用事例でも実績があり、運用ノウハウが蓄積されている
  • 設定がシンプルで、PoCの迅速な検証に最適
実行基盤として以下の選択肢も検討しました。
・ ECS/Fargate: タスク定義やALBなど設定が多く、運用負荷が大きい
・ EC2: OSやミドルウェア管理が必要で、PoC段階では負荷が大きい
・ Lambda: 短時間処理向けで、常時稼働が必要なプロキシ用途には不向き

コンテナイメージ: BerriAI社の公式Dockerイメージ

インフラ構成イメージ

下図は主要なコンポーネントを抜粋した構成イメージです。 インフラ構成

各コンポーネントの詳細

コンポーネント 役割
CloudFront App Runnerアクセス制御用カスタムヘッダー付与
WAF (CloudFront用) 許可された社内IPアドレス以外のアクセスをブロック
App Runner LiteLLMをホスト
WAF (App Runner用) アクセス制御用カスタムヘッダーが一致するリクエストのみ許可
RDS for PostgreSQL LiteLLMのコスト集計・ログ記録を保存（必須）

運用

APIキーの発行・管理

LiteLLMの管理画面では、以下の操作によりAPIキーの発行が可能です。

1. 管理画面から「Create Key」ボタンをクリック

Admin UI - Create Key

2. 必要事項を入力してキーを発行

LiteLLMのAPIキー管理機能により、金額上限やリクエスト数の制限を事前に設定できるため、意図せず使いすぎることがなくなり、安心してAIサービスを利用できるという大きなメリットがあります。 これにより、予期しない高額請求を防ぎ、コスト管理の透明性が向上します。

主な項目については以下の通りです。

  • Key Name: キーの名前。個人名やプロダクト名など自由に定義
    • 例: example-user, backend-teamなど
  • Models: 利用可能なModelの指定が可能
    • 例: claude-4-sonnet, All Team Modelsなど
    • 選択するモデルは各自で定義が必要
  • Max Budget: このキーが使える上限の金額（米ドル）を設定可能
  • Reset Budget: 設定した上限がどの周期でリセットが設定可能
  • Tokens per minute Limit: 分間処理できる最大トークン数
  • Requests per minute Limit: 分間にAPIリクエストの上限数
  • Expire Key: このキーの有効期限（いつまで使えるか）を指定が設定可能

Admin UI - Key Settings

3. 発行されたAPIキーを管理 表示されたシークレットキーが今後利用するAPIキーとなるので、安全に控えておきます。

  • sk-virt-xxxxxxxxxx の形式で表示されます
  • 例: sk-virt-abc123def456...

コスト・リクエストの確認

LiteLLMは、リクエスト単位でのメトリクス取得と可視化が可能です。以下の項目がダッシュボード上で確認できます。

  • コスト: モデル別、ユーザー別、時間別のコスト分析
  • リクエスト数: 成功・失敗を含むリクエスト数の推移
  • 消費トークン量: 入力・出力トークンの詳細分析

Admin UI - Analytics Dashboard

この情報を元に、AI活用事例や業務でのAI利用を用途ごとにトラッキングし、予算配分や改善施策に活用できます。

リクエストログの確認

リクエスト情報をログとして連携しているDB (PostgreSQL)に保存されています。

ログ内容は以下のようなカラム構成で構築されており、業務監査・障害調査・モデル最適化などに活用可能です。

  • 基本情報: 実行時間、ステータス、セッションID、リクエストID
  • コスト情報: コスト、キーハッシュ、モデル、トークン数
  • メタデータ: ユーザー情報、リクエスト内容、エラー詳細

Admin UI - Request Logs

Clineでの設定

Clineは、VSCode用のAIアシスタント拡張機能です。 ローカル開発環境からAI APIを利用するためのツールで、LiteLLMとの連携が可能です。

以下、VSCodeでClineを利用する際の設定手順について説明します。

Clineの拡張機能を開き、「API Configuration」に以下を設定

  • API Provider: LiteLLM を選択
  • Base URL: LiteLLMのAPI URLを入力
  • APIキー: 自身のチーム用のAPIキー（sk-virt-xxxxxxxxxx形式）を入力
  • ModelID: 利用可能なモデル名から1つを選択して入力
    • 例: claude-4-sonnet, gpt-4, gpt-3.5-turboなど
  • Use prompt caching: チェックを入れる（プロンプトキャッシュの有効化）

Admin UI - Cline Settings

設定後の動作確認

設定が完了すると、VSCode内でClineを通じてLiteLLM経由でAI APIを利用できるようになります。 これにより、ローカル開発環境から直接LiteLLMのコスト追跡・ログ記録機能を確認できます。

Admin UI - Cline Configuration Complete

成果

これまでの成果

LiteLLMを通じたコスト可視化・解析に成功

試験的にCline経由で接続し、リクエスト単位でのコスト追跡や用途別の分析を実現しました。

APIキーによる制御の仕組みを確認

LiteLLMの管理画面ダッシュボードを使うことで、リクエスト状況をリアルタイムに把握できました。 また、APIキーごとに金額上限・リクエスト数・有効期限などを細かく設定でき、利用を柔軟にコントロールできることも確認できました。

短期間でシンプルかつセキュアなPoC環境を構築

App Runner・CloudFront・WAF を組み合わせることで、セキュアかつ運用負荷の少ない環境を設計しました。 その結果、約2週間という短期間でPoC環境の構築と稼働を開始できました。

浮上した課題

全AI活用施策にLiteLLMを導入することは困難

LiteLLMは、各ベンダーが提供するシンプルな推論APIを扱える仕組みです。

  • 例: OpenAIの chat/completions, Anthropicの messages など

一方で、AIツールの中には、APIのエンドポイントの指定ができないパターンもあります。 これはツール側があらかじめ接続先を固定しており、ユーザーがLiteLLMを経由させるよう設定できません。

  • 例: Devin, Cursor（定額プラン） など

LiteLLMのエンドポイントを指定する利用方法を選ぶ必要がある

一部のSDKはベンダーAPIに直接接続する仕様となっており、そのままではLiteLLMのエンドポイントを指定できないケースがあります。 例えば、Google Chrome拡張によるAIアシスタント施策では「AWS SDK for Python (boto3)」のBedrock Runtimeを利用しています。 この場合、boto3はAmazon Bedrockのエンドポイントに直接接続するためLiteLLMを挟めません。 ただし、呼び出し側を改修し、SDKを使わずにHTTPリクエストを直接発行する方式へ切り替えれば、LiteLLMを経由できるようになります。 そのためには追加の実装工数が必要となるため、事前に考慮すべき重要な課題となりました。

おわりに

今回の取り組みでは、App Runner + CloudFront + WAF を活用し、簡易的かつセキュアなLiteLLM環境を短期間で構築・運用できました。
ローカルからの利用ツール（Cline）を介した疎通と用途別のコスト可視化が実現できた一方、LiteLLMでは扱いにくいケースもあることが分かり、PoCとして大きな学びとなりました。 類似するソリューションとして、Amazon Bedrockの推論プロファイルも調査する予定です。 これにより、LiteLLMでは扱いにくいパターンについても、統合的な管理・制御の可能性を検討していきたいと考えています。 今回の内容が、同じようにAI活用のコスト可視化や基盤構築に取り組む方の参考になれば幸いです。

参考資料