Platform For AI:非同期推論サービスのデプロイ

非同期推論サービスへのアクセス

デフォルトでは、非同期推論サービスと同じ名前のサービスグループが作成されます。キューサブサービスはトラフィックエントリポイントとして機能します。以下のパスを使用してアクセスします。詳細については、「キューサービスへのアクセス」をご参照ください。

非同期推論サービスの管理

システムがサブサービスを自動的に処理するため、非同期推論サービスの管理は通常のサービスの管理と同じです。たとえば、非同期推論サービスを削除すると、キューサブサービスと推論サブサービスの両方が削除されます。推論サブサービスを更新しても、最大限の可用性を確保するためにキューサブサービスは変更されません。

サブサービスのアーキテクチャのため、1 つのサービスインスタンスを設定すると、リストには推論サブサービス用とキューサブサービス用の 2 つのインスタンスが表示されます。

非同期推論サービスのインスタンス数は、推論サブサービスのインスタンス数を指します。キューサブサービスのインスタンス数は、推論サブサービスのインスタンス数に応じて自動的に変更されます。たとえば、推論サブサービスのインスタンス数を 3 にスケールアウトすると、キューサブサービスのインスタンス数は 2 にスケールアウトします。

2 つのサブサービス間のインスタンスの比率は、次のルールに従います。

• 非同期推論サービスが停止されると、キューサブサービスと推論サブサービスの両方のインスタンス数が 0 にスケールインします。インスタンスリストは空になります。

• 推論サブサービスのインスタンス数が 1 の場合、キューサブサービスのインスタンス数も 1 です。ただし、キューサブサービスの設定で別途指定されている場合を除きます。

• 推論インスタンスが 2 つ以上ある場合、キューインスタンスの数は 2 のままです。ただし、キューサブサービスの設定で別途指定されている場合を除きます。

• 最小インスタンス数を 0 にして Auto Scaling を設定した場合、推論サブサービスが 0 にスケーリングしても、キューサブサービスは 1 つのスタンバイインスタンスを維持します。

キューサブサービスのパラメーター

ほとんどの場合、キューサブサービスはデフォルト設定で正常に動作します。カスタマイズするには、JSON ファイルのトップレベルで queue フィールドを設定します。例：

{  
  "queue": {
     "sink": {
        "memory_ratio": 0.3
     },
     "source": {
        "auto_evict": true
     }
 }

以下のセクションでは、設定項目について詳しく説明します。

キューサブサービスのリソース設定

デフォルトでは、キューサブサービスのリソースはメタデータ内のフィールドに従って設定されます。ただし、一部のユースケースでは、キューサブサービスのリソースを個別に設定する必要がある場合があります。

• queue.resource を使用して、キューサブサービスのリソースグループを指定します。

  {
    "queue": {
      "resource": "eas-r-slzkbq4tw0p6xd****"  # デフォルトでは、推論サブサービスのリソースグループに従います。
    }
  }

  • デフォルトでは、キューサブサービスは推論サブサービスと同じリソースグループを使用します。

  • キューサブサービスをパブリックリソースグループにデプロイするには、resource を空の文字列 ("") に設定します。これは、専用リソースグループの CPU とメモリが不足している場合に便利です。

    説明

    キューサブサービスをパブリックリソースグループにデプロイすることを推奨します。

• queue.cpu と queue.memory を使用して、各キューサブサービスインスタンスの CPU (コア単位) とメモリ (MB 単位) を指定します。

  {
    "queue": {
       "cpu": 2,  # デフォルト: 1
       "memory": 8000  # デフォルト: 4000
    }
  }

  リソースを設定しない場合、各キューサブサービスインスタンスはデフォルトで 1 CPU コアと 4 GB のメモリを使用します。これは、ほとんどのシナリオのニーズを満たします。

  重要

  • サブスクライバー (たとえば、推論サブサービスインスタンス) が 200 を超える場合は、CPU コア数を 2 以上に設定することを推奨します。

  • 本番環境でキューサブサービスのメモリ設定を減らすことは推奨しません。

• queue.min_replica を使用して、キューサブサービスインスタンスの最小数を設定します。

  {
    "queue": {
       "min_replica": 3  # デフォルト: 1
    }
  }

  非同期推論サービスを使用する場合、キューサブサービスインスタンスの数は、推論サブサービスインスタンスのランタイム数に基づいて自動的に調整されます。デフォルトの調整範囲は [1, min(2, 推論サブサービスインスタンス数)] です。特別なケースとして、非同期推論サービスの Auto Scaling を設定し、インスタンス数を 0 にスケールインできるようにした場合、1 つのキューサブサービスインスタンスが自動的に保持されます。また、queue.min_replica を使用して、保持されるキューサブサービスインスタンスの最小数を調整することもできます。

  説明

  キューサブサービスインスタンスの数を増やすと可用性は向上しますが、パフォーマンスは向上しません。

キューサブサービスの機能設定

キューサブサービスには、いくつかの設定可能な機能があります。

• queue.sink.auto_evict または queue.source.auto_evict を使用して、それぞれシンクキューまたは入力キューの自動データエビクションを有効にします。

  {
    "queue": {
       "sink": {
          "auto_evict": true  # シンクキューのエビクションを有効にします。デフォルト: false
        },
        "source": {
           "auto_evict": true  # 入力キューのエビクションを有効にします。デフォルト: false
        }
    }
  }

  デフォルトでは、自動データエビクションは無効になっています。キューが一杯の場合、それ以上データを書き込むことはできません。データオーバーフローを許可する場合は、自動エビクションを有効にします。これにより、キューは新しいメッセージのためのスペースを確保するために最も古いメッセージをエビクションします。

• queue.max_delivery を使用して、最大配信試行回数を設定します。

  {
     "queue": {
        "max_delivery": 10  # 最大配信試行回数: 10。デフォルト: 5。0 に設定すると、最大配信試行回数は無効になり、メッセージは無期限に配信できます。
     }
  }

  メッセージの配信試行回数がこのしきい値を超えると、デッドレターとしてマークされます。詳細については、「デッドレターポリシー」をご参照ください。

• queue.max_idle を使用して、メッセージの最大処理時間を設定します。

  {
      "queue": {
        "max_idle": "1m"  # 1 つのメッセージの最大処理時間を 1 分に設定します。この時間を超えると、メッセージは他のサブスクライバーに配信されます。配信後、配信カウントが 1 増加します。デフォルト値は 0 で、最大処理時間がないことを意味します。
      }
  }

  この例で設定されている時間は 1 分です。h (時間)、m (分)、s (秒) など、複数の時間単位がサポートされています。単一メッセージの処理時間が設定された時間を超えると、次のいずれかが発生します。

  • queue.max_delivery で設定されたしきい値を超えていない場合、メッセージは他のサブスクライバーに配信されます。

  • queue.max_delivery で設定されたしきい値を超えている場合、メッセージにデッドレターポリシーが適用されます。

• queue.dead_message_policy を使用して、デッドレターポリシーを設定します。

  {
      "queue": {
        "dead_message_policy":  "Rear"  # 有効な値: Rear (デフォルト) または Drop。Rear はメッセージをキューの末尾に移動します。Drop はメッセージを削除します。
      }
  }

キューの制限設定

キューの最大長と最大ペイロードサイズは反比例の関係にあります。これらは次の数式に従います。

キューサブサービスインスタンスのメモリは固定です。したがって、メッセージあたりの最大ペイロードサイズを増やすと、キューの最大長は減少します。

• queue.sink.max_length または queue.source.max_length を使用して、それぞれシンクキューまたは入力キューの最大長を設定します。

  {
      "queue": {
         "sink": {
            "max_length": 8000  # シンクキューの最大長を 8,000 メッセージに設定します。
         },
         "source": {
            "max_length": 2000  # 入力キューの最大長を 2,000 メッセージに設定します。
         }
      }
  }

• queue.sink.max_payload_size_kb または queue.source.max_payload_size_kb を使用して、それぞれシンクキューまたは入力キューのメッセージあたりの最大ペイロードサイズを設定します。

  {
      "queue": {
         "sink": {
            "max_payload_size_kb": 10  # シンクキューのメッセージあたりの最大ペイロードサイズを 10 KB に設定します。デフォルトは 8 KB です。
         },
         "source": {
            "max_payload_size_kb": 1024  # 入力キューのメッセージあたりの最大ペイロードサイズを 1024 KB (1 MB) に設定します。デフォルトは 8 KB です。
         }
      }
  }

メモリ割り当て比率の設定

• queue.sink.memory_ratio を使用して、入力キューとシンクキュー間のメモリ割り当てを調整します。

  {
      "queue": {
         "sink": {
            "memory_ratio": 0.9  # シンクキューのメモリ比率を設定します。デフォルト値は 0.5 です。
         }
      }
  }

  説明

  デフォルトでは、入力キューとシンクキューはキューサブサービスインスタンスのメモリを均等に共有します。出力データ (例：画像) が入力データ (例：テキスト) よりも大きい場合は、queue.sink.memory_ratio を増やしてシンクキューにより多くのメモリを割り当てることができます。逆に、サービスが画像を入力として受け取り、テキストを出力する場合は、queue.sink.memory_ratio を減らすことができます。

水平 Auto Scaling