サーバーレス実行環境Cloudflare Workers 第1回 Cloudflare Workersとは
Cloudflare社が提供するサーバーレスの実行環境、Cloudflare Workersについて解説していきます。従来のFaaSにもある特徴に加え、Cloudflare Workersならではの特徴を見てみましょう。
はじめに
このシリーズでは、CDNなどネットワーク系の事業を手がけるCloudflare社が提供するサーバーレスの実行環境、Cloudflare Workersについて解説していきます。
Cloudflare Workersは、CodeGridにある過去のシリーズでいうと、AWS LambdaやNetlify FunctionsなどのFaaS(Function as a Service)に近しいサービスです。
Cloudflare Workersの特徴には、
- JavaScriptのコードをデプロイするだけで、サーバーサイド機能が構築できる
- 負荷に応じて自動的にスケーリングされ、常に安定して処理される
- 常時起動されているわけではなく、呼び出しに応じて起動される
- 使用量に応じた従量課金ではあるが、ある程度までは無料で使える
などなど、従来のFaaSと同様な部分もありつつ、似て非なる点もいくつかあります。
シリーズ第1回目のこの記事では、そんなCloudflare Workersの特徴について広く取り上げます。
特徴1: 全世界のCDNエッジで実行される
従来のFaaSでは、書いたコードを事業者のどのリージョン(東京、アメリカ西海岸など物理的な場所)にデプロイするかを、最初に決める必要がありました。
たとえば、東京リージョンにコードをデプロイした場合を考えます。この場合、日本国内からのアクセスであれば速く応答することができます。しかし、地球の裏側であるブラジルからアクセスされてしまうと、どうしても物理的に遠いため相応の時間が必要になってしまいます。
その点、Cloudflare Workersにはなんとリージョンの指定がありません。単一の拠点を指定する代わりに、コードは世界100ヵ国200以上の拠点に配置されたCDNのエッジにデプロイされ、常にアクセスした場所の最寄りの拠点で実行されます。
そのため、日本からのアクセスであれば東京か大阪の拠点で実行され、ブラジルであればブラジル国内に点在する最寄りの拠点で実行されます。つまりリージョン指定が必要な従来のFaaSに比べ、どこからでも高速に応答することができるという特徴があるのです。
特徴2: Service Workerのような使い方もできる
従来のFaaSと同じく、APIのように単純なサーバーサイド機能を実装することもできますが、ブラウザにおけるService Workerのような使い方ができるという特徴もあります。
詳細は割愛しますが、Service Workerは、"目的のリソースを取得するためのリクエストがネットワークに出ていく直前"で任意の処理を差し込めるレイヤーでした。
そのため、発行されたリクエストを加工したり、レスポンスをキャッシュしておいて次からネットワークアクセスを省略するなどの処理が可能となります。もちろん、何も処理せずのリクエストをただバイパスすることもできます。
これに対して、Cloudflare Workersでは、"発行されたリクエストが目的のリソースに届く直前"で任意の処理を実行することができます。
そのため、
- リソースを加工してレスポンスを返す
- そのままバイパスし、元(オリジン)のリソースへリクエスト
- リダイレクトするなど、そもそものアクセスを禁止
- ABテストによるコンテンツの出し分け
- etc...
というように、CDN本来のキャッシュ機能をプログラムを介して柔軟に利用できるというわけです。キャッシュにロジックを付加できるという意味では、Fastly社のCDNで利用できるVCLのようなイメージがわかりやすいかもしれません。
Cloudflare Workersの場合、利用できるAPIもService Workerの実行環境と同等であるため、クライアントサイドとコードを共有するなんてことも可能になっています。
特徴3: Node.jsではないJavaScriptの実行環境
JavaScriptをサーバーサイドで実行できると聞くと、Node.jsを思い浮かべる人が多いかもしれません。しかしここも従来のFaaSとは違い、Cloudflare Workersの実行環境はNode.jsではありません。
Node.jsではない代わりに、JavaScriptの実行エンジンであるV8と、そのIsolatesという機能を使ってコードを実行するようになっています。詳しい技術解説は公式のブログ記事を参照してください。
ともあれそのおかげで、従来のFaaSで問題になっていたコールドスタート(休眠状態でリクエストを受けたときに、実行環境を起動してリクエストを処理できるようになるまでの待ち時間)が実質なくなっており、安定して高速な応答ができるようになっています。より正確には、コールドスタート自体は引き続き存在しますが、その時間が従来のFaaSよりも短く済むようになっています。
V8のアップデートは頻繁に行われるため、いつでも最新のJavaScriptの機能が使えるというメリットもあります。
ただ、Node.jsではないということは、npmにある既存の資産がそのまま利用できない場合もあるということです。ネットワークプロトコルとして利用できるものも、現状はHTTPのみとなっています。たとえば、TCPを直接利用するMongoDBは使えませんし、SMTPを使ったメール送信などもできません。
プログラマブルなCDNという出自からすると自然なのかもしれませんが、単なるFaaS代替として利用したいという場合、選定にあたって注意が必要なポイントです。
おわりに
Cloudflare Workersは、物理的な場所を問わずあらゆる場所から高速に応答でき、コールドスタートもないというパフォーマンスメリットが大きいサービスです。また、実装したサーバーサイド機能を付属の無料ドメインに公開できる点もとても手軽です。
筆者が最初に試したときも、「こんな簡単にAPIがデプロイできてしまうのか」という印象を持ったことを覚えています。
ですが反面、Node.js依存のライブラリは動かない、HTTPプロトコルしか使えないといった制限がいくつかあり、トレードオフになっています。
ほかにも、従来のFaaSと比べるとアップロードできるコードのサイズがやや小さく制限されていたり、コードを実行する以外の機能はほとんどありません。たとえばログの永続化にしても、自前でHTTPリクエストを発行して別のところで書き込むというコードを自分で用意する必要があります。周辺ライブラリや開発体験も充実しているとは言い難く、まだまだ発展途上であることは否めません。
どちらかというと万人向けのサービスではなく、玄人向けのサービスであるというのがいまの筆者の感想です。たとえば主に日本国内でしか利用する予定がないなど、その特性をフルに活かす使い方をしないのであれば、総合的には従来のFaaSのほうが安牌だと思っています。
ただ、Cloudflareが公開しているAWS Lambdaとのパフォーマンス比較を見てもわかるとおり、ベストなユーザー体験を追求したい場合には有力な選択肢となるでしょう。
こうしたCDNエッジでコードを実行できるサービスは、最近のトレンドであることも確かです。業界各社もこぞって参入を発表しています。
- Serverless compute environment | Fastly Compute@Edge | Fastly
- Customizing at the edge with CloudFront Functions - Amazon CloudFront
- Deno Deploy
- etc...
もちろん各社サービス間で差異はありますが、どれも概ねのコンセプトは同様です。その中で、Cloudflare Workersは2017年に発表されており、その先駆者とも言える存在だと思います。
どんな場面でもパフォーマンスが求められる昨今、こういったCDNエッジの実行環境を当たり前に活用していく時代が近々やってくるかもしれません。もちろん、世界中からアクセスされる想定がなかったとしても、FaaSを選定する際には一考の余地ありかと思います。
Cloudflare Workersには、そのコードの書き味をすぐに試すことができるプレイグラウンドもあります。興味を持たれた方はぜひ触ってみてください。
基本利用は無料ですが、一定以上の規模からは利用料金が必要となります。あわせてドキュメントを確認してください。
次回の記事では、簡単なWorkerのコードを実際にデプロイしてみます。