GALOIS: エッジデータ処理への新しいアプローチ

IoTデバイスが増えてきたから、大量のデータをいろんなソースから管理する必要が出てきたんだ。このデータはすぐに処理しなきゃいけないストリームの形で来ることが多くて、これが大きな課題になってる。一つの解決策が、エッジでのデータストリーム処理（DSPoE）システムを使うこと。これにより、データを中央サーバーに送る代わりに、生成された場所近くで処理できる。しかし、ハードウェアやプラットフォームの種類の違いで、これらのシステムは効果的に管理するのが難しいんだ。

#多様な環境の課題

最近の工場では、機械がすごい速度でデータを生成する。例えば、スタンピングプロセス中には、一つの生産ラインが毎秒6ギガビットのデータを生成することもある。この膨大なデータをすぐに理解するためには、いろんな組織で共有・分析することが重要だ。

でも、工場内の機械やネットワーク接続の多様性がデータ処理の課題を生んでいる。さらに、問題に迅速に対応し、異なる生産ラインのバリエーションに適応する必要もあって、複雑さが増す。Apache StormやTwitter Heronのような現在のシステムは大きなデータストリームに対応するように設計されているけど、一様なサーバーリソースで働くのが理想で、製造現場ではそうはいかない。

様々な機械からデータが中央サーバーに送られると、リアルタイムアプリケーションには許容できない遅延やスローダウンが起きることがある。これを解決するためには、データソースの近くで処理を行う、つまりエッジ処理をすることが必要だ。ただし、このアプローチにも、不安定なネットワーク接続や多様なハードウェア能力といった課題がある。

#GALOISの紹介

これらの課題に対処するために、新しいアーキテクチャ「GALOIS」を提案する。このシステムは、異なるハードウェア、プラットフォーム、プログラミング言語で働くように設計されている。P2Pネットワークと伝統的なマスター・ワーカーの方法を組み合わせて、システムコンポーネント間のコミュニケーションを改善している。

GALOISの特徴の一つは、WebAssembly（Wasm）を使っているところ。これは、特定の調整なしで異なる環境でコードを実行できる技術なんだ。Wasmを使うことで、GALOISのオペレーターは軽量になり、リソースを少なく必要としながらも効果的に機能する。

#エネルギー効率とパフォーマンス

テストの結果、Wasmで動くオペレーターは、Dockerで動くものに比べてエネルギーとCPUリソースをあまり消費しないことがわかった。こうした効率の違いから、GALOISはエッジでのストリーミングデータ処理に向いた選択肢になるんだ。

#効果的な処理のための重要な要件

GALOISが動的な環境でうまく機能するためには、いくつかの重要な要件を満たす必要があった：

1. プラットフォーム非依存の実行：オペレーターは、どんなハードウェアやソフトウェアでも制約なしに動作するべき。
2. 直接エッジ処理：データは近くのデバイス間で直接流れるべきで、応答時間を短縮する。
3. ネットワーク認識管理：システムはネットワークの状態を考慮して、データ処理の遅延を最小限に抑えるべき。
4. グローバルとローカルの最適化：パフォーマンスを向上させるために、グローバル戦略とローカル調整の両方を使うべき。
5. 空間的整理：オペレーターは物理的な位置に基づいてグループ化され、コミュニケーション時間を短縮する。
6. 分散調整：クエリプランの変更は独立して行われ、全体のプロセスを停止させる必要はない。
7. フォールトトレランス：システムは、いくつかのコンポーネントが失敗しても結果を出し続けるべき。

これらの要件がGALOISアーキテクチャの設計を導いた。

#アーキテクチャの概要

GALOISのアーキテクチャは、異なるレベル間の効率的なコミュニケーションを促進するように構成されている。いくつかのコンポーネントは異なるレイヤーに分類されている：

• クラスターレベル：ここでは、ノードがクラスタにグループ化されている。各ノードは同じクラスタ内の他のノードとデータを共有できる。
• リージョンマネージャー：これらは複数のクラスタを監督し、コミュニケーションを管理する。
• グローバルマネージャー：このコンポーネントは全体の最適化やスキーマ登録を担当している。

システムは、クラスタに問題が発生しても全体のプロセスが止まらないように設計されていて、他のコンポーネントが引き継いだり、自動的に再構成されたりすることができる。

#GALOISの実装

GALOISを実際に使うために、その能力を示すプロトタイプを作成した。主に、オペレーターを実行する際にWasmがDockerと比べてどう表現するかをテストすることにフォーカスした。

2つのRaspberry Piデバイスをエッジノードとして使い、処理環境をシミュレートした。別のコンピュータはデータストリームのプロデューサーとして機能し、データがシステムを流れる様子をテストした。電力計を使って、これらのテスト中のエネルギー消費を測定した。

目標は、Wasmが処理速度、エネルギー使用、全体的な効率の面でDockerよりも優れたパフォーマンスを提供できるかどうかを確認することだった。

#テスト結果

テスト中にいくつかの重要な結果が観察された：

• 処理時間：Wasmオペレーターは、Dockerのものに比べて常に処理時間が短かった。
• エネルギー消費：Wasmが使ったエネルギーは、特にデータ入力率が増加するにつれて、Dockerよりもかなり少なかった。
• CPU負荷：WasmのCPU負荷は低く、可用性のある処理能力をより良く活用していることを示していた。

これらの結果は、Wasmオペレーターがデータストリーム処理に適していることを示唆している、特に効率が重要なエッジ環境ではね。

#他のシステムとの比較

GALOISは、NebulaStreamやMobiStreamのような既存のDSPoEシステムからの教訓を基にしている。多くのこれらのシステムは中央制御コンポーネントに依存しているけど、GALOISは分散型の方法と中央管理を組み合わせて、柔軟性とスケーラビリティを提供している。

既存のほとんどのシステムはJava仮想マシンに依存していて、柔軟性を制限することがある。GALOISはWasmを使っていて、さまざまなプログラミング言語や環境をサポートできる代替手段を提供していて、異なるシナリオに適応しやすくなってる。

#今後の方向性

今のところ、GALOISにはまだ多くの作業が残っている。将来の改善には、Wasmで利用できるオペレーターのライブラリを拡充したり、より動的なクエリ管理のために品質監視を統合したり、すべてのレベルのアーキテクチャを包含するもっと完全なプロトタイプを開発したりすることが含まれる。

Wasmの複雑なデータ型の取り扱いや追加のコードが必要な制限を克服することで、GALOISはデータストリームを効率的に処理するための強力なフレームワークを提供できる。

#結論

GALOISは、IoTデバイスからの大量のデータをリアルタイムで管理・処理するための重要なステップを示す。ハイブリッドアーキテクチャを活用し、WebAssemblyの強みを利用することで、エッジ処理における大きな課題に取り組みつつ、異なるプラットフォームや言語における柔軟性を確保している。

システムが進化する中で、GALOISは動的環境におけるデータストリーム処理のアプローチに新たなスタンダードを生み出し、よりスマートで効率的な製造や生産の実践に道を開く可能性がある。