株式会社ブロードは企業のIT運用の効率化とセキュリティ向上を支援しています。

何点かの需要なポイント

• エッジは場所ではありません。というよりはストリーミングデータを計算する新しい手法といって良いでしょう。
• ストリーミングデータをリアルタイムで分析するために「REST+データベースの習慣」から離れる必要があります。
• クラウドコンピューティングはステートレスなマイクロサービスおよびステートフルなデータベース上に構築されていますが、方やエッジコンピューティングはステートフルな「モノ」、切れ目のないデータストリーム、そしてダイナミックなコンテキストを必要とします。
• SWIM.OSはリアルタイムストリーミングデータを処理するアプリケーションの為のステートフルでリアルタイムのプラットフォームの例と考えてください。

エンタープライズ用の環境をアーキテクトするメンバは、迅速にアプリケーションを構築する目的でパブリッククラウドサービスを利用することに慣れています。[REST API＋ステートレスマイクロサービス＋データベース]というモデルが今まではクラウドネイティブなアプリケーション用に活用されているパターンですが、これはクラウドのスケーリング（どのようなサーバでも可）には重要な要素でした。代わりにKubernetesなどのアブストラクションの使用はマイクロサービスの運用の展開や管理を簡素化します。しかし、アプリケーションのクラスには現在のクラウドネイティブスタックがうまく適さないものもあります。

クラウドで実行させるための高額な(しかも書き直すには長い時間がかかるもの)「リフト&シフト」のレガシーアプリケーションを引き合いに出しているのではありません。私が焦点をあてているのはストリーミングデータを分析し、リアルタイムでインサイトを提供し、ビジネスを駆動する支援をするために（生産、製造、サプライチェーンパートナ、社員に対して）ますます重要になっている企業顧客のアプリケーションクラスなのです。

このようなアプリケーションは最近では「エッジコンピューティング」カテゴリに含まれることが増えてきています。この記事で私は、このようなタイプのアプリケーションに必要な要件を解剖し（願わくは）、読者にストリーミングデータアプリケーションに対しては少なくとも「Edge－エッジ」は物理的な場所ではなく、ストリーミングデータを計算する新しい手法であることを理解していただければ幸いです。

次世代製品には進化したコンピューティング機能が内蔵され、利用されている多数の例があります。これらは「エッジ」にあり、例えば車からコンプレッサーなど、多数のデバイスに内蔵されています。開発者は最適なCPU、MLアクセラレータ、ハイパバイザ、Linuxなどの技術を利用し、垂直統合ソリューションを構築します。さらに良い車、コンプレッサー、ドローンなどを提供できるように。これは「エッジコンピューティング」でしょうか？ そうですね、でも一般の意味でなく―これらは緊密に統合されたソリューションであり、広範囲なアプリケーションセットに流用できるコンピュータシステムではありません、興味深いソリューションですが適用範囲は狭いのです。でもこれら、またはその他の連結されている製品が生み出すデータはどうでしょう？「スマート」デバイス（豊富なCPUを備えた）は一時間あたり２Mのレートで繋がり、すでにわれわれの手の中には何億というモバイルデバイスが存在しています。ネットワークはストリーミングデータで溢れかえっています。このようなストリーミングデータから得た情報を利用するアプリケーションはますます増加しています。このようなアプリケーションを開発するツールを提供する必要があるのです。

「エッジコンピューティング」という言葉はクラウドコンピューティングとは違う機能を示すようなニュアンスを持ちます。アプリケーションのオンプレ部品であり重要な要素、例えば、データ量の削減、遅延またはセキュリティ／コンプライアンスへの憂慮に対する要件は良くあげられますが、それ以外にエッジコンピューティングに独特な要件はあるでしょうか？ あります。「ストリーミングデータのリアルタイム分析で、これにはREST＋データベース習慣から離れる必要あり」ということです。しかし物理的なエッジとして独自の要件はありません。これは喜ばしいことです、つまり、「エッジアプリケーション」はクラウドインフラまたはオンプレで実行できることを意味します。「エッジコンピューティング」は絶対的に「モノ」ですが、それはエッジからのストリーミングデータを処理することを指し、アプリケーションを物理的なエッジ対象先で実行することではありません。

現実の世界のモノからストリーミングデータを処理するエッジアプリケーションは以下の要件を満たす必要があります。

• 切れ目なくステートフルに新しいデータを分析する： ステートレスマイクロサービスはデータベース更新あるいはデータベースからのデータ流用しか出来ません。これはパフォーマンスがデータベースのレスポンスタイムに左右されるということを意味します。コンテキスト結果を計算するために多くのデータベースへのアクセスを必要とし、結果パフォーマンスはリアルタイムで無くなります。ステートフルプロセスが鍵になります。
• 常に解答を提示： 「保存してから解析する」アプローチはデータベースへの行き来をしない「解析し、対応し、そして（多分）保存」にとって変わります。生データを事後の解析のために保存するのは時間がかかり、バッチ指向で、対外の場合ほとんどの生データは短期的に有用なだけです。
• 全てのデータの処理： 部分的なサンプリングでは不十分です。ソフトウェアのスタックは全てのイベントをオンザフライで処理し、リアルタイムのインサイトを共有する必要があります。
• コンテキストとして解析し可視化する： イベントはその発生したコンテキスト（状況）内でしか価値がありません。重要なのはイベントの元となるもの同士の深いレベルまでの相互関係です。

ストリーム処理ソフトウェアに関するこれらの要件はそのソリューションが「どこ」で実行されるかは関係ありません。もしデータ源が固定であれば計算機を近くに設置するのは意味があるかもしれません―特にデータ削減に対応するには。しかしモバイルデバイスからのデータを処理するソリューションではクラウドホストスタックが必要になります。ではその違いは？ クラウドコンピューティングは強力な三銃士、ステートレスAPI、マイクロサービス、およびステートフルデータベース、で構成されていますが、ストリーミングアプリケーションは異なるインフラ概念が必要です。

• 「モノ」はステートフル： Webのステートレスモデルは、どのようなサーバ（サーバレスなAWS LambdaやAzure Functionsも含む）でもイベントを処理することを可能にするので一般的なクラウドサービスに対しては適用できます。しかしこれはストリーミングデータを処理するには難点があります。各々の新しいイベントに対し、アプリケーションは（およびコードは）事前の状態をデータベースからロードし、新しい値を計算し、新しい状況をデータベースに戻す必要があります。パフォーマンスはデータベースへの行き来の時間に束縛され、結果的にCPUより何百万倍も遅くなるのです。コンピューティングアーキテクチャは現実世界の状況変更に対応する必要があります―「モノ」は頻繁に状態を変更しその一つの変更がその他に伝播するのです。
• アルゴリズムは切れ目のないデータに適用される必要あり： 解析、学習、予測を計算するアルゴリズムは切れ目のないデータに対応するように適用されなくてはなりません。－全ての新しいイベントを計算するということです。
• コンテキストは最重要です： イベントは独立していては意味を成しません。現実世界のモノ間の関係、例えば、隔離、距離感、順応性などはそのコンテキスト（状況）内で起こったイベントにアプリケーションが説明理由を付けるための鍵になります。つまりエッジコンピューティングは「データグラフ（動的に変化する）内」であることが必須で「（すでに前もって作成された）グラフ上」であってはなりません。

大切なのは、現実世界の「モノ」はその状態を同時進行でまた独立して変化させていて、その変化はコンテキスト（状況）―その存在する環境の状況（その他のモノ）に基づいて―特有ということを認識することです。

つまりアプリケーションにとって重要なのは生データではなく、モノの状態の変化なのです。さらにデータベースは固定された関係性（バスにはエンジンがある、など）を捉えるのは得意ですが、動的に計算された関連（ブレーキの動きが怪しいトラックが警官の近くにいる、など）を捉えるのは不得手です。現実の世界でのデータの元同士の関係は流動的で、計算された関連性、例えば怪しいブレーキの踏み込み、などによってアプリケーションはその応答を変えるべきです。最後に、変化の影響は即座で、ローカルであり、コンテキスト反映です。（警官はその怪しいトラックを停止するように通知を受けた）。性質上動的な関係はグラフデータベースのイメージに近いのです、まさに関連する「モノ」のグラフが必要なのです。しかしこのケースではそのような切れ目ない処理を可能にするにはグラフ自体が流動的で、計算自体が「グラフ内」で起こる必要があることを意味します。

ここまでのまとめ： エッジコンピューティングはどのような規模であってもステートフルな処理が必要で一般的なステートレスのマイクロサービスモデルと違うということです。
しかし、エンジニアの頭を悩ませたり、新しいことをおぼえさせるよりは、適応することが容易なアプローチを（慣れている開発やDevOps形式のメタフォーを使った）提供し、企業のエンジニアが迅速にスケーラブルなリアルタイムインサイトを提供するアプリケーションを展開できるようにすべきです。

以下からは、非常にパワフルな「ストリーミングネイティブ」アプリケーションプラットフォームSwimOSについて説明します。

これはApache 2 ライセンスのプラットフォームであり、リアルタイムで、リンクされたアクター（関係要素）間のグラフをビルドし、ステートフルにストリーミングデータ源を分析するアクターモデルです。開発者は単純にJavaやJavaScriptでオブジェクト指向のアプリケーションを組むだけです。ストリーミングデータがステートフルな、同時進行のオブジェクト（Webエージェントと言います）であるアクター、実際はデータ源の「デジタルツイン」のスケール拡大したグラフを自動的に作成します。

各々のWebエージェントは単一の元からの生データをアクティブに処理し、その状態をメモリに置きます。（またはその状態をバックグラウンドに常駐させフェールオーバする）従って、Webエージェントとはその（各呼応する）モノを反映し、その時の現実世界の状態を常にミラーリングしているリアルのデータ源のステートフルで、同時進行のデジタルツインとなります。この図はあるスマートシティ環境内のセンサーのデジタルツインとしてWebエージェントが作成されるケースを示しています。

Webエージェントはデータ内の変化に基づき計算されたコンテキストをベースにリンクされ、動的にグラフを作成します。このグラフは距離感、包含、または相関性のような現実世界の中の関係を反映しています。リンクされたエージェントはその他のエージェントとの変化状態をリアルタイムで理解します。エージェントは自身またはその他のリンクされたエージェントの状態を同時進行で計算できます。エージェントは分析し、学習し、予測し、そして継続して豊富なインサイトをUIやブローカ、データレイク、エンタープライズアプリケーションにストリームします。

SwimOSはメモリ内で実装され、ステートフルで、同時進行のコンピューティング技術によりデータベース指向の分析に比べて何十倍もパフォーマンスが優れています。なぜなら全てのステート（状態）はメモリ内に存在し、Webエージェントはデータが到着し、繋がっている別のWebエージェントのコンテキストに変更があったその瞬間に計算を実行できるからです。

SwimOS内には、主要な分析、学習および予測アルゴリズムは含まれていますが、Apache Sparkなどの既存のプラットフォームとのインターフェースを取るのも容易です。

SwimOSは分析、学習および予測をWebエージェントの動的に構築されたグラフ内に移動させます。従ってアプリケーションはデータから動的に構築されたグラフになります。これによりアプリケーションの作成が非常に簡素化します。

開発者はオブジェクトとそのインプット、そしてそれらがどうリンクされるかの計算式を定義するだけです。データが到着するとSwimOSは各々のデータ源に対しWebエージェントを作成し（各々は独立していて）データがその上を流れるのと同時に計算を実行し、同時にインサイトをストリームとして返します―例えば予測や分析のインサイトなど。

各エージェントはその現実の双子兄弟からの生データを使う役目を持ち、計算定義に基づきその他のエージェントと動的にリンクします。データはグラフ上を流れ、各Webエージェントは自身の状態およびリンクしているその他のエージェントの状態を利用してインサイトを計算します。

例えば米国カルフォルニア州Palo Alto市の交通インフラ環境で一日に４TBのデータを対象に処理するアプリケーションでSwimOSが活用されている事例をご覧になれます。これは各交差点の今後の状態を予測する（ブルー点をクリックすると待ち時間の予測をみたり、信号のダウンタイムをみたり）ことに利用されています。このアプリケーションは米国のその他の多くの市でも採用されています。車両のルート設定を効率化する必要があるような顧客にAzureホストされたAPI経由で提供されていて、必要な予測情報を提示します。このアプリケーションのソースコードはSwimOS GitHub repoの一部分です。SwimOSを開始するのは簡単です。オープンソース参照サイトには文書や教本ガイドが一緒に提供されています。

SwimOS内ではグラフは生き物で動的に変化する構成をとります。前に述べた（怪しいブレーキングをするトラックが警官の近くにいる）例で言うと、相互関係は動的に計算され短命です。警官とトラックのリンクも従ってその瞬時です、トラックが警官に近づいた（位置的に対象内に入った）際にリンクが構成され、離れるとリンクは外れます。

SwimOS内のアプリケーションはグラフ上をデータが流れるに沿って切れ目なく、同時進行で計算するWebエージェントのリンクから成るダイナミックなグラフです。各Webエージェントが自身の状態を変更するとその状態は即座にグラフ内でその他のリンクされたWebエージェントに可視化されます。これはストリーミングによって達成されます―リンクとはストリーミングAPIの効力があり、URIの型式をとります、REST APIコールに似ているといってもいでしょう。SwimOSはWARPプロトコルを利用します、これはWebソケット上で実行され、状態の同期を取り、ストリームのインサイトを配布します。主要な違いは、各Webエージェントは自身の生データを状態の変更に変換し、そのような状態変更はグラフ内のWebエージェントにストリームされます。そしてそれらは自身の状態に基づいて自身とその他のリンクされた状態を計算します。

SwimOSアプリケーションは各データ源に対して与えられたシンプルなオブジェクト定義があると、そのデータからビルドされます。アプリケーションは簡単にビルドできます。しかしこのアプローチ利用は別の利点もあります。例えばそのアプリケーションがその他の複数のサイトで再利用されても変更は全く必要無いのです。前例で参照した、スマートシティアプリケーションを挙げると、その市の今後の交通の状況を予測するためにデータはアプリケーションをビルドすることに使用されます。しかしここで、別の市ごとに特定のモデルが必要でないことに注目してください。対象交差点のデジタルツインによる各交差点用のローカルのコンテキストのみが使用され、学習し予測します。従って各市のアプリケーションはその都度生成されるデータからビルドされ、コードへの変更は必要ありません。

トランスフォーメーションという言葉： 今までの分析スタックでは―例えばApache Sparkなどを利用―データはアプリケーションに移動され、アプリケーションは各「モノ」に対してデータをステート（状態）に転換し、データベースに保存するといった順番で、現実のデータ源の状態に対する分析をアプリケーションが実行できるに至るまでにはこのような工程が必要でした。SwimOSは各Webエージェント内の関連するデータ源のステート（状態）に生データを転換します。データから状態への変換は各デジタルツインによって行われ、Webエージェントのグラフは現実世界のデータ源の状態の鏡となります。ですから各デジタルツインは自身の状態と、リンクしているその他のWebエージェントの状態を利用して高解析度のローカルでの計算が可能になります。この計算はCPUとメモリスピードで同時進行に進みます、データベースへのアクセスは必要ありません。パフォーマンスの向上は飛躍的に上がり、必要とされるインフラがどれほど削減可能かはそれに相応します。今までの事例ではデータベース指向の展開に比べ同じアプリケーションが利用するインフラはSwimOSアプリケーションでは5％以下となっています。

SwimOSのデジタルツインはエッジの「モノ」－現実世界のモノのリアルタイムのストリーミングの鏡です。デジタルツインはその瞬時に計算を実行しインサイトをストリームします。仮想化はそのようなアプリケーションにはとても重要です。SwimOSは開発者がブラウザベースでリアルタイムに更新可能なUIを迅速に開発可能にするためにJSおよびTypeScriptのバインディングのセットを含みます。これが可能なのはSwimOSはWebエージェントによって計算されストリームされたインサイトにサブスクライブするからです。

最後になりますが、エッジコンピューティングはもちろん「モノ」ですが、計算の実行自体がエッジで行われる必要はありません。代わりに何が必要かというと、エッジコンピューティング環境の多数の動的に変更するデバイスからのストリーミングデータ上に対して（どこでも）計算が実行できる能力です。このことはステートフルな分散環境に対応するアーキテクチャパターンを要するということです。SwinOSはリアルタイムストリーミングデータを処理するステートフルで、リアルタイムのプラットフォームです。

作者について

Simon CrosbyはSWIM.AIのCTOです。SWIM.AIの前職はセキュリティテクノロジのBromium社の創立者およびCTO職についていました。Bromium社では高度のセキュリティ仮想化技術をもってアプリケーションの保護を提供しました。Bromimu社の前職ではXenSource社の創立者でありCTO職についていました。その後XenSrouceはCitrix社に買収され、Citrixで仮想化および管理部に籍を置きCTOとして従事しました。英国Cambridge大学の名誉メンバとして研究職に貢献。またInfoWorld誌ではTop25 CTOとしてリストされました。