JavaScriptのコードとService Workerをユーザーに近いCDNのエッジで実行可能。Cloudflareが「Cloudflare Workers」を提供開始
CDNプロバイダのCloudflareは、同社が提供するグローバルなコンテンツデリバリーネットワーク(CDN)のエッジにおいて、開発者がJavaScriptのコードを配置し実行できる新機能「Cloudflare Workers」の一般提供を開始したと発表しました。
Cloudflare Workersを利用すると、開発者はネットワークの向こう側にあるクラウドではなく、利用者にもっとも近いCDNのエッジに位置するCloudflareのデータセンター内でJavaScriptのコードを実行できるようになります。
これによってクライアントに対して非常に高速にレスポンスを返すことができ、広範囲に分散された高い冗長性を持つ分散システムが構築可能になります。
同社は日本を含む世界中に127のデータセンターを展開しています。
「クラウドの夢」、Cloudflare Workersでできること
Cloudflare Workersが実現する、コードがユーザーの近い場所で自動的に実行される環境こそ、「クラウドコンピューティングの夢」なのだと、同社はCloudflare Workersの発表記事で次のように書いています。
We believe the true dream of cloud computing is that your code lives in the network itself. Your code doesn't run in "us-west-4" or "South Central Asia (Mumbai)", it runs everywhere.
私たちが信じるのは、クラウドコンピューティングの本当の夢とは、あなたが書いたコードがネットワークそのもので活動することだ。それは決してコードが「us-west-4」や「南中央アジア(ムンバイ)」で実行されることではなく、どこででも実行されることなのだ。
Cloudflare Workersを用いると、例えば次のようなことが可能になると説明されています。
- 異なるタイプのリクエストごとに、異なるオリジンサーバへリクエストをルーティングする
- HTMLテンプレートの展開をエッジで行い、オリジンサーバへの帯域にかかるコストを削減する
- キャッシュコンテンツに対するアクセスコントロールの適用
- 一部のユーザーをステージングサーバーにリダイレクト
- 全く異なる2つのバックエンド間でA/Bテストを実現
- Web APIに完全に依存するサーバーレスアプリケーションの実現
- アプリ独自のカスタムセキュリティフィルタを作成し、不要なトラフィックをブロックする
- リクエストの書き換えによるキャッシュのヒット率向上
- 独自のロードバランシングやフェイルオーバーロジックの実装
- クイックフィックスによる本番サーバやアプリケーションのアップデートの省略
- ブラウザに依存しない分析データの収集
JavaScriptエンジンV8とService Worker
Cloudflare WorkersのJavaScript実行環境として提供されるのが、ChromeブラウザやNode.jsのJavaScriptエンジンとして用いられている「V8」と、Service WorkerのAPI群です。同社によると、エッジでのJavaScriptのコードは1マイクロ秒以内に実行が開始されるとのこと。また、実行環境にはNode.jsを用いていないとも説明されています。
Service WorkerとはHTML5の新機能として策定されたもので、そもそもはWebブラウザに実装されバックグラウンドで起動される、いわばプログラミング可能なローカルプロキシです。ルーティングやレスポンスやキャッシングなどを操作し、オフラインで動作するWebアプリケーションを実現する上で重要な機能を提供します。
Service Workerは現在、主要なWebブラウザなどでの実装が進んでいます。そしてService Workerなどによって実現されるオフライン機能などを備えた「Progressive Web Application」(PWA)と呼ばれる新しい種類のWebアプリケーションの普及へ発展しようとしています。
- AppleもiOS/macOSをProgressive Web Apps(PWA)対応へ。次のSafari 11.1でService Workerなど実装 - Publickey
- マイクロソフト、Progressive Web Apps(PWA)をWindows 10のデスクトップで実行可能に。Windows 10はWindows、Linux、PWA対応のプラットフォームへ - Publickey
なぜService Workerを実装したのか?
そもそもWebブラウザに実装することが想定されたService Workerを、なぜCloudflareはCDNのエッジに実装しようとしたのでしょうか。
昨年9月、Cloudflare Workersのベータ版を発表したときの同社のブログ記事「Introducing Cloudflare Workers」によると、同社はCloudflare Workersの構想段階ではService Workerの実装は考えておらず、JavaScriptの実行環境および独自のフック機能を提供することを考えていました。
We all start from the assumption that we'd provide two main "hooks" where the developer could insert a callback: a request hook and a response hook. The request hook callback could modify the request, and the response hook callback modify the response. Then we think about the cache, and we say: ah, some hooks should run pre-cache and some post-cache. So now we have four hooks. Generally, it was assumed these hooks would be pure, non-blocking functions.
私たちは当初、開発者がコールバックを組み込めるような、2つのメイン「フック」を提供しようと考えていました。リクエストフックとレスポンスフックです。リクエストフックのコールバックはリクエストを変更でき、レスポンスフックのコールバックはレスポンスを変更できます。残るはキャッシュをどうするかですが、プレキャッシュとポストキャッシュのフックがあればよいでしょう。これで4つのフックになり、これらは単純でノンブロッキングな機能になるはずでした。
「Introducing Cloudflare Workers」から
ところがこのアイデアはその後のミーティングにおいて、Servce Workerの想定しているユースケースとそっくりであることが指摘されたため、独自実装ではなく標準仕様であるService Workerを実装する方向へと変更されたとのことです。
Cloudflare Workersは無料で利用可能な「Cloudflare Workers Playground」が用意され、誰でも試すことができるようになっています。
あわせて読みたい
AWSの各種サービスやSDKのドキュメントがオープンソースとしてGitHubに公開。誰でもコントリビュートや再利用が可能に
≪前の記事
Firefoxの拡張機能でGitHubのプルリクエストを匿名化し、コードレビュー時の性別や人種などによるバイアスを取り除く実験開始。ソフトウェア分野のダイバーシティに向け