エッジプラットフォーム「Volterra」のユースケース（1）モニタリング

前回は、エッジコンピューティングにおける管理機能を提供するエッジプラットフォームサービス「Volterra」の機能を紹介しました。今回からは、2回にわたってVolterraの具体的なユースケースを紹介します。

今回紹介するユースケースは、複数の小売店舗を運営する企業を例として、「各店舗で生み出されるデータを収集・分析することで、店舗運営の改善につなげる」というモニタリングのシナリオです。

全体構成イメージと利用するアプリケーション

最初に、システムの全体構造を説明します。構造はシンプルで、各店舗にエッジデバイスを設置し、各デバイスで収集した店舗データを、データセンター側で一元的に蓄積して分析可能にするものです。

構造はシンプルな一方で、実現には様々な技術要素が必要です。ここで改めて、前回紹介したVolterraの機能・構成要素を振り返ります。

• （1）エッジデバイス上のアプリケーション実行環境を提供する「VoltStack」
• （2）VoltStack間の接続やセキュリティ等のネットワークサービスを提供する「VoltMesh」
• （3）VoltStackとVoltMeshを統合管理する「VoltConsole」

また、今回のシナリオで利用するアプリケーションとして、Elasticが提供しているオープンソースのプロダクト群「Elastic Stack」を利用します。これは、全文検索エンジンである「Elasticsearch」 、データの取り込み・加工処理・転送を行う「Logstash」 、Elasticsearchに貯めたデータを可視化するGUIツール「Kibana」 、データ取り込みに特化した非常に軽いエージェント「Beats」 （今回はファミリー製品のFilebeatを用います）から構成されています。

システムを構成

では、「Volterra」と「Elastic Stack」を用いて、上記のシステム構成を実現していきます。

まず、「VoltStack」で、各店舗のエッジデバイスおよびデータセンターにCustomer Edge(CE)を配置し、各CEに対してアプリケーションをコンテナイメージで配信します。具体的には、各店舗のCEには、店舗内のIoTデバイスから生成されるデータを収集してデータセンターに送信するFilebeatを配信し、データセンター側のCEには、送信されてきたデータをElasticsearchに転送して格納するLogstashを配信します。

そして、「VoltMesh」で、各店舗のCEに配信したFilebeatと、データセンター側のCEに配信したLogstashをセキュアに接続します。これらによって、データの収集と可視化を実現できます。

• 図1：「各店舗で生み出されるデータを収集・分析」を実現するシステム構成

これらの「VoltStack」と「VoltMesh」の設定は、「VoltConsole」で一元的に管理することで、日本全国または世界各国などに分散して運営されている小売店舗のエッジコンピューティング環境を、運用負荷を抑えつつ運用できます。

店舗からデータセンターのLogstashにアクセスするために必要な通信は、「VoltMesh」のTCPロードバランサーにより実現されます。まず、データセンターのCE上で実行されるLogstashに対するTCPロードバランサーインスタンスを構成し、続いて店舗用のCEにロードバランサーをアドバタイズすることで、すべての店舗からデータセンターのLogstashにアクセス可能になります。

Volterraによるサイトの管理

Volterraで管理されるすべてのCEは「Site」として管理されます。各Siteには任意のキーと値で構成されるラベルを付与し、このラベルを利用することでSiteを仮想的にグルーピングできます。

今回の例では、データセンターで機能するCEにsite-type: datacenter、店舗で機能するCEにsite-type: branchというラベルを付与し、データセンターと店舗用のCEを「Virtual Site」としてそれぞれグルーピングしています。Volterraはコンテナのデプロイ時にSiteをグルーピングしたVirtual Siteとして、ラベルによって仮想的にSiteをグルーピングすることができるため、Logstashはデータセンターだけに、また、Filebeatは店舗だけにデプロイすることが可能です。

• 図2：Volterraによるサイトの管理

店舗におけるデータの加工

さらに、各店舗内でデータを収集するIoTエッジデバイスの種類や取り扱うデータのフォーマットが変更になる場合でも、この構成であれば、Filebeatの設定を更新するのみで、必要に応じてデータを整形したり、不要なデータを排除したりするなど、速やかに新しい環境に対応可能です。

各店舗に配信されるFilebeatのコンテナイメージ(filebeat:1.0)は、店舗で収集したデータをそのままデータセンターのLogstashに転送します。この状態では、Elasticsearchに格納されるデータは、どの店舗から送信されてきたデータなのか識別することができません。

• 図3：どの店舗から送信されてきたデータなのかを識別することができない

そこで、Filebeatの設定を変更してコンテナイメージfilebeat:1.1を作成します。この新しいコンテナイメージはデータ送信時に自身がどのサイトで実行されているのかを認識し、データにサイト名を追加して転送します。この新しいコンテナイメージ(filebeat:1.1)を各店舗に配信することで、各店舗のメトリックの可視化が可能になります。VoltConsoleでは新しいコンテナイメージの配信が容易にできるようになっています。

• 図4：送信されてきたデータが、大阪店舗のものか沖縄店舗のものかを識別

店舗の追加

新たな店舗が追加される場合も、新店舗内でZTP（Zero-Touch Provisioning）を利用してVoltStackを構成し、Siteとして登録されたCEにsite-type: branchというラベルを追加すると、CEが自動的に店舗用のVirtual Siteに追加され、Filebeatコンテナが追加されたCE上で起動し、データセンターのLogstashに対してメトリックの転送を開始します。

• 図5：新規店舗として札幌店舗を追加。自動的に識別されている

店舗におけるデータのフィルタリング

今回のシナリオでは、各店舗でHumidity（湿度）、Flow（販売した飲み物の量）、Sound（音量）、Temperature（温度）の4種類のメトリックを収集しています。Soundデータが不要になった場合は、Filebeatの設定を変更することで、各店舗のFilebeatでSoundに関するメトリックを破棄することが可能です。

具体的には、Soundに関するメトリックを破棄する設定をしたコンテナイメージをfilebeat:1.2として作成し、Deploymentのコンテナイメージを更新すると、Soundに関するメトリックの送信が停止するため、Elasticsearch上のデータ数が減少し、Soundメトリックに関するグラフもプロットが停止します。

• 図6：Sound（左下のグラフ）のデータ収集を破棄する設定に更新することで、グラフのプロットが停止

以上、Volterraを利用することで、小売店舗のように各地に分散された計算資源であるエッジを一元的に管理し、アプリケーションの配信を効率化し、拠点間のネットワークをセキュアかつ柔軟に構成することが可能になります。