スマートファクトリーを支える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. ありがとうございました!!