SMARTCAMP Engineer Blog

スマートキャンプ株式会社(SMARTCAMP Co., Ltd.)のエンジニアブログです。業務で取り入れた新しい技術や試行錯誤を知見として共有していきます。

AWS IoTとLambdaとDynamoDBでオフィス環境を可視化してみた

f:id:ug_23:20191115130728p:plain

スマートキャンプエンジニアの今川(@ug23_)です。

10月中旬に、スマートキャンプのエンジニアチームで開発合宿にいってきました。合宿のテーマは、スマートキャンプのミッションテクノロジーで社会の非効率を無くすになぞらえて、テクノロジーでSMARTCAMPの非効率を無くすでした。合宿を楽しんでいるメンバーの様子は来週のブログでお届けする予定なので、このエントリでは作ったものについて触れます。

解決する課題

合宿のチーム分けが決まり、合宿のためのプロダクトを検討し始めた頃、我々はちょうどオフィス移転から2ヶ月後ぐらいの真夏の時期でした。チームで社内の課題を出し合ったところ、オフィス移転してから風邪引いてるひと増えたかも空調が効き過ぎていて寒いって言ってる人多いよね、という声があがりました。

それらに対してシステムでどうアプローチしようかと考えていましたが、あの言葉が頭をよぎりました。

推測するな、計測せよ。 と。

まずはオフィスの状況を定量的に見れるようにしなければ、と思いました。そこで我々はオフィスの環境が計測できないという課題にフォーカスすることにしました。計測した上でそこから改善案を出せるようにしよう、そこから改善案を出せるようにしよう!という思いで設計をはじめました。

またチーム内で「今まで触れたことのないような技術に触れたい」ということで、チームみんなで実世界のデータを可視化するという分野への興味が湧いてきたというのもありました。

できたもの - bony

開発するシステムはRasberry Piで取得したセンサデータをへいい感じに出力する、という形になりました。

そこからプロダクトデザインをして、 bonyというプロダクトになりました。

f:id:ug_23:20191115124949p:plain

f:id:ug_23:20191115125013p:plain

※ジョニーはオフィスの案内業務を20倍効率化した高砂の愛称です。

システム構成

ローカルでないと動かない、というよりデプロイ・公開までしたいよね、という理由から最初からAWSでの開発で考えていました。 設計には私自身のサーバレスに取り組んでみたいという気持ちとAWS-SAAを取得して使ったことのないサービスを使ってみたいという気持ちが反映されています。

AWS-SAAを取得したときの話はこちらからどうぞ!

tech.smartcamp.co.jp

結果、システム構成は以下のようになりました。

f:id:ug_23:20191115130212p:plain

  • Raspberry PiのGPIOに温度・湿度センサCO2センサを接続しオフィス内に複数箇所配置する
  • AWS IoT CoreでMQTT経由でセンサデータをトピックとしてpublishする
  • IoT CoreのルールでトピックをそのままDynamoDBへ格納
  • DynamoDBに入った各センサからのデータを基に、オフィス上の温度のムラを示したヒートマップを生成する
    • ヒートマップ生成のためにクリギングができるpyKrigingを使用
    • Lambdaに載せたいが、一旦EC2に避難中
  • API Gateway + LambdaでDynamoDBのセンサの値をJSONとしてフロントエンドに提供する
  • Nuxt.js でフロントエンドを開発し、APIとヒートマップを生成
  • フロントエンドではデータに合わせてbonyからのアドバイス(通称ボニドバ)を表示
  • Netlify で配信

Raspberry Piはこんな感じ

f:id:ug_23:20191115130247p:plain

オフィスのヒートマップ

オフィスの温度を示すとして、ITエンジニアなら監視ダッシュボードのようなものを想像するかと思いましたが、オフィスの環境をみるには温度変化よりも今どこが暑い/寒いのか?という情報が重要と感じました。

複数の地点の温度データから地点間の温度を補完してヒートマップを作成し、それを見せることでそれが解決できると考え、追加しました。

地点間の数値補完等高線図で使われているようで、クリギングという概念があるようでした。以下のパッケージを利用して画像を生成しています。

pykriging.com

正確性はまだ測れていませんが この辺は温かい/寒いなどの情報を見せるにはこれが良いのではないかと考えていれてみました。

AWS IoT Coreを使ってみて

aws.amazon.com

当初、Raspberry PiからDynamoDBへのデータの格納はAPI Gateway + Lambdaを使おうかと考えてみましたが、調べてみるとAWS IoTってやつが使えそうだと気付き、採用しました。特にこの部分が私の担当だったのでLambdaもIoT Coreも慣れてなければより専用っぽいものを使ってみよう!という考えでした。

今回始めてIoT Coreを触ってみましたが、RaspberryPiに指定された証明書などを配置し、そのファイルパスをコード中で定義しつつIoT Core SDKを叩けばJSONをDynamoに送れました。サンプルコードでは双方向にpub-subをさせてRaspberryPi上とブラウザ上でトピックをやりとりするのが体験できましたが、この周りはなにかに応用できるかもしれません。MQTTが使われているとのことでしたが、そのあたりはあまり意識せずとも使えるようになっていると感じました。Linuxが入っていれば動くのでラクだと思います。調べてみるとarduinoやintel edisonも対応していそうなので夢が広がりますね!

トピックを受け取ったあとの流し先をいろいろ設定できるのでそのままDynamoDBに格納したり、Lambdaに流したりできるようです。

f:id:ug_23:20191115130431p:plain

ただし、複数台に対してデプロイするにはほかのサービス(CloudFormationなど?)を使う必要がありそうです。合宿中ではデモすることを重視してすべてを手作業で乗り切りました。また、権限周りはやはり少し複雑で、各端末にひとつの証明書をつけてそれに全台を統括するポリシーを割り当てるという方法を取りましたが最初はそれが原因でpublishに失敗して気づかなかったりして大きくハマりました。

具体的にどう使ったか?などコードを交えての説明はアドベントカレンダーの記事として出す予定なのでお待ち下さい!

ふりかえり

ほとんどの部分を合宿中に開発しましたが、環境周りで転けそうなところを早めに解消した状態で開発したり、1時間に1回顔を合わせて進捗や困りごとを共有してヘルプしたりやる順番を変えたり、落とし所を決めるなど柔軟に開発できた気がします。

一方でSwitch RoleやMFAが必要な環境で開発をしていた事もあり、Serverless Frameworkなどの権限周りやIAM等でハマった事もありました。 このあたりは最初からプロトタイピングと割り切って、権限を気にしなくても良い環境で開発すればよかったかもしれません。

そうした技術的な悩みも多かったですが、チームをまたいで組んだ5人が集まってものづくりをしたのは新鮮な体験で「○○さんといっしょに開発できて楽しかった!」という感想がでました。普段関わりが薄い人同士だとたのしいですね。

さいごに

先日全社の前でプロダクトのプレゼンをしましたが、現在まだRaspberry Piのデプロイ(物理)が済んでいないのと、回路実装がプロトレベルなのでそこを整える必要があり、実稼働には至っていません。また、ヒートマップ生成バッチにまだ不備があるのでそれを直すなど、早くこの辺の細々した課題を解決してリリースしたいですね。年内を目標にしたい…。

これからインフルエンザが流行る時期なので、これをもとにオフィス環境改善ができるといいな!と思います。寒くなってきたのでみなさまもご自愛下さいませ。

最後まで読んでいただきありがとうございました。