メインコンテンツへスキップ
オーケストレーターは、アウトポストで待機中のセッションがないか Outposts API を監視し、各セッションごとに VM またはコンテナをプロビジョニングして、その中でワーカーを起動します。このページでは、キューのポーリング、セッションの引き取り、ワーカーの実行、マシンの停止・削除からなるオーケストレーションループについて説明します。 すでに用意してあるマシンでセッションを処理したいだけであれば、まずは quickstart をご覧ください。オーケストレーターは不要です。サポート対象のプラットフォームで実行している場合は、統合 がこのループをすでに実装していることがあります。API と CLI の全体については、reference を参照してください。
Kubernetes 上で実行したいですか？ devin-outpost-k8s は、このループを代わりに実装してくれるオープンソースのオペレーターです。キューを監視し、 保留中のセッションを引き取り、認定済みクラスター (GKE、EKS、…) 上で各セッションを ワーカーポッドとして実行します。独自のオーケストレーターを構築する代わりに、 付属の Helm chart を使ってインストールしてください。

​
基本フロー

​
1. アウトポストを登録する

アウトポストは、お使いのインフラストラクチャ上で多数のワーカーが処理する、名前付きのセッションキューです (たとえば rhel、gpu-h200、my-outpost など) 。devin worker outpost create で作成します。
登録が完了すると、セッションの開始時に、そのアウトポストが Devin Cloud のマシンオプション (Ubuntu や Windows などと並ぶ) として表示されます。そのアウトポストを対象とするセッションは、ワーカーが引き取るまで、そのキューで待機します。
fleet API では、アウトポストは outposts リソースとして表され、アカウント単位でスコープされます (そのアカウント内のすべての組織で共有されます) 。詳しくは、 outposts エンドポイントをご覧ください。

​
2. fleet API で待機中のセッションを監視する

オーケストレーターは、担当するアウトポストの待機中のセッションを一覧表示します:
その後は、list の最後の cursor から再開しながら、Server-Sent Events (SSE) の監視を使って表示を最新の状態に保ちます:
これは、Kubernetesで一般的な「list してから監視する」パターンです。レスポンスの cursor を使って list をページングし、その後、list の続きから監視を開始します。また、変更を取りこぼさずに再接続できるよう、各イベントの cursor を永続化します。配信は少なくとも 1 回行われるため、metadata.session_id で upsert し、重複を許容してください。クエリパラメータ、レスポンス形式、pagination の詳細な仕様については、List queued sessions と Watch for changes を参照してください。

​
3. プロビジョニング前に引き取る

セッション用のマシンを起動する前に、ほかのワーカーに取得されないよう、アトミックに引き取ります。acceptor_id を渡します。これは、ワーカー自身が申告する識別情報です：
引き取りはアトミックです。別のワーカーが先にそのセッションを引き取っていた場合は、409 が返されます。引き取ると、サーバーによって割り当てられた引き取り期限 (status.claim_deadline) までにワーカーの準備が整うことが保証されます。期限切れになった引き取りは自動的にキューへ戻ります。プロビジョニングに失敗した場合は、セッションがすぐにキューへ戻るように、引き取りを解放してください。

​
4. マシンを起動してワーカーを実行する

取得済みの各セッションについて、イメージを使って VM またはコンテナをプロビジョニングします。その中で、セッションのリポジトリがすでにチェックアウトされているディレクトリからワーカーを実行します：
API で引き取る際に使用したものと同じ --acceptor-id を指定し、トークンは --token または DEVIN_OUTPOSTS_TOKEN で指定します (フラグの完全な一覧を参照) 。ワーカーは Devin のクラウドに接続し、セッションを準備完了にして、ツール呼び出しの実行を開始します。

​
5. ワーカーが終了したらマシンを終了する

devin worker start が終了した時点で、セッションは終了しているか、一時停止されています。VM またはコンテナを終了してください。アウトポストが再開可能な場合は、終了前にマシンのスナップショットを作成しておくと、セッション再開時に復元できます。 オーケストレーターは、引き取ったセッションとその状態を追跡できます：
各エントリの status.session_status には、pending、running、suspended、または terminated が示されます。

​
中央集約なしのスケジューリング

約16台を超えるコーディネーター (アウトポストを監視して引き取りを行うワーカーまたはオーケストレーター) を 運用する予定がある場合は、まずアカウント担当チームにご相談ください。大規模な フリートでは引き取りの競合やキュー読み取りの負荷が増大するため、 それに対応できるようアウトポストが適切にプロビジョニングされていることを 事前に確認したいためです。
フリートの運用に中央スケジューラーは必要ありません。キュー API は、多数の独立したワーカーが互いに通信することなく、同じアウトポストを処理できるよう設計されています。
  • 調整の仕組みは引き取りだけです。 各ワーカーは独立してキューを監視し、保留中のセッションの引き取りを競って行います。引き取りはサーバー上で原子的な compare-and-swap として処理されるため、成功するワーカーは必ず1台だけです。失敗したワーカーはすべて 409 を受け取り、そのまま次の保留中セッションに進みます。引き取り競争に負けることは通常の動作であり、エラーではありません。
  • 各ワーカーはそれぞれ固有の ID を持ちます。 acceptor_id によって、ワーカーの引き取り、更新、再起動後の復旧はそのワーカー自身にのみ紐づけられます。devin worker start はマシンごとにこれを自動生成して保存するため、フリート側で ID を設定する必要はありません。acceptor ID (またはコピーしたワーカーデータ directory) を複数のマシンで共有しないでください。衝突したワーカー同士で互いの引き取りを奪い合ってしまいます。
  • 障害は自動的に復旧します。 ワーカーが引き取り後に停止した場合、その引き取りは引き取り期限に達すると失効し、セッションはキューに戻って別のワーカーが取得できるようになります。フリート全体でヘルス状態を追跡する必要はありません。
つまり、スケールアウトは、同じアウトポストを参照するワーカーをより多くのマシンで実行するだけです。N 台のマシンで N 個のセッションを同時に処理でき、それ以外は保留のまま待機します。

​
カスタム オーケストレーターの構築

devin worker start で実行される処理はすべて fleet API から直接利用できるため、CLI を完全に置き換えられます。devin-remote バイナリを Devin の静的配布元から取得し、ドキュメントに記載された環境で自分で起動してください。詳しくは、リファレンスの Remote binary distribution と spawn contract を参照してください。