スマートファクトリーを支えるIoTインフラをつくった話

1. スマートファクトリーを⽀えるIoTインフラをつくった話【ヒカ☆ラボ】AWSによる⼤規模IoTプラットフォーム構築の裏側をお話しします！ 2017/3/2 Future Architect Inc, Keigo Suda

2. IIoTをクラウドで実現するための勘所 ü どのようなポイントがあったか ü どのようにそのポイントに対応したか IoTインフラをAWSでどのように構築したかという話 ※資料は終了後公開します話したいけど我慢すること ü IoT界隈にはびこるバズワードの追求(⼀部あり) ü 設備周辺の濃い話 ü チューニング周りの話

3. ＊ Technology Innovation Group スペシャリスト＊今の専⾨ -> ⼤きいデータを扱う領域(インフラ〜アプリ) ＊最近はKafkaとストリーム処理エンジンの諸々とECS 須⽥桂伍 (すだけいご) @keigodasu

4. もくじ l IoTインフラ全体の話 l 主な処理の話 l まとめ

5. IoTインフラ全体の話

6. IoTインフラ？ l ⼯場内の各センサーデータを収集・加⼯・蓄積・分析するための基盤 l IoTといってもいわゆるIIoT(Industrial Internet of Things) l 世界中にある製造拠点を対象に展開収集加⼯蓄積分析

7. Controlling

8. Monitoring

9. Full Automation

10. IIoTの魅⼒(つらみ) l 既存システムとの連携は・・・不可避 l 既にコアを担う別システム(パッケージ等)があることが多く、特に設備との連携のためにはどうしても既存システム群とのやりとりは発⽣ l 独⾃プロトコルやメーカーの縛りがまだまだ多い l つなげる機器はIoTで連想するような機器じゃない(ラズパイ等)。データを取得するだけでも、同⼀メーカの製品ラインを揃える必要があったり、IoTブームとはいえここはオープンさが少ない。 l SDK⼊らない・・・ l ノウハウがほぼない(公開されてない) l 上記の理由もあるのか、なかなか事例がなく、ましてやWEBの世界からのアプローチ事例など壊滅的な感じ(メーカーの製品導⼊事例とかはある) l そもそも⼟台ない l そもそもデータが取れてない、集まっていない、⽂化の下地もないことの⽅が多い

11. IIoTの魅⼒(つらみ) l 既存システムとの連携は・・・不可避 l 既にコアを担う別システム(パッケージ等)があることが多く、特に設備との連携のためにはどうしても既存システム群とのやりとりは発⽣ l 独⾃プロトコルやメーカーの縛りがまだまだ多い l つなげる機器はIoTで連想するような機器じゃない(ラズパイ等)。データを取得するだけでも、同⼀メーカの製品ラインを揃える必要があったり、IoTブームとはいえここはオープンさが少ない。 l SDK⼊らない・・・ l ノウハウがほぼない(公開されてない) l 上記の理由もあるのか、なかなか事例がなく、ましてやWEBの世界からのアプローチ事例など壊滅的な感じ(メーカーの製品導⼊事例とかはある) l そもそも⼟台ない l そもそもデータが取れてない、集まっていない、⽂化の下地もないことの⽅が多いデータの収集をするまでが⼀つの⼭場収集できてしまえばいつもの実装

12. シケーンサー(PLC)

13. IoTインフラの概要収集加⼯蓄積分析連携既存システム API API API API

14. システムの全体 Availability Zone(Active) Availability Zone(Stanby) データ登録処理チェック設備状態取得サービス監視 MirrorMaker EMRFS バッチ処理永続ストアストリーム処理メッセージングメタデータ管理メッセージング EC2 SM リリース監視オンプレ管理簡易集計 DWH/BI既存システム設備指⽰エッジサーバ既存システム・・・プロビジョニング

15. あれ？

16. あれあれ?(迫真)

17. そもそもなんでKafka on AWS l プラットフォーム⾮依存 l 海外への展開も考慮し、その都度適切なクラウドプラットフォームを選べるようにしたかった l 肝であるプラットフォームの⼊り⼝はつくりこみたかった l 今回の仕組み上、⼊り⼝兼プラットフォーム全体のバッファであるメッセージングは⾊々とつくり込みたかったため、挙動やクセも含め中⾝のわかるプロダクトが適していた l 機密なデータも扱うのでVPC(閉域に閉じたかった) l 製造に必要な機密情報もやりとりされるため閉域網内でやりとりしたい・蓄積したい

18. Producer処理はAPIとして公開 l 拠点にあるエッジサーバはライトに保ちたかった l ⼯場ではそもそもサーバをメンテナンスできる⼈も少ない l 極⼒は単純な右から左の処理にとどめる l プラットフォームの⼊り⼝としてKafkaを直接さらすのはいろいろつらい l セキュリティまわり(認証認可など) l 拠点側ではとりあえずデータを投げて、プラットフォーム側のロジックで救う l OSSのツールはどれも結構機能が多すぎたためAPIは⾃作 l ⾔語はGoでフレームワークはecho、Kafkaのクライアントはsaramaを利⽤

19. 主な処理の話

20. ⼯場とクラウド間での主な連携 l ⼯場からクラウドへの連携 l 設備稼働中に発⽣するセンサデータ連携 l 設備稼働状況の通知連携 l 他システム・クラウドから⼯場への連携 l 設備への設備コンフィグの連携 l 現場へのアラート・通知 l 管理機能 l クラウドからエッジサーバへの管理系通信 l クラウドでの設備マスタ情報管理

21. エッジコンピューティング(以下エッジ)について l データ発⽣源のデバイス近くに配置し、クラウドまでの中間処理や即時応答が必要な処理を⾏う(定義の⼀例) http://www.ntt.co.jp/news2014/1401/140123a.html

22. フォグコンピューティング(以下フォグ)ってのもあって・・・ l フォグコンピューティングはCiscoが提唱した定義 l エッジを包含する概念(エッジはエンドポイントだけが対象) l フォグはクラウド側の技術をエッジに落とし込みつつリアルタイムに分散処理することを⽬指す l この定義からするとLambda@Edge、Greengrassはフォグっぽい? l Lambda@Edge、Greengrassは機能配置の透過⽣を意識している l ただの定義厨・・・

23. 今回のエッジサーバ l より堅牢に l クラウドとのネットワーク障害時においても⼯場側で必要な処理が回せる l ⾼い可⽤性と耐障害性を考慮し、複数台配備 l よりシンプルに l ⼯場側にはいつもサーバメンテができる⼈がいるとは限らない l 配置する機能数は少なく(右から左への処理)・機能配置の透過性 l より確実かつ正確にを⽬指した機能配置 l データ到達は「at least once」で確実に(エッジ側の責務) l データ処理は「exactly once」で正確に(クラウド側の責務)

24. 今回のエッジサーバ⼯場エッジサーバ#1 エッジサーバ#2 設備センサモーターシーケンサ NW/IF 同⼀データを複数台のエッジサーバへ連携いずれかのエッジサーバが必ずクラウドまでデータを届ける重複排除のロジックやエッジサーバの管理など複雑なロジックはクラウド側に寄せていく加⼯蓄積加⼯蓄積クラウドへの連携ができない場合エッジ側でデータを蓄積 l クラウド側で重複データの排除 l リーダー選出 l エッジサーバの⼀元管理

25. ⼯場とクラウド間での主な連携 l ⼯場からクラウドへの連携 l 設備稼働中に発⽣するセンサデータ連携 l 設備稼働状況の通知連携 l 他システム・クラウドから⼯場への連携 l 設備へのコンフィグの連携 l 現場へのアラート・通知 l 管理機能 l クラウドからエッジサーバへの管理系通信 l クラウドでの設備マスタ情報管理

26. 設備設備稼働データの収集⼯場からクラウド管理機能他システム・クラウドから⼯場 l MESというのがあってだな・・・ l 設備稼働データはODBC/JDBCでRDBMSへ連携する仕組み(この構成が⼀般的らしい) l いかがネックとなり、今回は別の⽅式を検討 l サポート対象DBの多くはOracleかSQL Server、最新モデルではMySQL、PostgreSQLに対応するものも l DBインサート/UPDATEが基本で、スケールに限界ガガガだし、ロケーションをまたいだデータの収集はどうしよう・・・ l 他の連携⽅法としてはFTP/SMTP/ファイルシステムマウント l 今回はFTPの機能を活⽤する⽅向で検討(メール通知をストリーム処理と呼ぶのはちと・・・) センサモーターシーケンサ NW/IF MES デーモン DB(RDBMS) エッジサーバ設備センサモーターシーケンサ NW/IF エッジサーバ FTP PUT PUT WritePolling Read PUT M E S ⽅式 F T P ⽅式

27. 設備稼働データの収集⼯場からクラウド管理機能他システム・クラウドから⼯場⼯場エッジサーバ#1 エッジサーバ#2 設備センサモーターシーケンサ NW/IF IoTプラットフォームデータ登録API チェックAPI FTP PUT FTP PUT ファイル→JSON ファイル→JSON 1.複数センサデータをまとめて FTPでファイル連携 2. ファイル配置をトリガーにファイル名のハッシュ値⽣成、データのJSON変換 3. ファイル名のハッシュ値が処理済みかを問い合わせ 4. 処理済みでなければクラウドへ連携 5.まとめて送信されたセンサデータをレコードに分割 ⑥分割したレコードをメッセージとしてProduce ⑦登録に成功したファイルのハッシュ値を処理済みとして登録

28. メッセージング〜ストアローデータ加⼯データ⼯場からクラウド管理機能他システム・クラウドから⼯場データ取得API REST SOAP REST 単純パース/PUT ⽤途別加⼯/PUT オンメモリ/通知系同⼀トピックに対し⽤途別に Streamingアプリケーションを配置⼯場A – 製品A ⼯場A – 製品B ⼯場B – 製品D ⼯場N – 製品N ・・・⼯場×製品ラインの単位でトピック作成扱うデータのまとまりとメンテナンス性トピックデータ登録API メッセージ内容をもとに適切なトピックへ振り分け永続データストアは直接触らせず APIを経由させ流量等をコントロール既存システム他アプリケーションデータ連携

29. スキーマ管理(ストリーム処理最⼤の課題) l 標準でいわんやないので、コメント出⼒機能を使って、そこでスキーマ情報をいれこむ。 :GT2K_LOG,1 :DEVICE_NUM,5 :RECORD_NUM,100 :DATE_ORDER,YYYY/MM/DD hh:mm:ss :LOCAL_TIME,GMT 00:00 :DEV_COMMENT,“論理01:butsuri01”,“論理02:butsuri02”,“論理03:butsuri03 ”,“論理04:butsuri04” 2016/10/21 14:40:16, 0, 0, 0 2016/10/21 14:40:17, 0, 0, 0 2016/10/21 14:40:18, 0, 0, 0 ・・・・コメント部分データ部分スキーマ情報は以下の2つで構成 ü 論理名: 作業者や管理者が識別し利⽤するカラム名 ü 物理名: システムが処理時に利⽤するカラム名(BI利⽤時など) 管理ルール案 ü 論理名と物理名の区切りは「:」 ü 区切り⽂字は「,」 ü 値は「”」で囲む ü 最⼤⽂字数は32⽂字(システム制約) 出⼒例運⽤⽅式

30. 件数の突合 l 簡易的なものを⼿組みで実装し、以下の件数を突合 l 拠点のエッジサーバから送信した件数 vs. ストリーム処理後の件数 l 取得した件数情報はCloudWatchのカスタムメトリクスで連携エッジサーバ集約集約データ集約データ個別データ個別データ個別データ個別データ { ・・・ total_windows: 128, total_events: 2000, event_start_timestamp: "2017-02-10T11:44:27.000+09:00", event_end_timestamp: "2017-02-10T12:01:24.000+09:00” } チェッククエリの組み⽴て処理情報の連携 (REST API) 件数チェック結果連携⼯場からクラウド管理機能他システム・クラウドから⼯場

31. 設備へのコンフィグ連携⼯場からクラウド管理機能他システム・クラウドから⼯場 l 設備で製造する対象ごとに、設備パラメータを変更する必要あり l この部分を製造指⽰データをもとに、その製造に必要なパラメータをクラウドから⼯場の設備へ反映するための処理 l 処理は確実に1回！ l コンフィグデータが変わってしまうと、製造中の製品が仕損じてしまうため、製造が開始する際の１回だけの反映処理が必要

32. ⼯場・設備への指⽰連携⼯場からクラウド管理機能他システム・クラウドから⼯場コンフィグ反映先マスタ設備コンフィグ反映API 設備センサモーターシーケンサ NW/IF エッジサーバ製造指⽰書のバーコードを読み取る指⽰書のデータをもとに必要な設備コンフィグを取得・連携 SOAP 反映先の⼯場・設備情報をコンフィグデータをもとに取得処理IDが未処理であれば設備コンフィグデータをエッジサーバへ連携設備へ反映反映が成功した処理IDを受け付け済みとして登録 l 下記の反映処理は同期で⾏われ、エラー時はクライアント側に通知

33. エッジサーバの集約管理⼯場からクラウド管理機能他システム・クラウドから⼯場 l エッジサーバは⼯場に配置されるため、オンプレ環境に該当 l EC2 System Managerでエッジサーバの集約管理(めちゃくちゃ簡単・便利)

34. まとめ

35. まとめ l 全体としての機能配置をどうするか l データ発⽣源、中間地点、クラウドでどう機能配置していくか l 機能配置の位置透過性をどうデザインしていくか l インタフェースをどうつないでいくか(インテグレーション要素濃い⽬) l 独⾃プロトコル、ツールを併⽤するのか、より汎⽤的なプロトコルを選択しつくり込むか l 既存のシステムたちとどこをハブにしてどうつないでいくか l メッセージの到達性への配慮はほどほどに l 必ず到達させる&どこかでべき等になるような処理が⼀番楽 l くじけないマインド

36. 参考 l AWSでつくるapache kafkaといろんな悩み l https://www.slideshare.net/keigosuda/awsapache-kafka

37. 泥臭いフレンズ募集中です (ヒトじゃなくてもいいです)

38. ありがとうございました!!