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

非同期推論サービスにアクセスする

前述のように、非同期推論サービスと同じ名前のサービスグループがデフォルトで作成されます。このグループ内のキューサブサービスはトラフィックの入口として機能するため、次のパスを使用してキューサブサービスに直接アクセスします。詳細については、「キューサービスへのアクセス」をご参照ください。

非同期推論サービスを管理する

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

サブサービスのアーキテクチャのため、非同期推論サービスに 1 つのインスタンスを構成した場合でも、インスタンスリストにはキューサブサービスの追加インスタンスが表示されます。

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

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

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

• 推論サブサービスに 1 つのインスタンスがある場合、キューサブサービスにも 1 つのインスタンスがあります。ただし、キューサブサービスのパラメーターをカスタマイズした場合を除きます。

• 推論サブサービスのインスタンス数が 2 を超える場合、キューサブサービスのインスタンス数は 2 のままです。ただし、そのパラメーターをカスタマイズした場合を除きます。

• 非同期推論サービスの自動スケーリングを最小インスタンス数 0 で構成した場合、推論サブサービスが 0 にスケールダウンしても、キューサブサービスの 1 つのインスタンスはアクティブなままです。

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

ほとんどの場合、キューサブサービスのデフォルト構成で十分です。特定の要件がある場合は、JSON ファイルの最上位にある queue ブロックを使用してキューインスタンスを構成できます。次のコードに例を示します。

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

次のセクションでは、構成オプションについて詳しく説明します。

キューサブサービスのリソースを構成する

デフォルトでは、キューサブサービスのリソースは metadata セクションのフィールドに基づいて構成されます。ただし、一部のユースケースでは、このセクションで説明するように、リソースを個別に構成する必要がある場合があります。

• 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 を超える場合は、2 つ以上の CPU コアを構成します。

  • 本番環境では、キューサブサービスのメモリ割り当てを減らさないでください。

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

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

  非同期推論サービスを使用する場合、キューサブサービスインスタンスの数は、推論サブサービスインスタンスのランタイム数に基づいて自動的に調整されます。デフォルトの調整範囲は [1, min(2, 推論サブサービスインスタンスの数)] です。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 増加します。デフォルト値は 0 で、最大処理時間制限がないことを意味します。
      }
  }

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

  • 配信カウントが 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  # 出力キューの最大長を 8000 エントリに設定します。
         },
         "source": {
            "max_length": 2000  # 入力キューの最大長を 2000 エントリに設定します。
         }
      }
  }

• 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 を減らすことができます。

水平自動スケーリングを構成する