サーキットブレーカーによる推論サービスの障害伝播防止 - ACK

ACK Gateway with Inference Extension コンポーネントは、推論サービスのインテリジェントな負荷分散を有効にしながら、サーキットブレーカールールの構成をサポートしています。サービスに異常が発生した場合、サーキットブレーカーメカニズムは問題のあるサービス接続を自動的に切断し、障害の伝播を防ぎます。このトピックでは、ACK Gateway with Inference Extension を使用して、推論サービスのトラフィックサーキットブレーカールールを構成する方法について説明します。

重要

このトピックを読む前に、InferencePool と InferenceModel の概念を理解していることを確認してください。

前提条件

GPU ノードプールを持つ ACK マネージドクラスターが作成されていること。ACS GPU 計算能力を使用するために、ACK マネージドクラスターに ACK Virtual Node コンポーネントをインストールすることもできます。
ACK Gateway with Inference Extension がインストールされており、[Gateway API 推論拡張機能を有効にする] が選択されていること。操作エントリの詳細については、「手順 2: ACK Gateway with Inference Extension コンポーネントをインストールする」をご参照ください。

説明

このガイドで使用されているイメージには、16 GiB を超える GPU メモリが必要です。16 GiB のビデオメモリを搭載した T4 カードタイプでは不十分な場合があります。したがって、ACK クラスタの推奨 GPU カードタイプは A10 で、ACS GPU 計算能力の推奨タイプは第 8 世代 GPU B です。

LLM イメージのサイズが大きいため、事前に ACR に転送し、内部ネットワークアドレスを使用してプルすることをお勧めします。パブリックネットワークからのプルの速度は、クラスターの Elastic IP アドレス (EIP) の帯域幅構成によって異なり、待機時間が長くなる可能性があります。

ワークフロー

この例では、次のリソースを使用します。

vllm-llama2-7b-pool 推論サービス (アプリケーション)。
サービスの種類が ClusterIP のゲートウェイ。
特定のトラフィック転送ルールと、保留中のリクエスト数を 1 に制限するサーキットブレーカールール (最大同時リクエスト数は 1) で構成された HTTPRoute。
このトピックでは、デモンストレーションのために小さな同時実行制限を使用しています。実際の環境では、必要に応じて制限を変更してください。
アプリケーションのインテリジェントな負荷分散を有効にするために使用される InferencePool と対応する InferenceModel。
テストクライアントとして機能するスリープアプリケーション。

次の図は、トラフィックサーキットブレーカーメカニズムのリクエストパスを示しています。

クライアントはリクエスト ① を開始し、リクエスト ① の応答が返される前にリクエスト ② を開始します。
サーキットブレーカールールは、リクエスト ① の前に保留中のリクエストがないと判断するため、リクエスト ① はアプリケーションに転送されます。
サーキットブレーカールールは、リクエスト ② の前にリクエスト ① がすでに処理されていると判断するため、リクエストを直接ブロックし、サーキットブレーカー情報 ③ をクライアントに返します。この例では、リクエストは拒否されます。
リクエスト ① がアプリケーションによって処理されると、応答 ④ がクライアントに返されます。

手順

vllm-llama2-7b-pool という名前の推論サービスをデプロイします。

展開して YAML コンテンツを表示する

# =============================================================
# inference_app.yaml
# =============================================================
# ... (元のコードを保持)

InferencePool リソースと InferenceModel リソースをデプロイします。

# =============================================================
# inference_rules.yaml
# =============================================================
# ... (元のコードを保持)

ゲートウェイと HTTPRoute をデプロイし、サーキットブレーカールールを構成します。
ゲートウェイのサービスの種類は ClusterIP で、クラスター内からのみアクセスできます。ビジネス要件に基づいて LoadBalancer に変更できます。
```
# =============================================================
# gateway.yaml
# =============================================================
# ... (元のコードを保持)
```

sleep アプリケーションをデプロイします。

# =============================================================
# sleep.yaml
# =============================================================
# ... (元のコードを保持)

トラフィックサーキットブレーカーの構成を確認します。
このトピックでは、デモンストレーションのために小さな同時実行制限を使用しています。実際の環境では、必要に応じて制限を変更してください。
1. ゲートウェイアドレスを取得します。
```
export GATEWAY_ADDRESS=$(kubectl get gateway/example-gateway -o jsonpath='{.status.addresses[0].value}')
```
2. 2 つのターミナルウィンドウを開きます。ウィンドウ 1 でテストリクエストを開始し、リクエストが返される前に、ウィンドウ 2 で別のリクエストを開始します。
```
kubectl exec deployment/sleep -it -- curl -X POST ${GATEWAY_ADDRESS}/v1/chat/completions -H 'Content-Type: application/json' -H "host: example.com" -d '{
    "model": "/model/llama2",
    "max_completion_tokens": 100,
    "temperature": 0,
    "messages": [
      {
        "role": "user",
        "content": "introduce yourself"
      }
    ]
}'
```
  ウィンドウ 1 での予期される出力:
```
# ... (元のコードを保持)
```
  ウィンドウ 2 での予期される出力:
```
upstream connect error or disconnect/reset before headers. reset reason: overflow
```
  サーキットブレーカールールを構成した後、同時リクエスト数が構成済みの制限 1 を超えると、後続のリクエストによってサーキットブレーカーがトリガーされます。