osFoundry / Platform
サーバーレス関数
アプリ単位のLambdaスタイル関数 ― 40msでコールドスタート、プロビジョニング不要、ミリ秒単位課金。
概要
osFoundryのサーバーレス関数は、単一のアプリに属するLambda型のバックエンドハンドラです。ワークスペースでアプリを作るとき、サーバーサイドのロジックを担う関数を関連付けられます。フォーム送信の処理、保存済みのキーを使った外部APIの呼び出し、クライアントに届く前のデータ変換といった処理を、サーバーを自分で立てたり運用したりせずに実装できます。プロビジョニングするものは何もありません。ハンドラを書いてアプリをデプロイすれば、関数のバックエンドもいっしょに立ち上がります。コールドスタートは約40msなので、アイドル後の最初のリクエストもウォーム状態に近い挙動になります。課金は予約した容量ではなく実行のミリ秒単位で行うため、アイドル状態の関数のコストはゼロです。\n\nosFoundryの内部では、関数は共有プールではなくアプリのインストールごとにプロビジョニングされます。したがって各アプリは、そのアプリのデータとシークレットにスコープされた独立の実行環境を持ちます。すべてのアプリにはインスタンスごとのPostgresスキーマ（CRUD、JSONBドキュメントストア、キーバリュー、pgvector）も同梱されているため、関数はネットワーク境界を越えて別のデータベースサービスに接続することなく、自分のアプリの状態を直接読み書きできます。これにより、アプリのフロントエンド、バックエンドのロジック、データが、チャットやエージェント、コード、ナレッジを動かすのと同じワークスペースの中で、一つのデプロイ単位としてまとまります。\n\nこれが効いてくるのは、小さなアプリで「バックエンドを足す」局面がたいてい最もコストのかかる部分だからです。ホストを選び、ランタイムを配線し、何かをウォームに保ち、トラフィックの有無にかかわらず料金を払う。アプリ単位のサーバーレス関数は、その一連の作業をアプリのデプロイに畳み込みます。osFoundryのBYOKの姿勢はそのまま保たれ、関数が呼び出すモデルには自分のAPIキーを使い、リセラーによる上乗せはありません。支払うのは関数が実際に使った計算量だけで、ミリ秒単位で計測されます。
主な機能
- コールドスタートは約40msなので、事前のウォームアップやインスタンスの常時稼働なしに、リクエストはウォームに近い低レイテンシで応答します
- プロビジョニング不要。アプリに対して関数を書いてデプロイすれば、osFoundryがそのタイミングでバックエンドを立ち上げます
- 課金は実際の実行のミリ秒単位で、関数がアイドルのあいだのコストはゼロです
- 共有プールではなくアプリごとに独立した関数実行環境を持ち、そのアプリのデータとシークレットにスコープされます
- 各アプリに同梱されたインスタンスごとのPostgresスキーマと組み合わさり、関数はアプリの状態を直接読み書きできます
活用例
- アプリ制作者：別のバックエンドサービスを立てることなく、ルームアプリにフォーム送信ハンドラや定期的なデータクリーンアップを追加する
- 個人開発者：保存済みのキーを使って関数からサードパーティAPIを呼び出し、シークレットがクライアントバンドルに載らないようにする
- データ中心のチーム：アプリ同梱のPostgresスキーマを読み書きする関数を動かし、レコードを集計してからUIに返す
よくある質問
osFoundryのサーバーレス関数のコールドスタートのレイテンシはどれくらいですか
コールドスタートは約40msで、アイドル状態の関数への最初のリクエストもウォームパスに近いレイテンシで返ります。その水準を出すために、関数を事前にウォームアップしたり、最小インスタンス数を稼働させ続けたりする必要はありません。
サーバーレス関数の課金はどうなりますか
課金は実際の実行時間のミリ秒単位です。関数に対する月額固定料金はなく、アイドルのあいだの課金もありません。支払うのはリクエストが消費した計算量だけです。関数が行うモデル呼び出しは引き続き自分のBYOKキーで動くため、その部分にリセラーの上乗せはありません。
サーバーを自分でプロビジョニングしたり運用したりする必要はありますか
ありません。プロビジョニング、スケール、常時稼働の維持は不要です。アプリに対して関数を書いてアプリをデプロイすれば、osFoundryがアプリ単位の独立したバックエンドを立ち上げます。各アプリは、そのアプリのデータとシークレットにスコープされた独自の関数環境を持ち、アプリに同梱されたPostgresスキーマを直接読み書きできます。