LoginSignup
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@reoring(れおりん)inCraftsman Software

Vercel Fluid Compute徹底解説 – サーバーレスをさらに進化させる新モデル

Posted at

TL;DR

Fluid Computeは、Vercelが新たに提供するサーバーレスの実行モデルです。従来のサーバーレスと同様に必要なときだけ関数を起動しつつ、1つの関数インスタンスで複数リクエストを同時処理できる「ミニサーバー」のような動作を実現します (従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey) (従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey)。これによりコールドスタートの削減やリソースの有効活用によって最大85%のコスト削減効果が報告されています (Introducing Fluid compute: The power of servers, in serverless form - Vercel)。ストリーミング応答やレスポンス後の非同期処理にも対応し、フロントエンド・バックエンド・インフラの各エンジニアに嬉しいメリットをもたらします。

Fluid Computeとは何か？

Fluid Computeは 「サーバーのパワーをサーバーレスの形で提供する」 ことを掲げた新しい実行インフラです (Fluid compute)。従来のサーバーレスでは「1リクエスト＝1関数インスタンス」で実行し、処理終了後はインスタンスを破棄します。しかし、このモデルではリクエスト待ちや外部API呼び出し待機中のアイドル時間にもインスタンスが占有され、非効率でした (従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey) (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。Fluid Computeでは以下の原則に基づき、この非効率を解消しています (Introducing Fluid compute: The power of servers, in serverless form - Vercel) (Introducing Fluid compute: The power of servers, in serverless form - Vercel):

要するに、Fluid Computeはサーバーレスの自動スケーリングと課金モデルはそのままに、サーバー常駐プロセスの柔軟性を取り込んだハイブリッドモデルです (Introducing Fluid compute: The power of servers, in serverless form - Vercel)。開発者は今まで通りVercel Functionsを使えばよく、特別なコード変更なしにこの恩恵を受けられます (従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey)。

利点とユースケース

Fluid Computeによって得られる主な利点を、フロントエンド・バックエンド・インフラ各視点のユースケースと合わせて見てみましょう。

  • フロントエンドエンジニア向け: リアルタイムなUXを提供しやすくなります。たとえばサーバーサイドレンダリングしたHTMLや、チャットの逐次応答（「ChatGPT」のような一文字ずつ思考している風の出力）をストリーミング送信できます (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。Fluid Computeではレスポンス送信後も関数が即終了しないため、res.write()でチャンクを送り続けるような実装が可能です。加えて、関数の起動遅延が減り応答時間が安定するため、ユーザーにストレスのないインタラクティブなUIを提供できます。

  • バックエンドエンジニア向け: 外部APIやデータベース呼び出しが多いサービスでスループットとコストが大幅に改善します。従来はリクエストごとに別々の関数環境を起動していたため、たとえば複数ユーザからの同時リクエストがすべて外部API待ちになると待ち時間にも課金が発生していました (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。Fluid Computeでは一つの関数インスタンスが待機中に別のリクエスト処理を並行実行できるため、この待ち時間コストをほぼゼロにできます (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。実際、10並列の外部API待ち処理をFluid環境にまとめることで課金対象時間が1/10になり、約90%のコスト削減という試算もあります (Fluid compute)。また関数グローバルな変数や接続をインスタンス間で共有維持できるため（例えばデータベースコネクションを使い回す等）、余計な初期化のオーバーヘッドも減らせます。

  • インフラエンジニア向け: 可用性とスケーラビリティの担保がより簡単になります。Fluid Computeには標準でマルチリージョンのフェイルオーバー機能が組み込まれており、デプロイ先リージョンに障害が起きても自動で他地域へリクエストをリルート可能です (Fluid compute)（プロプランで最大3箇所、エンタープライズでは全リージョンがバックアップ対象 (Fluid compute)）。これにより高可用システムを構築する手間が大幅に削減されます。また、ワークロードに応じて同時実行数やリソース配分を動的調整するため、負荷予測や手動チューニングなしでも安定したパフォーマンスを発揮します (Fluid compute)。結果としてオーバープロビジョニングの削減によるコスト効率も向上し、組織全体としてのインフラ最適化に繋がります。

以上のように、Fluid Computeは低レイテンシーでリッチなフロント体験、高効率なバックエンド処理、信頼性の高いインフラ運用をそれぞれ支援します。特に大規模言語モデル(LLM)を扱うAIアプリケーションでは外部API応答待ち時間が長くなりがちですが、そのようなモダンなユースケースで真価を発揮するでしょう (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。

実装方法とコード例

実際にFluid Computeを試してみましょう。現在、Node.js（14以降）とPythonランタイムで利用可能です (Fluid compute)。設定はとても簡単で、既存のコードを変更する必要はありません (従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey)。以下の手順でプロジェクトにFluid Computeを有効化できます。

  1. Vercelのダッシュボードで対象プロジェクトを開きます。
  2. Settings タブ内の Functions セクションに移動します。
  3. Fluid Compute の項目までスクロールし、トグルスイッチをオンにします (Fluid compute)。
  4. プロジェクトを再デプロイします。これで新しいデプロイからFluid Computeが適用されます。

有効化後は、新しいデプロイの関数が自動的にFluidモデルで実行されます。例えばNext.jsのAPIルートでストリーミング応答を行う簡単なコードは以下のようになります。

// pages/api/time-stream.ts
import type { NextApiRequest, NextApiResponse } from 'next';

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  // ストリーミング可能なContent-Typeとキャッシュ無効化ヘッダをセット
  res.setHeader('Content-Type', 'text/event-stream; charset=utf-8');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  // クライアントへ現在時刻を5回ストリーム送信する
  for (let i = 1; i <= 5; i++) {
    const now = new Date().toISOString();
    res.write(`data: ${now}\n\n`);  // SSEのdataフレーム送信
    await new Promise((r) => setTimeout(r, 1000));  // 1秒待つ
  }

  res.end();  // ストリーム終了

  // レスポンス送信後の後処理（ログ出力など）
  console.log('Stream finished at', new Date().toLocaleTimeString());
}

上記はシンプルな例ですが、res.write()で逐次データを送ることでクライアント側ではリアルタイムに内容を受け取れます。res.end()後にログを出力する部分はポストレスポンス処理の例示です。Fluid Computeではレスポンス返却後も関数実行がすぐに終了しないため、このような後処理も可能です (Fluid compute)。

実行中の関数インスタンスは複数リクエストを同時に処理する可能性がある点にも注意してください。例えば別タブからこのAPIをほぼ同時に叩いた場合でも、Fluid Compute有効時には単一インスタンス内で2つのリクエストループが並行して動くことがありえます。結果として一方のres.write()実行中に他方のリクエストも進行し、効率的に処理されます。コード上では特別な対応をしなくても、Fluidの仕組みにより自動的にリソースが共有・並行利用される点がポイントです (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community) (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。

なお、Fluid Compute有効化に伴い関数のデフォルト実行時間上限が延長されています（Proプラン/Enterpriseでは最大800秒まで） (Fluid compute)。長時間のバッチ処理やストリーミングにも耐えられるため、必要に応じてvercel.jsonや関数内の設定でタイムアウト値(maxDuration)を調整してください。またデプロイ地域を複数指定するマルチリージョンデプロイにも対応しているので、グローバルなユーザー相手のAPIでも高速応答が期待できます。

AWS LambdaやCloudflare Workersとの比較

最後に、Fluid Computeと他の代表的なサーバーレス実行環境との違いを簡潔に整理します。

AWS Lambdaとの違い

  • 実行モデル: AWS Lambdaは「1リクエストにつき1コンテナ（関数インスタンス）」が原則で、同時リクエスト数だけ並列にインスタンスが増えます (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。一方Fluid Computeは単一インスタンスで複数リクエストを処理できるため、関数内並行処理によってインスタンス数の爆発的増加を防ぎます (従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey)。その結果、コールドスタート頻度も下がりスケーラビリティの上限も向上します (従来のサーバレスよりさらに高効率で高速な「Fluid Compute」、Vercelが提供開始 － Publickey)。
  • リソース効率: Lambdaでは待機時間も含めリクエストごとに個別のリソースが消費されます。Fluidではアイドル時間に他処理を詰め込むためCPU・メモリ稼働率が高く、同じ負荷でも必要リソース総量を削減できます (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。これは特に外部サービス待ちが発生するワークロードで顕著です。
  • ストリーミング対応: Lambdaでも2022年頃からAWS API Gateway経由でストリーミング応答が一部可能になりました。しかしFluid Computeでは関数が応答後も生きているためコネクションを維持しやすく、より直感的にストリーミング実装ができます (Vercel’s Fluid Compute and what it means for AWS Lambda - DEV Community)。複雑なワークフローなしにチャンク配信やSSEが行える点は開発体験として優れています。
  • デベロッパー体験: Vercel上で動作するFluid Computeは、Next.jsなどフレームワークとシームレスに統合された環境です。デプロイやプレビューも含めフロントエンド開発と一体化しているため、Lambda単体を用いる場合よりも迅速に機能を提供できます（AWS CDK等での整備をする場合との比較）。その反面、Lambdaは対応言語が豊富でAWSサービス群との統合が容易という利点もあります。Fluid Computeは現時点Node.js/Python限定ですが、Vercelが提供する高レベルなサービス連携（StorageやEdge機能等）を活用できる強みがあります。

Cloudflare Workersとの違い

  • 実行環境: Cloudflare WorkersはV8エンジン上のアイソレート（Isolate）で動作し、エッジ（世界中のデータセンター）でグローバルに展開されます。アイソレートは起動が高速でメモリフットプリントも小さいためコールドスタートが実質的に無視できる一方、Node.js互換ではなくブラウザ的なJavaScriptランタイムです (How Workers works · Cloudflare Workers docs) (How Workers works · Cloudflare Workers docs)。Fluid ComputeはRegionベースですがマルチリージョン対応でグローバル冗長性は確保可能です。またフル機能のNode.jsランタイム上で動くため、既存のNPMパッケージやネイティブモジュール、Pythonの場合は通常のPyPIパッケージがそのまま利用できます。
  • 並行処理モデル: Workersもシングルスレッドイベントループ上で複数リクエストを同時処理できる点ではFluidと共通しています (How Workers works · Cloudflare Workers docs)。ただしWorkersは各リクエストの実行時間やCPU使用量に制限があり（デフォルトで数十ms程度のCPU時間制限）、長時間の処理や大容量データ処理には不向きです。一方Fluid Computeは数分以上の実行や高CPU負荷のタスクもこなせるため、重たいバックエンド処理やAI推論などにも耐えられます。
  • コストモデル: Cloudflare Workersはリクエスト数や帯域に基づいた課金体系（無料枠も広め）ですが、一定以上の規模では従量課金制のWorkers Unboundを利用することになります。Fluid ComputeはGB-時間あたり課金で、前述のように並行処理による効率化でコスト削減効果が期待できます (Fluid compute)。どちらが経済的かはワークロード次第ですが、アイドル時間が多い処理ではFluidが有利でしょう。逆にグローバル展開が必須の超低レイテンシ用途ではWorkersに軍配が上がります。

まとめ

Fluid Computeは、昨今のAI時代やリアルタイムWeb体験のニーズに応えるためにサーバーレスを再発明したプラットフォームと言えます (Why Vercel overhauled its serverless infrastructure for the AI era)。フロントエンドエンジニアにとってはリアクティブなUIを支える頼もしい武器に、バックエンドエンジニアにとっては効率的なスケーラブルAPI基盤に、インフラエンジニアにとってはコストと運用負荷を抑える安心できる選択肢となるでしょう。実際に設定はトグルをオンにするだけで試せます (Fluid compute)。ぜひ既存プロジェクトでFluid Computeを有効化して、その効果を体感してみてください。今後のサーバーレスインフラの進化にも注目です。

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?