> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# オーケストレーション

> セッションがキューに入ると、自動的にマシンをプロビジョニングしてワーカーを実行します

オーケストレーターは、アウトポストで待機中のセッションがないか Outposts API を監視し、セッションごとに VM またはコンテナをプロビジョニングして、その中でワーカーを起動します。このページでは、キューのポーリング、セッションの引き取り、ワーカーの実行、マシンの終了といったオーケストレーションのループについて説明します。

すでに用意してあるマシンでセッションを処理したいだけであれば、まずは [quickstart](/ja/onboard-devin/outposts/quickstart) をご覧ください。オーケストレーターは不要です。サポート対象のプラットフォームで実行する場合は、[統合](/ja/onboard-devin/outposts#integrations) によってこのループがすでに実装されていることがあります。API と CLI の全体像については、[reference](/ja/onboard-devin/outposts/reference) を参照してください。

<Note>
  Kubernetes で実行する場合は、[devin-outpost-k8s](https://github.com/CognitionAI/devin-outpost-k8s)
  を利用できます。これは、このループを代わりに実装するオープンソースのオペレーターです。キューを監視し、
  保留中のセッションを引き取り、それぞれを任意の認定クラスター (GKE、EKS、...) 上で
  ワーカー Pod として実行します。独自のオーケストレーターを構築する代わりに、
  付属の Helm チャートを使ってインストールしてください。
</Note>

<div id="the-core-flow">
  ## コアフロー
</div>

<div id="1-register-an-outpost">
  ### 1. アウトポストを登録する
</div>

アウトポストは、インフラストラクチャ上で複数のワーカーが処理する、名前付きのセッションキューです (たとえば、`rhel`、`gpu-h200`、`my-outpost` など) 。`devin worker outpost create` で作成します。

```bash theme={null}
devin worker outpost create <name> --platform <platform> --description "..."
```

登録が完了すると、セッション開始時に、そのアウトポストが Devin Cloud のマシンオプションとして表示されます (Ubuntu、Windows などと同様) 。それを対象とするセッションは、ワーカーが引き取るまで、そのキューで待機します。

<Note>
  fleet API では、アウトポストは `outposts` リソースとして表され、
  アカウント単位でスコープされます (そのアカウント内のすべての組織で共有) 。詳しくは
  [outposts endpoints](/ja/onboard-devin/outposts/reference#outposts) を参照してください。
</Note>

<div id="2-watch-the-fleet-api-for-waiting-sessions">
  ### 2. fleet API を監視して待機中のセッションを確認する
</div>

オーケストレーターは、担当するアウトポストの待機中のセッションを一覧表示します。

```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&phase=pending"
```

その後、Server-Sent Events (SSE) のwatchを使って表示を最新の状態に保ち、listの最後のcursorから再開します:

```bash theme={null}
curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&watch=true&cursor=<cursor>"
```

これは、Kubernetesスタイルの標準的な list-then-watch パターンです。レスポンスのカーソルを使ってリストをページングし、次にリストの続きから watch を開始します。その際、変更を取りこぼさずに再接続できるよう、各イベントのカーソルを永続化します。配信は at-least-once であるため、`metadata.session_id` で upsert し、重複は許容してください。クエリパラメータ、レスポンス形式、ページネーションの完全なセマンティクスについては、[List queued sessions](/ja/onboard-devin/outposts/reference#list-queued-sessions) と [Watch for changes](/ja/onboard-devin/outposts/reference#watch-for-changes) を参照してください。

<div id="3-claim-before-provisioning">
  ### 3. プロビジョニング前に引き取る
</div>

セッション用のマシンを起動する前に、他のワーカーに取られないようアトミックに引き取ります。`acceptor_id` を指定します。これは、ワーカーが自身で申告する識別子です:

```bash theme={null}
curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"acceptor_id": "worker-1"}' \
  "https://api.devin.ai/opbeta/outposts/devins/{session_id}/claim"
```

引き取りはアトミックに行われます。別のワーカーが先にセッションを引き取っていた場合は、`409` が返されます。引き取ると、サーバーが割り当てた引き取り期限 (`status.claim_deadline`) までにワーカーの準備が整うことが前提となります。期限切れになった引き取りは、自動的にキューに戻ります。プロビジョニングに失敗した場合は、セッションがすぐにキューへ戻るように、[引き取りを解除](/ja/onboard-devin/outposts/reference#release-a-claim)してください。

<div id="4-spawn-a-machine-and-run-the-worker">
  ### 4. マシンを起動してワーカーを実行する
</div>

引き取った各セッションごとに、使用するイメージから VM またはコンテナをプロビジョニングします。その中で、セッションのリポジトリがすでにチェックアウトされているディレクトリからワーカーを実行します:

```bash theme={null}
cd /path/to/repos
devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id>
```

API で引き取る際に使用したものと同じ `--acceptor-id` を渡し、`--token` または `DEVIN_OUTPOSTS_TOKEN` でトークンを指定します ([フラグの一覧](/ja/onboard-devin/outposts/reference#devin-worker-start)を参照) 。ワーカーは Devin のクラウドに接続してセッションを準備完了としてマークし、ツール呼び出しの実行を開始します。

<div id="5-terminate-the-machine-when-the-worker-exits">
  ### 5. ワーカーの終了時にマシンを終了する
</div>

`devin worker start` が終了すると、セッションは完了しているか、一時停止されています。VM またはコンテナを終了してください。アウトポストが再開可能な場合は、終了前にマシンのスナップショットを作成しておけば、セッション再開時に復元できます。

オーケストレーターは、引き取ったセッションとその状態を追跡できます：

```bash theme={null}
curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?phase=claimed&acceptor_id=worker-1"
```

各エントリでは、`status.session_status` に `pending`、`running`、`suspended`、または `terminated` のいずれかが示されます。

<div id="centralization-free-scheduling">
  ## 中央集約なしのスケジューリング
</div>

<Note>
  約 16 台を超えるコーディネーター (同じアウトポストを監視してセッションを引き取るワーカーまたはオーケストレーター) を稼働させる予定がある場合は、まずアカウントチームに連絡してください。台数が増えると引き取り競合とキュー読み取り負荷が大きくなるため、それに対応できるようアウトポストが適切にプロビジョニングされていることを確認したいからです。
</Note>

フリートの運用に中央スケジューラーは必要ありません。キュー API は、多数の独立したワーカーが互いに通信せずに同じアウトポストを処理できるよう設計されています。

* **協調のための仕組みは引き取りだけです。** 各ワーカーは独立してキューを監視し、保留中のセッションの引き取りを競います。引き取りはサーバー上でアトミックに行われる compare-and-swap で、勝つワーカーは必ず 1 台だけです。負けた側はすべて `409` を受け取り、そのまま次の保留中セッションに進みます。引き取り競争に負けるのは正常な動作であり、エラーではありません。
* **各ワーカーは固有の ID を持ちます。** `acceptor_id` によって、ワーカーの引き取り、更新、再起動後の復旧はそのワーカー自身に限定されます。`devin worker start` はマシンごとにこれを自動生成して永続保存するため、フリートで ID を設定する必要はありません。acceptor ID (またはコピーしたワーカーデータディレクトリ) を複数のマシンで共有してはいけません。衝突したワーカー同士で互いの引き取りを奪い合ってしまいます。
* **障害は自動的に回復します。** ワーカーが引き取り後に停止しても、その引き取りは claim deadline で期限切れになり、セッションは別のワーカーが拾えるようキューに戻ります。フリート全体でのヘルス監視は不要です。

つまり、スケールアウトとは同じアウトポストを対象にしたワーカーをより多くのマシンで実行するだけです。N 台のマシンで N 個のセッションを同時に処理し、残りは保留のまま待機します。

<div id="building-a-custom-orchestrator">
  ## カスタムオーケストレーターの構築
</div>

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