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

​
コアフロー

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

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

​
2. fleet API を監視して待機中のセッションを確認する

オーケストレーターは、担当するアウトポストの待機中のセッションを一覧表示します。
その後、Server-Sent Events (SSE) のwatchを使って表示を最新の状態に保ち、listの最後のcursorから再開します:
これは、Kubernetesスタイルの標準的な list-then-watch パターンです。レスポンスのカーソルを使ってリストをページングし、次にリストの続きから watch を開始します。その際、変更を取りこぼさずに再接続できるよう、各イベントのカーソルを永続化します。配信は at-least-once であるため、metadata.session_id で upsert し、重複は許容してください。クエリパラメータ、レスポンス形式、ページネーションの完全なセマンティクスについては、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 (またはコピーしたワーカーデータディレクトリ) を複数のマシンで共有してはいけません。衝突したワーカー同士で互いの引き取りを奪い合ってしまいます。
  • 障害は自動的に回復します。 ワーカーが引き取り後に停止しても、その引き取りは claim deadline で期限切れになり、セッションは別のワーカーが拾えるようキューに戻ります。フリート全体でのヘルス監視は不要です。
つまり、スケールアウトとは同じアウトポストを対象にしたワーカーをより多くのマシンで実行するだけです。N 台のマシンで N 個のセッションを同時に処理し、残りは保留のまま待機します。

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

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