近年、AWSにおいてインスタンスの管理が自動化された「マネージドサービス」と呼ばれるサービス群が次々と発表されています。このマネージドサービスを活用することで、インフラの管理を最小限にしつつ、効率的にアプリケーション開発に専念することができます。また、AWS は拡大する IoT / M2M 市場に適したサービスの提供も始め、 IoT / M2M 向けシステム開発においてもスケーラビリティや低コストなど AWS のメリットを享受できるようになりつつあります。本記事シリーズでは、2015年6月に開催されたAWS Summit Tokyoにて開催されたアマゾンデータサービスジャパン社 榎並氏によるセッション「AWS クラウドを活用した IoT / M2M ソリューション」（講演動画、資料）の内容をベースに、AWS を活用したシステムの基本パターンについて構築例について紹介します。前編の本記事では概要として IoT / M2M 向けシステムの特徴および AWS サービスを選ぶ際の注意点などをご紹介します。
IoT / M2M システムの特徴
IoT（Internet of Things） とは身の回りにあるモノにセンサなど電子部品が組み込まれ、データの収集・分析結果に基づいて何らかのアクションを起こすことで新しい価値やサービスを生み出す技術分野を言います。以前から機器同士が自律的に通信を行うことで、サービスや価値を提供する M2M（machine-to-machine）と いう分野がありましたが、IoT は M2M を包含する概念です。システムのエンドポイントにあるのは機器だけではなく、エンドユーザやオペレータ、システム、サービスも含みます。
一方、従来の企業向け情報システムや Web と比較すると、システムのエンドポイントがセンサデバイスであり、センサデバイスから収集した大量の時系列データ（ストリームデータ）を収集する機会が多く、以下のようなケースが多く見られます。
- センサデバイスから収集した大量の時系列データ（ストリームデータ）を収集し、リアルタイムに処理・分析する。
- エンドポイントにあるデバイスのリソース制約により、サーバとの通信プロトコルとして Web のデファクトである HTTP より軽量なプロトコルが求められる。
- リアルタイム処理の結果をフィードバックするため、双方向通信が求められる。（例）機器に取り付けたセンサから収集したデータ内容に基づいてサーバから機器へ動作を変える指示を送る場合
センサデバイスが登場する例として、以下の図は AWS における IoT/M2M の事例としてよく紹介される回転寿司チェーン「スシロー」社の取り組みです。本システムでは、寿司皿の下に貼り付けられた RFID タグでベルトコンベア上に流れる寿司を識別し、鮮度や売り上げの状況をリアルタイムで管理しています。特徴的なのは、後述する Kinesis というストリームデータ処理向けのサービスと Redshift と呼ばれるデータウェアハウスサービスを利用して、リアルタイムで分析を行い、分析結果を店舗のマネジャーが確認できるようにしている点です。
リアルタイムで寿司の鮮度や売り上げ状況を分析するスシロー社のシステム（アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
IoT / M2M システムの構成
講演では、 IoT / M2M 向けのシステムで良く見られるシステム構成およびその構成要素へ AWS のマネージドサービスをマッピングしていく方法についても紹介がありました。マネージドサービスは、負荷分散や自動スケールの仕組みなど、インスタンスの管理が AWS によって自動化されています。運用の深い知識をマネージドサービスに委譲できるため、開発者はアプリケーション開発に専念することが出来るメリットがあり、AWS ではマネージドサービスを活用することが推奨されています。
本記事では、企業向け情報システムと比較して特徴的な「Device Interface」、「Event Processing」について注目して紹介します。IoT / M2M向けシステムでは機器やファームウェアの管理を行う「システム管理」部分も非常に重要ですが、システムや機器の個別的な事情が強い分野ですので、本記事では割愛します。
IoT / M2M 向けの典型的なシステム構成（アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
以下の図は、講演で紹介されたデータフローに基づいてシステムの構成要素へ AWS のマネージドサービスをマッピングしていく際の基本的な考え方です。前述のシステム構成のスタックと表現が異なるため、やや混乱してしまう面があるかと思います。以下の対応関係になっている点に注意して確認してください。
- マッピング図左端の「Data Collection（収集） and Storage（保存）」はシステム構成図下部の「Device Interface」に相当
- マッピング図中央の「Event Processing」と「Data Processing」はシステム構成図中央左側の同名の構成要素に相当
- マッピング図右端の「Data Analysis」はシステム構成図上部左端に「アプリケーション」に相当
データフローと AWS サービスのマッピング（アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
Device Interface（デバイスとの通信）
デバイスインタフェースはデバイスとサーバの接点となり、デバイスから指示を受けたり、データ収集を行ったりする部分です。講演では、データの形式によってデータ収集するサービスを選ぶ方法が紹介されました。
| データ形式 | AWSのサービス | 注意事項 |
|---|---|---|
| ファイル（CSVなど） | S3 | HTTP/HTTPSのみサポート |
| ストリームデータ | Kinesis | HTTP/HTTPSのみサポート |
| トランザクションデータ | DynamoDB | HTTP/HTTPSのみサポート |
ただし、本記事執筆時点では、AWS サービスは通信プロトコルとして HTTP / HTTPS しかサポートしていません。デバイス側のリソース要求などにより、ストリームデータを MQTT や Websocket といった HTTP / HTTPS 以外のプロトコルで収集したい場合は、以下のようにサーバ側にゲートウェイとして EC2 インスタンスを置き、その上で目的のプロトコルをサポートしたブローカーを動かす必要があります。EC2 は前述のマネージドサービスではないため、負荷分散や自動スケールの仕組みなどインスタンス管理を自分で用意する必要があります。
MQTT をサポートするためサーバにゲートウェイを置くケース（アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
また、センサデバイスはリソース制約により HTTP で直接サーバにデータを転送できない場合があります。その際は、以下の図のとおり、デバイス側にゲートウェイを用意し、より軽量な近接通信向けのプロトコル（ZigBeeやBLEなど）を利用して、ゲートウェイにデータを集約し、ゲートウェイからサーバへデータをまとめて転送します。
デバイス側にゲートウェイを置くケース（アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
Event Processing（イベント処理）
イベント処理は、デバイスから送られてきたログまたはイベント発生を伝えるデータを解析して状況を把握し、その状況に応じた適切なアクションを起こすための処理です。前述のデータフローと AWS のマッピングでは、イベント処理において AWS Lamda と Kinesis を使うことを推奨されています。
AWS Lamda
AWS Lamda はイベント発生時にあらかじめ登録しておいた Node.js または Java のコードを実行するサービスです。コードを実行するインスタンスは用意する必要はありません。イベントとイベント処理の対応付けをコードで記述し、Lamda 上にアップロードすると、自動的にコードがデプロイされ、イベント発生時に実行されます。イベント駆動専用なため、バッチ処理や定期処理には使えませんが、インスタンスの管理が全く不要な点はアプリケーション開発者には大きなメリットです。
Lamda を実行するきっかけとしては以下のようなものがあります。Lamdaのコードを呼び出す部分自体は AWS で行う仕組みになっています。
- 他の AWS サービス上のイベント（Kinesis でデータを受信したなど）
- AWS の Web API で呼び出す
イベントドリブン処理用のコンピュートサービス Lamda（アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
以下は、AWS Lamda を使ったスマートホームの例です。このようにイベント処理を手軽に実装する方法として AWS Lamda は適しています。
- 家族が家に帰宅したことをセンサで検知し、AWS の API で Lamda を実行します。
- Lamda 上のコードでは、モバイルへの通知、ライト点等指示、DBへのステータス更新などを実行します。
- Lamda から送られてきた指示を元に家のライトが点灯されます。
Lamda を IoT / M2M 向けに利用する例（アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
Kinesis
Kinesis はストリームデータをリアルタイム処理するためのサービスです。前述のスシロー社の事例でも利用されていました。
Kinesis そのものは一種のデータキューであり、センサデバイスなどから収集されたストリームデータを一時的に保持することができます。保持したデータは他のAWSサービスから利用することができます。Kinesisを間に置くことで、データ送信側とデータ処理側は疎結合に保つことができます。具体的には、データ送信側はデータ処理のタイミングや処理内容を特に気にすることなく、一方的に Kinesis へのデータ送信に専念できます。また、データ処理側はデータ送信側の詳細を気にすることなく、データ処理に専念できます。Kinesisのストリーム自体およびデータ処理側の性能拡張は柔軟に行うことができるため、その時の性能要求に応じて徐々にシステムを拡張することができます。
ストリームデータ処理向けのマネージドサービス Kinesis （アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
以下は、Kinesisを利用したシステムの基本構成パターンです。データ処理側の選択肢として、以下の選択肢があります。
- EC2
- Kinesis Client Library が提供されており、Kinesis からデータを受け取る箇所はライブラリを使って実装できます。
- EC2 はマネージドサービスではないため、負荷分散やスケールの仕組みを用意する必要があります。
- Lamda
- Kinesis でデータを受信したことをイベントとして Lamda で受け取り、イベントに応じた処理を行うことができます。
Kinesis の基本構成（アマゾンデータサービスジャパン社 榎並氏 講演資料 より引用）
まとめ
本記事では、AWS Summit Tokyo 2015 の講演内容を元に、IoT / M2M システムの特徴とシステムの構成要素に AWS のマネージドサービスをマッピングしていく方法を紹介しました。多種多様な AWS サービスが提供されており、システムの多くの部分にマネージドサービスを適用することで、システムの運用面を省力化し、アプリケーション開発に専念することが出来る点をお分かりいただけたと思います。ただし、システムの内容によっては完全にマネージドサービスだけで構築できない場合があります。その際は、EC2インスタンスを利用して足りない部分を補う必要があります。
次回は、Kinesis の基本構成で示したシステムを例に実際に Kinesis や Lamda といったマネージドサービスを利用する方法を紹介します。