エッジでのサーバーレス: 簡単な概要

最近のフロントエンド開発で最もエキサイティングなトピックの 1 つは、エッジ コンピューティングです。エッジでコードを実行できることは、アプリケーションの作成方法を根本的に変える新しい機能です。この記事では、サーバーレス エッジ コンピューティングの概要、それが有益な理由、およびその使用方法について簡単に説明することを目的としています。

サーバーレス エッジ コンピューティングとは?

最近まで、エッジについて話すとき、私たちは通常、HTML、CSS ファイル、画像、ビデオなどの静的アセットを世界中の何百ものサーバーにキャッシュするコンテンツ配信ネットワーク (CDN) について考えていました。コンテンツがユーザーに近いため、アクセスが非常に高速です。サーバーレス エッジ コンピューティングは、開発者がサーバーを管理することなくエッジでコードを実行できるようにすることで、この考え方を拡張します。エッジ コンピューティングは、開発者に、バックエンドとデバイスという 2 つの従来のオプションに加えて、コードの新しい場所を提供します。

最も注目すべきエッジ コンピューティング プラットフォームとは?

最近話題になっている 2 つのプラットフォームは、 Cloudflare WorkersとDeno Deployです。大まかに言えば、これらには多くの類似点があります。

• どちらも V8 エンジンを使用する JavaScript ランタイムです。 Deno には組み込みのコンパイラがあり、TypeScript を第一言語として扱うことができます。 Cloudflare Workers を使用すると、TypeScript や、Python、PHP、Dart、Scala などのJavaScript にコンパイルできるその他の言語でコードを書くこともできます。
• どちらもWebAssemblyをサポートしているため、C、C++、Rust などのコンパイル済み言語で記述されたコードをネイティブに近い速度で実行できます。
• どちらのランタイムも、マルチテナンシーのためにV8アイソレートに依存しています。
• どちらも、Fetch API、Streams API などのWeb標準を実装しています。
• リクエストを受け取ってレスポンスを非同期に返すハンドラ関数を記述する必要がある同様の API。
• どちらもストリーミングと WebSocket をサポートしています。

一方、2 つのプラットフォームの最も明らかな違いは、Deno Deploy はストレージ ソリューションを提供しないのに対し、Cloudflare Workers は一貫性のあるストレージのための耐久オブジェクトを備え、 Workers KVは結果整合性を備えた低遅延ストレージを備えていることです。

サーバーレス エッジ コンピューティングを選ぶ理由

エッジ コンピューティングは、URL の書き換え、リクエストのリダイレクト、または Cookie とヘッダーの操作を行う単純なスクリプトであるミドルウェアの実装に最もよく使用されます。たとえば、Cookie の値に応じて異なるバージョンのページを提供することで、A/B テストを実行できます。ローカリゼーションをサポートできます。つまり、さまざまな国のユーザーがさまざまなコンテンツを見ることができます。ユーザー認証ステータスに基づいて、特定のページへのアクセスを許可またはブロックすることもできます。

上記のユース ケースはバックエンドやクライアントで処理できますが、エッジ コンピューティングを使用する方が、パフォーマンスとシンプルさの点ではるかに最適です。クライアントに A/B テストまたはローカリゼーションを実装すると、バンドルのサイズが大きくなり、UI がちらつく可能性があります。一方、バックエンドでこの機能を実装するには、通常、サーバーの構成が必要であり、応答が遅くなります。

ただし、エッジ コンピューティングはミドルウェア以上のものです。実際、エッジ コンピューティングを使用してバックエンドを完全に置き換えることもできます。 Remix や Fresh などの多くのフルスタック フレームワークでは、データベースに直接アクセスしてエッジで HTML をレンダリングする関数を記述できるようになりました。そうすることで、おそらく以前のように API を開発する必要がなくなります。 (ただし、エッジで RESTful API または GraphQL API を提供したい場合は、それも可能です。)

しかし、なぜバックエンドをサーバーレス エッジ コンピューティングに置き換えることを検討する必要があるのでしょうか?それにはいくつかの理由があります。まず、サーバーレスであるため、サーバーのメンテナンスや自動スケーリングについて心配する必要がありません。第二に、ユーザーのすぐ近くで実行されるため、従来のバックエンドよりもはるかに高速であり、通常の Function-as-a-Service プラットフォームと比較して、エッジ コンピューティングにはコールド スタートがほとんどまたはまったくありません。第 3 に、従来のサーバーレス オプションよりも安価です。これは、エッジ コンピューティング プラットフォームが (仮想マシンやコンテナーではなく) V8 アイソレートなどの軽量テクノロジをマルチテナンシーに使用しているためです。これにより、リソースをより効率的に利用し、多くの処理を行うことができます。より多くの要求。

エッジ コンピューティングの使用方法

Netlify や Vercel などのプラットフォームを使用して Web アプリケーションを展開している場合、エッジ コンピューティングにオプトインするのは非常に簡単です。たとえば、Netlify のEdge Functions (Deno Deploy 上に構築されている) または Vercel のEdge Middleware (おそらく Cloudflare Workers 上で実行される) を使用できます。 Next.js アプリケーション (バージョン 12.2 以降) を Vercel または Netlify にデプロイすると、一部またはすべてのページがサーバー レンダリングに Edge ランタイムを使用するように構成できます (この機能はEdge SSRと呼ばれます)。

Netlify、Vercel、または同様のプラットフォームにデプロイしない場合は、エッジ ネイティブのフル スタック フレームワークを使用して、選択したエッジ コンピューティング サービスにアプリケーションを直接デプロイすることをお勧めします。たとえば、 Fresh フレームワークを使用してアプリを開発し、それを Deno Deploy に公開できます。別の例は、Cloudflare Workers と Deno Deploy の両方に (他の多くのデプロイメント ターゲットと共に) アダプターを提供するRemix フレームワークです。

フルスタック フレームワークを使用したくない場合は、フロントエンドとバックエンドを別々に開発できます。 Cloudflare を使用すると、 PagesまたはWorkers Sitesを使用してフロントエンドおよび静的アセットを提供できます。 Deno Deploy を使用すると、ファイルシステムから静的アセットを提供できます。バックエンドに関しては、 Sunder (Cloudflare Workers をターゲットにする場合)、 oak 、 Router 、またはSift (Deno Deploy をターゲットにする場合) などの HTTP フレームワークを使用することをお勧めします。

エッジ コンピューティングの欠点とは?

エッジ コンピューティングはミドルウェア スクリプトの実装に最適ですが、それを使用してバックエンド全体を実装する場合は、ターゲット プラットフォームの CPU ランタイム、メモリ、パッケージ サイズなどの制限に注意する必要があります。 Cloudflare Workers の制限に関する詳細情報はこちらで、Deno Deployはこちらでご覧いただけます。

結論

要約すると、Cloudflare Workers や Deno Deploy などのエッジ コンピューティング プラットフォームを使用すると、開発者は高速かつ安価なミドルウェアとバックエンドを作成できます。エッジ コンピューティングは、Remix や Fresh などの新世代のフルスタック フレームワークを可能にしたゲーム チェンジャーです。これらのフレームワークを使用して、アプリケーションを開発し、エッジに直接デプロイできます。さらに、エッジ コンピューティングは、Netlify や Vercel などのプラットフォームを介して間接的に使用できます。

それはほんの始まりです。近い将来、さらに多くのフレームワーク、ライブラリ、およびツールがエッジ用に開発されることが期待できます。この記事があなたの興味をかき立て、エッジ コンピューティングに関するハイレベルな情報を提供して、その可能性を探求し始めることができれば幸いです。