osFoundry / Platform
コンテナコンピュート
永続プロセスが必要？ ランタイムをコンテナに切り替え。同じアプリ、別モード。
概要
コンテナ実行は、osFoundryで作ったアプリのための実行モードです。多くのアプリは、リクエストが来たときに起動して応答し、すぐに終了する短命なプロセスとして問題なく動きます。しかし、なかには動き続けていてほしいワークロードもあります。接続を張り続けるWebSocketサーバー、キューを処理し続けるバックグラウンドワーカー、自前の時計で動くスケジューラ、リクエストの合間もメモリ上の状態を温めておくバックエンドといったものです。こうした場合は実行モードをコンテナに切り替えると、同じアプリが毎回起動し直すのではなく、常駐プロセスとして動き続けます。
重要なのは、それが同じアプリだということです。書き直す必要も、フォークする必要も、別のサービスへ移す必要もありません。コード、ルート、配線はそのままで、変えるのは実行のされ方だけです。だからコンテナモードは、機能がそれを必要としたときに下せる判断であって、最初から背負い込むアーキテクチャではありません。まずは軽量な短命モードでアプリを始め、状態を保持しなければならない部分を足した瞬間にコンテナへ切り替えればよいのです。
この仕組みは、チャット、エージェント、アプリ、コード、データを別々のホスティング契約に散らばらせず、ひとつのワークスペースにまとめておくというosFoundryの考え方にそのまま沿っています。osFoundryはBYOKでローカルファーストなので、SaaSの席課金でくるまれることなく、自分のアプリを自分の条件で動かせます。コンテナ実行はそれをバックエンドにも広げます。アプリがステートレスな補助役から、動き続ける必要のあるものへと育ったとき、そのアプリが暮らす場所はワークスペースの中にすでに用意されているのです。
主な機能
- osFoundryのどのアプリも、コードを変えずに短命モードとコンテナモードを切り替えられる
- WebSocketサーバー、バックグラウンドワーカー、スケジューラ、デーモンといった常駐プロセスを動かせる
- 呼び出しごとにコールドスタートせず、リクエストの合間もメモリ上の状態を温めておける
- 実行モードはアプリ単位で選べるので、常駐プロセスが要る機能にだけコストをかけられる
- バックエンドは、チャットやエージェント、コード、データと同じワークスペースの中で動く
活用例
- 開発者: ライブ更新のためにWebSocket機能を追加したアプリを、接続を張り続けられるようコンテナに切り替える
- 自動化の作り手: ジョブキューを処理してスケジュールで動くバックグラウンドワーカーには、決してスリープしないプロセスが要る
- チームリード: ステートレスで始めた試作アプリが、温かいキャッシュと常駐バックエンドを必要としたところで、作り直さずにコンテナモードへ移した
よくある質問
アプリをデフォルトの実行モードではなくコンテナ実行に切り替えるべきなのはどんなときですか。
リクエストの合間も何かを生かしておく必要があるときです。WebSocketのような張り続ける接続、バックグラウンドやスケジュール実行のワーカー、デーモンプロセス、呼び出しごとに失いたくないメモリ上の状態などがある場合です。リクエストに応えて終了するだけのアプリなら、軽量な短命モードのほうが向いています。
コンテナとして動かすには、アプリを書き直す必要がありますか。
いいえ。モードが違うだけで同じアプリです。実行モードの設定を切り替えれば、既存のコードが常駐プロセスとして動きます。それこそが狙いで、アプリはシンプルに始め、ある機能が実際に必要になったときだけコンテナへ移せます。
これはosFoundryがBYOKでローカルファーストであることとどう関係しますか。
コンテナ実行はアプリのバックエンドがどこで動くかという話なので、osFoundryの他の部分とそのまま並びます。鍵もモデルもデータも自分の管理下にあり、アプリのバックエンドは別のホスティング契約ではなく、チャットやエージェント、コード、データと同じワークスペースの中で動きます。