はじめに

　エッジコンピューティングの一丁目一番地と言えば、ラズパイやNVIDIA Jetsonみたいな エッジデバイスでKubernetesですよね(!?)。k3s、k0s、MicroK8sと軽量Kubernetesは、前々からKubernetes on エッジデバイスの代名詞ですし、KubeEdgeやEclipse FoundationのEdgeNative WGが推進するioFogなど、エッジコンピューティング向けのKubernetes関連のオープンソースプロジェクトも増えつつあります。そして、KubeCon + CloudNativeConでもKubernetes on Edge Dayなイベントをやったりと、コミュニティの盛り上がりも高まっています。
　そんな中、エンタープライズ向けのKubernetesディストリビューションを提供しているレッドハットが、軽量版OpenShiftとしてMicroShiftをオープンソースとして推進し始めたり、VMwareのVMware Edge Compute Stack 2.0のポートフォリオにもDevice Edgeがチラ見えしていたりと、イノベーター向けと思っていたDevice EdgeでのKubernetes活用がいよいよアーリーアダプタ向けに動きだした雰囲気を感じてなりません。
　そこで今回は、エッジコンピューティングの中でも特に「Device Edge」に着目し、Device EdgeでのKubernetesの利用動向と「Device EdgeでなぜKubernetesを使うのか」について、自身の経験も踏まえて整理してみたいと思います。

Device Edgeとは

　そもそもエッジコンピューティングというのは、「センサーなどのデータを生成する場所へコンピューティングを近づける概念」を指します。詳しくは、過去の記事でまとめてますので、詳細を知りたい方は以下を参照してください。

　その中で「Device Edge」とは、フィールドへ展開された様々なデバイス(エッジデバイス)によって提供されるITリソースを指します。エッジデバイスとDevice Edgeの違いを明確に語ってるサイト等をあまり見かけませんが、エッジデバイスはデバイス単体を表し、Device Edgeはリソースを表すイメージを持つと分かりやすいかもしれません。つまり、Device Edgeは、エッジデバイス単体でも良いし、複数でも良い、という考え方です。

Linux FoundationのLF Edgeのプロジェクトである Open Glossary of Edge Computing ¹では、Device Edgeを以下で定義しています。

Edge computing capabilities on the device or user side of the last mile network. Often depends on a gateway or similar device in the field to collect and process data from devices. May also use limited spare compute and data storage capability from user devices such as smartphones, laptops and sensors to process edge computing workloads. Distinct from infrastructure edge as it uses device resources.

ちなみに、Device Edge Cloudというものもあります。エッジデバイスでKubernetesを実行する場合は、Device Edge Cloudと言った方が正しいのかもしれませんが、本稿では、それも含めてDevice Edgeと呼びます。

An extension of the edge cloud concept where certain workloads can be operated on resources available at the device edge. Typically does not provide cloud-like elastically-allocated resources, but may be optimal for zero-latency workloads.

　以下に、エッジコンピューティングの全体像を示します。一番下に位置するDevice Edgeは、我々の職場や生活圏に溢れるデバイスが対象になります。従来の組み込み市場がモロ被りですが、組み込み市場にIoTやクラウドネイティブの波が押し寄せて、生活圏にあるシステムをスマートにする期待があります。同時に、従来の組み込み市場のプレイヤーは、モノ売りからコト売りへビジネスモデルを転換するチャンスを得ます。

エッジデバイスでKubernetesを利用している事例

　ここでは、公開されている事例をいくつかピックアップして整理していきます。

カメラでKubernetes

　ラズパイやNVIDIA Jetsonなどのカメラとの組み合わせは、あるあるなユースケースですよね。「お家監視カメラやってみた」とか、とっつきやすいです。ラズパイはエンタープライズの現場でもPoCでよく使われます。基本的に既存の機器とラズパイ等を連携できるようにして、既存の機器をスマート化するモジュールの様な使い方が主流かと思います。エッジコンピューティングを現場に展開される既存のシステムの延長と捉えて、既存の機器を取り替えたり、ソフトウェアを改修しようと思うとなかなかハードルが高いです。既存のシステムはそのままに、手頃なデバイスで試行錯誤するのが第一歩と思います。

　今年の4月に組み込みエッジコンピューティング展（春）という展示会があったのですが、そこではたくさんのエッジデバイスが展示されていて、非常に盛り上がりを感じました。産業向けのデバイスということで、ファンレス、防塵、耐水、低消費電力など、デバイスをフィールドに展開するときに気になる耐久性の高さや省電力を売りとしたハードウェアがたくさん展示されていた、と言うことに加えて、AIとの組み合わせの展示がとても多かったのが印象的でした。とにかく様々なニーズに応えるためにハードウェアのラインナップを豊富に揃えて、昨今のAIを付加価値的に組み込みで昨今のAIのニーズに応える、というのが組み込みの戦い方なんだなと思います。
　例えば、製品の傷の検知とか簡単なAIはラズパイを使ってさくっと試し、ムラとかもっと深い解析が必要な場合は、NVIDIAのJetsonを使ってみる、みたいな話をよく聞きます。そして、ラズパイのSDカードの故障率が高いことを嫌って、本番運用時は、ラズパイより高価な産業用PCなどの機器も候補に検討するケースが多いとのことです。安くて買いやすいラズパイだからこそ、予備をたくさん確保しておいて、壊れたらすぐ交換、という運用をしやすそうにも感じますが、壊れすぎてもコストがかさんでやってられない訳で、本格運用のフェーズでは、高価で丈夫な機器に向かうんだと思います。
ちなみに、展示されていたハードウェアは以下みたいなやつです。

　なお、組み込みエッジコンピューティング展から何か傾向が見えないかと独自に調べた感じだと、シングルボードコンピュータの製品とアセンブリ済みのボックス製品が半々くらいでした。NVIDIA GPUは意外と少なくて、ほとんどがIntel CPUを採用した製品で、次にARMの製品が多ったです。OSはWindowsとLinuxが多く、Linuxは基本的にUbuntuでした。

産業機器でKubernetes

　エッジデバイスやエッジサーバでOPC-UAクライアントを動かして、PLCからデータを取得する、というのはよくあるユースケースと思います。更に一歩進んで、現在は、PLCそのものをコンテナで動かすという動きがあります。元々ハードウェアシステムとして提供されていたPLCがソフトウェアPLCとしてWindowsアプリケーション等で利用出来るようになり、更に発展して、産業用PCでコンテナプラットフォームを構築し、コンテナPLCとAI等のITアプリケーションを同じプラットフォーム上で実行する検討がされています。通信業界におけるNFVみたいな流れです。
　例えば、Red HatとIntelは、Intel ECI（Edge Controls for Industrial）とOpenShiftでコラボレーションしています。²

　IntelはTCC（Time Coordinated Computing）やCAT（Cache Allocation Technology）といったリアルタイム処理とハードウェアアクセラレーションを担い、Red HatはOpenShiftを産業用PCへインストールしてコンテナプラットフォームを構築する役割を担っています。OpenShiftはリモートワーカーノードのトポロジで展開して、Masterノードはデータセンター内のサーバで、Workerノードは産業用PCで構成しています。そして、産業用PCのホストOSにRHEL for realtimeを入れて、OpenShiftのPerformance Addon OperatorでホストOSのKernelをチューニングして、コンテナPLCをリアルタイム実行できる様にセットアップしてます。

※評価結果のレポートがブログに公開されていますので、興味のある方はご参考まで。

　産業用PCがコンテナプラットフォームになると、工場毎にプライベートクラウドが構成されて、正に分散クラウドみたいな世界観に感じます。一昔前のプライベートクラウドは、パブリッククラウドでは満たしづらい、SLAやコスト、データセキュリティ、社内ネットワーク接続の要件をカバーするための存在だったと思いますが、NFVやコンテナPLCといった動向を見ると、プライベートクラウドの存在価値を再定義する時代なのかもと思ったりします。プライベートクラウドが現場に近づくことで、従来ハードウェアで導入されていた専用機器を汎用ハードウェアで実行することが可能となり、パブリッククラウドと組み合わせて全体最適化を図る時代に突入してきてるのかなと思います。

自動車でKubernetes

　SDV（Software Defined Vehicle）の動きが熱いですが、車でKubernetesの事例は、2018年頃にデンソーの発表した「Misaki³」というプラットフォームの取り組みが有名かと思います。車を制御する機能を実行するECU(Electronic Control Unit)をKubernetes Workerとして利用して、車の中でデータ収集や制御アプリケーションを実行する取り組みをしています。
　この取り組みでは、車とクラウドをVPNで繋げて、フラットなアンダーレイネットワークを作り、クラウド側に配置したKubernetes Masterから車へコンテナを展開します。クラウド側には開発コンソールを実装し、クラウド側で実装したアプリケーションを車へ展開するデジタルツインなプラットフォームを実証しています。また、Misakiでは、車のECUのリソースも有限ということで、車のコンピューティングリソースが不足した際に、クラウドのリソースを補助リソースとして活用するCloud Burstingにも取り組んでいます。

参照） https://www.slideshare.net/JunKaiYong/integrating-service-mesh-with-kubernetesbased-connected-vehicle-platform

ロボットでKubernetes

　ロボット制御のミドルウェアであるROSやROS2といったアプリケーションをコンテナで実行し、ロボット上にKubernetesを動かしてROSアプリケーションを実行する、という取り組みがされています。例えば、Sony R&D⁴の取り組みや、GoogleのGoogle Cloud Robotics Core⁵、インテック先端技術研究所のRDBOX⁶といった事例があります。

参照) SONY R&D - https://www.slideshare.net/FujitaTomoya/rosros2-distributed-system-with-kubernetes

参照) Google Cloud Robotics Core - https://googlecloudrobotics.github.io/core/

参照) RDBOX - https://github.com/rdbox-intec/rdbox

　それぞれ共通して、ロボットとクラウドを統合してフラットなプラットフォームを実現するという取り組みになっています。エッジとクラウドでアプリケーションの管理プラットフォームがサイロになってしまう課題を、Kubernetesで標準化することで対応しています。

飲食店でKubernetes

　北米でハンバーガーショップを展開しているChick-fil-a⁷は、フライドチキンの需要予測を精緻化するために、店舗内のPOSやフライヤーなどの調理機器からデータを収集し、店舗内にIntel NUC 3台で構成したKubernetesクラスタでデータ分析を行うプラットフォームを発表しています。2018年のKubeCon+CloudNativeConで発表された有名な事例です。
　もともと、本社の方にPOS等のデータが集まって、全店舗共通の需要予測が店舗に降りてくる業務フローだったのに対して、各店舗のPOSや調理機器等から得たリアルタイムデータで補正して、店舗毎に最適化した需要予測を算出し、店舗スタッフの業務の生産性を向上しようという取り組みです。既に約2000店舗へこの分析プラットフォームを展開しているということで、かなりイノベーティブな事例です。初めからエッジコンピューティングありきで取り組んだのでなく、初めはクラウドで構築したりしていたそうですが、外部ネットワークとの切断が起こっても業務を継続できる点と、ネットワーク接続性がそもそも乏しい店舗が存在するということから、エッジコンピューティングに舵を切って推進しています。将来的に、調理の自動化をやるぞ！という方針もあるようです。

参照) https://medium.com/@cfatechblog/edge-computing-at-chick-fil-a-7d67242675e2

スーパーでKubernetes

　Walmartは、店舗内にKubernetesクラスタを展開して、クラウドPOSの決済トランザクションを店舗で、BIなどの分析アプリケーションをクラウドで処理するアーキテクチャに改善する取り組みをおこなっています。2019年にKubeCon North America⁸で発表されました。クラウドPOSは、決済トランザクションがクラウド側で行われる故に、外部ネットワークとの切断が発生してしまうと業務影響が大きい課題に取り組んだ事例です。

参照) https://static.sched.com/hosted_files/kccncna19/20/3%20Manesh%20and%20Siram%20New%20V2.pptx.pdf

衛星でKubernetes

　Red HatとIBM Space Techは、ENDURANCE⁹という宇宙ミッションで、Red Hatがオープンソースとして開発を推進する軽量版OpenShiftの「MicroShift」を小型人工衛星(CubeSat)へ搭載して、SpaceXの宇宙船で宇宙へ運び、磁力計、太陽センサー、電圧、温度といった衛星のテレメトリデータの取得やCubeSatのカメラで写真撮影などを地上から制御できるプラットフォームをIBM Cloud上に実装しています。

他にも、Hypergiantが軍事衛星軌道にk3sベースのKubernetesクラスタを導入したり¹⁰、地味に衛星エッジコンピューティングでKubernetesが自然と採用されている感じがします。衛星でKubernetesが動く時代...胸熱...

Device EdgeでKubernetesを使う理由

　このように、様々な業界でDevice EdgeへKubernetesを導入し、アプリケーションを実行する検討がされているわけですが、なぜDevice EdgeでもKubernetesを検討するのでしょうか？クラウドやデータセンターで使われるソフトウェアとして生まれたKubernetesは、もともと分散システムの思想で実装されており、ある意味初めからエッジにも親和性が高いソフトウェアです。そのため、クラウドの延長でエッジを考えた時に、Kubernetesが候補に上がるのは必然の様に感じます。一方で、もともとエッジデバイスを主戦場としている開発者がKubernetesに期待することは何なのでしょうか？事例やお客様とのトークを踏まえて自分なりに整理すると、以下の3つに集約されました。

アプリ管理の自動化ソフトとしてのKubernetes

　これは、シンプルに、Kubernetesというソフトウェアそのものの価値への期待です。Device Edgeのアプリケーション開発者からすると、Kubernetesの、APIベースでアプリケーションをデプロイできる機能、ローリングアップデートといったアップデートの自動化機能など、アプリケーションのライフサイクル管理の効率化をスクラッチ実装を考えずに容易に実現する点に価値を感じています。

クラウドのKernelとしてのKubernetes

　これは、クラウドネイティブの動向に強い開発者のニーズです。Kubernetesは、ハードウェアでいうところのOSのように、クラウドのKernelとしてアプリケーションの管理やコンピューティングリソースの管理を標準化するソフトウェアです。マルチクラウドやハイブリッドクラウドでもKubernetesを軸に運用の一貫性のあるプラットフォームを設計するように、エッジに対してもKubernetesを軸として、クラウドとエッジの運用の一貫性を確保したい、というものです。

エッジでもクラウドネイティブなオープンソースを使いたい

　これも、クラウドネイティブの動向に強い開発者のニーズです。例えば、エッジデバイスを横断してサービスメッシュを構成したい、サーバレスなプラットフォームを実現したいといった、CNCFなどで推進されるオープンソースをエッジでも利用したい、というものです。

今後のエッジコンピューティングの技術的な方向性（インフラ観点）

　エッジコンピューティングの導入形態は様々ありますが、個人的にはDevice Edgeこそ、エッジコンピューティングの真骨頂と思います。そんなDevice EdgeとクラウドがKubernetesを中心にインテグレーションされて、エッジもクラウドも一貫性を持った運用が可能になると、正にコンピューティングがネットワークに溶け込む世界が見えてきます。
点々と存在するコンピューティング環境が線で結ばれて一つの群を成して、論理的な一つの大きなコンピューティングリソースを形成する分散システムのワクワクが止まりません。

　Eclipse FoundationのEdge Native Working Groupでは、DevOpsの原則をエッジへ適用しつつ、エッジならではの特徴を解決するコンセプトとして「EdgeOps¹¹」というコンセプトを推進しています。

参照) https://cedalo.com/wp-content/uploads/2021/06/Eclipse-Foundation-EdgeOps-White-Paper.pdf

　EdgeOpsを実現するオープンソースとして「ioFog」というオープンソースがあります。ioFogは、北米のエッジプラットフォームのスタートアップであるEdgeworxが主導して開発されているオープンソースで、同社の「Darcy.ai」などのエッジPaaSの基盤として使用されています。ioFogのコアコンセプトはまさに、エッジデバイスを群としてコンピューティングリソースを統合管理し、エッジデバイスを横断してサービスメッシュを構成できるプラットフォームです。各エッジデバイスや、エッジデバイス上のマイクロサービスは、コントロールプレーンで一元管理されます。この様に、今後のエッジコンピューティングの方向性は、Control PlaneとData Plane、エッジとクラウドが統合したフラットなプラットフォームであると考えています。

参照) https://iofog.org/docs/2/getting-started/architecture.html

まとめ

　本稿では、Device EdgeのKubernetes動向を踏まえて、「なぜエッジデバイスでKubernetesが期待されているのか？」、についてまとめました。他にこんな事例があるよ！とか、他にhogehogeな理由でKubernetes使うんだぜ！という方がいましたらぜひご連絡いただけると嬉しいです〜。最後まで読んでいただき、ありがとうございましたー！

コンピューティングがネットワークに溶け込む未来〜僕たちがエッジデバイスでKubernetesを使う理由〜