見出し画像

エッジコンピューティングについて色々調べてみました。

Kyutaro

以下は最新のエッジコンピューティングについて自分の学習目的で、Wasmer Edgeとの比較でCloudflare Workers、K8s（Kubernetes）、Dockerについて、下記の情報（The Cloud is dead, long live the Cloud! Announcing Wasmer Edge）を元にGPT-4に書いてもらいましたので、それを共有いたします。正確性に欠ける部分があると思いますが、新しい分野なのでザックリつかむ程度でお読みいただければと思います。
お気づきの点があれば教えていただけるとありがたいです。

なお、WebAssembly（WASM）に関する知識が前提となるので、先にコチラをお読みいただくと理解がスムーズになります。

Wasmer Edge

Wasmer Edgeは、クラウドよりもはるかに安価で、Cloudflareのワーカーよりも柔軟性があり、Herokuのような使い心地の新しいアプリケーションのパラダイムを提供します。それはデプロイの複雑さを隠しながら、高度なスケーリングとセキュリティを提供します。これにより、一つのサーバから大規模なグローバルクラスタまで、あらゆるスケールのアプリケーションを柔軟に運用することが可能になります。

Wasmer Edgeは、あらゆるHTTP/s TCP WebAssemblyアプリケーションを自動的にスケールさせることが可能で、現在では静的なウェブサイトやRustサーバを使った各種アプリケーション、TCPビデオサーバやDNSサーバなどを稼働させることができます。また、近い将来では、FlaskやDjango、Wordpress、Ruby on Rails、Node.jsなどのフレームワークも対応予定とのことです。

比喩を使えば、Wasmer EdgeはCloudflare Workersの価格設定、Herokuの使いやすさ、AWSのパワフルさを一つにしたものと言えるでしょう。つまり、Wasmer Edgeは、現行のクラウドインフラストラクチャの課題を解決し、より使いやすく、効率的な次世代のクラウドコンピューティングの形を提供することを目指しています。

この新技術により、開発者はクラウドに依存することなく、自分のコードに合わせたインフラを構築できます。Wasmer Edgeは、あなたのアプリケーションが必要とするリソースだけを消費するため、開発者はDevOpsについて心配することなく、開発に専念することができます。

彼らの発表によると、Wasmer Edgeは現在プライムタイム（本番環境）で稼働しており、実際にWasmerのフロントエンドプロジェクトがVercelやCloudflare Workersから移行し、すでに100万リクエスト以上を処理しています。

Wasmer Edgeのデプロイ方法は非常に簡単で、Wasmerのログイン後、次のように自分のパッケージをデプロイすることができます。

$ wasmer app create wasmer/docs --name wasmer-docs
...
✅ App wasmer-docs was successfully deployed!

このコマンドを実行すると、自動的に設定ファイルが作成され、そのサイトがどこにデプロイされたかが記憶されます。次回からは、wasmer deployと入力するだけで、すべてが自動的に動作します。

Wasmer Edgeのビジョンは、クラウドコンピューティングの未来を形作るものであり、彼らはそのベースがしっかりと確立された後で、そのエンジンをオープンソース化する予定です。なお、現在はWasmer Edgeのウェイトリストに参加することができます。

Wasmer社が新たなアプリケーションプラットフォーム「Wasmer Edge」を発表しました。このプラットフォームは、エッジロケーション上のデータセンターにWebAssemblyランタイムを展開し、分散モノリスなアーキテクチャを採用しています。従来のクラウドに依存しないこの新システムは、複雑さを減らし、高いスケーラビリティを実現しつつ、簡単にデプロイできることが特長です。また、POSIX準拠の「WASIX」を用いて、Linuxアプリケーションを開発するのと同じようにフル機能のアプリケーションを記述し、WebAssemblyにコンパイル可能です。

次に、詳細な解説を行います。

  1. 分散モノリスによるシンプルなデプロイとスケーラビリティ： 今までのクラウドアプリケーションでは、多くの異なる機能を持つサービスが連携して1つのアプリケーションを形成する「分散システム」が主流でした。しかし、「Wasmer Edge」は「分散モノリス」システムを採用しています。これは、1つのノードが単独のアプリケーションとなり、すべての必要な機能がそこに含まれるという考え方です。負荷によってノード数が増減することでスケーラビリティが実現します。これにより、オーケストレーションやサービスメッシュなどの複雑な概念を気にせず、負荷に対するノードの増減だけを考慮することで、シンプルなデプロイが可能となります。

  2. WebAssemblyランタイムとPOSIX対応： 「Wasmer Edge」は、Wasmer社が開発したWebAssemblyランタイムを用いており、POSIXに準拠した「WASIX」を通じて、Linuxアプリケーションを開発するのと同様のアプリケーション開発が可能です。WebAssemblyはサンドボックス型の軽量仮想マシンで、堅牢性があります。これにより、従来必要だったハイパーバイザやコンテナなどのレイヤが不要となり、その分のオーバーヘッドがなくなります。

  3. 今後の展開： 今後は、データを保存するPersistent volumes、セキュアなプライベートネットワークの実現、負荷がないときでもノードを0にせずに設定されたインスタンス数を維持する機能などが追加される予定です。ただし、現時点では「Wasmer Edge」はアルファ版であり、利用するにはウェイトリストへの登録が必要です。

具体例や比喩を使って説明すると、「Wasmer Edge」はある意味で、大量生産の製品とカスタムメイドの製品のバランスを取ったようなシステムです。それぞれのノード（製品）は完全に自己完結型で、それぞれが全ての機能を持っています（カスタムメイドのように）。しかし、それらのノードは負荷に応じて増減する（大量生産のように）ことで、高いスケーラビリティ（対応力）を実現しています。これにより、従来の複雑さから解放され、よりシンプルで効率的なシステムが構築可能となりました。

分散モノリス： 分散モノリスとは、1つのノード（サーバ）が一つの完全なアプリケーションとなるアーキテクチャのことを指します。そのノードにはすべての機能が含まれており、スケーラビリティを確保するために、負荷に応じてノードの数が増減します。例えば、大量のアクセスがあるときはノード数を増やし、逆にアクセスが少ないときはノード数を減らすといった形です。これにより、オーケストレーションやサービスメッシュなどの複雑な管理を必要とせず、負荷に対するノードの増減だけを気にすることで、シンプルなデプロイ（システムの展開）を可能にしています。

  1. WebAssembly： WebAssembly（通称：Wasm）は、ウェブブラウザ上で実行できる新しい種類のコードで、JavaScriptと共に利用することで、ウェブ上で高性能なアプリケーションを動作させることができます。WebAssemblyはバイナリ形式で提供されるため、ブラウザはそのコードを迅速に解析し、実行することが可能です。また、C++やRustなどの言語で書かれたプログラムをWebAssemblyにコンパイルすることができます。

  2. POSIX： POSIX（Portable Operating System Interface）は、オペレーティングシステムに関するAPIの標準規格です。UNIXシステムをベースに設計されており、これに準拠したシステム間での互換性を保証します。つまり、POSIXに準拠したソフトウェアは、それをサポートするどんなシステム上でも同じように動作するはずです。

  3. Wasmer： Wasmerは、WebAssemblyをサーバーサイドで使うためのランタイム（プログラムが動作するための環境）です。これにより、WebAssembly形式のアプリケーションをサーバーサイドで実行することが可能になります。

これらの技術を使って、「Wasmer Edge」は、クラウドではなくエッジロケーション上のデータセンターでアプリケーションを展開します。そのための基盤として、Wasmerランタイムを利用し、WebAssemblyで開発されたアプリケーションを展開します。そのアプリケーションは、POSIX準拠のWASIX（WebAssembly System Interface）を通じてシステムリソースを利用できます。

一つの具体例として、それぞれのノードは独立したレストランのようなものです。各レストラン（ノード）は、すべての料理（機能）を作ることができます。レストランが多くの客（負荷）を持つ場合、新しいレストラン（ノード）を開くことで対応します。反対に客が少ない場合はレストランを閉じます。これにより、レストランの運営（システム運用）が非常に簡単になります。全てのレストランは同じレシピ（アプリケーション）を使って料理（機能）を提供し、そのレシピはWebAssemblyで記述されています。このため、レシピはどのレストランでも同じように動作します。

K8sと比較

Kubernetes (K8s)とは何か？ Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、そして管理を自動化するためのオープンソースのプラットフォームです。多数のコンテナをマネージメントし、自動的にスケーリングやフェイルオーバー、ローリングアップデートなどを行うことができます。

KubernetesとWasmer Edgeの比較：

  1. アーキテクチャ： Kubernetesではマイクロサービスアーキテクチャが一般的に使われ、各サービスは分散環境で独立して動作します。一方、Wasmer Edgeでは分散モノリスアーキテクチャが採用され、一つのノードが完全なアプリケーションとなり、必要な機能が全て含まれています。

  2. デプロイの複雑さ： Kubernetesのデプロイは複雑で、K8s環境を理解し、設定ファイル（YAML）の記述や管理を行う必要があります。一方、Wasmer Edgeは分散モノリスアーキテクチャの採用により、デプロイは非常にシンプルで、アプリケーション全体を一つのノードにデプロイするだけです。

  3. オーケストレーション： Kubernetesは強力なオーケストレーションツールで、サービスメッシュ、プロキシ、サービスディスカバリなどの機能を提供します。これらは、アプリケーション間の通信やロードバランシング、セキュリティなどを管理します。一方、Wasmer Edgeでは、これらのオーケストレーションツールは不要で、スケーラビリティは負荷に対するノードの増減によって自動的に管理されます。

メリットとデメリット：

  1. Kubernetesのメリットとデメリット：

    • メリット：強力なオーケストレーション機能、高度なスケーリングとロードバランシング、広範なエコシステムとコミュニティのサポート。

    • デメリット：設定と運用が複雑、学習曲線が急、高度なエクスパート知識が必要。

  2. Wasmer Edgeのメリットとデメリット：

    • メリット：シンプルなデプロイと管理、高いスケーラビリティ、WebAssemblyによる言語の柔軟性、ネイティブなパフォーマンス。

    • デメリット：分散モノリスアーキテクチャが適用できるシナリオは限られている、新しい技術であるためエコシステムやコミュニティのサポートはまだ成熟していない、POSIX準拠のアプリケーションの開発が必要。

このように、KubernetesとWasmer Edgeはそれぞれの目的と要件により使い分けることが望ましいです。また、両者の採用にはそれぞれの学習曲線と習熟度を考慮する必要があります。

Wasmer EdgeとDockerの関係

Wasmer EdgeとDockerは、基本的には異なる目的と技術を利用していますが、共通する点もあります。どちらもアプリケーションのデプロイと実行を容易にするためのツールです。それぞれについて詳しく見てみましょう。

Dockerとは何か？ Dockerはコンテナ化技術の一種で、アプリケーションとその依存関係をパッケージ化して一緒に実行できるようにします。Dockerを使用すると、アプリケーションのビルド、配布、実行が非常に簡単になります。Dockerコンテナは軽量であり、既存のOSの上で直接実行されます。

Wasmer EdgeとDockerの関係は？ DockerとWasmer Edgeは、いくつかの重要な違いがあります。以下にそのいくつかを示します：

  1. 実行環境： Dockerはコンテナ技術を使用し、一方Wasmer EdgeはWebAssemblyランタイムを使用します。これは実行環境の違いを意味します。Dockerコンテナは特定のOS（通常はLinux）上で動作しますが、WebAssemblyアプリケーションは任意のOSや環境で動作します。

  2. 安全性： WebAssemblyはサンドボックス化された環境で動作するため、セキュリティが高いとされています。Dockerはコンテナ内で隔離されますが、特権エスカレーションやカーネルの脆弱性を利用した攻撃に対しては、WebAssemblyよりもセキュリティが弱いと考えられています。

  3. パフォーマンス： Wasmer Edgeは、WebAssemblyのために設計されたランタイムを使用するため、ネイティブに近いパフォーマンスを提供することが可能です。一方、DockerはOSの上で実行されるため、一部のリソースはホストOSと共有され、パフォーマンスに影響を及ぼす可能性があります。

  4. 互換性： Wasmer EdgeはPOSIXに準拠したWebAssemblyランタイムを提供していますので、既存のLinuxアプリケーションをWebAssemblyに移植することが可能です。一方、Dockerは、特定のOSのコンテナを作成し、それを他の同じOSのマシンで実行することが可能です。

要約すると、DockerとWasmer Edgeは互いに補完的な技術であり、どちらを使用するかは具体的なユースケースと要件によります。Dockerは既存のアプリケーションのコンテナ化に非常に適しており、広範で成熟したエコシステムを持っています。一方、Wasmer Edgeは高いスケーラビリティとセキュリティを備えた新しいアプリケーションのデプロイと実行に非常に適しています。

Cloudflareのエッジコンピューティングとの比較

Cloudflareはそのネットワークインフラストラクチャを利用してエッジコンピューティングサービスを提供しています。Cloudflare Workersと呼ばれるこのサービスは、WebAssemblyとJavaScriptを用いてユーザのコードをエッジサーバー上で実行します。Wasmer Edgeも同様にWebAssemblyを利用してアプリケーションをエッジ上で実行しますが、いくつかの重要な違いがあります。

1. 実行モデル： Cloudflare Workersは、イベント駆動型の実行モデルを採用しています。HTTPリクエストなどのイベントが発生するたびにコードが実行されます。これに対して、Wasmer Edgeはより汎用的なモデルを提供し、ステートフルなアプリケーションも扱うことができます。

2. APIと機能： Cloudflare WorkersはWebWorker APIをベースにした独自のAPIを提供します。これにより、Web開発者が馴染みのあるAPIを使用してエッジコンピューティングを利用することができます。一方、Wasmer EdgeはPOSIX互換のAPIを提供し、Linuxアプリケーションを開発するのと同じようにフル機能のアプリケーションを記述することが可能です。

3. スケーラビリティとデプロイ： Cloudflare WorkersはCloudflareの広大なグローバルネットワーク上で自動的にスケールします。コードは全世界のエッジサーバーに分散デプロイされ、リクエストは最も近いエッジサーバーで処理されます。Wasmer Edgeも同様に分散モノリスのアーキテクチャを採用してスケーラビリティを提供しますが、より広範なアプリケーションタイプを扱うことができます。

総じて、Cloudflare WorkersとWasmer Edgeは似た目標を持っていますが、そのアプローチと提供する機能は異なります。Cloudflare WorkersはWeb開発者向けのエッジコンピューティングを提供していますが、Wasmer Edgeはより汎用的なアプリケーションのエッジコンピューティングを提供しています。

コールドスタートについて

「コールドスタート」は、関数型のサーバレス環境で初めて呼び出されるとき、または一定時間呼び出しがなかったために休眠状態になっていた関数が再度呼び出されるときの現象を指します。このときには、バックエンドのインフラストラクチャがその関数の実行環境をセットアップするために時間がかかります。これがコールドスタートの遅延となります。

Wasmer Edgeのコールドスタートに関する具体的な情報は記事中には示されていませんでした。しかし、Wasmer EdgeはWebAssemblyを使用していますので、一般的にWebAssemblyの起動は非常に高速です。そのため、理論的にはWasmer Edgeのコールドスタート遅延も小さいはずです。

一方、Cloudflare Workersのコールドスタートについては、公式のドキュメンテーションによれば、「ほぼゼロ」とされています。これはCloudflare WorkersがV8 Isolatesというテクノロジーを使用しており、それにより新しいWorkerを迅速にスピンアップできるためです。

ただし、コールドスタートの遅延はサービス提供者のインフラストラクチャや設計の他、関数のサイズや依存関係の数などにも大きく影響されます。したがって、Wasmer EdgeとCloudflare Workersの間の正確な比較をするためには、両方のサービスで同等の関数をテストする必要があります。


この記事が気に入ったらサポートをしてみませんか？