PR

KubeCon NA 2021プレカンファレンスのWASM Dayの後半を紹介

2022年3月1日(火)
松下 康之 - Yasuyuki Matsushita
KubeCon前日のプレカンファレンスからWASM Dayを紹介する。

クラウドネイティブなシステムに関するカンファレンス、KubeCon/CloudNativeCon North America 2021は、2021年10月11日から15日までカリフォルニア州ロスアンゼルスのLA Convention Centerで開催された。このレポートでは10月12日に行われたミニカンファレンスの中から「Cloud Native WASM Day」の後半の内容を紹介する。

Liam Randall氏が参加者に配っていたステッカー

Liam Randall氏が参加者に配っていたステッカー

KubeCon/CloudNativeConは非常に盛り上がっているカンファレンスであるが、今回現地に集まったのは約3300名だった。当然、プレカンファレンスの参加者も限られた人数となっており、WASM Dayの参加者は約30名と非常にコンパクトなセッションとなった。

参加者の人数はこれぐらい。左端はLiam Randall氏だ

参加者の人数はこれぐらい。左端はLiam Randall氏だ

WASMとwasmCloudでマルチクラウド上にサービスを構築

後半のセッションからは「Helping One of Europe's Banks Re-platform with Declarative, Self-healing, Multi-cloud WasmCloud Clusters on Kubernetes」と題されたセッションを紹介する。これはロンドンのコンサルティングファームRed Badgerの創業者であるStuart Harris氏とエンジニアのAayush Attri氏によるセッションで、マルチクラウド上に構築したサービスをWASMとwasmCloudで実装したデモを使って解説するというものだ

セッションを行うHarris氏とAttri氏

セッションを行うHarris氏とAttri氏

まずはHarris氏が顧客であるヨーロッパの銀行が求めるクラウドベースのシステムについて、単にプラットフォームを移し替えるだけではなくマルチクラウドで運用できること、障害時の素早い対応などを目的に新しいシステムを求めていたことを紹介した。そしてその要求に応えるためのプラットフォームとして、wasmCloudを選択したことを説明。その理由を深く説明することはせずにデモを行うことで、マルチクラウドでのサービスが障害時に切り替わる部分を解説した。

GCPとAWSで同じサービスを動かしてActorが切り替わるようすを見せた

GCPとAWSで同じサービスを動かしてActorが切り替わるようすを見せた

このデモはGCPとAWS双方にHTTPを受け付けるアプリ、Actorとしてそのリクエストを受けるアプリ、そしてGCP側だけにRedisのストレージにデータを書き込むというシンプルな構成になっている。このイラストにあるようにそれぞれはKubernetesのPodとして実装されているが、Pod間の通信はwasmCloudのサービス通信機能であるLatticeが受け持っている。LatticeはCNCFのプロジェクトでもあるNATSを使って実装されている。そして、クラスター間を繋ぐサービスとしてNGSが使われている。このNGSは、NATSの開発をリードしているSynadiaが提供するマネージドサービスである。

クラスター間を繋ぐのはSynadiaのNGS

クラスター間を繋ぐのはSynadiaのNGS

NGSもNATSをベースにしたコミュニケーションサービスであり、Synadiaは有償でのサービスとして提供している。

デモの中では故意にGCP側のActorを削除して、HTTPの送信がAWS側に切り替わるようすを示した。ここでは特にサービスディスカバリーのための操作をするわけでもなく、自動的にLatticeがメッセージ送信の相手を切り替えたことになる。実際の設定などが説明されることもなく終わってしまったため、若干消化不良という感は否めなかった。

6つのターミナルを使ってGCPとAWSでの動作を見せるデモ

6つのターミナルを使ってGCPとAWSでの動作を見せるデモ

ここからはこのデモを可能にしたwasmCloudの概要としてWASMのランタイム、wasmCloudのランタイム、分散型で自律的に構成が行われるLatticeなどを紹介した。ちなみにデモの中でPodのログを確認するために使っていたのはSternというツールだ。

参考:https://github.com/wercker/stern

Wasmcloudを構成するコンポーネント

Wasmcloudを構成するコンポーネント

また次のスライドでwasmCloudのランタイムについても言及している。「ボイラープレートが少ない」という部分はさまざまなOSSのライブラリーなどを定型的に挿入しなくても良いという辺りを指すのだろう。また「開発言語を選ばない」というのもWASMの利点としていつも挙げられる部分だ。

wasmCloudのランタイムを解説

wasmCloudのランタイムを解説

Latticeに関してはメッシュネットワークとして説明されており、NATSのPub/Subを使ったメッセージングを、サービス間を接続するネットワークスタックとして利用していることがわかる。

Latticeの解説

Latticeの解説

SynadiaのNGSについては簡単な説明にとどまったが、マルチクラウドでの接続機能を実装するためには必要なピースということになる。ここまででマルチクラウドでのサービスメッシュを解説したが、サービス自体が軽量化に向かうことでプラットフォーム自体の機能が増えていくという傾向を説明したスライドでは、KubernetesからIstio、Microsoftが強力にプッシュするDaprなども紹介された。ここではすでにKubernetesがレガシー扱いされていた。

DockerのSolomon Hykes氏の「サーバーサイドのWASMがあればDockerは作らなくても良かった」という発言やSingleStoreのwasi-dataなどを見ても、演算処理そのものをポータブルにすることでコンテナやそのためのオーケストレーション機能自体が余計な仕組みとして見なされていることは、WASM Dayのプレゼンターの中ではある程度一致している見方なのだろう。

WASMによるWebhookの置き換え

次に紹介するセッションも、サービスとサービスを繋ぐためのWebhookについてWASMで繋ぐという発想自体を止めて、WASMのコードを埋め込むことでより性能を上げられるという内容のものだ。

これはSuborbital Software SystemsのConner Hicks氏が行ったセッションで「Create an Extensible Cloud Native Application with WebAssembly」と題されているようにWASMを使ってWebhookを置き換える試みについて解説している。

WebhookをWASMで置き換えるとは

WebhookをWASMで置き換えるとは

どうしてWebhookが良くないのか? については次のスライドで説明されている。ここではインターネットを超えて行く必要があり、それはレスポンスタイムとコストの両方とも無駄にしていること、セキュリティの観点からはお互いのサービスを認証する標準的な仕組みがなく、センシティブなデータを送受信する場合にそれを守るために手間がかかること、さらにWebhookを使う側にとってみればWebhookを実装するためのサーバー等が必要になることなどを挙げた。

Webhookの問題点を列挙

Webhookの問題点を列挙

その解決方法として、Webhookで呼ばれる機能を元のアプリケーションにエンベッドするアイデアを説明。この利点は高い性能と低いコスト、より良いセキュリティ、実装するための特別なサーバーなどを必要としないというWebhookの問題点をすべて解決する内容となっている。

ロジックをエンベッドすることで問題点を解決

ロジックをエンベッドすることで問題点を解決

そしてロジックをエンベッドするという部分にWASMが使えるのではないか? というのがHicks氏の提案だ。

WASMをサーバーロジックに埋め込むアイデアを紹介

WASMをサーバーロジックに埋め込むアイデアを紹介

このアイデアを実証するために、クラウドプロバイダーを使って実験を行ったというのが次のスライドだ。

WebhookとWASMのエンベッドを比較

WebhookとWASMのエンベッドを比較

これは同じクラウドプロバイダーのインスタンスを用意して、Webhookでロジックを起動する方法とWASMのコードを元のアプリケーションに埋め込んで起動する方法を比べた結果を示したものだ。パフォーマンス的には30秒間で5000回しか実行できなかったWebhookに比べて30,000回実行でき、レイテンシーは30ms以上かかったのに比べて平均で5msだったと解説した。さらにコストについては、Webhookにはデータ転送が発生するためにコストが発生しているが、WASM埋め込みの場合はデータ転送自体が発生しないということを説明した。

ただすべてがこの方法で解決するわけではないとして、欠点も解説している。

WASMを埋め込む場合の欠点

WASMを埋め込む場合の欠点

埋め込まれる側のアプリケーションに対する注意点以外にも、これまでデベロッパーが使っていたツールとの親和性がない可能性があること、利用する言語によっては起動に時間がかかることなどを挙げていた。時間がかかる例としてSwiftが、起動が速い言語の例としてRustがそれぞれ挙げられているのが興味深い。

Akriの一部をWASMで書き直すプロジェクト

その他にも監視カメラなどのIoTエッジデバイスをKubernetesから利用できるようにするためのオープンソースソフトウェアAkriの一部をWASMで書き直すという非常に実験的なプロジェクトを、Microsoftのエンジニアがブラジルの大学生と共同で発表したセッションなどがあった。ポータブルで高速、ミニマムなファイルサイズというWASMの利点を活かした内容となった。

セッションのタイトルは「Living on the Edge: Using IoT Devices on Kubernetes WebAssembly Applications - Kate Goldenring, Microsoft; Rodrigo Farias Rodrigues Lemos, Federal University of Pernambuco」。

Akriのデバイス探索機能をWASMで書き直した例

Akriのデバイス探索機能をWASMで書き直した例

このセッションでは、書き換えたWASMモジュールによってOCIイメージが1/54まで小さくなったことを説明していた。

Akriの一部をWASMで書き換えたことでファイルサイズが減少

Akriの一部をWASMで書き換えたことでファイルサイズが減少

このAkriというプロジェクトはDeis Labs発祥のもののようだが、2021年10月にCNCFのサンドボックスプロジェクトとして採用されたことがブログ記事として発表された。この記事を書いているのは、このセッションのプレゼンターでもあるKate Goldenring氏だ。

参考:Akri a Year Later

Akriについては以下の公式ドキュメントも参照されたい。

参考:Akri

Cloud Native WASM DayはWASMにフォーカスしたミニカンファレンスであるため、WASMがコンテナを置き換えるポータブルなワークロードのデファクトスタンダードであることが、多くの参加者の共通認識となっていることを感じさせる一日となった。最後にSolomon Hykes氏のツイートを使ってWASMを紹介しているワンシーンを紹介してこの項を終えたい。これもMicrosoftのKate Goldenring氏のセッションで使われたスライドだ。

「サーバーサイドのWASMがあればDockerは要らなかった。

「サーバーサイドのWASMがあればDockerは要らなかった。

著者
松下 康之 - Yasuyuki Matsushita
フリーランスライター&マーケティングスペシャリスト。DEC、マイクロソフト、アドビ、レノボなどでのマーケティング、ビジネス誌の編集委員などを経てICT関連のトピックを追うライターに。オープンソースとセキュリティが最近の興味の中心。

連載バックナンバー

サーバー技術解説

Tigeraのアドボケイトが、x86とARMのマルチアーキテクチャークラスターを解説

2022/4/7
ARMの優位性を解説しながら、ARMをx86クラスターに追加するマルチアーキテクチャークラスターを、デモを用いて解説。
システム開発イベント

KubeCon NA 2021からサービスメッシュの2セッションを紹介

2022/3/18
KubeCon NA 2021からサービスメッシュのLinkerdの最新情報とIstioを使ったユースケースのセッションを紹介する。
セキュリティイベント

KubeCon NA 2021、ソフトウェア開発工程のタンパリングを防ぐSLSAを解説

2022/3/9
KubeCon NA 2021のプレカンファレンスから、ソフトウェアサプライチェーンを実装するフレームワークSLSAを取り上げたセッションを紹介する。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています