Zenn
Aidemy Tech BlogPublicationへの投稿
📚

SpiderLightning触ってみた

へたれ
2022/12/15に公開
AWS
WebAssembly
WebAssembly
tech

2022年Aidemy社のアドベントカレンダー15日目の記事です。

はじめに

おはこんばんにちは、へたれです。
Aidemy社でModeloy Engineeringという伴走型のDX内製化サービスを提供するチームに所属しています。

アドベントカレンダー1日目の記事では初めてWebAssembly(以下Wasm)に触れてみました。
様々なホスト上でハードウェアリソース(もしくは相当の働きをするもの)へのアクセスを可能にする標準化の試みとしてThe WebAssembly System Interface(以下WASI)を紹介し、実装状況についてまとめたので、よかったら読んでみてください。

一方でWASIとは別のアプローチとして、SpiderLightningというプロダクトが登場しています。
なんとWasmからクラウド上の各種リソースへのアクセスを可能とするものです！

本記事ではこのSpiderLightningに入門し、対応状況や使い勝手を確認していきたいと思います。

SpiderLightining概要

システムを構築する際、キーバリューストアやメッセージキューなどワークロード特性に応じたインフラを用意する必要があります。
キーバリューストア一つとっても、ローカルファイル、仮想マシン上にRedisを構築、各種クラウドプロバイダのサービスなど様々な選択肢があり、可用性等の要件に応じて使い分けます。
しかしこれらはインターフェイスが統一されているわけではありません。
都度都度実装する必要があり、これではWasmのポータビリティが失われてしまいます。
そこで画一的なインターフェイスを提供するのがSpiderLightningです。

試してみる

実際に試してみましょう。
今回はAWS DynamoDBをキーバリューストアとして書き込み・読み込みを行うコードを実行してみます。

手順はSpiderLightning公式ページを踏襲しています。
また最終的なコードはGithubに載せているので、よかったら試してみてください。

slight CLIをインストールします。
プロジェクトを作成する他、このCLIを通じて実行します。

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/deislabs/spiderlightning/main/install.sh)"

次にプロジェクトを作成します。

$ slight new -n spidey@v0.2.0 rust && cd spidey

コードを書いていきましょう。
まずはslightfile.tomlにキーバリューストアとしてDynamoDBを利用すること、そのテーブル名を記述します。
クレデンシャル情報は環境変数から自動読み込みしてくれます。

specversion = "0.2"

[[capability]]
resource = "kv.awsdynamodb"
name = "try-spiderlightning"
    # This capability does not require any configs

次にmain.rsに実行するコードを記述していきます。

use anyhow::Result;

use kv::*;
wit_bindgen_rust::import!("wit/kv_v0.2.0/kv.wit");
wit_error_rs::impl_error!(kv::Error);

fn main() -> Result<()> {
    let kv_store = Kv::open("try-spiderlightning")?;
    kv_store.set("key1", b"Hello, SpiderLightning!")?;
    kv_store.set("key2", b"How are you?")?;
    // show each messages
    println!(
        "{}",
        std::str::from_utf8(&kv_store.get("key1")?)?,
    );
    println!(
        "{}",
        std::str::from_utf8(&kv_store.get("key2")?)?,
    );
    Ok(())
}

コードは準備できたので、DynamoDBを用意しましょう。
テーブルの形式は{"key": {"S":" <key>}, "value": {"S": <value>}}を想定しているみたいです。

純粋なWasmのビルドを行います。

$ rustup target add wasm32-wasi
$ cargo build --target wasm32-wasi

最後にslight CLIを通して実行してみましょう。

Wasmそのものは実行する機能を持っておらず、あくまでインターフェイスを知っているだけです。
slight CLIがslightfile.tomlの内容に基づき実装を提供し、Wasmのプロセスを実行する形となっています。

$ slight -c slightfile.toml run -m target/wasm32-wasi/debug/spidey.wasm
Hello, SpiderLightning!
How are you?

またAWSコンソールから覗いてみると、DynamoDBのテーブルにちゃんと書き込まれていることがわかります。

ちゃんとDynamoDBをキーバリューストアとして書き込み、読み込みできました。

対応状況

少なくともDynamoDBはキーバリューストアとして利用できることが確認できました。
他のコンポーネントやクラウドプロバイダの対応状況はどうなっているのでしょうか？

v0.2.0の時点では提供する機能とその実装は以下のとおりです。

  • events-api ... None
  • events ... None
  • http api ... Local
  • http handler macro ... Local
  • http ... Local
  • key-value-store ... AWS DynamoDB, Azure Blob, Local File, Redis
  • lockd ... etcd
  • message queue ... Azure Service Bus, Local File
  • pubsub ... Apache Kafka, Mosquitto
  • runtime-configs ... Azure App Service, Environment Variables, User Secrets

こうしてみると、クラウドサービスへの対応がまだまだで、実運用への道は遠そうです。

ちなみにSpiderLightiningとWASIでは重複する仕様も多いのですが、キーバリューストアの仕様をみてみると、WASIに準拠しようとしているわけではなさそうです。

おわりに

今回はWasm上から共通インターフェイスを通じて各種インフラへのアクセスを可能とするSpiderLightningを触ってみました。
slightfile.tomlを書き換えるだけで実装を入れ替えることができる手軽さは開発者体験がとてもよさそうだなと思いました。
一方でローカルとリモートの違い(速度やレースコンディションの考慮)、各種サービス特性や制約の差をここで吸収しきれるとは思えないところもあり...どこまで解決可能か、どこからは割り切るか、というところは今後の議論に期待ですね。

ところでslightを始めwasmcloudやwasmer、Node.jsなどWasmのランタイムが増えていき群雄割拠みたいな状態にはなっていて面白いですね。
最終的にどんなパワーバランス・棲み分けに落ち着くのか楽しみです。

Aidemy Tech Blog
Aidemy Tech BlogPublication

株式会社アイデミーの技術ブログです。

Discussion