WebAssembly + Dapr = 次世代のクラウド ネイティブ ランタイム?

クラウド コンピューティングは、デジタル経済の発展を支える重要なインフラストラクチャとなっています。クラウドコンピューティング基盤も、IaaSからContainer as a Service（CaaS）、そしてサーバーレスコンテナやFunction PaaS（fPaaS、FaaS）へと進化を続けており、新たなコンピューティング形態が次々と登場しています。コンテナやサーバーレスに代表されるクラウド ネイティブ テクノロジーは、アプリケーションのライフサイクル全体を再形成しています。

ガートナーの分析レポートでは、クラウドコンピューティング インフラストラクチャの開発経路も、クラウドネイティブの特性が徐々に強化されるプロセスであるとされています。具体的には、次のようになります。

モジュール性の向上 - コンテナやサーバーレス関数などのより細かい粒度のコンピューティング ユニットは、マイクロサービス アーキテクチャでのアプリケーション配信に適しており、クラウド機能をより有効に活用し、アーキテクチャの俊敏性を向上させます。プログラマビリティはますます向上しており、宣言型 API とポリシーを通じて自動管理と運用・保守を実現できるほか、不変インフラストラクチャを通じて分散アプリケーションの運用・保守の確実性をさらに向上できます。弾力性の効率はますます高まり、VM は数分で拡張できます。コンテナとサーバーレス コンテナは数秒で拡張できます。スケジューリングの最適化により、機能を数ミリ秒単位で拡張できます。回復力の向上 - Kubernetes は、アプリケーション システムの自己修復機能を向上させる強力な自動オーケストレーション機能を提供します。サーバーレスにより、安定性、スケーラビリティ、セキュリティなどのシステムレベルの複雑さがインフラストラクチャにまで押し下げられるため、開発者は独自のビジネス アプリケーション ロジックにのみ集中すればよくなり、生産性がさらに向上し、システムの回復性が向上します。

分散クラウドは、クラウド コンピューティングの発展におけるもう 1 つの重要なトレンドです。パブリック クラウド サービスはさまざまな物理的な場所に拡張できるため、コンピューティングを顧客の近くに配置できます。分散クラウドにより、顧客はクラウド コンピューティングの利便性を享受しながら、リアルタイム コンピューティングとセキュリティ コンプライアンスの要求も満たすことができます。これにより、エンタープライズ アプリケーション アーキテクチャも変化します。アプリケーションは、最適な方法でサービスを提供するために、さまざまな環境に展開および移行できる必要があります。

さらに、モバイルインターネット、AI、IoTなどの新しいテクノロジーの出現により、ユビキタスコンピューティングが現実のものとなりました。同時に、コンピューティング能力の多様性も生まれています。 X86 アーキテクチャが世界を支配していた時代は終わりました。 ARM/RISC-V などの新しいチップ勢力は、モバイル通信や組み込みデバイスの分野を支配しているだけでなく、エッジ コンピューティングやデータ センター市場にも攻勢をかけています。開発者は、アプリケーションが異なる CPU アーキテクチャをサポートするようにする必要もあります。たとえば、エッジや IoT などのさまざまな環境で、さまざまなアーキテクチャを持つデバイス上で実行できるように画像認識アプリケーションをデプロイできます。

分散クラウド、エッジ コンピューティング、クラウド統合コンピューティングなどの新しいクラウド コンピューティング シナリオでは、次世代のクラウド ネイティブ アプリケーション ランタイムにはどのような特性があるのでしょうか。

次世代クラウドネイティブアプリケーションランタイム

1. ユビキタスコンピューティングにより、次世代のポータブルで高性能、軽量なセキュリティサンドボックスが誕生

コンテナ アプリケーションは、アプリケーション コードと依存するシステム コンポーネントを含むコンテナ イメージという自己完結型のパッケージ化方法を使用します。これにより、アプリケーションをインフラストラクチャから分離できるため、パブリック クラウドやプライベート クラウドなどのさまざまな運用環境でアプリケーションを一貫した方法で展開および運用できるようになり、弾力性と移行が簡素化されます。さらに、Docker イメージ仕様ではマルチアーキテクチャ (Multi-Arch) イメージがサポートされているため、さまざまな CPU アーキテクチャ (x86、ARM など) 向けのアプリケーション イメージの構築と配布が簡素化されます。

関数アプリケーションにはイベント応答用のコード パッケージのみが含まれており、これによりアプリケーション配信形式がネイティブ バイナリ ファイルから高水準言語レベルに引き上げられます。これにより、アプリケーションの移植性に対する想像力が広がり、理論的には実行環境の CPU アーキテクチャの違いを隠すこともできます。たとえば、ネイティブ コードに依存しない Python/NodeJS や Java アプリケーションなどのスクリプトは、変更を加えることなく x86 や ARM などのさまざまな CPU アーキテクチャで実行できます。

しかし、理想は希望に満ちているが、現実は非常に乏しい。移植性とベンダーロックインは、機能 PaaS の開発の障害となります。

多くのスクリプト コードでは、データ処理を実装し、ミドルウェア (データベース ドライバーなど) を呼び出すためにネイティブ コードを呼び出しておく必要がありますが、ネイティブ コードをコンパイルするには、互換性を確保するためにビルド環境がターゲット実行環境と一致している必要があります。たとえば、AWS Lambda/Alibaba Cloud Function Compute では、指定されたカーネルと libc のバージョンに依存するバイナリ ネイティブ コードが必要です。そのため、機能アプリケーションのパッケージ化と依存関係の管理を簡素化するために、ますます多くの機能 PaaS サービスがキャリアとしてコンテナ イメージをサポートしています。関数アプリケーションは通常、データ アクセスとコンピューティング機能を実装するためにバックエンド サービス (BaaS、Backend as a Service) に依存します。 BaaS には標準がないため、AWS Lambda 上で開発された関数アプリケーションを Alibaba Cloud の Function Compute サービスに移行することは困難です。

サーバーレスコンピューティングでは、AWS Firecraker や Alibaba Cloud サンドボックスコンテナなどのサンドボックスコンテナ技術を使用して、強力に分離された安全な実行環境を実現するのが既存の主流技術ですが、リソースの消費も大きくなります。 Alibaba Cloud サンドボックス コンテナは最適化後、Docker などの OS コンテナの起動速度に近い 300 ミリ秒のコールド スタート速度を実現できるようになりましたが、それでも Function PaaS のミリ秒レベルの起動要件を満たすことはできません。現在、この要件を満たすには、一定数のスタンバイ インスタンスを予約するスケジューリング戦略が必要ですが、これによりリソースの消費も増加します。

WebAssembly (WASM) は、汎用的、オープン、効率的、かつ安全な仮想マシンの抽象化の基盤となる新しい W3C 仕様です。もともとは JavaScript のパフォーマンスの問題を解決し、Web アプリケーションがネイティブ アプリケーションに近いパフォーマンスを実現できるようにするために設計されました。 C/C++、Rust などの既存のプログラミング言語アプリケーションを WASM バイトコードにコンパイルし、ブラウザーのサンドボックス環境で実行できます。

WASM は、アプリケーション開発テクノロジーをランタイム環境から切り離し、コードの再利用を大幅に促進します。 Mozilla は 2019 年に WebAssembly System Interface (WASI) を立ち上げました。これは、ファイル システム アクセスやメモリ管理など、WebAssembly とシステム リソース間の相互作用の抽象化を標準化するために、POSIX に似た標準 API を提供します。 WASI の登場により、WASM の適用シナリオが拡大し、さまざまな種類のサーバー側アプリケーションを仮想マシンとして実行できるようになりました。 WASM/WASI はアプリケーションの移植性に新たな希望をもたらします。 WebAssembly エコシステムの発展をさらに促進するために、Mozilla、Fastly、Intel、Red Hat は共同で Bytecode Alliance を設立し、WASI 標準、WebAssembly ランタイム、ツールなどの作業を共同で主導しています。

WebAssembly のセキュリティ、移植性、高効率性、軽量な機能により、アプリケーション サンドボックスの開発に新しいアイデアがもたらされました。 WASM は、ミリ秒レベルのコールド スタート時間と極めて低いリソース消費を簡単に実現できます。同時に、WASM バイトコードはネイティブ マシン コードよりもセキュリティ レベルが高くなります。さらに、WASI は、最小権限の原則に従うきめ細かい機能ベースのセキュリティ モデルを実装します。実行中、WASI アプリケーションは依存性注入によって指定されたリソース セットにのみアクセスできるため、従来の粗粒度のオペレーティング システム レベルの分離と比較して、セキュリティ攻撃対象領域がさらに狭まります。

このため、WASM/WASI はサーバーレス、IoT/エッジコンピューティングなどのコミュニティから広く注目を集めており、Fastly、Cloudflare などのベンダーも WebAssembly 技術をベースにしたより軽量なサーバーレス サービスを次々とリリースしています。

しかし、サーバー側での WebAssembly の適用には、まだ多くの困難が伴います。まず、WASI の機能はまだ非常に初期段階にあり、いくつかの重要な機能がまだ欠けています。その 1 つ目は、標準化されたネットワーク アクセス機能の欠如です: https://github.com/WebAssembly/WASI/issues/315。

現在、WASI アプリケーションは一部のコンピューティング タスクしか実行できず、基本的に分散アプリケーションを実装することはできません。また、Redis、MySQL、Kafka などのさまざまなバックエンド サービスやアプリケーション ミドルウェアを呼び出すこともできません。これにより、WASI の適用シナリオが大幅に制限されます。

理想と現実が衝突したとき、あなたは血みどろの敗北を喫するのか、それとも生き残るのか?

2. 次世代のポータブルアプリケーションランタイムは、プログラミングインターフェースの向上とアプリケーションインフラストラクチャ機能の低下を加速します。

Dapr は、クラウド ネイティブ アプリケーション向けの Microsoft のオープン ソース分散アプリケーション ランタイムです。その目標は、すべての開発者が、あらゆる言語とフレームワークを使用して、回復力があり、イベント駆動型の移植可能なマイクロサービス アプリケーションを簡単に構築できるようにすることです。

Dapr は、高性能、スケーラブル、高可用性の分散アプリケーションを構築するための一連の設計パターンを実装します。たとえば、サービス検出機能とサービス呼び出し機能を提供し、イベント駆動型アプリケーション アーキテクチャをサポートするためのシンプルで一貫性のあるプログラミング モデルも実装します。

さらに、Dapr は、リソース バインディング、セキュリティ管理、可観測性など、インフラストラクチャを通じてバックエンド サービスへのアプリケーション アクセスの技術的な詳細を保護します。これは、サーバーレス アプリケーションにとって非常に重要です。一方では、開発とデプロイメントを切り離し、開発者と運用および保守チームが懸念事項を分離することでシステムの複雑さを簡素化できるようにします。一方、ライフサイクルが短くステートレスな Serverless アプリケーション ロジックを、データベース接続プール管理などの長時間実行されるステートフルなミドルウェア アクセス機能から分離し、Serverless アプリケーションのスケーラビリティと運用効率を向上させます。

「あらゆる言語、あらゆるフレームワーク、どこでも」は Dapr の重要な設計目標です。 Dapr は、サイドカー方式を通じてアプリケーションとバックエンド サービス間の抽象化レイヤーを提供し、標準化された HTTP/gRPC API を通じてアプリケーションの移植性とバックエンド サービスの置き換え可能性を実現します。

詩と距離に向かって

WebAssembly と Dapr を組み合わせることで、移植性が高く、強力に分離された軽量のマイクロサービス アプリケーション アーキテクチャを実現できます。 Dapr サイドカーは、WASM 仮想マシンとともに展開されます。 WASI アプリケーションは HTTP/gRPC を介してローカル Dapr サービス エンドポイントにアクセスし、Dapr エージェントはさまざまなバックエンド サービスに接続したり、サービス間の通信を実装したりします。

このアーキテクチャ設計により、WASI アプリケーションのセキュリティ境界が非常に明確になり、WASI セキュリティ モデルに準拠します。 WASI アプリケーションは、Dapr サイドカーを介してのみ外部サービスにアクセスできます。同時に、このアーキテクチャでは、WASM 仮想マシンと Dapr のみが信頼できる環境の依存関係としてネイティブ マシン コードで実行されます。アプリケーションは移植可能な WASM バイトコードであり、アーキテクチャの移植性とセキュリティが大幅に向上します。

Microsoft の Deis Labs の Radu Matei 氏は最近、WASI に HTTP サポートを追加する実験的なプロジェクトに貢献しました。詳細については、https://deislabs.io/posts/wasi-experimental-http/ を参照してください。

これを基に、WebAssembly と Dapr を組み合わせる技術的な実現可能性を検証するための最小限のプロトタイプを構築しましょう。

1. Dapr環境の準備

まず、https://docs.dapr.io/getting-started/ のプロセスに従います。

$ dapr init ハイパースペースにジャンプしています... バイナリをダウンロードし、コンポーネントをセットアップしています... バイナリをダウンロードし、コンポーネントのセットアップを完了しました。 daprd バイナリが /Users/yili/.dapr/bin にインストールされました。 dapr_placement コンテナが実行中です。 dapr_redis コンテナが実行中です。 dapr_zipkin コンテナが実行中です。実行中のコンテナを確認するには、「docker ps」を使用します。成功！ Dapr が稼働しています。開始するには、こちらにアクセスしてください: https://aka.ms/dapr-getting-started$ dapr run --app-id myapp --dapr-http-port 3500警告: アプリケーション コマンドが見つかりません。 ID myapp で Dapr を起動しています。 HTTP ポート: 3500。gRPC ポート: 63734 Dapr サイドカーが HTTP ポート 3500 でリッスンしているかどうかを確認しています... Dapr サイドカーが GRPC ポート 63734 でリッスンしているかどうかを確認しています。Dapr サイドカーは起動して実行中です。起動して実行中です! Dapr ログがここに表示されます。

2. WASIアプリケーションの状態ストレージとしてRedisを使用する

以下の Dapr の Get Started の例を使用し、WASI アプリケーションの状態ストレージとして Redis を使用します。具体的なロジックは以下の図に示します。

注意: 以下のアプリケーションでは Rust および AssemblyScript の環境設定が必要なので、ご自身で完了してください。

Radu プロジェクトに基づいたバージョンをフォークしました。まず、コードをダウンロードしてビルドします。

$ git clone https://github.com/denverdino/wasi-experimental-http$ cd wasi-experimental-http$ cargo build... 3分2秒でdev [unoptimized + debuginfo]ターゲットが完了しました

このテスト アプリケーションを実装するために AssemblyScript を使用しました。テストコードは次のとおりです。

$ cat tests/dapr/index.ts// @ts-ignoreimport { Console } from "as-wasi";import { DaprClient, StateItem } from "./dapr";import { JSON } from "assemblyscript-json";Console.log("Dapr API をテストしています....")let dapr = new DaprClient()dapr.saveState("statestore", "weapon", JSON.Value.String("Death Star"))let o = JSON.Value.Object()o.set("name", "Tatooine")o.set("test", 123)let item = new StateItem("planets", o)let items: StateItem[] = [item]dapr.saveBulkState("statestore", items)let testObj = dapr.getState("statestore", "planets")let testStr = dapr.getState("statestore", "weapon")if (testStr.toString() == "Death Star" && testObj.isObj && (<JSON.Integer>(<JSON.Obj>testObj).getInteger("test")).valueOf() == 123) { Console.log("テストに成功しました!")} else { Console.log("テストに失敗しました!")}

コード ロジックは非常にシンプルで、Dapr クライアントを作成し、REST API を通じて Dapr ステータスを管理します。これをすぐに確認できます。

$ cargo run 0.19 秒で開発 [非最適化 + デバッグ情報] ターゲットが終了しました `target/debug/wasi-experimental-http-wasmtime-sample` を実行しています Dapr API をテストしています....POST http://127.0.0.1:3500/v1.0/state/statestore with [{"key":"weapon","value":"Death Star"}]POST http://127.0.0.1:3500/v1.0/state/statestore with [{"key":"planets","value":{"name":"Tatooine","test":123}}]GET http://127.0.0.1:3500/v1.0/state/statestore/planetsGET http://127.0.0.1:3500/v1.0/state/statestore/weapon テストに成功しました!モジュールのインスタンス化時間: 333.16637ミリ秒

3. 要点分析

wasi-experimental-http プロジェクトは、WASI アプリケーションでの HTTP サービスへのアクセスをサポートするために、Wasmtime (Bytecode Alliance の WASM 実装) 仮想マシンに拡張機能を実装します。また、AssemblyScript HTTP クライアントの実装も提供します。

wasi-experimental-http プロジェクト: https://github.com/deislabs/wasi-experimental-http/。

さらに、AssemblyScript 用の Dapr ラッパーも提供しています。これは https://github.com/denverdino/wasi-experimental-http/blob/main/tests/dapr/dapr.ts で見つかります。

// @ts-ignoreimport { Console } from "as-wasi";import { Method, RequestBuilder, Response } from "../../crates/as";import { JSONEncoder, JSON } from "assemblyscript-json";export class StateItem { key: string value: JSON.Value etag: string | null メタデータ: Map<string, string> | null コンストラクター(キー: 文字列、値: JSON.Value) { this.key = key this.value = value this.etag = null this.metadata = null }}...export class DaprClient { port: i32 address: 文字列コンストラクター() { this.address = "127.0.0.1" this.port = 3500 } stateURL(storeName: 文字列): 文字列 { return "http://" + this.address + ":" + this.port.toString() + "/v1.0/state/" + storeName } saveState(storeName: 文字列、キー: 文字列、値: JSON.Value): boolean { let item = new StateItem(key, value) let items: StateItem[] = [item] return this.saveBulkState(storeName, items) } saveBulkState(storeName: 文字列、アイテム: StateItem[]): boolean { // ハンドル フィールド let encoding = new JSONEncoder(); // 必要なオブジェクトを構築します。encoder.pushArray(null); for (let i = 0, len = items.length; i < len; i++) {let item = items[i] encoding.pushObject(null); encoding: encoder.setString("key", item.key) encodeValue(encoder, "value", item.value) if (item.etag != null) { encoding: encoder.setString("etag", <string>item.etag) } encoding: popObject() };エンコーダー.popArray(); // または、シリアル化されたデータを文字列として取得します。let jsonString = encoding.toString(); url = this.stateURL(storeName); とします。 Console.log("POST " + url + " with " + jsonString); res = new RequestBuilder(url) .method(Method.POST) .header("Content-Type", "application/json") .body(String.UTF8.encode(jsonString)) .send(); ok = res.status.toString() == "200" res.close() とします。 ok を返します } getState(storeName: string, key: string): JSON.Value { let url = this.stateURL(storeName) + "/" + key; Console.log("GET " + url); res = new RequestBuilder(url) .method(Method.GET) .send(); とします。 ok = res.status.toString() == "200" とします。 result = <JSON.Value> new JSON.Null() とします。 if (ok) { body = res.bodyReadAll();結果 = <JSON.Value>JSON.parse(body) } res.close();結果を返します。

テスト アプリケーションのメイン関数は、Wasmtime ランタイム環境を作成し、それを HTTP 拡張機能として追加し、テスト アプリケーションを実行する WASM バイトコードをロードします: https://github.com/denverdino/wasi-experimental-http/blob/main/src/main.rs。

fn main() { let allowed_domains = Some(vec![ "http://127.0.0.1:3500".to_string(), ]);モジュールを "tests/dapr/build/optimized.wasm" にします。 create_instance(module.to_string(), allowed_domains.clone()).unwrap();}/// コンパイルされたモジュールから Wasmtime::Instance を作成し、/// WASI をリンクします imports.fn create_instance( filename: String, allowed_domains: Option<Vec<String>>,) -> Result<Instance, Error> { let start = Instant::now(); store を Store::default() とします。 mut linker = Linker::new(&store); とします。 ctx = WasiCtxBuilder::new() .inherit_stdin() .inherit_stdout() .inherit_stderr() .build() ? とします。 let wasi = Wasi::new(&store, ctx); wasi.add_to_linker(&mut リンカー)?; // リンク `wasi_experimental_http` let http = HttpCtx::new(allowed_domains, None)?; http.add_to_linker(&mut リンカー)?;モジュールを wasmtime::Module::from_file(store.engine(), ファイル名) とします。インスタンスを linker.instantiate(&module) とします。継続時間を start.elapsed() とします。 println!("モジュールのインスタンス化時間: {:#?}", 期間); Ok(インスタンス)}

道は長く困難だが、進み続ければ目的地にたどり着くだろう

WASM/WASI は、軽量で移植性があり、デフォルトで安全なアプリケーション ランタイムの優れた基盤を提供します。 WebAssemblyはブロックチェーンなどの分野で広く利用されています。ただし、一般的なサーバー側アプリケーションの場合、WASM と WASI の間のギャップは依然として非常に明白です。 Berkeley ソケットなどの標準化されたネットワーク プログラミング インターフェイスがないため、WASM 仮想マシンを拡張することによってのみ補完できます。さらに、WASM のマルチスレッド機能はまだ標準化されていません。現在の HTTP 呼び出しでは、ブロッキング同期呼び出しが使用されるため、効率的で安定したネットワーク通信を実現できません。

さらに、WASM/WASI のもう一つの欠点は、開発効率とエコシステム構築です。現在、多くのプログラミング言語が徐々に WebAssembly のサポートを開始していますが、一般的な開発者にとっては、AssemblyScript などのスクリプト言語の方が適切な選択肢です。 AssemblyScript は TypeScript 構文を再利用するため、Rust/C++ に比べて学習曲線が大幅に短縮され、VS Code などの非常に優れた IDE ツール エクスペリエンスも提供されます。ただし、実行のために JavaScript に変換される TypeScript とは異なり、AssemblyScript アプリケーションは実行のために WASM バイトコードにコンパイルされます。 AssemblyScript は本質的には静的に型付けされたコンパイル言語であり、JS/TS のような動的に型付けされた解釈型言語とは大きく異なります。両者の間には構文にも若干の違いがあります。たとえば、AssemblyScript には現在、クロージャや正規表現などの一般的な関数のサポートがないため、WASM アプリケーションの開発にはまだ一定の技術的ハードルが存在します。

さらに、NPM の強力なエコシステムと比較すると、AssemblyScript コミュニティも非常に若いです。 JSON のシリアル化やデシリアル化など、多くの機能をゼロから構築する必要があります。私たちは _https://github.com/nearprotocol/assemblyscript-json_ を選択しましたが、その使いやすさとパフォーマンスは成熟した JSON ライブラリに比べるとまだはるかに劣っています。もちろん、AssemblyScript の急速な成長も見られ、正規表現のサポートなど、AssemblyScript コード ベースに貢献する開発者が増えています。

Dapr の登場により、WASM/WASI 向けの一般的な分散アプリケーション、特にポータブルおよびサーバーレス アプリケーションの開発に新たな希望の光がもたらされました。ただし、Dapr は完璧ではありません。API の標準化によりバックエンド サービスの移植性は向上しますが、差別化された機能のサポートも妨げられます。 Sidecar アーキテクチャにより、柔軟性が向上する一方で、展開と管理の複雑さが増します。

合理的な楽観主義者として、私はあらゆる技術にはまだ初期段階があると信じています。ユビキタスコンピューティングとイノベーションの理想を現実のものにするために、コミュニティが共同で取り組むことを期待しています。