teratail Report vol.1

2017/03/16

AWSによる大規模IoTプラットフォーム構築の裏側に迫る!

AWSによる大規模IoTプラットフォーム構築の裏側に迫る!

こんにちは。teratail Report編集部です。

“teratail Report”は、エンジニア一人一人の中に隠れている本当は貴重な情報を、日本中のエンジニアに届けていくメディアです。「最新技術や気になるイベント、話題の製品」についての「考え方や捉え方、経験や思想」など、Webにはなかなか出てこない有機的な情報が、まだまだ”ヒト”の中に多く潜んでいるはずです。そういった情報を、実際にお会いしたエンジニアから仕入れ、発信していきます。

記念すべき第1弾となる今回の記事では「実務におけるIoT」をテーマにお届けします。"IoT"はバズワードとして各所でよく聞くようになっただけでなく、Raspberry PiやEdisonなどをつかったワークショップやIoT勉強会などのリアルイベントも多く目にするようになり、更に盛り上がってきていると感じます。

しかし一方で「実務で使われるシステムとしてのIoTがどのように構築されているのか?」「そこにはどのような難しさが存在するのか?」「Webシステムとはどのような部分が異なるのか?」など、IoTの実際に関するリアルな声や実情は、まだ表に出ることが少ないように思います。

そこで今回teratail Report編集部は、3/2(木)渋谷ヒカリエで開催された技術イベント「ヒカ☆ラボ」(イベント詳細はこちら)に潜入。
時代に先駆け、大規模IoTシステムのプラットフォーム開発を行っているフューチャーアーキテクト社のエキスパートお2人が発表された内容を、余すところなく詳しくお伝えしていきます。「実務におけるIoT」ならではの、現場目線の面白さや難しさ、考え方や実際の解決策など、ディープな内容をお楽しみ下さい!

AWS × IoTというテーマに、120名もの参加者が駆けつけた
- AWS × IoTというテーマに、120名もの参加者が駆けつけた -

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

須田 桂伍 氏

須田 桂伍すだ けいご

フューチャーアーキテクト株式会社

2012年フューチャーアーキテクト株式会社に新卒入社。

Hadoopによる大規模バッチ処理基盤からKafkaとSpark Streaming等のストリームエンジンを使ったリアルタイムな処理基盤など、エンタープライズ領域を中心とした様々なデータ処理を得意とするデータインフラエンジニア。

  • Twitterアカウント
  • Qiitaアカウント
  • GitHubアカウント

IoTでなく、IIoT?

皆さんは、"IIoT"という言葉をご存知でしょうか?IoTに比べると、まだまだ聞き慣れないワードかもしれませんが、"Industrial IoT"の略で、製造業におけるIoTのことです。
1人目となる須田氏の講演内容は、この"IIoT"に関する事例で、スマートファクトリーを支えるIoTプラットフォームをつくったお話です。

「スマートファクトリー」とは、ドイツの工業の高度化プロジェクト「インダストリー4.0」で提案されているIoT化された工場のことです。工場内のあらゆる情報にリアルタイムでアクセスし、製造ラインで発生した問題を即座にアラートで知らせてくれたり、様々なデータを可視化して、常に各所からモニタリングできるようにする、といったワクワクするような構想や事例が多くあります。

しかし、このようなスマートファクトリーを実際に構築していくにあたって、どのような苦労や困難があるのでしょうか?そしてそれらを、どのように解決していくのでしょうか?
今回の須田氏の講演内容を元に、とりわけ工場内のデータ収集部分にフォーカスを当て、解説をしていきます。

「稼働中の工場から、いかにデータを集めるか」それこそがIIoT最大の山場

スマートファクトリーにおけるデータの取り扱いでは、工場内に設置された様々なセンサーから送られてくる大容量のデータを収集し、それらを加工→蓄積→分析していくというのが基本的な骨子となります。

「データさえ収集できればこちらの土俵」と須田氏
- 「データさえ収集できればこちらの土俵」と須田氏 -

その中でも最大の山場といえるのは、「稼働中の工場から、いかにデータを集めてくるか?」であると須田氏は言います。また、まだまだ事例が豊富とはいえないIIoT界の魅力でもあり、つらみとも言える3つのポイントを、次のようにまとめています。

Webのシステムとは一味違うIIoTならではの、つらみ
- Webのシステムとは一味違うIIoTならではの、つらみ -

確かに、過去数十年も稼働してきた工場内のシステムからデータを引っ張ってくるというのは、想像しただけでも骨が折れそうです。では、この最大の障壁「いかにデータを集めるか?」を今回の事例ではどのように解決していったのでしょうか。

システムの全体像

まずは本講演で紹介されたシステムの全体像(下図)を確認しましょう。
基本的な流れとしては、各工場内のデータや既存システムからのデータを、APIを経由してKafkaで受けて、Sparkに流し、HBaseに蓄積させ、あとは自由に分析する、といった形になるようです。

Kafka:Apache Kafka。高スループット/低レイテンシが強みの分散メッセージングシステム。

HBase:Apache HBase。Hadoopプロジェクトが開発したNoSQLデータベース。

Hadoop:Apache Hadoop。大規模データ分析用の並行分散処理を行うOSSフレームワーク。

各工場から送られてくるデータを収集し、活用するまでの流れ
- 各工場から送られてくるデータを収集し、活用するまでの流れ -

さらに詳細化したものが下図です。

今回構築したシステムの全体像、詳細図
- 今回構築したシステムの全体像、詳細図 -

ポイントは、工場からクラウドにデータを直接送っていない点です。
後程詳しく説明しますが、工場とクラウドの間にエッジサーバと呼ばれるゲートウェイが用意されています。そのエッジサーバで一度データを受けたのち、AWSのECS(Amazon EC2 Container Service)上のAPIコンテナ群に引き渡し、メッセージング部分を担当するKafkaに流れていきます。そして、Kafkaにデータが溜まったら、Spark Streamingに流し、最終的にHBaseに蓄積されます。

Apache Spark:インメモリで並行分散処理を高速に行えるフレームワーク。

Spark Streaming:Apache Spark Streaming。ストリームデータ処理を行うライブラリ。

HBaseでは順序を担保したい項目で行キーを生成することによって、蓄積の過程でデータの順番が乱れても、最終的にはきちんとソートされるようになっており、またどれだけ重複があっても冪等性を保つことができるようになっています。
こうした構造のため、少なくとも1度クラウド側でデータを受け取ることができれば、最終的にはきれいな形で利用することが可能になります。

Kafkaを選定した理由

さて、ここでシステムの全体像について、1つ気になる点が出てきました。それは、AWSの各サービスを中心として今回のIoTインフラを構築しているにも関わらず、なぜメッセージングシステムにKafkaを用いているのか、という点です。AWSには、Amazon Kinesis Streamsなどのメッセージングシステムが用意されていますが、なぜそれらを選択しなかったのでしょうか?

須田氏は、下記3点を理由として挙げました。

あえてKafkaを選定した理由
- あえてKafkaを選定した理由 -

ちなみに今回の仕組み全体は、基本的にGoで実装しており、全体的に使用しているフレームワークはecho、 Kafkaのクライアントは、機能が充実している点が気に入っているというsaramaを使っているとのことです。

sarama:Go言語で書かれたKafkaのクライアントライブラリ。

エッジコンピューティングとは

次に、工場のデータをKafkaに入れる過程で重要な概念となる、"エッジコンピューティング"について説明がありました。エッジコンピューティングは、データの発生源の近くにゲートウェイとなるデバイスを置き、クラウドとの中間処理を実行させたり、即時応答が必要な処理をその場で実行させます。これによって、遅延の少ない処理や、大量データの集約効率化を実現することができるそうです。

参照:http://www.ntt.co.jp/news2014/1401/140123a.html

データ発生源のデバイス近く(端っこ)なのでエッジ
- データ発生源のデバイス近く(端っこ)なのでエッジ -

今回のシステムでもエッジコンピューティングの概念を取り入れており、下記のようなポイントを抑えた上でエッジサーバを立てています。

「at least once」や「exactly once」など、思わず会場からも「なるほど」との声が出た
- 「at least once」や「exactly once」など、思わず会場からも「なるほど」との声が出た -

at least once, exactly onceでデータを流す

それでは、実際に工場からのデータをKafkaに入れるまでの過程を詳しく説明していきます。下図はある工場での構成例を図式化したものです。

2つのエッジサーバ(中央左)を経由しCheckAPIをかませることで「at least once」を実現
- 2つのエッジサーバ(中央左)を経由しCheckAPIをかませることで「at least once」を実現 -

まず、複数のセンサーやモーターのデータが、それらを管理するシーケンサにまばらに集まってきます。それらのデータを1ファイルとして、エッジサーバに送ります。
なお、このファイルは、各センサーやモーター毎のデータというように綺麗にまとまっていません。シーケンサが管理してる複数のセンサーやモーターからのデータは、一定期間ロギングしたものがごちゃ混ぜの状態で1ファイルとなっているようです。

そして、エッジサーバは、このファイル名からハッシュ値を算出し、そのファイルが処理済みかどうかのステータスをチェックAPIで確認します。そこでもし処理済みでなければ、データ登録APIにファイルを投げ、ファイルを受け取ったデータ登録APIが、その複数データを1レコードずつにパースしてKafkaに入れていく、といった流れでデータが蓄積されていきます。

この例では、エッジサーバが2台用意されていますが、この2台はそれぞれステートレスな状態となります。また、リーダー/スレーブが決められており、先ほどシーケンサにて作られたファイルは、時間差を置いて2台のエッジサーバに両方に投げられることとなります。これによってデータの紛失を防ぐことができ、堅牢なリアルタイム監視システムが構築出来たと言えるのですね。

まとめ(前編)

本編のまとめ

  • スマートファクトリーにおける最大の山場は「いかにデータを収集するか」である
  • IIoTの魅力(つらみ)は下記3点
    • 既存システムとの連携が困難な場合が多い
    • 独自プロトコルやメーカーの縛りが多い
    • 公開されているノウハウがが少ない
  • メッセージングシステムとしてKafkaを活用するのは、プラットフォームへの依存性をなくす、データ解析基盤の入り口が肝であるため自身で作り込みたい、VPCに閉じた閉域網を実現したいといったニーズに対して有効であった
  • 工場からのデータは、エッジサーバを経由してクラウドへ送られる
    • エッジサーバをリーダー/スレーブの2台用意し、二重でクラウドにデータを送り、またクラウド側では、工場データにもたせた処理済みかどうかのステータスを確認することで、「exactly once」を実現

資料について

下記に須田氏の発表資料を掲載しております。非常にキレイなSlideにまとめられていますので、是非全ページご覧下さい。