デプロイ先を選ぶ
Agent Fleet を何の上で動かすかを決めます。あとから変えることもできますが、手間がかかるので、最初に 20 分かけて選んでください。
| あなたが決めること | 決め手 |
|---|---|
| 形態（compose・native・ec2-single・ecs・ecs-ec2・kubernetes） | 特に理由がなければ Linux 1 台の compose。ほかは下の表で選ぶ |
| AWS なら、ec2-single か ECS か | 費用ではなく、隔離とメンバーごとの障害の分離が要るかどうか |
| ECS なら、Fargate か ecs-ec2 か、出口の経路 | 起動の回数と、外向きの通信を記録・制限したいかどうか |
各形態に何ができるかは 配備形態 にあります。このページは選び方だけです。
まずは compose
Section titled “まずは compose”特に理由がなければ、Linux 1 台の compose を選んでください。 既定の形態で、いちばん使われていて、ほかの形態はどれもこれと比べて説明しています。 必要なのは、Docker の入ったホスト 1 台、ドメイン名、1 時間です。
ほかの形態を選ぶとき
Section titled “ほかの形態を選ぶとき”| こういうとき | 選ぶ形態 | 理由 |
|---|---|---|
| その機械に Docker を入れられない | native | コンテナを使いません。1 人で使うときだけ です。コンテナの境界がないので、共有のモードでは起動を拒否します |
| 機械が Mac（Apple Silicon） | macOS 用の overlay を重ねた compose、または Linux VM の中の native | 1 人で使うときだけ で、127.0.0.1 で動かします。colima・OrbStack・Docker Desktop と、Lima・OrbStack の VM での native で確かめています。Intel の Mac は対象外です。手順は compose の runbook の「macOS」 |
| AWS に置きたい、少人数、費用を抑えたい | ec2-single | 中身は VM の上の compose です。別のランタイムではありません |
| タスク単位の隔離、メンバーごとの障害の分離、イメージの順次の入れ替えが要る | ecs | 得られるのは隔離で、節約ではありません |
| 上に加えて、起動の速さとディスクの性能が要る | ecs-ec2 | インスタンスのプールと、メンバーごとの永続ディスクを使います |
| 基盤が Kubernetes か Google Cloud で、使わないときは 0 台に縮むワークスペースが欲しい | kubernetes（プレビュー） | 自分のクラスタの上で、ワークスペースはメンバーごとの永続ボリュームを持つ Pod になります。最初の対象は GKE Standard です |
AWS の費用で選ぶ
Section titled “AWS の費用で選ぶ”ECS のほうが安くなると思われがちですが、実際は逆です。月額の目安は次のとおりです。
| 人数 | ec2-single | ECS（平日 8 時間） | 判断 |
|---|---|---|---|
| 5 人まで | $87（t3.large、30 GB のディスクと固定 IP を含む） | $154 | ec2-single で決まり。ECS は床の $110 を取り戻せません |
| 15 人まで | $283（8 vCPU / 32 GB） | $240 | ほぼ同じ。運用の手間と隔離の要件で決めます |
| 20 人 | $283〜368 | $285 | ほぼ同額。ここが分かれ目で、ここから先は費用以外で決まります |
| 20 人・24 時間 365 日 | $283 | $830 | 常に動かすなら、VM 1 台にまとめるほうがずっと安くなります |
- 費用で ECS が勝つ場面は、ほとんどありません。 ECS を選ぶ理由は、タスク単位の隔離、メンバーごとの障害の分離、イメージの順次の入れ替え、インスタンスメタデータとロールの締め方です
- 使わないときに 0 台に縮むしくみ（scale-to-zero）は安くするためのものではなく、ECS の割増を「20 人で VM と同じくらい」まで薄めるためのものです
- 少人数の 1 チームなら ec2-single です。中身は VM の上の compose なので、運用は compose と同じです
- 隔離やメンバーごとの可用性が要るなら ECS です。ただし床の $110 と、上の数字はアイドルの自動停止が実際に効いていて初めて成り立つことを引き受けてください
Fargate の起動は NAT で課金される
Section titled “Fargate の起動は NAT で課金される”上の表には入っていない費用です。
- AWS の Fargate のワークスペースはイメージのキャッシュを持たないので、起動のたびにワークスペースのイメージ全体（圧縮して約 918 MiB）を NAT ゲートウェイ経由で取得 します
- NAT は処理したデータ量で課金します。1 GB あたり $0.045〜0.062 とすると、1 回の起動で約 $0.04〜0.06、1 日 100 回の起動で月に約 $120〜180 です
- 料金はリージョンで違います。自分のリージョンの値は Amazon VPC の料金 の NAT Gateway の項で確かめてください
- 自前のエンジン（
60-engines）が Hugging Face や Civitai からモデルを取得する通信も、NAT を通ります
起動が多いなら ecs-ec2 を選んでください。
| 起動のしかた | 取得するもの |
|---|---|
| 同じイメージを持つ既存のスロットで起動する | レイヤーを取り直しません。NAT の通信は合計 65 MiB ほどです |
| 新しいスロット、作り直したスロット、キャッシュにないとき、イメージを更新したとき | イメージを取り直します。ただしワークスペースは専用のサブネットにあるので、レイヤーは NAT ではなく無料の S3 の VPC エンドポイントを通ります。これはテスト用の配備でだけ確かめています |
- golden snapshot は別のものです。短くするのは CLI のインストールの時間で、NAT の通信ではありません
- ワークスペースは、NAT ゲートウェイの代わりに egress ゲートウェイから外へ出ることもできます（次の節）
- 設定は deploy/aws/ecs/README.md にあります
AWS の出口の経路を選ぶ
Section titled “AWS の出口の経路を選ぶ”00-network の EgressRoute で、ワークスペース がインターネットへ出る経路を決めます。Control Plane と AWS のホストは、どちらを選んでも NAT ゲートウェイを使います。
NAT ゲートウェイ（nat-gateway、既定） |
egress ゲートウェイ（gateway） |
|
|---|---|---|
| 記録 | しません。管理 の「通信」タブは空のままです | ワークスペースの接続ごとに、名前とアドレスをワークスペースに紐づけて記録します。「通信」タブに出るのはホストごとの件数で、紐づけた記録は GET /api/admin/egress/events で読めます |
| 許可リスト | 効きません | log-only か enforce |
| 時間あたりの費用 | NAT ゲートウェイ | NAT ゲートウェイ（Control Plane とホストが使い続けます）と、小さなインスタンスとそのアドレス |
| GB あたりの費用 | ワークスペースの全通信（S3 を含む）に NAT の処理料金 | ワークスペースの通信にはかかりません。通常のデータ転送料金だけです |
| 運用 | AWS が管理します | 運用するインスタンスがあります。入れ替えの間の数分、ワークスペースは外へ出られません |
| 可用性 | AWS の管理、1 つのアベイラビリティーゾーン | 1 つのアベイラビリティーゾーンに 1 台。自動で入れ替えます |
| HTTP 以外の通信（SSH の git、データベース） | 使えます | enforce では、管理者が宛先とポートを挙げたもの（tcp: のエントリ）だけ通ります。どちらのモードでも記録します |
| 相手の許可リストに登録するアドレス | NAT ゲートウェイのもの | 2 つ。NAT ゲートウェイのもの（Control Plane とホスト）と、ゲートウェイのもの（ワークスペース）。後者は切り替える前に確保して登録できます |
- egress ゲートウェイは新しく、テスト用の配備でだけ確かめています。本番ではまだ使っていません
pause.shはゲートウェイも止め、同じ送信元のアドレスのまま戻します- 設定と制約は deploy/aws/ecs/README.md の「Egress gateway」にあります
Kubernetes を選ぶとき、選ばないとき
Section titled “Kubernetes を選ぶとき、選ばないとき”選ぶとき
- 組織がすでに Kubernetes のクラスタでものを動かしている
- Google Cloud で、AWS の ECS と同じもの（ワークスペースごとの Pod、クラスタによる隔離、動いている間だけの容量）が欲しい
引き受けるもの
- まだ使っていなければ、Terraform と kustomize を覚えること
- ノードプール・マネージドなデータベース・ロードバランサという、ECS と同じ種類の床の費用
- ワークスペースを隔離するためにクラスタが満たす前提条件。runbook で 1 つずつ確かめます
選ばないとき
- 少人数で費用を抑えたい（どのクラウドでも、VM 1 台のほうが安くなります）
- 名前空間とノードプールを専用に割けないクラスタ
- NetworkPolicy を強制しないネットワークプラグインのクラスタ
ホームは 1 つのゾーンに置かれ、バックアップの対象に入りません。
あとから変えにくいもの
Section titled “あとから変えにくいもの”| もの | 理由 |
|---|---|
AF_MASTER_KEY |
なくすと、保存した資格情報が二度と復号できなくなります。データとは別の金庫に置き、バックアップには入れません |
DATA_DIR の絶対パス |
復元は basename に依存します。移すのは設定の変更ではなく、手順です |
| アップグレード | 一方通行です。ダウングレードはできないので、毎回先にバックアップを取ってください |
ドメイン・サインインの方法・上限・大きさは、ふつうの設定としてあとから変えられます。
- セルフホストの全体像：形態ごとの runbook
- インストールする
- 配備形態
エージェント向け
この指示をエージェントに送ると、このページを読ませられます。
https://agent-fleet.org/docs/ja/operate/choose/index.md を読んで