見出し画像
Photo by nakameguromt

microserviceアーキテクチャのその先にあるIoTの進化をワクワクして楽しもう。待っているだけじゃもったいない。

Yohei

この記事はMakuake Advent Calendar 2022の24日の記事です
※めちゃくちゃ遅れてすいませんでした。

2022年9月、Googleは自社のスマートホーム向けラインナップの新製品発表と共に、MatterというIoT規格への対応を発表しました。
MatterはIoT業界が現状抱えている代表的な困り事を取り除くポテンシャルを秘めています。今回はこの規格にまつわる話です。

 IoT・スマートホーム業界を取り巻く悲しい状況

この規格が策定されたのには、いくつかの重要な背景があります。
代表的な困りごととしては

  • Smart Home黎明期の機能競争で各社デバイスの独自仕様が氾濫していて、互換性がない

  • ZigBee、BLEなど、一般化を目指した省電力通信規格も多数あったが、Insteon、SmartThingsなど、メーカー独自の規格の栄衰も後を立たない

  • IoTデバイスのマネジメントポリシーが確立していないため、脆弱性に関する脅威と懸念と戦いにくい

  • 結果としてデバイスを買ってきても導入に必要な手順が多すぎてオンボーディングが難しすぎる。

などがあげられます。

今現在も、スマートホームを実現するIoTガジェットは各国のAmazonで見ても数え切れないほどにリリースされていますが、常に消費者は「この聞いたこともないメーカーが消え去ったら使えなくなってしまう？ずっと使えるメーカーはどこだ？」といった悩みを抱えています。
家の防犯の根源を担う鍵管理を担うスマートロックでさえ、メーカー（ホスト）がなくなってしまったらその機能を失ってしまうような構造になっている製品がいくつもあります。
負のリスクはメーカーの消失だけではなく、ハッキングによる乗っ取りリスクも無視できず、その保全はそれぞれのメーカーに委ねられていました。

そして魅力的なアイデアや実力を持つIoTデバイスメーカーの多くはスタートアップ企業であり、深刻なリスクに対応できる十分な経済力は持ち得ない状況です。
Insteon（ https://wired.jp/article/insteon-shutdown/ ）などはそうしたリスクを顕在化した例であり、こうしたリスクは今現在市場に出回っているIoT製品のどれにも少なからず存在します。
このままでは「継続的な運営を行える経済基盤がある企業のみがスマートデバイス競争に参加できる」という可能性が閉ざされた業界になりかねません。
アイデアで勝負するスタートアップの参入障壁が高く、本当の意味でのスマートホームの普及に対して業界の本腰が入らない理由はまさにこれで、象徴するかのように最近は深圳・ベルリンなどのスマートデバイス・スタートアップも当時ほどの勢いがない状況が続いています。

Matter は業界のどんな困り事を取り除くのか？

そんな中、 2019年12月18日、Amazon、Apple、Google、Samsung SmartThings、およびZigbee Allianceは、スマートホームデバイスの互換性向上の取り組みで連携し、スマートホーム製品間の互換性を高めるための新たな接続規格を開発するワーキンググループ「Project Connected Home over IP（CHIP）」の立ち上げを発表しました。

その後2021年05月11日、Zigbee Allianceは、団体名をConnectivity Standards Alliance（CSA）への改称を発表し[19]、そして以前から行なっていたワーキンググループCHIPでの成果として、新たなスマートホームのための通信規格をプロプライエタリソフトウェア（ https://ja.wikipedia.org/wiki/プロプライエタリソフトウェア ）のロイヤリティフリーのホームオートメーションの工業規格とし発表しました[20]。これがMatterです。
wikipedia引用： https://ja.wikipedia.org/wiki/Matter_(%E8%A6%8F%E6%A0%BC)

それを皮切りにApple / Google / Amazonは2021年に相次いでMatterへの対応を表明し、2022年にはGoogleがNestラインとAndroidのMatter対応（ https://k-tai.watch.impress.co.jp/docs/news/1464282.html ）を、AppleはiOS16でのMatter対応（ https://www.itmedia.co.jp/mobile/articles/2207/26/news073.html ）を発表しました。
2023年はMatterへの対応を表明する製品がどんどん増えていくでしょう。

具体的なMatterの功績で最も目立つのはIoTの要となるLow Availability Devices（低スペックな端末）をインターネットに接続できるようにしたことです。
これを実用化レベルで実現するためには、低スペックで動作すること、低消費電力であること、セキュアであることなど、クリアし、整備しなければならないハードルがいくつもあります。
そしてMatterは現在考え得るほぼ全てのハードルをクリアし、本当の意味での実用的なIoTを活用する基盤を実現しようとしています。

テクニカルな鍵は４つ。

  • 6LoWPAN（IPv6 over Low-power Wireless Personal Area Networks｜ https://www.uctec.com/iot-products-ja/question/about-6lowpan/ ）をベースにしたThreadにより、低消費電力な無線モジュールから構成されるネットワーク上でIPv6に基づく通信を実現

  • Thread（ OpenThreadとしてOSS公開されている｜ https://github.com/openthread ）はBorder router（Edge router）により、従来の製品メーカーごとアプリケーション層に依存した独自ネットワークとは違い、ネットワーク層での互換性を確保するため、アプリケーション層での相互接続がかなり容易になる。

  • Border routerは同一エッジクラスター内で相互に役割を補完しあうことができるため、ネットワーク内の単一障害点にならない

  • Threadは認証されたデバイスだけがネットワークに参加することができるため、高いセキュリティレベルを維持できる。

これらの標準的な作法がないばかりに、各IoTメーカーはアプリケーション層で構築した独自のエッジルーティングを用いたネットワークを介して低消費電力な無線通信を展開するしかありませんでした。
そして各社がその仕様を隠蔽またはネットワーク常に解放するインターフェースに制限を設けることでギリギリのセキュリティレベルを確保していたのです。
これらがネットワーク層に構築された標準規格の上に並ぶことにより、各デバイスが必要に応じて直接命令をやりとりできるようになります。
Threadについては、ここ（ https://openthread.io/codelabs/openthread-testing-visualization#0 ）がわかりやすい記事です。

Matter / Threadとk3s の両者に通ずる概念

Dockerを中心に、コンテナエコシステムはコンピューティングリソースの再概念化を通じて

  • 限りあるコンピューティングリソースの効率的な利用

  • コンピューティングの自由度向上

を実現しようとあらゆる規格・ソリューションを推進していて、これらはある側面で一般的なWebテクノロジーのスケーラビリティ確保・リソース・ポータビリティなどの恩恵をもたらしています。

一方でGAFAMを始めとしたテクノロジー業界が本当にやりたいのはもっと拡張性が高く、発展的なアプローチです。
その代表的なひとつに、kubernetesにおけるk3sの取り組みがあります。
コンテナエコシステムでインターネット業界が培ってきた概念構成の価値を本格的にエッジコンピューティングなどの物理デバイスのアーキテクチャ・エコシステムに還元しようという試みです。

kubernetesはMatterが構築するアーキテクチャと概念レベルでさまざまな共通点があります。

  • クラスター内に所属するリソースの認証モデル → Threadの認証機構

  • ネットワーク層とアプリケーション層の役割設計 → Threadの実装がネットワーク層に特化し、アプリケーション層のサイロ化を防ぐ

  • Podによるスケーラブルリソースの抽象化 → Border Routerによるデバイスクラスターの抽象化

  • ServiceMesh / Protocol Buffers / gRPC によるリソース（コンテナ）の提供するAPIインターフェースの自己申告制 → Matterも参加デバイスにはインターフェースの標準準拠、または独自仕様の公開を義務付けている

k3sについてはRancher LABSが日本語マニュアルを公開していますが、

https://www.rancher.co.jp/pdfs/K3s-eBook4Styles0507.pdf

ここでで提唱しているアーキテクチャもそうした共通概念を感じられるものになっています。

ITエンジニアの視点から見ると、これらを概念レベルでつなげることでMatterは「kubernetesエンジニアリングの延長線上で物理デバイス常に構築されたコンピューティングリソースも仮想コンピューティングリソースも同じように取り扱えるようにする」という世界線を実現してくれています。

そしてこれらの取り組みは僕の知る限りでは2014年頃から本格的に始まって今に至ります。
kubernetes / microservice を取り巻くリソースハンドリング、POD単位の役割設計、ネットワークなどはソフトウェア・アーキテクチャである程度の成功モデルとして確立しました。
この成功モデルがあってこそ、Matterのような規格はまとまりを得るようになってきています。（実際にCNCFの取り組みがMatterの策定に影響を及ぼしたことは何度もあります）
k3sのようなmicroserviceベースの責務分離モデルとクラスターコントローラーのオーバーヘッドを極限まで小さくする試みはエッジコンピューティングとも非常に相性が良く、Matter 1.0正式リリース前からこのモデルを意識したプロジェクトは数多くあります。

象徴するような業界の動き

スマートホームのOSS Home Assistant

最もパワフルなスマートホーム・IoTのOSSプロジェクトのひとつにHome Assistantがあります。
Home AssistantはIoTマネージャーとしてはかなり優秀で、日本でも有名なIoTの雄、Switchbot（米Wonder Labs）にも対応しています。（ https://hackmd.io/@yuzuafro/switchbot-homeassistant ）※我が家も一部この構成です。
対応していない機器を探すのが難しいくらいさまざまなデバイスに対応しており、思想としてはそのままMatterに通ずるところがあります。（ https://gigazine.net/news/20210926-home-assistant/ ）
※実装を読むと、相当アプリケーション層の結合にパワーを割いています。

2021年のこの Automating Your Home with K3s and Home Assistant - Eddie Zaneski & Jeff Billimek プレゼンは心が躍りました。
https://www.youtube.com/watch?v=icyTnoonRqI

Home AssistantはQNAPでも動く（ https://www.home-assistant.io/integrations/qnap/ ）ので、NASを起点にした一歩進んだIoTを実現するのにぴったりなソリューションです。
Matterの思想にもかなり通ずるようなアーキテクチャになっており、エンジニアリングの心得がある人にとっては現時点でのIoTデバイスのポテンシャルを最も引き出せるソリューションと言っても過言ではないでしょう。

またCSAのなかでも重要なポジションを担っており、今年Matterに対応しました。（ https://www.home-assistant.io/integrations/matter/ ）
※Matterはまだv1.0なので、現時点では暫定対応が多いです

また、HJome AssistantはRPCプロトコルでOTBRファームウェアと会話できるBorder Router向けAdd-onを開発中（ https://community.home-assistant.io/t/thread-spinel-rpc-firmware-for-texas-instruments-cc2652-cc1352-to-use-openthread-border-router-otbr-add-on-for-use-with-thread-based-devices-like-some-future-matter-chip-products/433278 ）で、この行く末は非常に気になるところ。

これはそのままMatterの現時点での暫定ホストコントローラーとしてQNAPを使用することができることを示しています。
今後の発展が期待されます。

k3sを使用したSmart Home / IooTモデルの構築

Edge Computing on Low Availability Devices with K3S in a Smart Home IoT System
では、k3sを用いたIoT Systemを提案しています。
Low Availability Deviceでいかにk3sアーキテクチャが有利に働くかが研究されています。

株式会社スタイルズによるSUSE k3s＋SUSE Rancher ＋ FLEETをベースとした産業向けのエッジコンピューティングモデル

株式会社スタイルズはk3s＋SUSE Rancher ＋ FLEETをベースとした産業向けのエッジコンピューティングモデルを実用化しています。
https://www.stylez.co.jp/edge_mlops/edge_platform/
モバイルデバイスの管理にARMベースの端末を積極的に採用するなど、クラウドに閉じないいかにもk3sらしい活用方法をSUSE k3sプロジェクトを通じて実現しています。
https://www.suse.com/ja-jp/products/k3s/

このモデルの成功もMatterの規格化に一役買った大きな功績です。

k0sはさらにこの変化を加速させるかもしれない

2020年にはk0sというオンプレ〜パブリッククラウド、プライベートクラウドなど、さまざまなクラスターのkubernetesがリリースされました。
https://k0sproject.io/

k3sとの連動が期待されており、よりEdge Computingに向けた実装が加速していくのは間違いありません。

microserviceエンジニアリングはもはやwebベースのサービスだけに向けたスキルではない。その続きにあるIoTを楽しもう！

ソフトウェアエンジニアは、これまでもそのスキルを常に抽象化し、ほかの業界へ生かすチャレンジをしてきました。
今ではハードウェアエンジニアリングにも、ソフトウェアエンジニアリング業界が育んだPDCAサイクルや、アジャイルリリースはどんどん生かされつつあり、何千万人を相手にするようなプラットフォームの改善思想から生まれた人間の体験を抽象化するUXも、さまざまな業界を飛び越えて顧客の切り取り方の重要な一つの手法として確立しました。
そしてここ数年、CNCFの一部が始めた「リソースの抽象化」はリアルデバイス・仮想デバイスの垣根をなくし、「オーバーヘッドの限りない除去」はEdgeクラスターをバーチャルクラスターと同じように扱えるよう進化させ、またひとつ社会を大きく変える種を見出しつつあります。

microserviceなど、エンジニアリングを通じてITに登場するさまざまなキャラクターを抽象化して取り扱うようなアーキテクチャーに携わっている皆さん、抽象化は一見して慣れないと苦しい作業ですが、その抽象化にこそ次のテクノロジーの活用の扉を開け大きな大きなポテンシャルがあります。
そうやってソフトウェアエンジニアは、社会に驚くべき価値を生み出してきたんです。

そしてそうした大きなムーブメントが起きる準備の第１段階は、2022年に整ったと言っていいと思います。
2023年から数年は、IoTの世界で巻き起こるこのムーブメントを肌で感じ、全力で楽しんじゃいましょう。

※本編ではアプリケーション層とネットワーク層の比較をTCP/IPモデルを前提として解釈しています（ https://wa3.i-3-i.info/diff322model.html ）
※今回は（も？）総論を書いたので、詳細な解説はリンク先などを参照くださいね。

Other Appendix

この記事はMakuake Advent Calendar 2022の24日の記事です
※めちゃくちゃ遅れてすいませんでした。


この記事が気に入ったらサポートをしてみませんか？