エンジニアが本気で作ったIoTパタパタ
展示で「触れるクラウド体験」を作りたくて、あえてアナログな“パタパタ”をAWSとつなぎました。見た目はレトロでも、中身はIoT Core・Lambda・Rekognitionでリアルタイム制御と画像解析、異常検知にまで至る構成です。
本記事では、ラズパイを中心にした物理デバイスとサーバーレスをどう組み合わせたか、なぜその選択にしたのかを軸に、約1か月で作り上げたゲーセン風筐体の仕組みをコンパクトに解説します。
そもそもこれはいったい何？
解説を始める前に、パタパタって何？ということを説明した方が良いかもしれません。
パタパタとはいったい？
そもそもこれは何
昔懐かし行き先案内表示板のミニチュア（パタパタ回るやつ）を、株式会社星光様にお願いして作ってもらいました。表示内容はディーネットオリジナルです。
そのミニチュアを「自動でまわしたい！」「AWSと連携させたい！」という要望を、有志のエンジニアが叶えてくれた代物が「パタパタ」となります。
なぜ回したいのか？なぜAWSと連携させる必要があるのか？それはまた別の機会があればそちらに譲りましょう。
参考）作成風景はこちらから
KOBE風ジオラマ：https://blog.denet.co.jp/star-flap-vol1/
ゲーセン風筐体：https://blog.denet.co.jp/star-flap2-vol1/
全体構成
全体構成としては、このようになっています。以降では特定部分に絞って説明していきます。
アクセス集中時に発生する事象
モーターの制御はラズパイで
いきなりAWS関係ない部分からの説明になりますが、モーター制御はラズパイで制御しています。
パタパタ自体がもともとは手回しを想定されているので、モーターで回せるように部品交換が必要になります。「KOBE風ジオラマ」ではギアとギアを咬み合わせる仕組みで実装しましたが、ゲーセン風筐体ではベルト式へ変更しています。ベルト式にすることで、静音、設置の簡易性向上などを見込むことが可能です。
ラズパイには、パタパタ以外にもカメラとディスプレイが接続されており、Wi-Fiを経由してAWS IoT Coreと接続しています。
WEBインタフェースはサーバレスな構成
WEBインタフェースはサーバレスな構成
パタパタ回転の起動・停止はWEBインタフェースから実施が可能になっています。構成図を見てわかる通り、サーバーレスな構成で実装しています。
まずブラウザに表示する管理画面は、S3へ保存したHTMLをCloudFront経由で配信しています。
管理画面の「START」ボタンを押すとREST APIのリクエストを実行し、API Gatewayを通じてIoT Coreへ「START」の指令を発行します。同様にパタパタを止める時は「STOP」ボタンを、待機画面へ戻す場合は「AUTO」ボタンを押す形になります。
パタパタとAWSの連携にはIoT
パタパタとAWSの連携にはIoT
WEBのインタフェースとラズパイの間には 「AWS IoT Core」を挟んでいます。
ラズパイからIoT Coreへ常時接続を行い、LambdaからはIoT Coreが提供するMQTTトピックに情報をPublishすると、トピックをSubscribeしているラズパイにメッセージが送信される仕組みです。
IoT Coreを入れることで、次のようなメリットが発生します。
・ 複数のパタパタを同時制御できる（いまは1台）
・ リアルタイムに操作可能
・ 周辺のAWSサービスとシームレスに連携が可能
セキュリティ面に注目すると、ラズパイから直接AWSを操作するためにはラズパイ上にアクセスキーを置いておく必要が生じ、好ましい実装にはなりません。ラズパイからLambdaなどのAWSリソースの実行をIoTアクションにオフロードすることで、IAM権限をすべてAWS上のIAMロールで管理してラズパイ自身では何のIAM権限も有していない点でセキュリティ的にメリットがあります。
画像解析はRekognitionを使ってサーバレスに
画像解析はRekognitionを使ってサーバレスに
パタパタが止まるとカメラで撮影をして、IoT Coreを経由してLambdaに処理が移ります。Lambdaでは、Rekognitionを使って画像解析を行い、撮影された画像に対応するメッセージを写真に追加してモニターへ表示する仕組みになっています。ると、トピックをSubscribeしているラズパイにメッセージが送信される仕組みです。
展示会ではどこにパタパタを配置するかが不確定要素としてあるため、撮影された画像からパタパタ部分を特定する必要があります。Rekognitionでは、あらかじめパタパタの画像データを学習させることで、撮影画像からパタパタ部分を特定させることができました。大人数の画像から、特定の人物をピックアップするなどに使えそうな機能ですね。
パタパタが特定できたら、表示されている面に応じたメッセージを画像へ追加（画像編集）して画像をラズパイに送るように制御しています。Rekognitionでは独自の基準で認識するように学習させることも出来る上、学習用のプログラムなどを用意することなく簡単に画像認識モデルを構築できます。
CloudWatchでトラブルを監視、メールやSlackへの通知も実現
CloudWatchでトラブルを監視
「カメラのピントが合わずに画像の特定ができない」「IoT Coreに接続されていない」などいくつか想定されるトラブルがありました。そのようなトラブルが発生したときに、すぐに検知・対応できるように、「AWS IoT Events」を使って、SNSやCloudWatchへ情報をプッシュする仕組みを構築しました。
CloudWatchでトラブルを監視
「カメラのピントが合わずに画像の特定ができない」「IoT Coreに接続されていない」などいくつか想定されるトラブルがありました。そのようなトラブルが発生したときに、すぐに検知・対応できるように、「AWS IoT Events」を使って、SNSやCloudWatchへ情報をプッシュする仕組みを構築しました。
SNSからはメールやSlackへ情報を飛ばすことで迅速に人が異常を検知することが出来ます。CloudWatchへログを保存しておくことで、検知後のトラブルシュートなどに活用します。
関連するFAQ
Q. この「パタパタ」は何をしているシステムですか？
A. ラズパイで制御する物理表示装置をAWS経由で遠隔操作し、カメラ画像をRekognitionで解析して表示内容を自動制御、異常時は通知するIoTデモです。
Q. どのAWSサービスが使われていますか？なぜそれらを選んだのですか？
A. API Gateway／Lambda（サーバーレスで即時にリクエスト処理したい）、IoT Core（デバイスとの双方向・常時接続と拡張性を確保）、Rekognition（学習や推論基盤を用意せずに画像認識を実装）、S3／CloudFront（管理画面を軽量配信）、IoT Events／CloudWatch／SNS（展示中の監視と即時通知）を採用しています。短期開発・現地運用・拡張性を優先した選定です。
Q. なぜEC2ではなくサーバーレス構成にしたのですか？
A. 展示用途での短期開発・不定期アクセス・運用負荷の低減が主目的です。サーバー管理を持たずに素早く作り、必要な分だけ動く構成にするためサーバーレスを選びました。
Q. IoT Coreを使わずにHTTPで直接つなぐ構成との違いは？
A. MQTTによる常時接続で低遅延な双方向通信ができ、デバイス数が増えてもトピックでスケールします。加えて、デバイスに強い権限を持たせずIAMロール側で制御できるためセキュリティ面でも有利です。
Q. 画像解析（Rekognition）の精度や苦労した点は？
A. 設置位置や照明が変わる展示環境では、パタパタ部分の特定が不安定になることがありました。事前学習用の画像のバリエーションを増やし、失敗時の再試行や通知で運用カバーしています。
Q. ハードウェアはなぜベルト方式に変更したのですか？
A. ギア方式からベルト方式へ変更し、静音化と設置のしやすさを優先しました。展示会では周囲の騒音や設営時間が制約になるため、運用上のメリットが大きかったためです。
Q. 展示会特有の制約にはどう対応しましたか？
A. 通信環境の不確実性と設置自由度の低さを前提に、Wi-Fi経由＋IoT Coreの再接続設計、異常時のSNS通知、現地での即復旧を意識した構成にしています。
Q. コスト感はどれくらいですか？
A. サーバーレス中心のため待機コストは低く、主にリクエスト数（API Gateway/Lambda）と画像解析（Rekognition）に依存します。展示規模であれば小〜中程度に収まるケースが多いです。
Q. トラブル対応はどのようにしていますか？
A. IoT EventsとCloudWatchで状態を監視し、異常時はSNS経由でメールやSlackへ通知。ログを残して現地での切り分けを迅速化しています。
Q. 開発期間はどれくらいですか？
A. 業務の合間で約1か月弱です。
Q. この構成は実務にも応用できますか？
A. はい。複数デバイス管理、遠隔操作、画像解析、監視通知は製造業の設備監視や店舗ディスプレイ、スマートデバイス管理などにそのまま応用可能です。
まとめ
モノとAWSを連携させて本気で遊んでみた事例ということで、サーバーレスで様々なサービスを利用した展示物を作ることができました。約1か月弱かつ業務の合間を縫っての実装だったので、もっと良い方法があったかもしれませんが、短期間でもオモシロいものが作れるのがAWSの良いところでもあると思います。
AWSを使って何か面白いことをしたい！という相談もお待ちしております。