[招待講演] ネットワークの構造変化からIoTプラットフォームま で, 社会に溶け込むコンピューティングの実現に向けた 取り組みのご紹介 電⼦情報通信学会 NS研究会 2022年1⽉ 2022/01/27 Copyright(C)2022IEICE さくらインターネット研究所 上級研究員 菊地 俊介 さくらインターネット株式会社 本資料の著作権は電⼦情報通信学会に帰属します 信学技報, vol. 121, no. 356, NS2021-111, pp. 7-12, 2022年1⽉.

話者紹介 2 菊地 俊介 （東京都出⾝） 所属 さくらインターネット研究所 学歴 早稲⽥⼤学⼤学院 理⼯学研究科 電⼦・情報通信学専攻 修⼠課程修了 早稲⽥⼤学⼤学院 国際情報通信研究科 博⼠課程単位取得退学 職歴 富⼠通（株）富⼠通研究所に就職 ネットの研究やったり、SEやったり、NICTに出向したり、 トイレIoT作ったり さくらインターネットに転職 データ流通（FIWARE, NGSI）、OpenFogコンソーシアム（標準化）、 量⼦（アニーリング）コンピュータ、 AR/VR、RISC-V、Erlang/Elixir 専⾨ エッジ・Fogコンピューティング（分散系システムのあたり） ビジョナリーとして技術・社会、会社の将来を思い描く 新規領域調査、PoC実施、社内適⽤コンサル、講師・講演 趣味 新技術調査、読書、最近はガンプラ作り @kikuzokikuzo h"ps://note.mu/kikuzokikuzo https://www.facebook.com /kikuzokikuzo

⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング • 端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会（FIWARE） • まとめ 3

⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング • 端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会（FIWARE） • まとめ 4 →何を⽬指すのか、なぜそれを⽬指すのか

超個体型データセンター コンセプト / Super Organism Data Center • 序⽂ • クラウド時代の⼀極集中構造が限界に達し、エッジコン ピューティングによる半集中の階層構造を利⽤しつつも、さ らに分散化が進み、あらゆるデバイスや場所にデータセン ター的な機能が溶け込んでいく。 • しかし、各コンピューティングは独⽴した個体として機能し ながらも、総体としては統率されているようにみえたり、 ⼩・中規模データセンターがハブとなって結果的に全体がう まく繋がれ、構成されていく。その様は、分散された各個体 と集中する各個体が群体をなしており「超個体的」であると いえる。 • 各コンピューティングが⾃律的に分散と集中のハイブリッド 構造をとるような環境を「超個体型のデータセンター」、各 データセンターを総体として透過的に扱えるOSを「超個体 型データセンターOS」と定義する。 5

超個体型データセンター コンセプト / Super Organism Data Center 1. 現在はデータセンターに巨⼤なコンピューティングリソースが存在してい るが、今後は、レイテンシ・セキュリティ・コスト等の要件から、あらゆ る場所や社会（組織）にコンピューティングリソースが溶け込んでいくこ とになる。 2. それら分散したコンピューティングリソースは、単独でコンピューティン グパワーを提供するにとどまらず、その場所や社会の要求に応じて、⾃律 的に、分散あるいは有機的に結合し、現場・クラウドそれぞれが縦横に結 びついたハイブリッド構造をとれるように機能する。 3. そのようなシステムにより実現されるものは、⼈々の⾝近に存在し、リア ルタイムかつインテリジェンスにユーザを⽀えながら、しかし同時にバッ クエンド側が有機的に結合することにより、かつてないマシンパワーとリ ソース量を動員することで現場最適かつ全体最適をも実現するSuper Organism Worldである。 4. さくらインターネット研究所はこのようなビジョンのもと、Super Organism Worldを実現する超個体型データセンターシステムやそれを統 括管理する超個体型データセンターOS等の研究開発を推進していく。 6

さくらインターネット研究所 10年ビジョン（2021年版） 7

さくらインターネット研究所 10年ビジョン（2021年版）(⼀部抜粋) 8 MEC/エッジ/ オンプレ再勃興 中規模データセンター （各政令指定都市へ） センターレス・ 分散システム 集中・分散の ハイブリッド ⾃動構成・ ⾃動障害検出・復旧 ⾃律動作 ⾃動機能追加・進化 クラウド・エッジ・ 階層型アーキ Fog・分散型 アーキ レイヤレス 分散アーキ データセンタートレンド 運⽤管理トレンド システムアーキトレンド 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031

⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング • 端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会（FIWARE） • まとめ 9 →何をやっているのか

（国内）ネットワークの構造 （エッジコンピューティングを理解するために）まず 前提となるネットワークとクラウドの構造を理解する 10 地域IP網 =フレッツ網 コア網= インターネット網 携帯電話網 =LTE(4G) クラウド クラウド クラウド ⾃営網 ネットワーク装置（ルータ） サーバ アクセス網側︓エンドユーザが居る側 クラウド側︓サーバがある側 （有線）キャリアネットワーク 携帯ネットワーク

ネットワークインフラに求められる要件の変化 キーポイント︓IoTの登場 11 クラウド IoT機器 各種 アクセスネットワーク 往復 伝搬遅延 ＝間に合わない︕︕ 【参考】 • ⼈(4.8km/h)が1秒間に進む距離︓1.3 m • ⼈の反応速度︓300 msec ↓ • ⼈の動きに対応するための応答速度︓100 msec • ⾃動⾞(100km/h)が1秒に進む距離︓28 m （1m進むのに0.035秒=35 msec） ↓ • ⾃動⾞に対応するための応答速度︓10 msec ⼈の反応速度より早く反応するシステムが求められる︕

期待されるネットワークの構造の変化 - エッジコンピューティング クラウドを現場（＝エッジ）側に延伸していく、 これがエッジコンピューティング 12 地域IP網 =フレッツ網 コア網＝ インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 （有線）キャリアネットワーク 携帯ネットワーク

エッジコンピューティングの分類 – 誰がエッジコンピューティングを作るのか(1) 誰がエッジサーバを⽤意するか ＝アクセスネットワークとの関わり⽅、から エッジコンピューティングは３種類に分類できる。 13 モバイル（キャリア）ネットワーク 有線（キャリア）ネットワーク ⾃営（有線）ネットワーク RAN Mobile Backhaul the Internet クラウド （⼤規模D.C.） 基地局 局舎 アクセス網 （NTT東⻄） BackBone ⾃営網 ⾃営D.C. Local5G デバイス ３種のアクセスネットワーク

エッジコンピューティングの分類 – 誰がエッジコンピューティングを作るのか(2) 14 モバイル（キャリア）ネットワーク 有線（キャリア）ネットワーク ⾃営（有線）ネットワーク RAN Mobile Backhaul the Internet クラウド （⼤規模D.C.） 基地局 局舎 アクセス網 （NTT東⻄） BackBone ⾃営網 ⾃営D.C. Local5G デバイス ３種のアクセスネットワーク MEC型 IIC型（OT発展型） クラウド延伸型 MEC : Multi-Access Edge Computing →携帯キャリアがすすめるエッジコンピューティング IIC : Industrial Internet Consortium →産業機器業界がすすめるエッジコンピューティング クラウド事業者がすすめる エッジコンピューティング 誰がエッジサーバを⽤意するか ＝アクセスネットワークとの関わり⽅、から エッジコンピューティングは３種類に分類できる。

エッジコンピューティングの動向(1) クラウド事業者とモバイルキャリアとの協業体制の構 - AWS WaveLength 15 https://news.kddi.com/kddi/corporate/newsrelease/ 2019/12/04/4167.html h"ps://www.watch.impress.co.jp/docs/topic/1297141.html

エッジコンピューティングの動向(2) • AWS Outposts • AWSのオンプレ向けエッジコンピューティングソリューション • サーバ利⽤料⾦は、クラウド(EC2)の15%増し程度の模様 • https://dev.classmethod.jp/articles/aws-outposts-cost-assessment/ • 3年間継続利⽤を約束 • Outposts->クラウド（イン）のデータ転送は無料、アウトは有料（EC2 と同様） 16 h"ps://aws.amazon.com/jp/outposts/

エッジコンピューティングの動向(2) • AWS Outpostsに19インチラックサイズが登場(21年11⽉) 17

さくらでの取り組み • モバイルキャリア各社と、協業の可能性について打ち 合わせ実施 • →キラーコンテンツ・ビジネス採算性などから実現に⾄らず （と推測） 18 モバイル（キャリア）ネットワーク 有線（キャリア）ネットワーク ⾃営（有線）ネットワーク RAN Mobile Backhaul the Internet クラウド （⼤規模D.C.） 基地局 局舎 アクセス網 （NTT東⻄） BackBone ⾃営網 ⾃営D.C. Local5G デバイス ３種のアクセスネットワーク MEC型 IIC型（OT発展型） クラウド延伸型 MEC : Multi-Access Edge Computing →携帯キャリアがすすめるエッジコンピューティング IIC : Industrial Internet Consortium →産業機器業界がすすめるエッジコンピューティング クラウド事業者がすすめる エッジコンピューティング

エッジコンピューティングの内部構成、その要件 エッジコンピューティングの（究極の）⽬標 • 現場での制限なしのコンピューティングの利⽤、その環境の構築 • コンピューティングおよびネットワーク利⽤の最適化（地産地消化） エッジコンピューティングの（より現実的な）⽬標 • エッジとクラウドをシームレスに使えるコンピューティング環境の実現 • クラウド、エッジそれぞれの特徴を活かす 19 地域IP網 =フレッツ網 コア網＝ インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 （有線）キャリアネットワーク 携帯ネットワーク クラウドをエッジに延伸することで、 クラウドエコシステムを活かす リソース・性能を⾃由・動的に 選択・組み合わせ可能に 移動に対応する アクセスネットワークの機能を取り込む …

エッジコンピューティングを実現する技術(クラウド側) 「エッジとクラウドをシームレスに使えるコンピューティング環境の実現」 に向けて • AWS WaveLength, Anthos for Telecom, Azure Edge with Carrier • AWS Outposts, Azure Private Edge, Azure Stack HCI • Service Mesh, KubeEdge • Nerves(Elixir) 20 地域IP網 =フレッツ網 コア網＝ インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 （有線）キャリアネットワーク 携帯ネットワーク クラウドをエッジに延伸すること で、クラウドエコシステムを活かす リソース・性能を⾃由・動的に 選択・組み合わせ可能に

エッジコンピューティングを実現する技術(アクセス網側) 「クラウド、エッジそれぞれの特徴を活かす」に向けて • 5G（Local5G） • MEC • IP Anycast (IPルーティング) 端末の移動をサポートするのは難しい 21 地域IP網 =フレッツ網 コア網＝ インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 （有線）キャリアネットワーク 携帯ネットワーク 移動に対応する アクセスネットワークの機能を取り込む …

移動への対応(1) • サーバの移動 • エンドユーザの近傍のサーバでプログラム（/ジョブ/タスク）を動かす • →（ライブ）マイグレーション、エッジデプロイ • エンドデバイスの移動 • エンドユーザ（⼈）に付随してデバイスが移動する際に、サーバとの接続 が切れないようにする • →携帯通信システム(LTE/5G)、MobileIP • エンドユーザの（物理的に）近傍のサーバに接続する • →︖IP Anycast ? DNS ? • 移動サポートの難しさ • 適切なアクセス先エッジノード（サービス）をどうやって探す・決めるか • どうやってそのサービスにアクセス（ルーティング）させるか • 期待したように動いているかの監視 22

移動への対応(2) • 移動サポートの難しさ • 適切なアクセス先エッジノード（サービス）をどうやって探す・決めるか • どうやってそのサービスにアクセス（ルーティング）させるか • 期待したように動いているかの監視 23 地域IP網 =フレッツ網 コア網＝ インターネット網 携帯電話網 ⾃営網 オンプレ設備 （有線）キャリアネットワーク 携帯ネットワーク • 現状では、携帯網・キャリア網（地域IP網）から外に出ていく経路は１通りしかない。 • →5Gでは複数の外部接続をサポートする。 • →キャリアネットワークでは網設計次第（PPPoE, IPoEのGWをどこに設置するか）。 • 端末側で、通信先サーバを選択しなければならなくなる可能性も。 • ...監視︖ →今後の業界を巻き込んだ検討が求められる。 ︖

エッジコンピューティングの分類 24 モバイル（キャリア）ネットワーク 有線（キャリア）ネットワーク ⾃営（有線）ネットワーク RAN Mobile Backhaul the Internet クラウド （⼤規模D.C.） 基地局 局舎 アクセス網 （NTT東⻄） BackBone ⾃営網 ⾃営D.C. Local5G デバイス ３種のアクセスネットワーク MEC型 IIC型（OT発展型） クラウド延伸型 MEC : Multi-Access Edge Computing →携帯キャリアがすすめるエッジコンピューティング IIC : Industrial Internet Consortium →産業機器業界がすすめるエッジコンピューティング クラウド事業者がすすめる エッジコンピューティング 誰がエッジサーバを⽤意するか ＝アクセスネットワークとの関わり⽅、から エッジコンピューティングは３種類に分類できる。 この領域（障壁）を超えてエッジネットワーク を相互接続するのは⾄難の業

エッジコンピューティングで求められるネットワーク構造の変化 25 エッジ時代のインターネットインフラに向けて • エッジを意識したクラウド（サーバ）技術の拡張 • エッジを意識したアプリ・プログラム技術の拡張 • 地域での横のつながり、地域ネットワークの（再）構築 地域IP網 =フレッツ網 コア網＝ インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 （有線）キャリアネットワーク 携帯ネットワーク どこにでもコンピューティングリソースがあり、⾃在に利⽤できるような時代に向け て、インターネットインフラの⾰新が進む（ことを期待）

ネットワーク構造の変化に向けて - さくらでの取り組み インターネットトラヒック 流通効率化検討協議会（CONECT） 26 JANOG （JApan Network Operatorsʼ Group）

ネットワークの構造とその変化、まとめ • エッジコンピューティングは、アクセス網により３つに分類される、 と考える • MEC型 • クラウド延伸型 • IIC型（OT発展型） • モバイルキャリアとメガクラウドベンダが⼿を組んで、MEC型/クラウド延 伸型は融合が進んでいる • エッジコンピューティングを活かすキラーアプリはまだ⾒いだされ ていない、と考える • エッジコンピューティングの（真の）メリットとは、アクセスネッ トワークとの融合や端末移動への対応、と考える • 技術的にも網構造（ビジネス）的にも、まだ真価を発揮できる状態 ではない • 業界としての議論なども必要、さくらとしても積極的に貢献してい きたい 27

⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング • 端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会（FIWARE） • まとめ 28

Fogコンピューティングとは︖ エッジコンピューティングの先にある、 よりコンピューティングが現場に溶け込んだ概念 • エッジコンピューティングに、エッジノード間の横連携、端末デ バイス間の横連携を＋αしたもの • 更には、エッジノード、端末デバイスの区別なくすべてが連携・ 協調する分散アーキテクチャシステムも想定 29 クラウド エッジノード 間横連携 端末間連携 Fogシステムイメージ （分散計測）

Fogコンピューティング = Beyond 5G ? • 総務省「 「Beyond 5G推進戦略 －6Gへのロードマップ－」の公表」に、Fogコンピューティングに 似た考え⽅が盛り込まれている • https://www.soumu.go.jp/menu_news/s-news/01kiban09_02000364.html （別紙３より） 30 2 Beyond 5Gに求められる機能等 拡張性 超低消費電力 Beyond 5G 超安全・信頼性 超高速・大容量 超低遅延 超多数同時接続 5Gの特徴的機能の更なる高度化 高速・大容量 低遅延 多数同時接続 5G 持続可能で新たな価値の創造に 資する機能の付加 自律性 •アクセス通信速度は5Gの10倍 •コア通信速度は現在の100倍 •5Gの1/10の低遅延 •CPSの高精度な同期の実現 •補完ネットワークとの高度同期 •多数同時接続数は5Gの10倍 •現在の1/100の電力消費 •対策を講じなければ現在のIT 関連消費電力が約36倍に （現在の総消費電力の1.5倍） •セキュリティの常時確保 •災害や障害からの瞬時復旧 •ゼロタッチで機器が自律的に連携 •有線・無線を超えた最適なネットワークの構築 • 衛星やHAPSとのシームレスな接続（宇宙・海洋を含む） • 端末や窓など様々なものを基地局化 • 機器の相互連携によるあらゆる場所での通信 ※ 緑字は、我が国が強みを持つ又は積極的に 取り組んでいるものが含まれる分野の例 テラヘルツ波 オール光ネットワーク 完全仮想化 量子暗号 時空間同期 （サイバー空間を含む。） センシング HAPS活用 インクルーシブインターフェース 低消費電力半導体 注⽬ 注⽬

さくらでの取り組み - OpenFogコンソーシアムに加⼊、Fog標準化に協⼒ • OpenFogコンソーシアムに参加 (2016) • Fogコンピューティングのアー キテクチャ議論等に参加 • テストベッド活動などにも協⼒ 31

Fogコンピューティングとは︖ エッジからFogへ • OpenFog Consortium作成資料より 32

Fogコンピューティング （イメージ） • OpenFog Reference Architectureより 33

Fogコンピューティング （イメージ） • OpenFog Reference Architectureより 34

Fogコンピューティング実現に向けたさくらでの取り組み • さくら・⽇⽴製作所でのFogコンピューティング実現に向けた取り組み 35 3. Fogコンピューティングテストベッド テストベッドシステムの設計：アーキテクチャ 2021/03/19 さくらインターネット / ⽇⽴製作所 7 エッジノード エンドデバイス クラウド （親ノード） NGSI （⼦ノード） 独⾃⽅式可 （⼦ノード） （親ノード） 管理機能 セキュリティ 機能 • クラウド上のノードを「親ノー ド」，エッジやエンドのノードを 「⼦ノード」とする階層構造 • エッジでも親ノードになってよい（そ の場合親ノード兼⼦ノード） • 親ノードはサーバ（待受機能）を持つ • エッジ間接続を実装するためにはエッ ジに親ノード機能が必要 • 管理機能，セキュリティ機能はコ ントローラ相当機能をクラウド側 に持つ

端末とコンピューティングの関係、まとめ • 端末とサーバの1:1関係を拡張しn:n、n:n:nに広げていく （ことを⽬指す）のがFogコンピューティング • Beyond 5G検討で検討されている内容にもFogコンピュー ティング的要素が含まれる（と考える） • さくらインターネットはかなり初期からFogコンピュー ティングの検討（OpenFogコンソ）に参加 • 標準化、実装は余り進んでいない • 研究レベルの取り組みをすすめる 36

Elixirによる、IoT・エッジ・クラウドシームレス接続環境の実現 エッジ・Fog要素を取り込んだBeyond5Gシステムを、関数型⾔語Elixirを⽤いて構築 • これまでの検討で得られた知⾒を、要件として反映 • ノード間通信⽅式にFIWARE(NGSI)を考慮する、等 37 関数型パラダイムで実現するB5G時代の 資源透過型広域分散コンピューティング環境 ︓最適配分アルゴリズム ︓IoTノードの計算資源 ︓資源透過型の分散処理プラットフォーム ① ︓IoTノードの能率的な実⾏環境 ② ︓計算資源配分の決定⼿法 ③ ︓実証評価向けアプリケーション ④ ︓透過型分散プラットフォーム ︓BEAM（Elixir処理系） MEC BEAM クラウド BEAM エッジ BEAM 最適配分アルゴリズム 透過型分散プラットフォーム BEAM システム開発者 デプロイされ るコード ① ③ ② ③ ③ ❤ 評価アプリ ❤ 評価アプリ ④ ④ ❤ 評価アプリ ④ ② ② ❤ 評価アプリ ④ ② ② ② ②

Elixirによる、IoT・エッジ・クラウドシームレス接続環境の実現 • Elixir/Nerves⽤クラウド環境 • クラウドから、エンド・エッジデバイスに向けてFirmware導⼊、状 態監視、ログ閲覧、リモートログインができる • サーバサイドサービス(Phoenixアプリ)も実⾏できる • Fog的な多段のシステムを構築可能 38 VM Hardware Hardware App OS Hardware エッジノード クラウド (x86) Hypervisor OS OS Mgr. NervesHub (⾃前) BEAM App App BEAM OTAアップデート BEAM SSHd SSH リモートトンネル Hardware App エンドデバイス OS BEAM Linux OS(汎⽤) Elixirプロセス OS Linux OS (Buildroot) BEAM Erlang仮想マシン

⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング • 端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会（FIWARE） • まとめ 39

なぜ、IoT/CPSやデータ流通（FIWARE）に注⽬するのか • MECは、（採算性のある）アプリケーションが⾒い出せず、現 実的な普及には疑問符がついている状態 • 社会に溶け込むコンピューティングとは、「⼈」「⼈の操作す る端末」を起点にするのではなく、環境・現場に備え付けられ たシステムが縦横に連携して⼈間をサポートするシステム • = IoT / CPS(Cyber Physical System) / ユビキタス︖ / アンビエン ト︖ / DX...? • （さくらとしては、エッジ/MEC、社会に溶け込むコンピュー ティング実現を推進していきたい • 各現場でデータを保持し、それを相互に接続して（Fog的な） システムを構築するのがスマートシティ、そしてその実現⼿段 がデータ流通⽅式 • IoT/CPS、データ流通の普及を推進する技術に注⽬・アシスト 40

エッジ・FogとIoTの標準化進展状況 (1) Industrial Internet of Things Distributed Computing in the Edge Technical Report が出た。（2020/10/20） 41 h"ps://www.iiconsor9um.org/press-room/10-20-20.htm

エッジ・FogとIoTの標準化進展状況 (2) OGC (Open Geospatial Consortium) SensorThings API https://www.ogc.org/standards/sensorthings 42 OMG (Object Management Group) Simplified Electronic Notation for Sensor Reporting https://www.omg.org/spec/SENSR/

なぜ、FIWAREに注⽬するのか • IoT/CPSの実施形態として、個別の事例を超えた形で 先⾏しているのがスマートシティ • ノード間の連携のための標準プロトコル・データモデ ルとして、実⽤化フェーズに⼊っている • FogやIoTの標準化なども⾒ているが、まだまだ。 • FIWAREは、データを集め/利⽤し/連携させることを ⽬的として開発された集約型アーキテクチャであり、 分散システムとして利⽤するのには向いていない。 • ではなぜ注⽬︖ →現状それしか無いから。 43

スマートシティとは︖ （イメージ）都市に関係するサービスが連携して賢くなる 44 スマートシティ官⺠連携プラットフォーム（国⼟交通省） https://www.mlit.go.jp/scpf/

スマートシティとは︖ （イメージ）都市に関係するサービスが連携して賢くなる 45 スマートシティ（Smart City）とは （IoT News） https://iotnews.jp/archives/1218

都市OS → FIWARE • 同じようなシステムを重複開発したくない • 相互接続を実現したい • ソフトウェア部品（アプリ・サービス）を使い回したい • 知⾒・ノウハウを共有したい 46 都市OSという概念を共通基盤システムとして実装 それがFIWARE（ファイウェア） 共通基盤 OS OS OS 共通基盤 共通基盤 FIWARE（ファイウェア） • 共通プラットフォーム • 標準API、プロトコル • 標準データモデル • サービス部品 アプリ サービス アプリ サービス アプリ サービス

FIWAREの概要 FIWARE : スマートソリューションの開発促進のための オープンソースプラットフォーム部品群のフレームワーク 47 https://www.fiware.org/developers/catalogue/ （同時に、それを開発・推進する組織（FIWARE Foundation）の名前でもある） データを交換する基盤となる コンテキストブローカー （サーバ） 様々な（IoT）デバイス等と データをやり取りするための インターフェース部品 データを蓄積・分析・可視化 するサービス部品 https://www.fiware.org/

FIWAREによるスマートシティ システム構築 • データをやり取りする中⼼となるコンテキストブローカーを⽴てる • IoTデバイスや他のサービスとデータをやり取り（変換）するインタフェー ス部品を動かす • データを利⽤する（蓄積・可視化・分析）アプリケーションを動かす • データのやり取りには標準プロトコルNGSI :Next Generation Service Interfaces を利⽤する • データの表現（セマンティクス）にFIWARE Data Modelsを利⽤する 48 共通基盤 OS OS OS 共通基盤 共通基盤 アプリ サービス アプリ サービス アプリ サービス あるスマートシティ的 サービス FIWAREサービス部品を利⽤して構築 通信プロトコル︓ NGSI 共通データモデル︓ FIWARE Data Models

FIWAREのサービス部品（例） コア・コンポーネント • Context Broker : コンテキストブローカー、データを中継・保存 • STH︓ データの蓄積（短期主体） • Cygnus︓ データ蓄積（外部DBとのIF部品） • Draco︓ データ蓄積（外部DBとのIF部品、GUIベース） • QuantumLeap︓ データ蓄積（外部DBとのIF部品） インタフェース部品 • IoT Agent︓ UL2など別プロトコルとNGSIを相互変換 アプリ・サービス • Wirecloud︓ データ可視化（GUI、ノーコードタイプ） • Grafana︓ データ可視化 • CKAN︓ データカタログ • Knowage︓ BIツール • Node-Red︓ プログラム環境 管理ツール • Keyrock︓ 認証部品 49

サービス部品例 • いずれも、NGSIでContextBrokerからデータを取得できる 50 h"ps://www.knowage-suite.com/site/resources/knowage-cockpits/ https://knowage.readthedocs.io/en/latest/user/NGSI/README/index.html Knowage Wirecloud Node-Red

【解説】データモデルの構造（2/3） 51 データ流通実証実験資料（さくら・NEC）より引⽤ 10 © NEC Corporation 2019 NGSIデータモデル モノ・コトを Entity – Attributes – Metadata のデータ構造で表現 Attributes • Name • Type • Value Entity • EntityId • EntityType 1 n “has” Metadata • Name • Type • Value 1 n “has”

【解説】データモデルの構造（3/3） 52 データ流通実証実験資料（さくら・NEC）より引⽤ 11 © NEC Corporation 2019 コンテキスト・データのJSON表現例 id : P-9073-K type : Car name : speed type: Number value : 112 name : accuracy type: Number value : 5 name : timestamp type: DateTime value : 2017…… Entity Attributes Metadata Metadata ※NGSIv1のJSON表現 { "id": "P-9073-K", "type": "Car", "speed": { "type": "Number", "value": 112, "metadata": { "accuracy": { "type": "Number", "value": 5 }, "timestamp":{ "type": "DateTime", "value": "2017-10- 14T07:21:24.238Z" } } } }

【解説】FIWARE Data Models 53 データ流通実証実験資料（さくら・NEC）より引⽤ 12 © NEC Corporation 2019 FIWARE Data Models “Internet of Things”（IoT）分野で調和の取れたスキーマを作成する ために schema.org の設計原則とワークフローを採用 • IoTおよび非IoTアプリケーションを橋渡しするセマンティック相互運用性の実現を目指す アラーム Point of Interest (POI) デバイス 廃棄物管理 Point of Interest (POI) 駐車場 運輸・交通 市政課題の追跡 管理（Open311互換） 公園、庭園 環境 街灯 天候 各種指標

NGSIの通信⽅式（概要） 出版-購読型（Pub/Sub型）通信モデル • データ送信ノードは、データをContext Brokerに送信（Publish） • データ受信ノードは、予めデータ購読（Subscribe）を申し込んでおき、ヒットしたデータを Context Brokerから受信 • 受信ノードは取得（Pull）も可能 54 データの送信 （Publish） データの受信 （Subscribe/Push） データの取得 （Pull） 送信ノード Context Broker 送信ノード Context Broker 受信ノード 送信ノード Context Broker 受信ノード ⽣成 / 更新 HTTP POST/PUT データ JSON ⽣成 / 更新 HTTP POST/PUT 通知（更新） HTTP POST/PUT Subscribe設定 HTTP POST PublishとSubscribe/Pushの図では、HTTPのレスポンスは省略 取得要求 HTTP GET 通知（更新） HTTP Response

データ流通実証実験（さくら・NEC） • FIWARE環境をPaaSとして構築したもの • データ可視化ツールWirecloudが使える • ホームページから利⽤登録申請すると発⾏されるIDでログインして使う • お試しオープンデータ登録済みで利⽤できる • ドキュメント整備、コミュニティ掲⽰板あり 55 Context Broker Linux / VM Wirecloud アプリ サービス さくらのクラウド 実証実験PaaS環境 ⾃分で⽤意した IoT機器 ⾃分で作成した サービス どういうことができるの︖ • オープンデータの可視化 • ⾃前IoTデバイスのデータの可視化

センサデータの登録 （1/3） • Raspberry PiのセンサデータをContext Brokerに送る • センサデータを取得してNGSIで送信するサンプルコードあり • https://github.com/sakura-internet/fiware-ngsi 56 pi@raspberrypi:~/demo $ git clone h

センサデータの確認 (Wirecloud) 別途作っておいたダッシュボード画⾯で、登録データを取得・確認できる 57

API公開データのFIWARE基盤(Context Broker)への登録 • APIが公開されているものであれば、そこからデータを取得して、 Context Brokerに登録できる • ⼀例として、SwitchBotのデータをAPIで取得 58 import json import requests def readData(): header = {"Authoriza@on": ”xxxx.xxxxxx......"} response = requests.get("hFps://api.switch-bot.com/v1.0/devices", headers=header) devices = json.loads(response.text) #print(devices) bots_id = [device["deviceId"] for device in devices['body']['deviceList'] if "Meter" == device["deviceType"]] #for bot_id in bots_id: response = requests.get("hFps://api.switch-bot.com/v1.0/devices/" + bots_id[0] + "/status", headers=header) bot = json.loads(response.text) #print(bot) temperature = bot['body']['temperature'] humidity = bot['body']['humidity'] value = {"temperature": temperature, "humidity":humidity} return(value) #print("bot id (" + bot_id + ") power : " + power) if __name__ == '__main__': print(readData()) SwitchBot 温湿度計 https://www.switchbot.jp/ Context Broker Linux / VM Wirecloud さくらのクラウド 実証実験PaaS環境 ⾃分で⽤意した IoT機器 SwitchBot サービスAPI SwitchBot温湿度計 のデータを取得 NGSIで データ 登録

データから現場への働きかけ事例 • CO2センサのデータを監視し、1000ppmを超えている 場合に、Slackに通知/スマートスピーカーで⾳声通知 59 Context Broker さくらのクラウド 現場（FGN） CO2センサ 閾値 判定 AWS (Lambda) スマートスピーカー

FIWARE の価値 • さくらでは（NECと共同で）、FIWAREによるデータ流通実証実験を４年間 実施した。その経験からわかったこと（概要）は以下。 • FIWAREの価値とは、 • スマートシティ（システム）を実現する際に、ソフトウェアを再開発しなくて済む。 • 複数のシステムを連携させられる。そのときにデータ・プロトコルの共通化が図れ る。 • 2022年の現時点では、 • スマートシティ（システム）実装の際にOSSとして使われるようになってきている。 • 可視化事例は増加。システム間での連携、データ流通の実現（特に組織間）には遠 い。 • ソフトウェアとしてのFIWAREは、クラウド集約型アーキであり、分散型シ ステムへの展開はこれから。 • Kubenetesとの組み合わせなど、検討は徐々に出てきている。 60

⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング • 端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会（FIWARE） • まとめ 61

まとめ • 将来的にはコンピューティングリソースは、より社会・⽣活に溶け込んでいく という想定のもとに超個体型データセンター構想を提唱。 • 社会に溶け込むコンピューティング実現のために、ボトムアップ型アプローチ だけでなく、トップダウン型（ビジョン思考）アプローチで以下のような既存 のアーキテクチャを変更していく取り組みを実施。 • MEC/エッジコンピューティングなどによるネットワーク構造の変化 • 端末とコンピューティングリソース（サーバ）の関係の変化（Fogコンピューティング) • IoTやデータのプラットフォームの構築・普及（Elixir/NervesなどのIoT実装, FIWARE） • クラウド事業者だけでできることには限りがあり、様々なステークホルダーと お話をしていく。 • 通信キャリアやネットワーク事業者 • 社会に溶け込むシステム（IoT/CPS/スマートシティ）を作っていく⽅々 • また研究フェーズのものは、アカデミー領域 および官領域でも貢献を⽬指す。 • これらの皆様と将来のアーキテクチャ変更に向けた議論ができるように、検 討・研究推進と認知拡⼤に努めたい。 62

謝辞 • 本研究成果の⼀部は、国⽴研究開発法⼈情報通信研究 機構の委託研究（04001）により得られたものです。 63

以下、参考資料 64

広がるエッジコンピューティングの概念 ※ Z. Zhou et al.: Edge Intelligence: Paving the Last Mile of Artificial Intelligence With Edge computing, Proceedings of the IEEE, Vol. 107, 1738 2019. 65 どれが正しいエッジコンピューティング、どれが偽物、というものではない。 対象としているエッジコンピューティングがどのタイプかを意識しないと、議論がかみ合わないので注 意。 センサ収容、スモー ルエッジタイプ エッジAIタイプ ⾃動⾞(V2X) タイプ Micro-DataCenterタイプ

エッジコンピューティングの特徴 66 現場内での⾼速なやりとり クラウド 端末 端末 • サーバの⽤意、拡張が簡単 • ⼤パワー・⼤容量を使える • 低コスト • 仮想化技術 • 設備を⼀括して⽤意 • 空間・電⼒に余裕のある場所 ＋ ・低遅延で使える ・エッジ内での共有がしやすい ・通信費が下がる ・利⽤者の近傍に設置 あとからゆっくり ⼤規模処理 外に出して良い情報だけに フィルタ、加⼯ 今だけココだけ、 を素早く処理 特徴（メリット） その理由 クラウド エッジ

エッジコンピューティングの想定ユースケース エッジコンピューティングの特徴である、 • 低遅延（速い応答速度） • 現場内での情報共有 • 上流（クラウド）との通信量の削減 を活かせるアプリケーションの想定として以下等がある。 67 • CDN（コンテンツ・デリバリ・ネットワーク） • DR（ディザスタリカバリ） • eスポーツ（イベント、ストリーミング） • AR/VR、画像・⾳声認識 • コネクティッドカー • ⾦融取引 • イベント等での多視点共有システム 等

エッジコンピューティングの想定ユースケース(1) • ゲーム（e-sports） • 専⽤会場などが設⽴され始めている • ゲーム⾃体はローカルPCで実⾏する • プレイヤー間での連携のためのサーバ • リアルタイム性を確保するため、データ通信、システムデザインに相当の⼯夫（の模様） • エッジで収容することに合理性がある。が、システムアーキテクチャから⾒直す必要があ る（かも）、ゲームメーカーとの協調が必要。具体的なサービス形態を設計するのはまだ 難しい。 68 h"ps://esports-world.jp/column/1702 https://weekly.ascii.jp/elem/000/001/763/1763144/ ゲーム内の通信処理 クラウド 端末 全国ランキング など 会場内でのゲーム プレイ内容の統合 e-sport会場 想定されるエッジ適⽤構成

エッジコンピューティングの想定ユースケース(2) • ゲーム（ストリーミング） • Googleが「Stadia」をスタート（2019年11⽉22⽇）→開発を⼤幅縮⼩(2021年2⽉) • nVidiaはAU/Softbankと組んで「GeForce Now」をスタート（2020年6⽉） • Microsoftは「Project xCloud」（2020年9⽉サービスin予定→2021年10⽉サービスin） • SONY「PlayStation Now」は2015年9⽉から • （「Apple Arcade」 （2019年9⽉）はダウンロード型） • Google/Stadiaはゲームビジネスの経験が少なく失敗した（模様）→新アーキを模索中︖ • GeForce Nowは携帯網の出⼝すぐにセンターを設置している（模様）でエッジコンピュー ティング形態 69 h"ps://www.itmedia.co.jp/pcuser/arMcles/1911/24/news009.html https://www.nvidia.com/ja-jp/geforce-now/

エッジコンピューティングの想定ユースケース(2)-2 GeForce Nowの（想定される）構成 70 地域IP網 =フレッツ網 コア網＝ インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 （有線）キャリアネットワーク 携帯ネットワーク 携帯網（au/softbank）からそこそこ速い、それ以外からもそれなりに速い、を実 現。

エッジコンピューティングの想定ユースケース(2)-2 GeForce Nowの（想定される）構成 71 https://xtech.nikkei.com/atcl/nxt/column/18/00001/04399/

エッジコンピューティングの想定ユースケース(3) • Connected Car • Cellular V2Xという技術が 注⽬を集めている • ⾞が周囲と連携するための 技術 • LTE/5Gの技術をベースに しながら、各種V2Xを実現 する • V2Nはクラウド、V2I/I2V がエッジに相当（Road Side Unit =RSUと呼ぶこ とが⼀般的） 72 h"ps://www.n"docomo.co.jp/binary/pdf/corporate/technology/ rd/technical_journal/bn/vol27_4/vol27_4_006jp.pdf V2Xの各形態 • ⼤量のインフラを打つ必要があるため、参⼊しずらい 【参考】 全国の信号機数︓208,251(2018年、警察庁資料) 全国の電柱の本数︓3578万本(2016年、国⼟交通省資料)

エッジコンピューティングの想定ユースケース(4) • エッジでの画像処理（センサのエッジ収容） • 現場で低スペックなデバイス（センサ）で取得したデータを エッジノードに送りデータ処理し、その結果を現場に返す。 73 “Astraea: Deploy AI Services at the Edge in Elegant Ways” Zhe Fu, Jingyu Yang, Changming Bai, Xiao Chen, Cun Zhang, Yanlin Zhang and Dongsheng Wang h"ps://conferences.computer.org/edge /2020/program/

エッジコンピューティングの想定ユースケース(5) • エッジAI : エンドデバイス⾃⾝で画像処理等する • 解析した結果をクラウド側に送信して利⽤する（スタンドアローンな系ではない） • 学習モデルを⽣成するのにクラウドを利⽤する形態が多い • Federated Learning(分散機械学習)など研究盛んに 74 h"ps://www.itmedia.co.jp/news/ ar9cles/2003/19/news050.html この図では、「エッジ側」がエンドデバイスなのか そうでないのかが、曖昧に⾒える。 （記事本⽂内ではきちんと解説されている。） エッジAIデバイス https://www.nvidia.com/ja- jp/autonomous-machines/embedded- systems/jetson-nano/ Jetson-Nano (NVIDIA) エッジAIソリューション h"ps://actcast.io/ja/ Actcast

スマートシティとは︖ スマートシティ︓技術で都市を効率化すること︖ 75 スマートシティは、先進的技術の活⽤により、都市や地域の機能やサービス を効率化・⾼度化し、各種の課題の解決を図るとともに、快適性や利便性を 含めた新たな価値を創出する取組であり、Society 5.0の先⾏的な実現の場 といえます。 スマートシティ官⺠連携プラットフォーム（国⼟交通省） https://www.mlit.go.jp/scpf/ スマートシティ（Smart City）とは （IoT News） https://iotnews.jp/archives/1218 スマートシティとは、IoT（Internet of Things︓モノのインターネット） の先端技術を⽤いて、基礎インフラと⽣活インフラ・サービスを効率的に管 理・運営し、環境に配慮しながら、⼈々の⽣活の質を⾼め、継続的な経済発 展を⽬的とした新しい都市のことだ。 スマートシティとは、どのような概念の取り組みなのでしょうか。国⼟交 通省は「都市が抱える諸問題に対して、ICT等の新技術を活⽤しつつ、マネ ジメント（計画・整備・管理・運営）が⾏われ、全体最適化が図られる持 続可能な都市または地区」と定義しています。 スマートシティとは︖⼀⼈ひとりの⽣活様式にあった持続可能な都市づくり （NEC business leaders square wisdom） https://wisdom.nec.com/ja/feature/smartcity/2021011501/index.html （強調は本資料 著者による） →IoT、エッジ、Fogなどをすべて⽤いる総合領域

スマートシティの取り組みの例 オープンデータたかまつ https://opendata-portal.smartcity-takamatsu.jp/ 76 ⾏政がオープンデータを公開し、 それを活⽤しようとする先進事例

スマートシティの取り組みの例 My City Report https://www.mycityreport.jp/ 77 市⺠参加型の⾏政課題共有サービス。 「ちばレポ」を発展させたもの。

NYC311 Open311の先駆けになったNew York市の市⺠参加型サービス 78 さらに 2009 年 6 ⽉には、NYC311 は市のホームページに「311 オンライン」を⽴ち上げました。これによ りユーザーは市政情報を得たり、問題を報告したり、市に問合せて依頼した案件の進捗状況を確認したりする ことができるようになりました。 2011年 2 ⽉、ユーザーが NYC311 と相⽅向でやり取りをすることができる NYC311 報告ツールが 誕⽣しました。ユーザーは、311 に届いた問合せに対し独⾃の回答を投稿する ことができます。ま た⾃治区や郵便番号、⾃治会レベルまで絞って情報を閲覧したり、過去 の情報を時系列的に検索する こともできます。 「NYC311」設⽴から 10 年の歩み http://www.clair.or.jp/j/forum/c_mailmagazine/201306_2/2-1.pdf 不確か

【解説】データモデルの構造（1/3） 79 9 © NEC Corporation 2019 エンティティとコンテキスト情報 ・エンティティとは、実世界におけるモノ・コトの表現 ・コンテキスト情報とは、エンティティを特徴付ける属性値 バス • 位置情報 • 乗客数 • ドライバ • ナンバープレート 市民 • 名前 • 誕生日 • 好み • ロケーション • ToDoリスト 店舗 • ロケーション • 店舗名 • フランチャイズ • 販売する商品 実世界のモノ・コト エンティティ コンテキスト 情報 データ流通実証実験資料（さくら・NEC）より引⽤

Wirecloudでのデータ可視化の例 • センサデータの可視化事例 • センサデバイスのデータ（CO2）をContext Brokerに送信 • 複数地点分まとめてパネル表⽰ 80

Wirecloudの可視化画⾯（作り⽅） • Wirecloudは、機能部品を組み合わせてロジックを作 成する • この例↓では、データ取得部品、条件判断部品、表⽰部品の 組み合わせ 81

センサデータの登録 （2/3） 82 #!/usr/bin/python #-*-coding: u\-8-*- import fiwareorion import requests import json import dateFme import logging import bme280_custom ### センサーデータを取得 ### sensor_data = bme280_custom.readData() ### アクセス先およびデータ定義 ### USERNAME="user002@fiware-testbed.jp" PASSWORD=”xyzabc12345" CBHOST="h

センサデータの登録 （3/3） 83 pi@raspberrypi:~/demo/fiware-ngsi $ python ./senddata.py pi@raspberrypi:~/demo/fiware-ngsi $ senddata.pyを実⾏ ### リクエスト送信パート ### try: ret_fi1 = orion.registerEnFFes(body) #ret_fi2 = orion.updateEnFFes(bodypart) #ret_fi3 = orion.deleteEnFFes(data_id) #ret_fi4 = orion.getEnFFes() #ret_fi5 = orion.getTargetEnFty(data_id) except requests.excepFons.RequestExcepFon as e: print('request failed(fiware): ', e) senddata.pyを編集 初回だけ、registerEntities()を実⾏、 2回⽬以降はupdateEntities()にする なにも出⼒されないが、OK!