Compute がまだ JavaScript をサポートしていない理由

Fastly のサーバーレスコンピューティング環境である Compute のビジョンは、開発者が熟知し慣れ親しんだ言語を使用して、安全性に秀でた高性能のアプリや優れたエクスペリエンスをエッジで構築できるようにすることです。このため、Fastly について最もよくある質問のひとつに「どうして Compute は JavaScript をサポートしていないのか？」という質問があるのも不思議ではありません。

その他のサーバーレスオプションでは JavaScript をサポートしているため、このような質問は妥当かつ重要なものです。以前このブログで、Compute の基盤である WebAssembly に JavaScript がまだコンパイルできないことに言及しながら、どのように Compute でサポートする新しい言語を審査しているのかをお伝えしました。そこで朗報なのが、このような開発者のニーズに応えるべく、Fastly では現在 AssemblyScript の審査を行っています。AssemblyScript (TypeScript のサブセット。TypeScript は JavaScript の型付けされたスーパーセット) を使用することで、WebAssembly の型安全性とパフォーマンスのメリットをそのまま保持しながら、JavaScript のプログラミングモデルとシンタックスの使用が可能になります。

しかし、疑問は依然として残されたままです。それは、なぜ Fastly は簡単な道を選ばず、JavaScript のサポートが組み込まれている V8 のような既製のテクノロジーを使用しなかったのか、なぜ一から独自のコンパイラツールチェーンを構築するというより険しい道を選んだのか、ということです。

購入すべきか構築すべきか？

Fastly には、基本原理から問題を見据えて、困難なプロジェクトであってもお客様のメリットになると分かっていれば、恐れずにそのプロジェクトに取り組む、という長きにわたる伝統があります。独自にカスタマイズされたルーティングインフラの構築は、当時設立1年目のスタートアップ企業が取り組むには無謀な事業のように思われたかもしれません。しかし既存のネットワーキングソリューションではパフォーマンスとコントロールのトレードオフを余儀なくされていたため、パフォーマンスと柔軟性の両方を実現する必要性を感じた私たちは、自ら構築するしかなかったのです。そして、この決断は現在もなお、私たちに恩恵をもたらしています。

この原理を Compute に適用する

同様に、既存のサーバーレステクノロジーにおいても、パフォーマンスとセキュリティのトレードオフが強いられています。サーバーレス関数を初めて起動する「コールドスタート」では、すでにすべて開始された状態にある「ウォームスタート」に比べ時間がかかります。一部のテクノロジーは、多くの関数の呼び出しにかかるコールドスタートのコストを償却するため、多くのリクエストでこの環境を再利用し、この問題を部分的に軽減させています。しかしその結果、このパフォーマンスの問題はセキュリティの問題へと発展するのです。環境を再利用することで一連のセキュリティ脆弱性が生じるためです。攻撃者は、前回の呼び出しからの「残存」データにアクセスしたり、環境を意図的に汚染して後続の呼び出しに害を与えようと試みたりすることも可能になります。

私たちは、コールドスタートのコストを削減することで、優れたパフォーマンスと安全性の両方を兼ね備えたソリューションを実現できると考え、まさにこれに成功したのです。Compute の起動時間は35マイクロ秒以下です。そのため、あらゆるリクエストに対し完全にクリーンな動作環境を提供し、以前の呼び出しとの間におけるデータ残留の可能性を排除できます。

JavaScript を適切な方法でサポートする

Fastly ではこのバランスを一貫して保ちながら、ユーザーに最も人気のある言語をサポートすべく、近日中に AssemblyScript の使用を通じて JavaScript のサポートを開始できるよう取り組んでいます。ぜひご期待ください。私たちは、Compute の活用範囲の拡大に向け引き続き投資を行い、言語を問わず、お客様がどのようにその可能性を最大限に引き出してくれるのか、とても楽しみにしています。