エッジコンピューティングの整理
エッジコンピューティング関連の話をしていると、エッジコンピューティングに様々な形態があるせいで、話の食い違いなどがよく起きると感じることがあります。
今回は、その部分について、説明したいと思います。
エッジコンピューティングの整理の必要性
エッジコンピューティングのシステムは、システム内は多様なコンポーネントで構成される場合が多くあり、その形態も様々です。しかし、それらを一括して「エッジコンピューティング (もしくはIoT)」と纏められてしまうことが多く、その結果、よく問題が起きます。
2019年のOpen Infrastructure SummitというOpenStack関連の最大イベントで、エッジにアプリケーションの開発・実行環境を整えるインフラ基盤StarlingXが紹介され、多くの注目を浴びました。ただ、その際、「エッジとはなにか」について、コントリビュータ自身も合意・統制を取るのに苦労していた、という話が取り上げられていました。
エッジコンピューティングには様々な形態があります。会社で「エッジコンピューティングに力を入れます！」といっても、従業員の数だけ想像するビジョンが異なり、すぐに破綻するでしょう。
対象とする内容によって、開発内容、ハードウェア、開発スキル、保守性、コスト、等々、全く異なります。そのため、エッジコンピューティングと一言に言っても、エンジニア一人ひとり、捉える内容が異なります。
エッジコンピューティング、と言った時に、システムにどんな形態があるか整理した上で、どこにフォーカスしているのかを決定し、プロジェクトメンバーと共有・合意する必要があるでしょう。
整理の仕方
よくある形態の整理の仕方は、システムをコンポーネントに分割し、各コンポーネントが、（物理的に）どの場所に置かれるか、という整理です。これは、技術的な側面であり、システム構成図で説明されます。この整理によって、ハードやネットワーク、アプリケーションの内容、制約など、技術的な側面を語ることができます。
ただし、本記事で強調したいのは、運用面についても整理する必要がある、という点です。具体的には、各コンポーネントの管理主体（組織）や、そのシステムを使うユーザはどの組織なのか、という点です。
例えば、単一の組織でシステム全体を作り上げるのか、デバイスの部分だけ別組織が作り上げるのか。ユーザは、システムを作った組織内の人間なのか、別組織の顧客なのか。また、クラウド側およびクラウド-エッジ間の連携だけを、単一の組織が作って、SaaSのように他のユーザ企業にサービス展開したい、というビジネス形態なのか。
こういった運用面によって検討事項が大きく変わってきます。システム開発を受注した場合、顧客とこの部分をしっかり議論し、互いにベストな境界線を定義するべきでしょう。
技術的側面による整理
技術的側面からのエッジコンピューティングの構成図は、よく目にすると思います。
概ね、このような図かと思います。
大きな箱として、クラウドとCDNと現場、があります。現場の部分がブラックボックスになっているケースもありますが、この内部こそ必要なスキルや制約などが非常に多様なので、一応サブコンポーネントも書いています。
クラウド
普通は、クラウドが存在します。パブリッククラウドかプライベートクラウドかは問いませんが、エッジデバイスが存在する物理的な空間とは別のデータセンタ（or サーバ群）です。
このクラウドの部分がないものは、普通は考えられません。あるとしたら、デバイスやシステムがP2P的に繋がり完結するケースか、CDN（MEC）は使うがクラウドがない、という状況ですが、どちらも極めてまれです。家の家電をスマートリモコンで操作できるようにした、というケースで、IoT化した、といった表現は使われはしますが、システムと呼べるほどのものではないでしょう（単に現場側でデバイスを買って取り付けた、という程度の話です）。
クラウドは、多数のユーザや多数の現場（デバイス）の統合ポイントです。そのため、デバイスの情報を見たり操作したいユーザからのリクエストを最初に受け付けるのは、通常、このクラウドです。また、デバイスのデータは基本的には、クラウドに集約されます。ただし、秘匿性の高いデータや、あまりに巨大なデータなどは、意図的にデバイス側に留めて使われる、という場合もあります。
また、運用の観点でも、エッジデバイスに関する稼動データなどはクラウドに集約されます。
CDN (MEC)
ネットワーク的に、クラウドと現場の間に位置する、データ保管環境および計算環境です。このコンポーネントはオプションであり、多くの場合は存在せず、現場から直接クラウドにパケットが送信されます。
従来、CDNはクラウドにあるデータのキャッシュサーバと認識されていましたが、最近のCDN事業者の多くは、処理をデプロイして実行できる機能を提供しています。特に、WebAssembly (WASM)のコードを実行できる環境（と言いますかインターフェース: WASI）を用意しているものをよく見かけます。
5Gの分野では、MEC (Multi-access edge computing)という名前で、3GPPやETSIなどの5Gの標準規格の中でも明確に処理環境が定義されています。具体的な場所は、5Gのアクセスポイントや、キャリア網内のどこかなど、バリエーションはいくつかあります。
ここを処理系として利用することが期待されていますが、今時点、そこまで多く利用されてはいないと思います。考えられる理由は、開発の複雑度が増すためエンジニアが採用したがらないことと、これを利用しないと成り立たないユースケースが少ない、という点です。
システムのドメインロジックが地理的に分散するのは開発として難易度が高くなるため（私は前職でこれを何とかする研究をしてましたが）、比較的インフラレベルに近い部分の処理だけ切り出して、CDN (MEC)を利用することなら考えられるかもしれません。
クラウドで処理をするより処理遅延が抑えられるというメリットはありますが、先進国であれば、パブリッククラウドのリージョンは比較的近くにあるので、遅延の減少という文脈では効果は多少、といったところかなと想像しています。従来のCDNのように、全世界から一斉に処理リクエストが来るが、処理ロジックをクラウドベンダの世界中のリージョンにデプロイするのが面倒なので、CDNにおまかせしたい、というユースケースならありかなと思います。
現場
ここが、さらに多様なコンポーネントを含んでいます。また、それぞれのコンポーネントは、全てオプションです（全てない、ということはありえません）。
エッジゲートウェイ
エッジゲートウェイは、現場側のエッジデバイスのデータの集約点です。IoTゲートウェイと呼ばれることもあります。多くの場合、普通のPC並か、それ以上の処理能力を持ち、Linuxなどの汎用OSが稼動しています。Raspberry Piをエッジゲートウェイとして用いることも、よくあると思います。
アプリケーションの修正のために、わざわざエッジゲートウェイがある場所までエンジニアが毎回足を運ぶのはかなり面倒です。そのため、実運用は、クラウドからエッジゲートウェイへ、リモートでアプリケーションをデプロイできるようにするのが一般的です。AWSであれば、Greengrassというサービスで実現できます。Kubernetesでは、KubeEdgeなどがあります。
これで、エッジゲートウェイ内のアプリケーションを更新したい場合に、いちいち現場に足を運ぶ必要がなくなります。特に、現場環境が複数ある場合は、現実的にほぼ必須です。
クラウド側の開発者が、「エッジコンピューティング」と言う時、エッジ側の環境は大抵、エッジゲートウェイを指していることが多い印象です。
エッジゲートウェイは、単一でなければならないことはありません。現場の複数のデバイスが、クラウドやCDNとデータの送受信を行いエッジゲートウェイとして振る舞うこともありえます。ただ、単一の組織が開発しているのに、複数のエッジゲートウェイを用意するのは、不必要に管理コストが増大します。例えば、クラウド側で複数のエッジゲートウェイを管理する必要があり、現場側でも各エッジゲートウェイごとに証明書の設置などの環境構築や管理が必要となってきます。
センサー
センシングを行う素子です。Raspberry PiのGPIOなどに接続し、センシングしたデータを有線でエッジゲートウェイに送信したり、Bluetoothなどがついたセンサーであれば無線でエッジゲートウェイにデータを送信します。
組み込み機器
コストが小さく、消費電力も少ない機器です。
組み込み機器へのアプリケーションのデプロイは、専用のソフトで行うことが多く、クラウドからアプリケーションをデプロイするというのは、あまり聞きません。そのため、基本的には書き換えがなく、一度現場に配置したら変更なくずっと使われることが多い気がします。
大抵の場合は、組み込み機器にはPINでセンサーやアクチュエータがつながります。
汎用計算機
WindowsやLinuxなどの汎用計算機です。直接クラウドやCDNにアクセスする処理能力はあっても、あえて直接アクセスせず、エッジゲートウェイにデータを集約することは管理コストを抑える意味でもありうる構成だとは思います。
運用的な側面による整理
前述の技術面での整理を踏まえ、運用面の整理をしていきましょう。
システム全体を同一の組織が開発する場合
このケースは、IoTと言った時に最も想像しやすいユースケースで起き得る形式です。
このケースでは、ユーザはシステム内のコンポーネントに一切修正を加えません。もしユーザがデバイスの改造や設定変更を行った場合は、サポート外となります。また、開発側も、何からの都合でユーザが誤ってデバイスの設定などを変えないように工夫する必要があります。
この形式のユースケースは、非IT従事者のユーザに向けた事業か、開発組織内で使われる組織内システム、であることが考えられます。
例えば、前者は、農園の環境情報を農家の方がモニタリングするシステムや、ペットのトイレや首輪型デバイスで収集した情報からペットの状態を飼い主が把握するシステムなどがあります。後者も似たようなもので、従業員の名札型デバイスやスマホで普段誰がよく議論しているかをモニタしたり、トイレの空き状況が分かるシステムなどです。
重要な点は、単一の開発組織が全てのコンポーネントを面倒見るので、不確定要素や変動要素が少なく、運用しやすい点です。ただし、適用できるユースケースは、クラウドから現場までのトータルなIoTソリューションなので、ビジネスがスケールしにくい可能性はあります。一発の大口受注の大型システムを狙うか、現場側のデバイスやネットワークなどを固定してパッケージ化し、多数の顧客へ極力安価にソリューション展開する流れかと思います。
クラウド側とデバイス側で開発組織が異なる場合
ここからは、BtoBtoC側のビジネスになります。
また、この構成が最も難しいかと思います。
例えば、ロボット制御や、自動運転など、現場側のリソースが限られているため、エッジゲートウェイに、クラウドとの連携用の処理と、現場環境の制御の処理が同梱するケースがあります。クラウド側のデータ収集・処理と、現場環境の制御は、専門分野が大きく異るため、異なる組織で分業されます。
その場合、クラウド側の開発組織は、エッジゲートウェイの構成を固定することはできません。たとえ、OSレベル程度までは、ある程度は固定できるものの、ディレクトリ構成やカーネルパラメータ、リソース使用量、場合によってはハードウェアも、固定できない場合があります。
そのため、予期せぬ構成によるトラブルを回避するよう、クラウド側は最新の注意を払う必要があります。ですが、予期せぬことを予期しきるのは不可能です。
実際私自身も、エッジゲートウェイ相当のデバイスが、現場で時刻がズレており、それによりクラウド側の処理のためにエッジゲートウェイにデプロイされているエージェントソフトウェアが、信じられない量のログを吐き出し、危うくクラウドのロギングシステムを溢れさせて、システム全体のモニタリングが止まりかねない事態がありました。
クラウド側の開発者は、ネットワークの不調や時刻ズレ、想定外なディレクトリ構成、パーミッションエラー、リソース不足、等々、様々な検証が困難な事態を継続的に検証する必要があります。
できれば避けたほうが良い形式ではありますが、シナリオ上の制約で、どうしてもこの形式になる場合はあり得るので、その際はあらかじめ、アーキテクトはリスクを理解しておくべきでしょう。
クラウド側と現場側で開発組織が異なる場合
最後は、開発組織が複数あるものの、現場環境とクラウドとで、組織がきっぱり分かれる形式です。
この場合、クラウド側の組織は、エンドユーザに対するIoTソリューションのトータルコーディネータ（SIer）、というわけではなく、むしろ現場側の開発組織がその役目を担い、クラウド側はSaaSやPaaSのような位置づけなのではないかと思います。
クラウド側は、マルチテナントでシステムが運用され、多数の現場側の組織に対して、一貫したサービスを提供する形が想像されます。ある部分では、ユーザ組織個別にリソースを分離するかもしれませんが、少なからずどこかではリソースや処理が、ユーザ組織間で共有されることが多いでしょう。その方が明らかに効率的で、横展開しやすいためです。
この場合は、クラウド側で何らかの問題が生じると、全顧客に迷惑がかかる場合がありえます。しかし、クラウドとはそういうものです。集約による効率化があるからこそ、開発コストやクラウド料金を抑えられ、ユーザへの課金金額も抑えられるので、トレードオフとなります。
おわりに
エッジコンピューティングの整理の仕方は、まだあると思いますが、一旦、開発組織の構成によって、プロジェクト内容が大きく異ることは意識できれば良いかと感じています。
組織の狙いによって、取りうるIoT/エッジシステムの構成は変わります。
単一の組織でシステム全体を作り上げるのか、デバイスの部分だけ別組織が作り上げるのか。また、クラウド側およびクラウド-エッジ間の連携だけを単一の組織が作って、SaaSのように他のユーザ企業にサービス展開したい、というビジネス形態なのか。
アーキテクトは、当然ではありますが、自社がSIerなのかクラウド側のSaaSを作りたい会社なのか明確にして、ユーザも定義する必要があります。そしてその場合の開発内容を理解した上で、それが自社の強み（実績や人材が十分か）と照らして、リスクを含めて考える必要があります。
Discussion