読者です 読者をやめる 読者になる 読者になる

ryouma-nagareのブログ

IT関連の勉強会や、イベントのメモなどを書いていきます。

Developes.IO2016に行ってきました

3日連続でイベント参加。

【F-1 趣味でBlackJumboDogを作った Microsoft MVP が、iPhoneアプリ開発者になった話 〜定年自衛官がJOINしました〜 】 f:id:ryouma-nagare:20160222023710p:plain * 54歳の誕生日で定年を迎えました。 * 28歳でプログラムを始めて、5年前に定年後はプログラマになろうと決心した。 * 入って2ヶ月の私にここで話をさせるとはクラスメソッドってすごいなあw * 興味があれば一生懸命できて楽しい。 * 能力の限界はあるが、年齢の限界はない。

すごいです。

BlackJumboDogの名前の発祥を聞かせていただけました。

  • 当初の名前はWinProxy
    • 同名のソフトがあって、海外から訴訟の脅し
    • 友達が「大きな犬がいた!」と大げさに言っていた
    • サーチしたらヒットしない
    • BlackJumboDog!

【A-2 実践IoTシステムで求められる確実なデータ連携】

ラズパイで何か作りました!とかいう話ではなく、実際の案件で考えなきゃいけない泥臭いデータ転送の話をします。というマクラからスタート。

HULFTIoTを絶賛開発中! →HULFTのクオリティをそのままに、IoTのデータ転送をします。

●IoTには適用範囲によって種類がある。

●IoTシステムアーキテクチャ

  • Type1:Device to Cloud
  • バイス→メッセージブローカー→データストアといったように非同期のアーキテクチャ
  • MQTTが多い。
  • よいところ
  • 悪いところ
    • バイスが段階的に増えるときの管理コストで死ねる
    • バイスごとにデータが異なるときに後々面倒。
    • 再送処理どうすんの?
    • 電池が…
  • Type2:UsingGateway
  • Type3:UsingMobile
    • よいところ
    • みんなが持っているMobileを流用できる
    • 中継だけでなく他の使い道にも
    • 転送をコントロールしやすい
    • 悪いところ
      • Mobileがデバイスの近くにある必要がある
  • Type4:UsingServer
    • バイス→サーバ/PLC→メッセージブローカー→データストア
      • 製造業で多いパターン
    • よいところ
      • 中継処理でなんでもできる
      • 既存の資産を転用できる
      • 転送をコントロールしやすい
    • 悪いところ
      • そもそもIoTか?
      • モビリティに欠ける

●データ転送で考えること

●IoTシステムの大前提

1.到達保証

  • ロストを前提とするとアプリ側も対処がめんどくさい
  • HTTP、WebSocketでやろうとすると自前で実装する必要がある

2.セキュリティ

  • 認証
    • MQTTはパスワード認証だけどどうやってデバイスに渡す?
  • 暗号化
    • 経路の暗号化
    • 証明書の配付はどうする?
  • Soracom beamとEndorseがあれば経路の暗号化はOK。
  • 耐タンパー性
    • バイスそのものを盗まれたときにデータを抜き取られないように

3.多重度

4.圧縮

  • なるたけデータの転送量は圧縮したい
    • でもデバイスには負荷をかけたくない
  • そもそも圧縮しないアプローチ
    • メッセージが小さいから問題ない
    • でも画像やバイナリは…
  • 圧縮しながら転送
    • その都度圧縮
    • プロトコルではサポートしていないので開発する必要がある

5.トランザクション

  • そもそも必要ない場合も
  • 必要になるとっても頭の痛い話
  • バイスとサーバは疎結合なのにどうやって一貫性を担保?
    • 案1: HTTPとかWebSocketでがっちり実装
    • 案2:キューで実装

●MQTT一択なのか?

  • プロトコルとしてはIoTと相性はよさそう
  • それでもMQTTの気になるところ
    • データをストアするとスケールしづらくなる
    • 大容量データの転送
    • データの順序性の制御
      • MQTTにキューはありません!

●ファイル転送という選択肢

  • 古くさく聞こえるけど
  • ストアを考えなくてもよい
  • 順序性の管理がしやすい
  • ファイルでPub/Subっぽいこともできちゃう
  • スケールしやすい
  • 大容量もOK
  • 動画やバイナリもOK

でも…

  • 到達保証、整合性検証の仕組みが必要

そこでHULFT IoTですよ!

【La-3 実務で使うAWS Lambda 】

●実務でLambdaを使うのは難しい?

  • Lambdaがよさそうなのはわかる
  • EC2ではオンプレと同じようにプログラムを実行できた
  • Lambdaの使い方はそれとは異なる。
  • 納期が決まっているので下手にはまるとつらい。
  • 運用時に問題が出ると困る

WorkerでよいものはLambda化しやすい

実用上はメモリと同時実行数とサイズに注意

同期呼び出しは調整されるとエラーが返る

●Lambaバックエンドの並列耐性

  • 対策1:スケーラブルなバックエンドを使う
    • DynamoDB
  • 対策2:並列度を制御する仕組みを入れる
    • Functionを起動するFunctionを設ける

私は、Lambdaファンクションの実行時間より、起動までの時間が気になってます。

f:id:ryouma-nagare:20160222022233p:plain

ハッシュタグ付きでTweetしただけでTシャツをいただきました。

f:id:ryouma-nagare:20160222022249p:plain

SORACOM様のSIMアダプタとシールを。