DeepSeek エンタープライズ向けソリューション

1.1 アーキテクチャ全体図

エンタープライズ向けDeepSeekデプロイメントはレイヤードアーキテクチャを採用しており、各レイヤーは独立してスケーラブルで置き換え可能です。主要コンポーネントは以下の通りです：

1.2 リクエストフローパス

完全なAPIリクエストのフローパス：

1.3 アーキテクチャ設計原則

2.1 マルチノードデプロイアーキテクチャ

単一障害点を避けるため、異なる物理マシンまたはアベイラビリティゾーンに少なくとも3つの推論ノードをデプロイします：

# マルチノード vLLM デプロイ（3ノードクラスタ）
# ノード1（192.168.1.11）
python -m vllm.entrypoints.openai.api_server \
--model deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \
--tensor-parallel-size 2 \
--host 0.0.0.0 --port 8000

# ノード2（192.168.1.12）
python -m vllm.entrypoints.openai.api_server \
--model deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \
--tensor-parallel-size 2 \
--host 0.0.0.0 --port 8000

# ノード3（192.168.1.13）
python -m vllm.entrypoints.openai.api_server \
--model deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \
--tensor-parallel-size 2 \
--host 0.0.0.0 --port 8000

2.2 ヘルスチェック設定

ロードバランサーはバックエンドサービスのヘルス状態を定期的にプローブし、障害ノードを自動的に切り離す必要があります：

# Nginx ヘルスチェック設定
upstream deepseek_cluster {
server 192.168.1.11:8000 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8000 max_fails=3 fail_timeout=30s;
server 192.168.1.13:8000 max_fails=3 fail_timeout=30s;

# アクティブヘルスチェック（nginx-plus または nginx-module が必要）
# check interval=3000 rise=2 fall=3 timeout=1000 type=http;
# check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
# check_http_expect_alive http_2xx;
}

# カスタムヘルスチェックスクリプト
# /usr/local/bin/healthcheck-vllm.sh
#!/bin/bash
for node in 192.168.1.11 192.168.1.12 192.168.1.13; do
status=$(curl -s -o /dev/null -w "%{http_code}" http://$node:8000/health)
if [ "$status" != "200" ]; then
echo "ALERT: Node $node is DOWN" | systemd-cat -t healthcheck
# アラート通知をトリガー
fi
done

2.3 フェイルオーバー戦略

2.4 Kubernetes HA設定

# deepseek-ha-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deepseek-vllm
namespace: deepseek
spec:
replicas: 3
selector:
matchLabels:
app: deepseek-vllm
template:
metadata:
labels:
app: deepseek-vllm
spec:
# Podアンチアフィニティ：Podを異なるノードに分散させる
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- deepseek-vllm
topologyKey: kubernetes.io/hostname
# グレースフル終了：現在のリクエストを処理するためにPodに30秒与える
terminationGracePeriodSeconds: 30
containers:
- name: vllm
image: vllm/vllm-openai:latest
ports:
- containerPort: 8000
resources:
requests:
nvidia.com/gpu: 2
memory: "64Gi"
limits:
nvidia.com/gpu: 2
memory: "80Gi"
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 120
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 60
periodSeconds: 5
failureThreshold: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1

2.5 自動スケーリング（HPA）

# deepseek-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: deepseek-vllm-hpa
namespace: deepseek
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: deepseek-vllm
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 50
periodSeconds: 60
scaleUp:
stabilizationWindowSeconds: 30
policies:
- type: Pods
value: 2
periodSeconds: 30

3.1 Nginx Upstream 設定

# /etc/nginx/conf.d/deepseek-upstream.conf
upstream deepseek_vllm {
# least_conn アルゴリズム：接続数が最も少ないノードを優先
# LLM 推論シナリオに適しています（リクエストの所要時間のばらつきが大きい）
least_conn;

# 推論ノードプール
server 192.168.1.11:8000 weight=1 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8000 weight=1 max_fails=3 fail_timeout=30s;
server 192.168.1.13:8000 weight=1 max_fails=3 fail_timeout=30s;

# バックアップノード（低優先度、全プライマリノードがダウンした場合のみ有効）
server 192.168.1.14:8000 weight=1 backup;

# 長期間接続プール：TCP ハンドシェイクのオーバーヘッドを削減
keepalive 64;
keepalive_requests 1000;
keepalive_timeout 60s;
}

# vLLM 推論サービス（高性能）
upstream deepseek_vllm_large {
least_conn;
server 192.168.1.21:8000 weight=3; # A100 × 8（高ウェイト）
server 192.168.1.22:8000 weight=3; # A100 × 8
server 192.168.1.23:8000 weight=1; # A10 × 1（低ウェイト）
keepalive 32;
}

3.2 Sticky Session（セッション維持）

LLM 推論シナリオでは、Sticky Session により同じユーザーの連続リクエストを同じノードにルーティングし、KV Cache のヒット率を向上させることができます：

# Cookie ベースのセッション維持
upstream deepseek_sticky {
# ip_hash アルゴリズム：同じクライアント IP は常に同じノードにルーティング
ip_hash;

server 192.168.1.11:8000;
server 192.168.1.12:8000;
server 192.168.1.13:8000;
}

# sticky cookie を使用（nginx-plus または sticky-module が必要）
upstream deepseek_sticky_cookie {
# sticky cookie srv_id expires=1h domain=.example.com path=/;
server 192.168.1.11:8000;
server 192.168.1.12:8000;
server 192.168.1.13:8000;
}

3.3 コネクションプールと Keepalive 最適化

3.4 負荷分散アルゴリズムの比較

4.1 API認証方式

JWT（JSON Web Token）とOAuth2の2つの認証方式をサポートし、さまざまなシナリオに対応します：

JWT認証（サービス間呼び出し）

# JWTトークン生成（サーバー側）
# Python例
import jwt
import time

def generate_api_token(user_id: str, scope: str = "deepseek:read") -> str:
payload = {
"sub": user_id,
"scope": scope,
"iat": int(time.time()),
"exp": int(time.time()) + 3600 # 1時間で期限切れ
}
return jwt.encode(payload, "your-secret-key", algorithm="HS256")

# Nginx JWT検証（njsまたはlua-nginx-moduleを使用）
# locationブロックにJWT検証ロジックを追加
location /v1/ {
auth_jwt "DeepSeek API";
auth_jwt_key_file /etc/nginx/jwt_public_key.pem;
proxy_pass http://deepseek_vllm;
}

OAuth2認証（ユーザー認可）

# Kong API Gateway OAuth2プラグイン設定
# OAuth2プラグインを有効化
curl -X POST http://localhost:8001/services/deepseek/plugins \
--data "name=oauth2" \
--data "config.enable_authorization_code=true" \
--data "config.enable_client_credentials=true" \
--data "config.token_expiration=3600"

# OAuth2アプリケーションを作成
curl -X POST http://localhost:8001/consumers/your-app/oauth2 \
--data "name=DeepSeek App" \
--data "client_id=your-client-id" \
--data "client_secret=your-client-secret" \
--data "redirect_uris[]=https://your-app.com/callback"

4.2 レート制限

# Nginxレート制限設定
# /etc/nginx/nginx.conf
http {
# IPごとのレート制限：10リクエスト/秒、バースト20
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

# APIキーごとのレート制限：50リクエスト/秒
limit_req_zone $http_x_api_key zone=per_key_limit:10m rate=50r/s;

# 同時接続数制限
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
}

# Serverブロックで適用
server {
location /v1/chat/completions {
# 基本レート制限
limit_req zone=api_limit burst=20 nodelay;
limit_req_status 429;

# APIキーごとのレート制限
limit_req zone=per_key_limit burst=50 nodelay;

# 同時接続制限
limit_conn conn_limit 10;

proxy_pass http://deepseek_vllm;
}
}

4.3 IPホワイトリスト

# Nginx IPホワイトリスト
location /v1/admin/ {
# 内部ネットワークとVPNセグメントのみ許可
allow 10.0.0.0/8;
allow 172.16.0.0/12;
allow 192.168.0.0/16;
deny all;

proxy_pass http://deepseek_vllm;
}

# GeoIPモジュールを使用して国/地域を制限
# geoip_country /usr/share/GeoIP/GeoIP.dat;
# map $geoip_country_code $allowed_country {
# default no;
# CN yes;
# US yes;
# }

4.4 リクエスト検証

APIゲートウェイ層でリクエストを検証し、悪意のあるリクエストや異常なリクエストを防ぎます：

# Nginxリクエスト検証
location /v1/chat/completions {
# リクエストボディサイズを制限
client_max_body_size 1M;

# POSTメソッドのみ許可
limit_except POST {
deny all;
}

# Content-Typeを制限
if ($http_content_type !~ "^application/json") {
return 415 '{"error":"Unsupported Media Type"}'; }
# max_tokensパラメータを制限（リソース乱用防止）
# lua-nginx-moduleまたはnjsと組み合わせて実装

proxy_pass http://deepseek_vllm;
}

4.5 プロンプトインジェクション対策

プロンプトインジェクションは、エンタープライズAIアプリケーションが直面する主要なセキュリティ脅威の1つです。攻撃者は巧妙に細工されたプロンプトを通じてシステム指示を回避し、機密情報を取得したり、不正な操作を実行したりします。

# Pythonでのプロンプトインジェクション検出例
import re

INJECTION_PATTERNS = [
r"ignore\s+(all\s+)?(previous|above|prior)\s+instructions?",
r"you\s+are\s+now\s+(DAN|jailbreak)",
r"system\s*prompt[:=]",
r"pretend\s+you\s+are",
r"<\|im_start\|>",
r"<\|im_end\|>",
]

def detect_injection(user_input: str) -> bool:
for pattern in INJECTION_PATTERNS:
if re.search(pattern, user_input, re.IGNORECASE):
return True
return False

4.6 データ暗号化