Developers.IO 2016へ参加してきました

昨日は通常体力回復に当ててる貴重な週末を費やして、クラスメソッド主催のDevelopers.IO 2016に初参戦してきました。

AWS系の調べ物をしていると、必ずといってよいほどDevelopers.IOのブログに行き着くといっても過言ではないですし、IoT系の話とちょうど仕事で認証・認可周りで検討している事案があったので、重い腰を上げて参加してみたわけです

最近はこういったイベントの資料はSlideshare等ですぐに公開してくれますし、実際にその場に行かなくても、情報を得ることはできるのですが、そこでしか語られないこともあるし、時間拘束される分、集中して情報をINPUTするという気構えになるので、やはりイベント参加の意義はあるなと改めて思ったところです。

IoTについては、あまり積極的にウォッチしていなかったこともあり、現状のキャッチアップとアーキテクチャパターンについて聞くことができたのが大きな収穫でした。

EventRegistで予約していても席がなかったりと、若干イベント運営はこなれてないところがありましたが、扱っているトピックがやはり面白いので、来年も参加したいですね。

※以下は自分用メモですが、ご参考まで。

講演資料

http://dev.classmethod.jp/series/developers-io-2016/

1.スマホアプリデザインの心得

13:00-13:45 トラックD

クラスメソッド

  • ブログだけじゃなくて、モバイルアプリ開発やデザインもやってる
  • どんな仕事
    • くらめそ「モバイルアプリ開発部隊」
    • 自社サービスではなく、顧客からの受注
    • 昔はデザイン会社と協業、最近は自らデザイン
  • 何をデザインしているのか
    • UI/UX
    • サービス

生活とスマホ

  • 日本のスマホ普及率50%
  • スマホがある風景
    • 気象
    • 通勤
    • 昼休み
    • 帰宅
    • 風呂
    • トイレ
    • 就寝
  • すでにスマホは生活に溶け込んだといえる
    • 「スマホは生活」すでに一体化してる
  • スマホのデザインは、生活のデザイン

ライフスタイルデザイン

  • ユーザーの目的
    • 機能を使うことが目的ではない
    • 体験を通して価値を感じること
  • 体験をデザインする、体験を価値あるものにするために
    • 近視眼的デザイン
    • アプリ機能のみに着眼(周りが見えない)
    • 機能は提供するが、価値は提供できない
    • 価値がなければアンイストールされる(目的が達成できない)
    • 機能を俯瞰する
    • 周りの景色が見えてくる
    • 生活の中でアプリが登場するストーリーを考える
    • いつ、どこで、何をするとどうなる?
    • シーンにマッチした機能
    • 体験を通した価値の提供
      • スーパーで片手しか使えない状況で使うアプリは片手操作を意識するなど

スマホアプリデザインの心得

  • アプリは生活の中にある
  • ユーザーに届けるのは機能ではなくその先にある価値の体験
  • スマホの外では常になにかが起きている

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

14:00-14:45 トラックA

はじめに

  • IoTについて
    • ビジネスチャンスだとか、バズワードだとか・・・
    • エンジニアとしてはハックしがいのあるテーマ
    • 今までのアーキテクチャとは明らかに違う
  • DataSpiderServista
    • ノンプログラミングでデータ連携
  • HULFT IoT
    • 絶賛開発中のHULFTのIoT版

IoTシステム

  • 大まかな種類
    • テレマティクス、スマートメーター、センシング、リモートモニタリング
    • トレース、決済、セキュリティ

IoTアーキテクチャ種類

Device to Cloud

  • MQTT、Streaming Service(Message Broker)
  • メリット
    • 比較的すぐに始められる
    • デバイスが増えてもアーキテクチャ変更不要
    • 大量データもクラウドでらくらく対応
  • デメリット
    • 段階的に増えていくときにコストがかかる
    • デバイスごとにデータが異なるときに面倒
    • 再送処理をどうするか?
    • 電池がやばくなる場合あり

Useing Gateway

  • DeviceとMessage Brokerの間にIoT Gatewayをはさむ
  • メリット
    • デバイスに不可をかけない(近距離通信)
    • デバイスが増えたときにデバイスに手を入れなくていい
    • 転送をコントロールしやすい(再送、フィルタ) -

Using Mobile

  • Mobileがデータを受けてクラウドへ上げるパターン
  • メリット
    • みんなが持っているMoblle利用が可能
    • 転送をコントロールしやすい(再送、フィルタ)
  • デメリット
    • Mobileが必ずデバイスのそばにあるわけじゃない
    • 動作検証が大変(スマホいっぱいあるから)

Using Server

  • デバイスからサーバがうけて、クラウドへ

データ転送で考えるべきこと

  • 5つのポイント
    • 到達保証
    • セキュリティ
    • 多重度
    • 圧縮
    • トランザクション
  • 大前提
    • デバイスに極力負荷をかけない
    • スケーラブルなアーキテクチャにする
    • デバイスとクラウドは疎結合にする
  • 到達保証
    • IoTだからといってロストして放置というわけにいかない
    • どこまでやるかは決めるべき(MQTTのQoSレベル)
    • 配信だけ保証
    • 受信まで保証(このパターンが多い)
    • 受け取りの回数まで保証
  • セキュリティ
    • これも基本的にちゃんとやる羽目になる
    • 認証
    • MQTTはパスワード認証Only、どうやってデバイスに渡す?
    • AWS IoTはX.509はサポート
    • 暗号化
    • 経路の暗号化
    • 証明証の配布
    • Soracom beamとEndorseがあればいける
    • 耐タンパー性
    • デバイスぱくられたときにデータ漏洩しないように
    • セキュリティベンダの製品利用がベター
  • 多重度
    • トラフィックコントロール
    • スマートメーター(関西電力1300万台)が同時発報したらどうする?
    • リアルタイムに必要なわけでもないので、時間差で発報する仕組みをつくる
    • 耐障害性
    • Gatewayが死んでも転送できるように
  • 圧縮
    • デバイスに負荷かけたくないけど、データは圧縮したいといジレンマ
    • 圧縮せずにMessagePackなどを利用
    • 圧縮しながら転送
  • トランザクション
    • デバイスとサーバは疎結合のため一貫性担保は難しい
    • 方法
    • HTTP、WebSocketでがっちりやるパターン
    • キューで順序制御
  • MQTT一択?
    • プロトコルとしてはIoTと相性がいい
    • 気になるところ
    • データをストアするとスケールしづらい
      • AWS IoTなら解決
    • 大容量データの転送
      • 画像、バイナリデータの扱い
      • データの欠落チェック
    • 出たの順序性の制御
      • MQTTにキューはない
  • ファイル転送
    • 古臭いが・・・
    • ファイル転送のいいところ
    • 順序性の管理、Pub/Subなども可能

3.マイクロWebアプリケーション 〜 複数サブシステムを OpenID Connect で 繋ぐアーキテクチャ

15:00-15:45 トラックA

モノリシックと分割統治

  • 社内のポータルもはじめはモノリシック
  • 技術レイヤによる分割
    • ユーザー I/F、Web API、Queue Worker、データストア
    • これ以上は分割しづらいことに気づく・・・
  • ビジネスによる分割
    • 請求書発行サービス、・・・・
    • マイクロサービスアーキテクチャ(MSA)
  • マイクロWebアプリケーション
    • AWSはMSAの体現
    • RDSやELBもたぶんEC2上で・・・
  • 超えなければいけない問題
    • 認証・認可
    • インフラコスト
    • モノリシックよりもインフラコストがかかる

認証・認可

  • 認証は誰かなのか、認可は誰に何をやらせるのか
  • 認証と認可の密結合
    • モノリシックな場合、認証しなければ認可できない
    • 認証と認可の分離
    • 本来人間を持つ権限を外部システムに委譲する仕組みがOAuth
    • 認証
    • 認証のメタファー
      • 「証明書の確認」
      • 認証したからといって、何かが許されるわけではない
    • 現実世界の認証
      • what you are その人自身、署名
      • what you have 身分証、スマホ
      • what you know パスワードとか
    • 認可
    • 認可のメタファー
      • 鍵や切符の発行
    • 疑問
    • 認可にあたってIDを確認する必要はない
    • iptablesも認可だけ
    • 認証したのに認可しないことなんてあるのか?
      • モノリシックなら、まずない
      • マイクロサービス

OpenID Connect 1.0 と OAuth2.0

  • OIDC、OAuthの関係
    • OIDCはOAuthのスーパーセット
  • OIDCが実現してくれること
    • 登場人物
    • End-User(EU)
    • User-Agent(UA)
    • Relying Party(RP)
    • OpenID Provider(OP,IdP)
    • OIDCの仕組み
    • OPがID/PASS検証して、ID tokenを発行
    • RPはOPを全面信頼する
  • OAuthが実現してくれること
    • 登場人物
    • OIDCと呼び名が変わるが、役割は変わらない

4.IoTのビジネスをデバイス・ゲートウェイから見てみる ~この1年でどんなアップデートがあったのか?~

16:00-16:45 トラックA

2016年のIoTビジネス

  • IRにIoTで株価が上がる
  • YAMADAがIoT企業!?
  • IoT規模
    • 2020年までにインターネット接続デバイスは500億になる(2015年)
    • 今年、530億の予想になっている(総務省)
  • IoTのポジショニング
    • 実際にはそこまですごくない?ということで、幻滅期へ
  • IoTシステム
    • センサーからGWが集約してクラウドへという構成は去年と変わらない
    • センサーから直接クラウドはまだ厳しい
    • SORACOMが登場して、安く接続可能になってきた
  • 総括
    • 規模は続伸予想
    • 幻滅期が訪れている
    • クラウド&アクセス・ネットワークはプロダクトが充実、  フィールド・ネットワークがポイント(要するに現場)
  • 歴史に学ぶ
    • インターネットマガジン バックナンバーアーカイブ

池袋で1kmの距離を通信できる無線

  • サブギガ
    • 920MHz帯を使った無線通信
    • 免許が不要
    • 干渉が起きにくい
    • 通信距離が長い伝搬特性
    • センサーからゲートウェイ間のネットワークに使える
    • 江ノ島から茅ヶ崎まで届く
    • 法的な制約あり
    • スループットが低い
    • 最大でも18kbps
    • パソコン通信時代のモデムよりも遅い
    • データ設計が重要(パック化など)

GWデバイスの同時に1000台セットアップする

  • SORACOM Air カスタムDNS
    • デイバイスに配布されるDNSサーバアドレスを条件によって変更できる
    • Ansible連携も可能
    • アップデート、セットアップはこれでOKで

盗難に対して

  • EncFS
    • fuseでお手軽
    • しかも強固