建築家または建築家を目指す人が知っておくべき事柄を毎月まとめた概要です。
プロフェッショナルソフトウェア開発における知識とイノベーションの普及を促進
Git は、ソフトウェア開発におけるバージョン管理によく使われるツールです。複数の Git アカウントを使用することは珍しくありません。Git アカウントを正しく構成して切り替えることは困難です。この記事では、Git が提供するアカウント構成とその制限、およびプロジェクトの親ディレクトリの場所に基づいてアカウントを自動的に切り替えるソリューションについて説明します。
WebAssembly は、その範囲をブラウザからクラウドやエッジ コンピューティングなどの他のドメインにまで拡大しました。WebAssembly は、WebAssembly コンポーネント モデル (WCM) を使用して、Rust、Python、JavaScript などのさまざまなプログラミング言語のライブラリ間のシームレスな相互作用を可能にし、真の多言語プログラミング環境を推進します。
Shreya Rajpal は、リスクを軽減し、LLM の安全性と効率性を高めるために設計されたオープンソース プラットフォームである Guardrails AI を紹介します。
このポッドキャストでは、Culture & Methods の主任編集者である Shane Hastie が、開発者関係の役割とオープンソース コミュニティへの貢献について Craig Box に話を聞きました。
Ranjith Kumar は、グローバルな容量を持つサービス所有者に提示される抽象化と保証、数十の地域にわたるワークロードを管理するための設計と実装、さまざまな需要の分類とモデル化、さまざまな地域間で需要をシフトすることによるグローバルな容量管理の実現について説明します。
ソフトウェア開発の意思決定をレベルアップするための変革的な洞察を発見してください。限定オファーにはコード LIMITEDOFFERIDSBOSTON24 を使用してください。
上級開発者から実践的なアドバイスを得て、現在の開発課題を解決しましょう。限定オファーにはコード LIMITEDOFFERIDSMUNICH24 を使用してください。
注目すべき新たなトレンドを発見して、ソフトウェア スキルをレベルアップしましょう。今すぐ登録してください。
すべてのプロフェッショナルが知っておくべきすべてのトピック、テクノロジー、テクニックに関する月刊ガイド。無料で購読できます。
InfoQ ホームページ 記事 WebAssembly による多言語プログラミング: 実践的なアプローチ
2024年5月7日 11分読了
WebAssembly (Wasm と略されることもあります) はブラウザー用に構築されました。しかし、多くのテクノロジーと同様に、当初の目的を超えて、より重要なものになりました。そして、最近リリースされた WebAssembly コンポーネント モデル (WCM) により、私たちは新しいタイプのソフトウェア開発を体験しています。それは、当面の作業に最適な言語を選択し、言語に関係なく最適なアップストリーム ライブラリを選択できる世界です。つまり、真の多言語の世界です。当時 Mozilla にいた Luke Wagner が 2015 年に WebAssembly を初めて世に紹介したとき、彼は次のように述べていました。
Mozilla では、Chromium、Edge、WebKit のエンジニアと協力し、Web のコンパイル ターゲットとして特別に設計された、移植性が高く、サイズと読み込み時間の効率に優れた形式と実行モデルを定義する新しい標準である WebAssembly の作成に着手したことをお知らせします。
Mozilla、Google、Microsoft、Apple は協力して、JavaScript 以外の言語を、JavaScript と相互運用可能でブラウザが実行できる標準形式にコンパイルできるようにするオープンソース テクノロジを構築しました。
これは、ブラウザを複数の言語のホームにするという、いくつかの誤ったスタートを修正しようとしたものです。Java アプレット、Silverlight、Flash を覚えていますか。この道は以前にも踏まれていました。しかし今回は、Luke と他の初期の WebAssembly 開発者が推論したところによると、基盤となる技術はオープンソースで、幅広くサポートされ、言語に依存しないものでした。
ブラウザの WebAssembly は、これまで長い間安定してきました。W3C はバージョン 1.0 の最終勧告をリリースし、すでにバージョン 2.0 の開発に取り組んでいます。Figma や Microsoft Office Online など、いくつかの有名な Web アプリでは、すでに WebAssembly が使用されています。
しかし、Luke の WebAssembly の紹介をもう一度見てみると、WebAssembly がブラウザー以外にも有望である理由がわかります。「WebAssembly は […] 移植可能で、サイズと読み込み時間の効率に優れた形式と実行モデルを定義します。」この形式は、一度書けばどこでも実行できる新しい世代であり、Java と .NET で行われたバイトコード最適化に関する数十年にわたる研究に基づいて構築された世代です。
開発者はすぐに、プラグイン アーキテクチャ、IoT、エッジ、クラウド コンピューティングなど、コンピューティングの他の多くの分野で WebAssembly が有望であることに気付きました。結局のところ、WebAssembly にはセキュリティ サンドボックス (実際には Docker コンテナーよりも強力) があり、Windows、macOS、Linux、およびさまざまな特殊なオペレーティング システムで実行できます。WebAssembly は高速で、バイナリはコンパクトで転送も簡単です。
Luke 氏と他の多くの初期の WebAssembly 開発者は、新しい可能性に非常に興奮し、仕様を一般使用とリファレンス実装の構築に向けて拡張するために Bytecode Alliance を結成しました。最近の Cloud Native Computing Foundation (CNCF) レポートによると、WebAssembly はブラウザー以外でも人気が急上昇しています。2024 年 3 月にパリで開催された KubeCon EU では、WebAssembly は Docker に次いで 2 番目に話題になったトピックでした。
WebAssembly のようなテクノロジーが少しでも成功するには、多くの言語が WebAssembly へのコンパイルをサポートする必要があります。現在、上位 20 言語のほとんどが、ある程度 WebAssembly をサポートしています。
そして、これにより魅力的な新たな可能性が開かれました。
Python プログラムが WebAssembly として実行でき、Rust プログラムが WebAssembly として実行できる場合、2 つの言語が同じバイトコード形式にコンパイルされていることがわかります。このバイトコード形式は移植可能で、ランタイム (Java や .NET など) で実行できます。つまり、ランタイムは、コードのすべてのビットのランタイム情報 (どの関数が呼び出されたか、どの型が使用されたかなど) にアクセスできます。ある意味では、ランタイムは実行中のコードに対して言語に依存しないビューを持っています。
ランタイムを基盤として Python コードと Rust コードを相互に通信できるようにするのは、それほど難しいことでしょうか。Rust バイナリが Python ライブラリ (WebAssembly にコンパイル済み) をロードし、それを Rust で記述されているかのように使用できるようにするのは、それほど難しいことでしょうか。Go、C/C++、C#、JavaScript/Typescript、PHP、Swift、Kotlin、およびその他のいくつかの言語はすべて、WebAssembly を実行できます。理論的には、WebAssembly ランタイム内でこれらすべての言語が連携して動作できるようにするシステムを構築することは可能であるはずです。
WCM は、1 つの WebAssembly バイナリが他の WebAssembly バイナリにリンクされる方法を指定します。具体的には、WebAssembly バイナリがエクスポート (関数、型、インターフェース) とインポート (他のソースから取得する必要がある関数、インターフェース、型) を宣言できるようにします。
図1: WebAssemblyコンポーネントモデル
プログラムで YAML を解析し、LLM に対して AI 推論を実行し、その結果をキー値ストレージに保存する必要があるとします。WCMl を使用すると、次のようにプログラムを構築できます。TypeScript で記述されたメイン コードでは、いくつかの異なるライブラリが必要であることを宣言します。
現状では、このプロジェクトの開発者は、これらの要件を記述する WebAssembly Interface Types (WIT) ファイルを作成することを選択します。WIT は、特定のシステムが他のシステムと構造化データを交換する方法を記述するインターフェイス定義言語 (IDL) です。Protobuf、Thrift、MsgPack などのテクノロジを使用したことがある場合、IDL の動作を目にしたことがあるでしょう。
WIT ファイルは、WebAssembly バイナリのインポート (ニーズ) とエクスポート (機能) を定義します。上記の例では、プログラムには 3 つの異なる動作が必要です。ただし、そのうちの 1 つに焦点を絞ってみましょう。次のようなインターフェイスを持つキー値ストレージの実装が求められる場合があります。
このインターフェースは、特定のシグネチャを持つ 2 つの関数 (get と set) を宣言します。メイン プログラムの TypeScript コードでは、このオブジェクトの使用は次のようになります。
もちろん、開発者は、同じ WIT インターフェイスをエクスポートするキー値ストレージの実装を見つける (または別のコンポーネントとして独自に記述する) 必要があります。ただし、一致する実装が見つかったら、上流のキー値ストレージ実装を TypeScript コードにリンクする必要があります。
開発者が知る必要も心配する必要もないのは、キー値ストレージ実装がどのアップストリーム言語で記述されたかということです。Rust、Python、C のいずれでもかまいません。どれも同じように動作します。WIT 仕様のおかげで、アップストリーム実装と開発者のコードは、API の形状についてすでに一致しています。上記の TypeScript コードが示すように、開発者の観点からは、そのコンポーネントは TypeScript ライブラリとして表示されます。
この例には、もう 1 つ細かい点があります。キー値ストレージの実装は 1 つだけではなく、複数存在する可能性があります。ローカル JSON ファイルを使用してデータを保存したり、Redis を使用したり、単体テスト用のモックだけを使用することもできます。インターフェイスが一致していれば、適切なバージョンを使用してアプリケーションを構築できます。
最初は、このモデルが価値があるかどうか疑問に思う人もいるかもしれません。その理由は、次のようなものかもしれません。自分の好みの言語で書くことにすでに満足しているので、この機能は必要ありません。
しかし、その声明には価値提案が隠されています。現在使用しているすべての言語に対して、言語固有のライブラリ セットを構築する必要があります。JavaScript には、YAML パーサー、HTTP ライブラリ、タイムスタンプ パーサーがあります。Rust には、それぞれ独自のバージョンがあります。Go も同様です。他のすべての言語も同様です。
これらのライブラリはそれぞれ、他の言語ですでに解決されている問題を解決するために時間を費やす個人によって保守される必要があります。コアの動作は (事実上) 同じであるにもかかわらず、複数の言語で同じ機能を開発するためにおそらく何万時間もの作業時間が費やされています。なぜでしょうか。それは、ライブラリを真に言語間で使用する方法が存在しないからです。
さらにフラストレーションがたまる原因として、HTTP や YAML などの明確に規定された標準でさえ、言語エコシステム間で実装が不均一であることが挙げられます。YAML シリアル化の微妙な違いにより、コンテンツが 1 つの言語のライブラリでシリアル化され、別の言語のライブラリでデシリアル化されると、予期しないバグが発生します。これらのバグは時間の浪費や、場合によっては破壊的なバグやコストのかかる停止の原因にもなります。
各開発者は、自分の選んだ言語で記述する権限を与えられるべきです。開発者が 1 つの言語でしか記述しない場合は、その権限を与えられるべきです。WCM では、ユーザーが言語を選択しながら最先端の機能を使用できます。ある開発者は Python で記述し、別の開発者は C# で記述して、同じアップストリーム ライブラリを使用できます。
図2: WebAssemblyコンポーネントのユーザーは複数の言語で書かれたコンポーネントを使用できる
さらに、解析など、特にパフォーマンスが重要なコードの場合、開発者は Rust や C などの高性能言語でライブラリを作成することができます。AI と ML は Python の世界の得意分野です。突然、それらの Python ライブラリが Go や JavaScript プログラムで使用できるようになります。つまり、当面の問題を解決するのに最適な言語で基本的なコードを作成できるのです。他の開発者がどの言語を使用しなければならないかを指示することなく、これを行うことができます。
WCM と以前のものの違いは何でしょうか? 1990 年代後半の Common Object Request Broker Architecture (CORBA) や Component Object Model (COM) から、gRPC や Thrift などの最近の人気のフレームワークまで、多くのテクノロジが構造化データを渡す方法を提供してきました。
WebAssembly は、この概念をサンドボックス化されたバイトコード形式に取り入れ、ネットワーク インターフェースを必要とせずにコンポーネント間の分離を実現するという点でユニークです。2 つのコンポーネントが一緒に実行される場合、それらは同じ WebAssembly ランタイムで実行されますが、実行コンテキスト (またはサンドボックス) は別々です。各コンポーネントは独自の分離されたメモリで実行されるため、メモリ指向の攻撃のクラス全体を防止できます。
機能ベースのセキュリティ モデルのおかげで、各コンポーネントは異なるセキュリティ パラメータを持つことができます。たとえば、YAML パーサーはインターネットにアクセスできませんが、ファイルシステムの限られた部分にアクセスできます。また、コンポーネントはローカルで実行されるため、gRPC や Thrift などのフレームワークの高価なネットワーク オーバーヘッドは必要ありません。
WCM は有望ではあるものの、本格的な使用が期待されるまでに克服すべき 3 つの重要な課題があります。
WebAssembly の最大の強みは、同時に重要なリスクももたらします。中立的なバイトコード形式は、言語ツールチェーンがそれをサポートしている場合にのみ役立ちます。ほとんどの主要言語は少なくともある程度サポートされていますが、遅れている言語も多くあります。多くの言語が遅れている重要な領域の 1 つは、コンポーネント モデルのサポートです。Rust、C、Python、JavaScript/Typescript はサポートされていますが、他のほとんどの言語はサポートされていません。
たとえすべての言語がコンポーネントをサポートしたとしても、各言語がコンポーネントを記述するためのツールとして適切に機能するかどうかは興味深い疑問です。ガベージ コレクターを備えた言語 (Go など) は、ガベージ コレクターを備えていない言語 (Rust や C など) よりも実行時に遅くなります。スクリプト言語 (Python や JavaScript など) は、それぞれにインタープリターが必要なため、やはり遅くなります。
最後に、コンポーネントが普及するには、臨界質量に達する必要があります。2 つの条件を満たす必要があります。開発者がコンポーネントを作成して配布すること、および Wasm をターゲットとする開発者がネイティブ ライブラリではなくコンポーネントを使用することを意識的に決定することです。各主要言語ではすでに膨大な数のライブラリが蓄積されているため、克服しなければならない慣性は小さくありません。
おそらく、この慣性を克服する最善の方法は、開発者が利用可能な代替手段よりも使いたいと思うほど価値と品質の高いコンポーネントを作成することです。これは、新興コミュニティが達成すべき大きな課題です。
1 か月前、WCM は WebAssembly System Interface (WASI) v0.2 仕様 (WASIp2 と呼ばれることもあります) の一部としてリリースされました。すでに、WIT の自動生成と使用 (上記の例で作成したものなど) から、コンポーネントをアプリにリンクして運用環境でこれらのアプリを実行することまで、あらゆることを支援するツールが数多く登場しています。
ツールは急速に進化していますが、やるべき作業はまだたくさんあります。このエコシステムに早く参入した人たちは、コンポーネント エコシステムの基盤となる基本コンポーネントの作成を開始します。
WebAssembly 互換言語のすべてにコンポーネント実装がまだ備わっているわけではありません。Python、JavaScript、Rust が最初に導入しましたが、他の言語も急速に進歩しています。2024 年を通じて、さまざまな言語コミュニティがコンポーネント ツールを導入する予定です。
WebAssembly コンポーネント用の製品グレードのツールはすでに存在します。オープンソースの Spin プロジェクトはほぼ 1 年間コンポーネントをサポートしており、コンポーネントベースのアプリケーションは Raspberry Pi や巨大な Kubernetes クラスターなど多様な環境で実行できます。
しかし、コンポーネントが主流になるためには、WebAssembly はいくつかのハードルを乗り越える必要があります。言語はコア バイトコード仕様と最新の仕様をサポートする必要があります。特にさまざまな言語間でのパフォーマンスを分析して最適化する必要があります。しかし、おそらく最も重要なのは、このテクノロジを開発者にとって日常的に実行可能な選択肢にするために、十分なコンポーネントが生産され、消費される必要があることです。
コンポーネントが登場し、真の多言語アプリケーションが実現します。ブラウザー企業のコンソーシアムが WebAssembly プロジェクトを初めて発表して以来、このテクノロジーは多くの異なるコミュニティの協力に常に依存してきました。言語開発者、ブラウザー作成者、クラウド エコシステムはすべて、協力するための共通の基盤を見つける必要があります。そして、それがコンポーネントを主流に押し上げるのです。
このコラボレーションの証拠は、いくつかの言語とランタイムで前進の勢いが見られることから明らかです。この瞬間は、このテクノロジの作成に参加できるまれな機会です。WCM の中核となるツールとドキュメントを管理している Bytecode Alliance は、WCM への参加を開始するのに最適な場所です。
InfoQ の先週のコンテンツのまとめが毎週火曜日に配信されます。250,000 人以上のシニア開発者のコミュニティに参加してください。例を見る
InfoQ の先週のコンテンツのまとめが毎週火曜日に配信されます。250,000 人以上のシニア開発者のコミュニティに参加してください。例を見る
2024 年 6 月 24 日 – 25 日 | ボストン、マサチューセッツ州今日の重要な開発優先事項を明確にする実用的な洞察。InfoQ Dev Summit Boston は、InfoQ が主催する 2 日間のカンファレンスで、シニア ソフトウェア開発者が現在直面している最も重要な技術的決定に焦点を当てています。20 以上の技術講演を詳しく聞き、ジェネレーティブ AI、セキュリティ、最新の Web アプリケーションなどを扱うシニア ソフトウェア開発者から革新的な学びを得ましょう。今すぐ登録
InfoQ.com およびすべてのコンテンツの著作権は © 2006-2024 C4Media Inc. に帰属します。プライバシー通知、利用規約、Cookie ポリシー
元記事: https://www.infoq.com/articles/webassembly-component-model/