Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ネットワークの構造変化からIoTプラットフォームまで,社会に溶け込むコンピューティングの実現に...

 ネットワークの構造変化からIoTプラットフォームまで,社会に溶け込むコンピューティングの実現に向けた取り組みのご紹介

本資料は、電子情報通信学会NS研究会(2022年1月開催)における、招待講演「ネットワークの構造変化からIoTプラットフォームまで,社会に溶け込むコンピューティングの実現に向けた取り組みのご紹介」の発表資料です。
本資料の著作権は電子情報通信学会に帰属します。
本資料は電子情報通信学会の許諾の範囲内で著作者(菊地)が公開するものです。

さくらインターネット研究所では,コンピューティングリソースはより社会・生活に溶け込んでいくという想定のもとに超個体型データセンター構想を掲げ研究活動に取り組んでいる.社会に溶け込むコンピューティングの実現には,現状のクラウドの延長・発展だけでなく,MEC/エッジコンピューティングなどによるネットワーク構造の変化,端末とサーバの関係の変化(Fog コンピューティング),IoT やデータのプラットフォームの構築・普及(スマートシティ)など,既存のアーキテクチャを変更していく取り組みが必要であると考えられる.本講演では,これら新しいアーキテクチャ構築に向けてさくらインターネット研究所が取り組む種々の検討について紹介する.

KIKUCHI Shunsuke

January 27, 2022
Tweet

More Decks by KIKUCHI Shunsuke

Other Decks in Research

Transcript

  1. [招待講演] ネットワークの構造変化からIoTプラットフォームま で, 社会に溶け込むコンピューティングの実現に向けた 取り組みのご紹介 電⼦情報通信学会 NS研究会 2022年1⽉ 2022/01/27 Copyright(C)2022IEICE

    さくらインターネット研究所 上級研究員 菊地 俊介 さくらインターネット株式会社 本資料の著作権は電⼦情報通信学会に帰属します 信学技報, vol. 121, no. 356, NS2021-111, pp. 7-12, 2022年1⽉.
  2. 話者紹介 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
  3. ⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング •

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

    端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会(FIWARE) • まとめ 4 →何を⽬指すのか、なぜそれを⽬指すのか
  5. 超個体型データセンター コンセプト / Super Organism Data Center • 序⽂ •

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

    る場所や社会(組織)にコンピューティングリソースが溶け込んでいくこ とになる。 2. それら分散したコンピューティングリソースは、単独でコンピューティン グパワーを提供するにとどまらず、その場所や社会の要求に応じて、⾃律 的に、分散あるいは有機的に結合し、現場・クラウドそれぞれが縦横に結 びついたハイブリッド構造をとれるように機能する。 3. そのようなシステムにより実現されるものは、⼈々の⾝近に存在し、リア ルタイムかつインテリジェンスにユーザを⽀えながら、しかし同時にバッ クエンド側が有機的に結合することにより、かつてないマシンパワーとリ ソース量を動員することで現場最適かつ全体最適をも実現するSuper Organism Worldである。 4. さくらインターネット研究所はこのようなビジョンのもと、Super Organism Worldを実現する超個体型データセンターシステムやそれを統 括管理する超個体型データセンターOS等の研究開発を推進していく。 6
  7. さくらインターネット研究所 10年ビジョン(2021年版)(⼀部抜粋) 8 MEC/エッジ/ オンプレ再勃興 中規模データセンター (各政令指定都市へ) センターレス・ 分散システム 集中・分散の

    ハイブリッド ⾃動構成・ ⾃動障害検出・復旧 ⾃律動作 ⾃動機能追加・進化 クラウド・エッジ・ 階層型アーキ Fog・分散型 アーキ レイヤレス 分散アーキ データセンタートレンド 運⽤管理トレンド システムアーキトレンド 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031
  8. ⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング •

    端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会(FIWARE) • まとめ 9 →何をやっているのか
  9. (国内)ネットワークの構造 (エッジコンピューティングを理解するために)まず 前提となるネットワークとクラウドの構造を理解する 10 地域IP網 =フレッツ網 コア網= インターネット網 携帯電話網 =LTE(4G)

    クラウド クラウド クラウド ⾃営網 ネットワーク装置(ルータ) サーバ アクセス網側︓エンドユーザが居る側 クラウド側︓サーバがある側 (有線)キャリアネットワーク 携帯ネットワーク
  10. ネットワークインフラに求められる要件の変化 キーポイント︓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 ⼈の反応速度より早く反応するシステムが求められる︕
  11. エッジコンピューティングの分類 – 誰がエッジコンピューティングを作るのか(2) 14 モバイル(キャリア)ネットワーク 有線(キャリア)ネットワーク ⾃営(有線)ネットワーク RAN Mobile Backhaul

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

    ⾃営(有線)ネットワーク RAN Mobile Backhaul the Internet クラウド (⼤規模D.C.) 基地局 局舎 アクセス網 (NTT東⻄) BackBone ⾃営網 ⾃営D.C. Local5G デバイス 3種のアクセスネットワーク MEC型 IIC型(OT発展型) クラウド延伸型 MEC : Multi-Access Edge Computing →携帯キャリアがすすめるエッジコンピューティング IIC : Industrial Internet Consortium →産業機器業界がすすめるエッジコンピューティング クラウド事業者がすすめる エッジコンピューティング
  13. エッジコンピューティングの内部構成、その要件 エッジコンピューティングの(究極の)⽬標 • 現場での制限なしのコンピューティングの利⽤、その環境の構築 • コンピューティングおよびネットワーク利⽤の最適化(地産地消化) エッジコンピューティングの(より現実的な)⽬標 • エッジとクラウドをシームレスに使えるコンピューティング環境の実現 •

    クラウド、エッジそれぞれの特徴を活かす 19 地域IP網 =フレッツ網 コア網= インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 (有線)キャリアネットワーク 携帯ネットワーク クラウドをエッジに延伸することで、 クラウドエコシステムを活かす リソース・性能を⾃由・動的に 選択・組み合わせ可能に 移動に対応する アクセスネットワークの機能を取り込む …
  14. エッジコンピューティングを実現する技術(クラウド側) 「エッジとクラウドをシームレスに使えるコンピューティング環境の実現」 に向けて • AWS WaveLength, Anthos for Telecom, Azure

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

    端末の移動をサポートするのは難しい 21 地域IP網 =フレッツ網 コア網= インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 (有線)キャリアネットワーク 携帯ネットワーク 移動に対応する アクセスネットワークの機能を取り込む …
  16. 移動への対応(1) • サーバの移動 • エンドユーザの近傍のサーバでプログラム(/ジョブ/タスク)を動かす • →(ライブ)マイグレーション、エッジデプロイ • エンドデバイスの移動 •

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

    地域IP網 =フレッツ網 コア網= インターネット網 携帯電話網 ⾃営網 オンプレ設備 (有線)キャリアネットワーク 携帯ネットワーク • 現状では、携帯網・キャリア網(地域IP網)から外に出ていく経路は1通りしかない。 • →5Gでは複数の外部接続をサポートする。 • →キャリアネットワークでは網設計次第(PPPoE, IPoEのGWをどこに設置するか)。 • 端末側で、通信先サーバを選択しなければならなくなる可能性も。 • ...監視︖ →今後の業界を巻き込んだ検討が求められる。 ︖
  18. エッジコンピューティングの分類 24 モバイル(キャリア)ネットワーク 有線(キャリア)ネットワーク ⾃営(有線)ネットワーク RAN Mobile Backhaul the Internet

    クラウド (⼤規模D.C.) 基地局 局舎 アクセス網 (NTT東⻄) BackBone ⾃営網 ⾃営D.C. Local5G デバイス 3種のアクセスネットワーク MEC型 IIC型(OT発展型) クラウド延伸型 MEC : Multi-Access Edge Computing →携帯キャリアがすすめるエッジコンピューティング IIC : Industrial Internet Consortium →産業機器業界がすすめるエッジコンピューティング クラウド事業者がすすめる エッジコンピューティング 誰がエッジサーバを⽤意するか =アクセスネットワークとの関わり⽅、から エッジコンピューティングは3種類に分類できる。 この領域(障壁)を超えてエッジネットワーク を相互接続するのは⾄難の業
  19. エッジコンピューティングで求められるネットワーク構造の変化 25 エッジ時代のインターネットインフラに向けて • エッジを意識したクラウド(サーバ)技術の拡張 • エッジを意識したアプリ・プログラム技術の拡張 • 地域での横のつながり、地域ネットワークの(再)構築 地域IP網

    =フレッツ網 コア網= インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 (有線)キャリアネットワーク 携帯ネットワーク どこにでもコンピューティングリソースがあり、⾃在に利⽤できるような時代に向け て、インターネットインフラの⾰新が進む(ことを期待)
  20. ネットワークの構造とその変化、まとめ • エッジコンピューティングは、アクセス網により3つに分類される、 と考える • MEC型 • クラウド延伸型 • IIC型(OT発展型)

    • モバイルキャリアとメガクラウドベンダが⼿を組んで、MEC型/クラウド延 伸型は融合が進んでいる • エッジコンピューティングを活かすキラーアプリはまだ⾒いだされ ていない、と考える • エッジコンピューティングの(真の)メリットとは、アクセスネッ トワークとの融合や端末移動への対応、と考える • 技術的にも網構造(ビジネス)的にも、まだ真価を発揮できる状態 ではない • 業界としての議論なども必要、さくらとしても積極的に貢献してい きたい 27
  21. ⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング •

    端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会(FIWARE) • まとめ 28
  22. Fogコンピューティング = Beyond 5G ? • 総務省「 「Beyond 5G推進戦略 -6Gへのロードマップ-」の公表」に、Fogコンピューティングに

    似た考え⽅が盛り込まれている • https://www.soumu.go.jp/menu_news/s-news/01kiban09_02000364.html (別紙3より) 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活用 インクルーシブインターフェース 低消費電力半導体 注⽬ 注⽬
  23. Fogコンピューティング実現に向けたさくらでの取り組み • さくら・⽇⽴製作所でのFogコンピューティング実現に向けた取り組み 35 3. Fogコンピューティングテストベッド テストベッドシステムの設計:アーキテクチャ 2021/03/19 さくらインターネット /

    ⽇⽴製作所 7 エッジノード エンドデバイス クラウド (親ノード) NGSI (⼦ノード) 独⾃⽅式可 (⼦ノード) (親ノード) 管理機能 セキュリティ 機能 • クラウド上のノードを「親ノー ド」,エッジやエンドのノードを 「⼦ノード」とする階層構造 • エッジでも親ノードになってよい(そ の場合親ノード兼⼦ノード) • 親ノードはサーバ(待受機能)を持つ • エッジ間接続を実装するためにはエッ ジに親ノード機能が必要 • 管理機能,セキュリティ機能はコ ントローラ相当機能をクラウド側 に持つ
  24. Elixirによる、IoT・エッジ・クラウドシームレス接続環境の実現 エッジ・Fog要素を取り込んだBeyond5Gシステムを、関数型⾔語Elixirを⽤いて構築 • これまでの検討で得られた知⾒を、要件として反映 • ノード間通信⽅式にFIWARE(NGSI)を考慮する、等 37 関数型パラダイムで実現するB5G時代の 資源透過型広域分散コンピューティング環境 ︓最適配分アルゴリズム

    ︓IoTノードの計算資源 ︓資源透過型の分散処理プラットフォーム ① ︓IoTノードの能率的な実⾏環境 ② ︓計算資源配分の決定⼿法 ③ ︓実証評価向けアプリケーション ④ ︓透過型分散プラットフォーム ︓BEAM(Elixir処理系) MEC BEAM クラウド BEAM エッジ BEAM 最適配分アルゴリズム 透過型分散プラットフォーム BEAM システム開発者 デプロイされ るコード ① ③ ② ③ ③ ❤ 評価アプリ ❤ 評価アプリ ④ ④ ❤ 評価アプリ ④ ② ② ❤ 評価アプリ ④ ② ② ② ②
  25. 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仮想マシン
  26. ⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング •

    端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会(FIWARE) • まとめ 39
  27. なぜ、IoT/CPSやデータ流通(FIWARE)に注⽬するのか • MECは、(採算性のある)アプリケーションが⾒い出せず、現 実的な普及には疑問符がついている状態 • 社会に溶け込むコンピューティングとは、「⼈」「⼈の操作す る端末」を起点にするのではなく、環境・現場に備え付けられ たシステムが縦横に連携して⼈間をサポートするシステム • =

    IoT / CPS(Cyber Physical System) / ユビキタス︖ / アンビエン ト︖ / DX...? • (さくらとしては、エッジ/MEC、社会に溶け込むコンピュー ティング実現を推進していきたい • 各現場でデータを保持し、それを相互に接続して(Fog的な) システムを構築するのがスマートシティ、そしてその実現⼿段 がデータ流通⽅式 • IoT/CPS、データ流通の普及を推進する技術に注⽬・アシスト 40
  28. エッジ・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
  29. エッジ・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/
  30. なぜ、FIWAREに注⽬するのか • IoT/CPSの実施形態として、個別の事例を超えた形で 先⾏しているのがスマートシティ • ノード間の連携のための標準プロトコル・データモデ ルとして、実⽤化フェーズに⼊っている • FogやIoTの標準化なども⾒ているが、まだまだ。 •

    FIWAREは、データを集め/利⽤し/連携させることを ⽬的として開発された集約型アーキテクチャであり、 分散システムとして利⽤するのには向いていない。 • ではなぜ注⽬︖ →現状それしか無いから。 43
  31. 都市OS → FIWARE • 同じようなシステムを重複開発したくない • 相互接続を実現したい • ソフトウェア部品(アプリ・サービス)を使い回したい •

    知⾒・ノウハウを共有したい 46 都市OSという概念を共通基盤システムとして実装 それがFIWARE(ファイウェア) 共通基盤 OS OS OS 共通基盤 共通基盤 FIWARE(ファイウェア) • 共通プラットフォーム • 標準API、プロトコル • 標準データモデル • サービス部品 アプリ サービス アプリ サービス アプリ サービス
  32. FIWAREの概要 FIWARE : スマートソリューションの開発促進のための オープンソースプラットフォーム部品群のフレームワーク 47 https://www.fiware.org/developers/catalogue/ (同時に、それを開発・推進する組織(FIWARE Foundation)の名前でもある) データを交換する基盤となる

    コンテキストブローカー (サーバ) 様々な(IoT)デバイス等と データをやり取りするための インターフェース部品 データを蓄積・分析・可視化 するサービス部品 https://www.fiware.org/
  33. FIWAREによるスマートシティ システム構築 • データをやり取りする中⼼となるコンテキストブローカーを⽴てる • IoTデバイスや他のサービスとデータをやり取り(変換)するインタフェー ス部品を動かす • データを利⽤する(蓄積・可視化・分析)アプリケーションを動かす •

    データのやり取りには標準プロトコルNGSI :Next Generation Service Interfaces を利⽤する • データの表現(セマンティクス)にFIWARE Data Modelsを利⽤する 48 共通基盤 OS OS OS 共通基盤 共通基盤 アプリ サービス アプリ サービス アプリ サービス あるスマートシティ的 サービス FIWAREサービス部品を利⽤して構築 通信プロトコル︓ NGSI 共通データモデル︓ FIWARE Data Models
  34. 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
  35. 【解説】データモデルの構造(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”
  36. 【解説】データモデルの構造(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" } } } }
  37. 【解説】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互換) 公園、庭園 環境 街灯 天候 各種指標
  38. 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
  39. データ流通実証実験(さくら・NEC) • FIWARE環境をPaaSとして構築したもの • データ可視化ツールWirecloudが使える • ホームページから利⽤登録申請すると発⾏されるIDでログインして使う • お試しオープンデータ登録済みで利⽤できる •

    ドキュメント整備、コミュニティ掲⽰板あり 55 Context Broker Linux / VM Wirecloud アプリ サービス さくらのクラウド 実証実験PaaS環境 ⾃分で⽤意した IoT機器 ⾃分で作成した サービス どういうことができるの︖ • オープンデータの可視化 • ⾃前IoTデバイスのデータの可視化
  40. センサデータの登録 (1/3) • Raspberry PiのセンサデータをContext Brokerに送る • センサデータを取得してNGSIで送信するサンプルコードあり • https://github.com/sakura-internet/fiware-ngsi

    56 pi@raspberrypi:~/demo $ git clone h<ps://github.com/sakura-internet/fiware-ngsi Cloning into 'fiware-ngsi'... remote: EnumeraFng objects: 18, done. remote: CounFng objects: 100% (18/18), done. remote: Compressing objects: 100% (15/15), done. remote: Total 18 (delta 6), reused 15 (delta 3), pack-reused 0 Unpacking objects: 100% (18/18), done. pi@raspberrypi:~/demo $ cd fiware-ngsi/ pi@raspberrypi:~/demo/fiware-ngsi $ ls bme280_custom.py fiwareorion.py README.md senddata.py switchbot_getmetervalue.py pi@raspberrypi:~/demo/fiware-ngsi $ git cloneでファイルを⼊⼿ Raspberry Piと bme280 気温湿度気圧センサ
  41. 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で データ 登録
  42. FIWARE の価値 • さくらでは(NECと共同で)、FIWAREによるデータ流通実証実験を4年間 実施した。その経験からわかったこと(概要)は以下。 • FIWAREの価値とは、 • スマートシティ(システム)を実現する際に、ソフトウェアを再開発しなくて済む。 •

    複数のシステムを連携させられる。そのときにデータ・プロトコルの共通化が図れ る。 • 2022年の現時点では、 • スマートシティ(システム)実装の際にOSSとして使われるようになってきている。 • 可視化事例は増加。システム間での連携、データ流通の実現(特に組織間)には遠 い。 • ソフトウェアとしてのFIWAREは、クラウド集約型アーキであり、分散型シ ステムへの展開はこれから。 • Kubenetesとの組み合わせなど、検討は徐々に出てきている。 60
  43. ⽬次 • 「超個体型データセンター」コンセプト • 社会に溶け込むコンピューティングの実現に向けて • ネットワークの構造とその変化 • MEC/エッジコンピューティング •

    端末とコンピューティングの関係 • Fogコンピューティング • ターゲット・アプリケーション • IoT/CPS • データプラットフォームとデータ中⼼社会(FIWARE) • まとめ 61
  44. まとめ • 将来的にはコンピューティングリソースは、より社会・⽣活に溶け込んでいく という想定のもとに超個体型データセンター構想を提唱。 • 社会に溶け込むコンピューティング実現のために、ボトムアップ型アプローチ だけでなく、トップダウン型(ビジョン思考)アプローチで以下のような既存 のアーキテクチャを変更していく取り組みを実施。 • MEC/エッジコンピューティングなどによるネットワーク構造の変化

    • 端末とコンピューティングリソース(サーバ)の関係の変化(Fogコンピューティング) • IoTやデータのプラットフォームの構築・普及(Elixir/NervesなどのIoT実装, FIWARE) • クラウド事業者だけでできることには限りがあり、様々なステークホルダーと お話をしていく。 • 通信キャリアやネットワーク事業者 • 社会に溶け込むシステム(IoT/CPS/スマートシティ)を作っていく⽅々 • また研究フェーズのものは、アカデミー領域 および官領域でも貢献を⽬指す。 • これらの皆様と将来のアーキテクチャ変更に向けた議論ができるように、検 討・研究推進と認知拡⼤に努めたい。 62
  45. 広がるエッジコンピューティングの概念 ※ 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タイプ
  46. エッジコンピューティングの特徴 66 現場内での⾼速なやりとり クラウド 端末 端末 • サーバの⽤意、拡張が簡単 • ⼤パワー・⼤容量を使える

    • 低コスト • 仮想化技術 • 設備を⼀括して⽤意 • 空間・電⼒に余裕のある場所 + ・低遅延で使える ・エッジ内での共有がしやすい ・通信費が下がる ・利⽤者の近傍に設置 あとからゆっくり ⼤規模処理 外に出して良い情報だけに フィルタ、加⼯ 今だけココだけ、 を素早く処理 特徴(メリット) その理由 クラウド エッジ
  47. エッジコンピューティングの想定ユースケース エッジコンピューティングの特徴である、 • 低遅延(速い応答速度) • 現場内での情報共有 • 上流(クラウド)との通信量の削減 を活かせるアプリケーションの想定として以下等がある。 67

    • CDN(コンテンツ・デリバリ・ネットワーク) • DR(ディザスタリカバリ) • eスポーツ(イベント、ストリーミング) • AR/VR、画像・⾳声認識 • コネクティッドカー • ⾦融取引 • イベント等での多視点共有システム 等
  48. エッジコンピューティングの想定ユースケース(1) • ゲーム(e-sports) • 専⽤会場などが設⽴され始めている • ゲーム⾃体はローカルPCで実⾏する • プレイヤー間での連携のためのサーバ •

    リアルタイム性を確保するため、データ通信、システムデザインに相当の⼯夫(の模様) • エッジで収容することに合理性がある。が、システムアーキテクチャから⾒直す必要があ る(かも)、ゲームメーカーとの協調が必要。具体的なサービス形態を設計するのはまだ 難しい。 68 h"ps://esports-world.jp/column/1702 https://weekly.ascii.jp/elem/000/001/763/1763144/ ゲーム内の通信処理 クラウド 端末 全国ランキング など 会場内でのゲーム プレイ内容の統合 e-sport会場 想定されるエッジ適⽤構成
  49. エッジコンピューティングの想定ユースケース(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/
  50. エッジコンピューティングの想定ユースケース(2)-2 GeForce Nowの(想定される)構成 70 地域IP網 =フレッツ網 コア網= インターネット網 携帯電話網 クラウド

    クラウド クラウド ⾃営網 オンプレ設備 (有線)キャリアネットワーク 携帯ネットワーク 携帯網(au/softbank)からそこそこ速い、それ以外からもそれなりに速い、を実 現。
  51. エッジコンピューティングの想定ユースケース(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年、国⼟交通省資料)
  52. エッジコンピューティングの想定ユースケース(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
  53. スマートシティとは︖ スマートシティ︓技術で都市を効率化すること︖ 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などをすべて⽤いる総合領域
  54. 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 不確か
  55. 【解説】データモデルの構造(1/3) 79 9 © NEC Corporation 2019 エンティティとコンテキスト情報 ・エンティティとは、実世界におけるモノ・コトの表現 ・コンテキスト情報とは、エンティティを特徴付ける属性値

    バス • 位置情報 • 乗客数 • ドライバ • ナンバープレート 市民 • 名前 • 誕生日 • 好み • ロケーション • ToDoリスト 店舗 • ロケーション • 店舗名 • フランチャイズ • 販売する商品 実世界のモノ・コト エンティティ コンテキスト 情報 データ流通実証実験資料(さくら・NEC)より引⽤
  56. センサデータの登録 (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<ps://orion.fiware-testbed.jp" FIWARESERVICE="SAKURA" FIWARESERVICEPATH="/tokyo_office" DATATYPE="WeatherObserved" DATANAME="test002" senddata.pyのuserID/pass/データIDなどを編集 実証実験で発⾏された ID/Password テナント分離のためのテナント ID/⼩分類(任意⽂字列) FIWARE Data Modelsの気象データ、 NAME部分はユニークID
  57. センサデータの登録 (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!