Cloudflare WorkersのJavaScript/WASMランタイム「workerd」がオープンソースで公開。NanoservicesやHomogeneous deploymentなど新技術を実装

今回は「Cloudflare WorkersのJavaScript/WASMランタイム「workerd」がオープンソースで公開。NanoservicesやHomogeneous deploymentなど新技術を実装」についてご紹介します。

関連ワード （ブラウザ、事実上、単一等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

Cloudflareは、同社のCDNエッジでJavaScript/WebAssemblyを実行するサービス「Cloudflare Workers」のコアランタイム部分を「workerd」（読み方はワーカーディー：worker- dee）としてオープンソースで公開しました。

GoogleがオープンソースのChromiumをベースにGoogle Chromeを製品として提供しているのと同様に、CloudflareはworkerdをベースにCloudflare Workersのソフトウェアを開発していると説明されています。

It’s here!

workerd (no that’s not a typo) the runtime that powers Cloudflare Workers is now open source under the Apache 2.0 license.
https://t.co/qoNOQdtkVW

— Cloudflare Developers (@CloudflareDev) September 27, 2022

workerdはローカルにおけるJavaScript/WebAssemblyランタイムとして、あるいはプログラマブルなHTTPプロキシなどとして利用可能です。

標準準拠でロックインはされない

workerdはサーバ向けのJavaScript/WebAssemblyのランタイムですが、基本的にはWebブラウザが備えているAPIを実装しています。

と同時にDenoやNode.jsなどと共に今年立ち上げた非Webブラウザ系JavaScriptランタイムのコード互換を実現するワークグループの標準に従うとしており、コードのworkerdへのロックインは起こらないとしています。

参考：Deno、Node.js、Cloudflare Workersなど、非Webブラウザ系JavaScriptランタイムのコード互換を目指す「Web-interoperable Runtimes Community Group」（WinterCG）が発足

Nanoservicesによる高速なマイクロサービスの実現

wokerdには2つの大きな実装上の特徴があります。1つ目がNanoservicesです。

Nanoservicesは、マイクロサービスアーキテクチャのためのより優れた実行環境を提供しようとする技術的な試みです。

一般にマイクロサービスアーキテクチャでは、それぞれがDockerコンテナで分離されたサービスをネットワークで接続することで相互に連携します。この場合、ネットワーク上でトラフィックのやりとりが発生し、そこでオーバーヘッドが生じるという課題があります。

workerdでは1つのプロセスの中を多数のそれぞれ独立したグローバルスコープを持つ「Isolate」と呼ばれる空間に分離します。そして各Isolateごとに個別のサービスに当たるWorkerを実行します。

Isolateは分離されつつも同一のプロセス内で動いているため、まるで関数呼び出しのように事実上ゼロレイテンシで非常に高速に相互のやりとりが可能になるわけです。

ただしIsolateにはサンドボックスのような高度な分離機能は持たせていないため、高度な分離が必要な場合には仮想マシンなど別の技術を用いる必要があるとも説明されています。

Homogeneous deploymentによるシンプルなデプロイとスケーリング

Dockerコンテナよりも軽量なIsolateを踏まえ、さらにマイクロサービスの課題を解決しようとworkerdでCloudflareが提唱するのが、2つ目の特徴である「Homogeneous depolyment」です。あえて訳すとすれば「同一性デプロイ」でしょうか。

マイクロサービスで構成されるアプリケーションを、例えば3台のサーバからなるクラスタにデプロイする場合には、サーバAにデプロイするサービス群、サーバBにデプロイするサービス群、サーバCにデプロイするサービス群などを設定し、それぞれにデプロイしていくことになるでしょう。

そしてサービスごとの負荷に応じてサービスのコンテナを増やしたり減らしたりしてスケールすることになります。

Homogeneous deploymentでは、こうしたサーバごとに異なるサービスのデプロイを不要にします。全てのサービスをクラスタを構成する全てのサーバにデプロイするのです。つまり、クラスタ内の全てのサーバは同一の構成になるわけです。

なぜこうするのか、これにどんなメリットがあるのについて、Cloudflareのブログ「Introducing workerd: the Open Source Workers runtime」から、Homogeneous deploymentの説明を引用しましょう。

workerd’s nanoservices are much lighter-weight than typical containers. As a result, it’s entirely reasonable to run a very large number of them – hundreds, maybe thousands – on a single server. This in turn means that you can simply deploy every service to every machine in your fleet.

workerdのNanoserviceは、一般的なコンテナよりもはるかに軽量です。そのため、1台のサーバで数百から数千といった非常に多くのサービスを実行することがまったく合理的になるのです。これはつまり、あなたのクラスタを構成するすべてのマシンに、単純にすべてのサービスをデプロイできることを意味します。

Homogeneous deployment means that you don’t have to worry about scaling individual services. Instead, you can simply load balance requests across the entire cluster, and scale the cluster as needed. Overall, this can greatly reduce the amount of administration work needed.

Homogeneous deploymentでは、個々のサービスのスケーリングを心配する必要がありません。その代わり、クラスタ全体でリクエストをロードバランスし、必要に応じてクラスタ自体をスケーリングすればよいのです。全体として、必要な管理作業の量を大幅に削減することができます。

要約すると、クラスタを構成するすべてのサーバは同一の構成だからデプロイが簡単で、その単純な同一構成のサーバを増やしたり減らしたりすればスケーラブルになるので、スケーリング作業もシンプルになる、ということです（実際の運用ではサーバは仮想マシンになり、Nanoservicesの数に合わせた仮想マシンの適切なサイジングなども必要なように思われます）。

これは、グローバルに分散したCDNによる負荷分散を提供しているCloudflareから出てきた発想として非常にうなずけます。

例えばあるアプリケーションにリクエストが集中していたとしても、そのリクエストの多くが東京と大阪からであれば、東京と大阪のそれぞれのエッジにリクエストは分散されるわけです。それぞれのエッジで同一構成でデプロイされたサーバがあれば、それで負荷は分散されるし、デプロイもシンプルになるわけです（アプリが単一のデータベースに依存している場合はその手当も必要になるとは思いますが）。

NanoserviceやHomogeneous deploymentは非常にユニークな提案に見えます。今後これがマイクロサービスにどのような影響を与えていくのか、そしてV8やWebAssemblyが持つ分離機能の実装などにもどのような影響を与えていくのかなど、注目していきたいと思います。