Skip to content

コンピューティング

すべての製品の基盤。任意の OCI イメージを、インスタンスごとに専用の Firecracker microVM で実行します。キーのあるインスタンスとないインスタンス、インスタンスがスリープするタイミングと復帰させるもの、そしてキューブとサンドボックスがその上にどう載っているか。

更新

コンピューティングは、Glac の製品が動く基盤です。公開・非公開を問わず任意の OCI イメージ(docker がビルドし、レジストリが配信する種類のもの)を、インスタンスで実行します。各インスタンスは専用の Firecracker microVM です。キューブとサンドボックスはその上に作られた製品で、ドライブは、インスタンスより長く残るディスクをインスタンスに与えます。

インスタンス

インスタンスは、実際に動く唯一のものです。キューブやサンドボックスが動かすものは、すべてインスタンスの中で動きます。

  • **専用の仮想マシン。**イメージのレイヤーはルートファイルシステムに展開され、Firecracker がプラットフォームのカーネルでそれを起動します。間に Docker も、2 つ目の仮想マシンもありません。コマンドとファイルは、ネットワークではなく、インスタンス内部のエージェントを通じて届きます。インスタンスの中のものはすべて 1 つのプロジェクトに属します。
  • **テンプレートのコピー。**テンプレートとは、一度起動して保存したイメージで、メモリ、デバイス、ディスクを含みます。インスタンスはそのコピーなので、テンプレートが起動したプログラムはどのインスタンスでもすでに動いており、使うメモリは、インスタンスが変更するまで共有されます。キューブのインスタンスは、そのバージョンのテンプレートのコピーです。イメージから作る最初のサンドボックスは、プラットフォームがイメージをプルしてテンプレートをビルドする間待ちます。それ以降はコピーです。
  • **サイズ。**vCPU とメモリで、プランで許される量を超えることはありません(無料プランでは 2 vCPU と 4 GiB、有料プランでは 8 vCPU と 16 GiB)。サイズを指定しなければ、各製品が独自のサイズを使います。サンドボックスの作成とバージョンとはを参照してください。
  • **キーのあるインスタンスとないインスタンス。**キーのないインスタンスは多数のうちの 1 つで、プラットフォームが選びます。キューブのリクエストは、現在のバージョンのインスタンスに送られ、インスタンスはリクエストが来ると起動します。キーのあるインスタンスには名前があり、そのキーを運ぶものはすべてその 1 つのインスタンスに届きます。サンドボックスはキー別インスタンスで、ID か名前で指定します。キューブもキー別インスタンスを持てます。キーを運ぶリクエスト(ヘッダー、またはパスのセグメント)は、すべてそのキー専用のインスタンスに届きます(キー別インスタンス)。

ステートレスとステートフル

コンピューティングは、インスタンスごとに、状態を保持することも保持しないこともできます。

  • **スリープ中のインスタンスは、持っていたものを保持します。**メモリ、プロセス、ディスク、ネットワーク上の位置です。復帰すると、開いていた接続もそのまま続きます。sleep_tier がスリープのしかたを示します。paused(ホストのメモリ上に保持)、saved(メモリをホストに保存)、またはディスクだけが残る disk で、その場合は次の呼び出しでディスクから起動し、実行中だったものは失われます。
  • ステートレス:キューブのキーのないインスタンス(後述の専用のドライブにデータを保持する場合を除く)。delete_after_ms(指定しなければ 1 時間。短くもできる)の間、何によっても稼働させられなかったインスタンスは削除され、次のリクエストでテンプレートから新しいインスタンスが作られます。残さなければならないものを置かないでください。
  • **ステートフル:保持されるインスタンス。**サンドボックスは、削除するまで、または設定したルール(expires_at、delete_after_idle_ms、プロジェクトの delete_after_idle_days)で削除されるまで残ります。スリープだけで削除されることはありません。キューブのキー別インスタンスは、そのキーを持つ次のリクエストのためにメモリとディスクごと保持され、keys.delete_after_idle_ms を設定すると、その時間スリープした後に削除されます。専用のドライブを持つキューブのインスタンスはちょうど 1 つで、削除するまで、ドライブを持つマシン上に保持されます(データを保持するサービス)。
  • どのインスタンスより長く残すべきものはドライブに置きます。ドライブは、書き込まれるそばからリージョンのオブジェクトストアにコピーされます。

リージョン

リージョンは na、eu、ap の 3 つです。サンドボックスとドライブは、それぞれ 1 つのリージョンに作られます。キューブは指定したすべてのリージョンで動き、リクエストには届いたリージョンで応答します。それぞれが作られる場所と、リージョンが引き受けられない場合に起きることは、リージョンにあります。

スリープと復帰

アイドル状態のインスタンスはスリープし、次にそれを必要とするものが復帰させます。復帰させるための呼び出しはありません。何をアイドルとみなすかは製品によって異なります。

キューブのインスタンス サンドボックス
稼働する条件 リクエストに応答している(gRPC の呼び出しのような開いている HTTP/2 ストリームは、終わるまで数える)、API 呼び出しが使っている、または中のプログラムがホールドしている。CPU、パケット、開いている接続、タイマーは数えない 呼び出しが待っている、プログラムが平均で 1 コアの 2% 以上を使っている、パケットがネットワークリンクを通っている、外部への TCP 接続を持っている、5 秒以内に期限が来るタイマーがある、または中のプログラムがホールドしている(スリープするタイミング)
スリープするまで アプリのトラフィックから決まる待ち時間。最長は sleep_after_ms:指定しなければ 3,000 ミリ秒(最大 600,000 ミリ秒) sleep_after_seconds 秒のアイドル:指定しなければ 30 秒、最小 1 秒。null ならスリープしない
復帰させるもの 次のリクエスト、または開いたままの WebSocket に届く新しいデータ 必要とするものすべて:コマンド、ファイル、ポートへのリンクに届くリクエスト、プロジェクトのネットワーク上での接続、既存の接続に届く新しいデータ、ターミナルでのキー入力、スナップショット、フォーク、タイマー
削除 キーがない場合:delete_after_ms(指定しなければ 1 時間。短くもできる)の間、何によっても稼働させられなかったとき 削除したとき、または expires_at、delete_after_idle_ms、プロジェクトの delete_after_idle_days による
  • **ホールド。**応答した後もまだ処理が残っているプログラム(空にすべきキュー、終えるべき書き込み)は、Unix ソケット /run/sbx/awake を通じて、自らインスタンスを稼働させ続けられます。最長は sleep_hold_max_ms(キューブでは scale.sleep_hold_max_ms。指定しなければ 30,000 ミリ秒)です。方法とコードは内部から稼働させ続けるにあります。
  • **復帰にかかった時間。**インスタンスを復帰させる必要があった API 呼び出しは、その時間をミリ秒単位で Server-Timing: wake;dur=… ヘッダーに返します。キューブのログでは、インスタンスを復帰させた各リクエストの行に記録されます(ログとメトリクス)。

マシンが失われたとき

応答しなくなり、しばらく連絡のないマシンは失われたと判断され、そのサンドボックスとキー別インスタンスは別のマシンに引き継がれます。同じリージョンに引き受けられるマシンがあればそこ、なければ次のリージョンです。それらは、マシンが最後にオブジェクトストアにコピーした状態で、そこから戻ってきます。

  • スリープ中だったものは、スリープしたときのまま、メモリとプロセスを保って戻ります。
  • 稼働中だったものは、ディスクから再起動します。実行中だったものは失われ、書き込んだものはコピーされた範囲で残っています(その範囲はドライブの設定によります)。引き継ぎが終わると、リクエストを待たずに新しいマシンで復帰させられます。チェックポイントがあれば、代わりに最新のチェックポイントからプロセスごと再開します。
  • 引き継がれないもの:オブジェクトストアにコピーのない、マシン自身のディスク上のボリュームを持つサンドボックスと、オブジェクトストアに何もコピーしないマシンのすべてのインスタンス。これらはマシンが戻ると再び使えるようになります。

その間、それらへのリクエストや、それらを必要とする呼び出しには 503 node_unavailable(retryable)が返ります。引き継がれたものはそれぞれ、プロジェクトの sandbox.moved イベントになり、reason は host_lost、with_processes がプロセスごと戻ったかどうかを示します。キーのないキューブのインスタンスは引き継がれず、アプリのほかのマシンが新しいインスタンスを作ります。

拠点全体が失われ、コントロールプレーンがそこにあった場合は、まず別の拠点にある 2 つ目のコントロールプレーンが処理を引き継ぎます。それが済むまで、API の呼び出しには 503 standby(retryable、Retry-After 付き)が返ります。

戻ってきたマシンは、オペレーターが再び受け入れるまでコントロールプレーンと通信できず、引き継がれたかもしれないものについては応答しません。リースが切れた時点から、そのサンドボックスへのリクエストは 3 秒待って 503 fenced が返ります。その間、キー別インスタンスとボリュームを持つサンドボックスは止められたままで、それ以外のサンドボックスのマシンは、外部とやり取りできないまま動き続けます。コントロールプレーンが応答すると、別の場所に引き継がれたものはそのマシン上では終了し(409 moved)、引き継がれなかったものはそこで再び処理されます。2 台のマシンから応答するサンドボックスはありません。

キューブとサンドボックス

2 つの製品は、同じインスタンスを 2 つの方法で使います。

  • **キューブ**は、イメージを固有のアドレスを持つサービスとして実行します。これがキューブで、API ではアプリ(/v1/apps)と呼びます。デプロイのたびにバージョンが作られ、バージョンのインスタンスはそのテンプレートのコピーです。プラットフォームはリクエストが来るとインスタンスを起動し、来なければ 1 つも残しません。すべてのキューブはプロジェクトのサービスです。サービスはプロジェクトのプライベートネットワーク上で互いを見つけ、まとめてデプロイされ、Compose ファイルから取り込むこともできます(サービスと Compose)。
  • **サンドボックス**は、AI エージェントが作業するためのキー別インスタンスを提供し、API(/v1/sandboxes)で作成して使います。サンドボックスでは、コマンドの実行、ファイルの読み書き、ターミナルの利用、スナップショットの取得とフォーク、SSH による接続、ネットワークのルールの設定ができます。
  • **基盤は 1 種類のインスタンス。**キューブのインスタンスはプロジェクトのサンドボックスの一覧に載り(ラベル app)、ほかのサンドボックスと同じく計測され、中でコマンドを実行することもできます。

料金

どのインスタンスも、どの製品のものであっても、同じ方法で計測されます。稼働中は、使った CPU 時間と確保したメモリ(128 MiB 刻み、ミリ秒単位)。スリープ中は CPU を使わず、ホストのメモリ上で一時停止しているインスタンスはそのメモリの分を支払い続け、メモリが保存されたインスタンスは保持するものの分だけを GB-月単位で支払います。プランによる同時稼働の制限は、アカウントのすべてのプロジェクトのサンドボックスとキューブのインスタンスを合わせて数えます。料金とプランと制限を参照してください。

ナビゲーション

キーワードを入力して検索…

↑↓ 移動↵ 選択Esc 閉じる