
2026/10/01 3:17
Edge Functions の高速化:V8 が Firecracker MicroVM に隔離され、処理が 5 倍速くなりました。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Netlify は、Firecracker MicroVMs を搭載した独自のエッジネットワークへ Edge Functions を移行することでサーバーレスのパフォーマンスを革命化したものであり、中央値速度は約 5 倍の向上、p99 呼び出しでは 47.4% の高速化を実現しています。このアーキテクチャ変更は最も重要な機能を最優先しており、リクエストが外部サービスを経由せずに内部コンピューティングノードに直接到達し、中央値ウォーム呼び出し遅延をわずか 5–6ms(前比 25–40ms)まで短縮するとともに、推定 1.2% のリクエストが必要とする場合にサブ 10ms のコールドスタートを可能にしています。メモリマッピングされたイメージを利用し、使われていない仮想マシンが保存されたスナップショットによってゼロにスケールするのを許可することで、システムは即座な再起動とローカル DNS リゾルバーによる最適化されたキャッシュングを確保します。stripped-down Linux 環境内で動作するこのセットアップでは、機能ごとに隔離することで顧客間でのセキュリティ侵害を防ぎ、同時に rendezvous hashing を活用してサービスを実行ノード上に保ちつつキャッシュ効率を高めています。NPM パッケージサポートがベータ段階から脱却するにあたり、開発者はこの高い可用性(99.998%)をサポートし、大規模なトラフィック急増時でも堅牢な安定性を提供する安全なインフラストラクチャ内で、市場投入までの時間を大幅に短縮し、グローバルユーザーの信頼性を高めることが期待されます。
本文
Netlify Edge Functions のアーキテクチャ再構築:高速化と高信頼性の実現
Netlify の Edge Functions には毎日約 10 億回の稼働があります。Sunweb のページカスタマイズや Loto-Québec のクッキーチェックルーティングなど、数十万のサイトが個人化・認証処理をこのプラットフォームで実行しています。これらすべての機能は、顧客トラフィックに合わせてスケーリングされる完全な JavaScript ランタイム上で動作します。
本記事では、極限まで低遅延を実現するための技術的課題に対し、チームが直面した問題とその解決策について詳しく解説します。
再構築の成果とアーキテクチャ変更
過去数ヶ月間、当チームは Unikraft チーム(類似事例も発信)との密な協力により、Edge Functions の背後にあるインフラを完全に見直しました。 以前のホスト型実行環境から、独自の edge ネットワーク内MicroVMへの移行を完了させました。これにより以下のような成果を得ており、中央値で約 5 倍の高速化を実現しています。
- セキュリティと信頼性の向上: リクエスト処理の分離性が高まり、侵害リスクが大幅に低減。
- 計算実行の可能性拡大: Edge でより複雑な計算を実行できるようになりました。
- 開発者体験への影響なし: URL インポート、npm パッケージ、Node.js 標準機能、
の宣言、ローカル開発環境など、すべての利用法は以前と同じ動作を維持しています。netlify.toml
性能メトリクス:数値による証明
Edge Functions はサイトの最前線で稼働するため、顧客が待機する時間(所要時間)の短縮が最重要課題です。
ウォームインボケーション(既に準備済みの状態)
計算ノードへのルーティング、MicroVM の起動、関数の実行までの全体コストは以下の通り改善されています。
- 中央値(p50): 約 5〜6ms に改善(旧インフラ:25〜40ms)
- p99 インボケーション: 47.4% の高速化を達成
- 可用性: 99.998% を維持
- ログ配信: 処理速度が約 5 倍に向上
コールドインボケーション(初めて到達した地域)
以前計算ノードが確認したことのない地域へのリクエストでは、イメージフェッチが必要になります。
- 発生頻度: 全体の約 1.2%
- 平均処理時間: 約 9ms
リクエスト処理の全体像:ステップバイステップ
以下は、単一のリクエストが Netlify のネットワーク内を通過する際のフローです。
1. Edge ノードへの到達
すべてのリクエストはクライアントに近い Edge ノードに届きます。
- ノードは TLS 接続を終了し、Edge Functions のルート照合を行います。
- ルート一致時は、以前「インターネット経由で外部へ出し戻す」のではなく、自社ネットワーク内の計算ノードへ直接転送されます。
2. Edge Functions サービスの作成・確認
計算ノードはサービス ID を受け取り、既存サービスの有無を確認します。
- 既存の場合: リクエストを既存サービスへ転送し、MicroVM 起動へ進む。
- 同一サイトに対し複数の MicroVM を関連付け、スケーリングタイミングや終了前の処理上限(リクエスト数固定)を制御可能にしています。
- 新規作成の場合: サービスが存在しない場合は新規作成後、指定されたイメージがディスクに存在するか確認します。
- 不足しているイメージは edge ノードからフェッチしてディスクに書き込みます。これにより、その地域でトラフィックを受けているイメージのみをフェッチする効率化を実現しています。
3. Edge ノードによる仕様の作成と移動制御
リクエストが計算ノードへ移動する前に、Edge ノードは実行マシンの仕様(3 つのイメージ:ランタイム、プラットフォーム、Edge Functions イメージ)および CPU、メモリ制限を作成します。
- 分離性の保証: ハッシュ値とサイト固有情報からサービス ID を計算し、異なるデプロイ(コード・環境変数が異なるとしても)は決して同じ MicroVM を共有しないように管理しています。
- セキュリティ上の意義: 潜在的に侵害されたデploy は別の MicroVM で実行されるため、ランタイム脱出による他社顧客や計算層の汚染リスクを排除できます。(従来の Isolates(V8 など)では提供できなかったレベルの隔離を提供)
4. 計算ノードの選択(Rendezvous ハッシング)
各地域には計算ノードグループがあり、Edge ノードはサービスごとにハッシングを用いて最適なノードを選択します。
- 「くっつきやすさ(Stickiness)」の活用: 同じサービスが毎回同じノードに割り当てられるため、MicroVM はウォーム状態を維持でき、コードやキャッシュディスク上に保持されます。これによりキャッシュ戦略が可能になり、コールドスタート回避に寄与します。
- ホットスポット対策: すべてのリクエストを同一ノードに送るのは高速ですが、ボトルネック化のリスクがあります。特定の閾値を超えた場合は、サービスをノードの一部スライス(slice)に分散させ、単一顧客からのトラフィック急増による影響を他のサービスから隔離しています。
- コードフェッチ: 計算ノードが決定されると関数コードを取得し、初回リクエストのコストのみで済むようにキャッシュ管理を行います。
5. MicroVM の起動(Firecracker)
各関数は独自の Firecracker MicroVM で実行され、以下の特性があります。
- 起動速度: 作成に要する時間 1ms を切らず、p99 で約 2ms で起動。
- フル OS の起動ではなく、スリープされた Linux 環境を開始するため高速です。
- メモリ効率: Edge Functions ファイルは圧縮されていない EROFS イメージとしてマウント・メモリーマップされるため、VM はバンドル全体を読み込むのではなく、実際に必要な部分のみを読み取ります。
- ライフサイクル管理: Unikraft のプロダクトが担当し、起動→スナップショット作成→復元→ゼロスケール(アイドル時はシャットダウン)を自動化しています。
- インボケーションがない間は MicroVM をゼロスケールさせ、次回起動時にはそのスナップショットから即座に VM を再構築します。
6. 実行とレスポンス処理の最適化
大規模運用を通じて得た教訓(仮想スイッチポート不足や DNS の課題など)を反映し、以下の強化を行いました。
- ローカル DNS Resolver: 計算ノード内で動作させ、遅延を削減。
- 計測の強化: 起動時間、ポート開放時間、ユーザーコード開始時間の精密な計測を実装。
- サーキットブレーカー: 即時再ルーティングや撤廃機能を確保し、システムの健診性を向上。
これらすべての工程はEdge ネットワーク内で行われ、ウォームインスタンスの場合約 6ms で完了します。リクエスト到着からレスポンス送信までのサイクルを完全に制御しています。
強固なコンピューティングインフラの設計原則
本システム構築では、「エンドユーザー体験」と「ロールアウトの堅牢性」の両立を最優先しました。素早い展開と即座なロールバックのバランスが取れるアーキテクチャを採用しています。
アーキテクチャの特徴
- 計算ノードの独自構築: Unikraft のベースイメージから構築し、edge ノードとは別個にビルドされています。これにより、軽量化・高速化や異なるインスタンスタイプの利用、独立したスケーリングが可能になります。
- コントロールプレーンとデプロイ戦略:
- コントロールプレーンが計算ノードの健全状態を監視し、Edge ノードがポーリングを行います。
- デプロイは新しいフラート(Flotte)を既存群の横に立ち上げ、規模を合わせ、健全を確認した後にトラフィックを引き継ぐという手法を採用。
Unikraft チームとの緊密な連携により、正しさの検証や大規模リクエストへの対応、プラットフォーム固有機能の実装が推進されました。
現在提供されている恩恵と将来性
Edge コンピューティングアーキテクチャの再構築は速度向上だけでなく、継続的に拡張可能なより強力な基盤を提供しています。移行ステップなしでプロジェクトの変更も不要ながら、すでに今日から顧客のプロダクショントラフィックに提供されています。
自社で計算を行うことで、以下の制約が緩和・撤廃されました:
- npm パッケージサポートのベータ終了
- ネイティブバイナリや実行時ファイル読み込みの制限が大幅に緩和され、本格的な VM と実在のファイルシステムが利用可能になりました。
- 動作制限の見直し余地
- 従来の CPU 50ms・メモリ 512MB・圧縮コード 20MB の固定制限から自由になり、より柔軟なリソース割り当てが可能に。
- 自社ネットワーク内での計算制御
- 過去に依存していた第三者インターネット接続によるパス制御の問題が解決し、完全な自制管理を実現しました。
今後も未解決の課題や新たな制限への挑戦を続けてまいります。