T O K Y O - pages.awscloud.com · WebフロントでAPI-Gateway / AppSyncの比較 API 認証方式...

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

T O K Y O2

01

9.1

0.0

3-

04


T O K Y O

20

19

.10

.03

-0

4

IoT デバイスと連携するコンパニオンアプリの作り方

Takashi KoyanagawaSenior Solution ArchitectAmazon Web Service, Japan

F - 4


自己紹介

名前

小梁川貴史（こやながわたかし)

所属

デジタルトランスフォーメーション本部

シニアソリューションアーキテクト(IoT/プロトタイプ）

前職

SIer -> 電機メーカー自社サービスの開発・運用元AWSユーザ

好きなAWSサービス

AWS IoT Core , AWS Lambda(python), Amazon Kinesis


本セッションの内容


Agenda

コンパニオンアプリ

IoTにおけるアプリケーションライフサイクル


コンパニオンアプリケーション

スマートフォンやタブレットなどの携帯端末にインストールして、ネットワークに接続されたテレビやゲーム機などとの連携を可能にするアプリケーション。携帯端末からの対応機器の操作や、各種情報を取得して表示・確認などができる。たとえば、テレビとの連携では、携帯端末で番組にかかわるさまざまな情報へのアクセスや、録画番組の一覧確認、番組予約などができる。ゲーム機と連携させると、プレイ画面とは別にサブ画面を表示して機能を拡張することや、ユーザー同士でメッセージを交換することが可能となる。連動させる機器の代表的なものとしては、テレビ、レコーダーなどの映像機器やゲーム機、体重計、脈拍計などの健康管理機器などがある。


コンパニオンアプリの例) Alexa smart home

① 発話

② (必要なら）Update Toke

③ SkillのLambdaからAPIをコール

④ API GatewayのCustom Authorizerでトークンの検証

⑤ 検証結果からThing名を取得

⑥ Update Shadowを行い、デバイスにコマンドを伝える

⑥

⑤

Echo

Alexa

ServiceSkill

Adaptor

①

②

③

④

Alexa App/Web

デバイスクラウド

IoT Shadow

smartphone

application



⑥

⑤

Echo

Alexa

ServiceSkill

Adaptor

①

②

③

④

① 発話






Alexa App/Web


IoT Shadow

smartphone

application

認証


⑥

⑤

Echo

Alexa

ServiceSkill

Adaptor

①

②

③

④

Alexa App/Web


IoT Shadow

smartphone

application

API化とMatching


① 発話








① 発話






⑥

⑤

Echo

Alexa

ServiceSkill

Adaptor

①

②

③

④

Alexa App/Web


IoT Shadow

smartphone

application

MQTT通信を使ってのリアルタイム双方向通信


アプリケーションデザイン: 2-tier か 3-tier か？


デバイスの管理にIoT shadowを使うか？


通信方式


コンパニオンアプリを作るのに便利なサービス

AWS IoT Core

Amazon API Gateway

AWS AppSync

Amazon Cognito

AWS Cloud

AWS IoT Core

Amazon Simple

Notification Service

IoT ThingsApplications

Alexa skill

Light

Door lock


コンパニオンアプリを作るのに便利なサービス

AWS IoT Core

Amazon API Gateway

AWS AppSync

Amazon Cognito

AWS Cloud

AWS IoT Core

Amazon Simple

Notification Service

IoT ThingsApplications

Alexa skill

Auth

X509 certificate file

Auth


WebフロントでAPI-Gateway / AppSyncの比較

API

認証方式

他サービス接続性

プロトコル

Cognitoベースでの３つの認証

GraphQL + resolvers

fine grained access (後述)

MQTT over WebSockets

REST API

service proxy 設定での簡単な接続

WebSockets


Amazon API Gateway AWS AppSync


Cognitoでの３つの認証

1. UserPools Authorizers

2. AWS IAM authorization

3. Custom Identity Providers(Lambda Authorizers)

認証方式

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html






認証方式

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/permissions.html

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/permissions.html






認証方式

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html



API

認証方式


プロトコル


GraphQL + resolvers



REST API


WebSockets




なぜ、GraphQLが登場したのか？

• REST API開発者、利用者の課題

・API仕様のドキュメント管理が大変

・APIの叩き方を理解するのが大変

・APIのドキュメントと実装がずれる

• クライアント開発者からの不満

・１ページ表示するのに幾つもAPIを叩かないといけない

・折角イベントドリブンに作ってもサーバーとの接続は結局

Request / Responseの形が残る

API


GraphQL: クライアントがレスポンス形式を指定

{"id": "1","name": "Get Milk",“priority": "1"

},{

"id": “2","name": “Go to gym",“priority": “5"

},…

type Query {getTodos: [Todo]

}

type Todo {id: ID!name: Stringdescription: Stringpriority: Intduedate: String

}

query {getTodos {

idnamepriority

}}

Schemaとモデルデータ (Type)

クライアントが必要なものだけをリクエスト

リクエストしたデータだけが返される

API



API

認証方式


プロトコル


GraphQL + resolvers



REST API


WebSockets




AppSync:サービス間接続fine grained access


AWS AppSync

DynamoDB

Elasticsearch

/graphql

HTTP Endpoint

Lambda

AuroraServerless

（DataSources）

（Schema）


AWS AppSync

DynamoDB

Elasticsearch

/graphql

HTTP Endpoint

Lambda

AuroraServerless

（Subscription）

（Resolvers）

（DataSources）

（Schema）

AppSync:サービス間接続fine grained access



IoT デバイスのライフサイクル

IoTソリューションを構築する際には、以下のライフサイクルの検討が済んでいることが望ましい

• プロビジョニング• IoT機器の製造と初期化、大量生産など主にエンドユーザが使用する前、生産工程に関わる検討をする

• 運用• IoT機器が実際にユーザに使われている際に管理や利用状況を検討する

• 廃棄• ユーザが利用をやめる際にやるべき内容を検討する


プロビジョニング

検討事項

• 認証

• policy設計

• マスプロダクト• 生産、アプリデプロイと認証情報のセットをいつ、だれが、どのようにやるのか？

• AWS IoTのthingなどの情報登録をいつ、だれが、どのようにやるのか



検討事項

• 認証

• policy設計

• マスプロダクト


(主にIoT Thing側)AWS IoTを利用する際のプロトコル/認証/portのマッピング

プロトコル認証 Port ALPN protocolName

MQTT X.509 クライアント証明書 8883, 443(*) x-amzn-mqtt-ca

HTTPS X.509 クライアント証明書 8443, 443(*) x-amzn-http-ca

HTTPS SigV4 443 n/a

MQTT over

WebSocket

SigV4 443 n/a

https://aws.amazon.com/jp/blogs/news/how-to-implement-mqtt-with-tls-client-authentication-on-port-443-from-client-devices-python/

https://aws.amazon.com/jp/blogs/news/how-to-implement-mqtt-with-tls-client-authentication-on-port-443-from-client-devices-python/


WebSocketを実現するAWSサービスの差分比較

API Gateway AWS IoT Core

セキュリティ/認証 API-key,

Cognitoの３タイプ認証スタイル、なしも可能

認証でSigV4必須

エンドポイントURL API-Gateway提供のエンドポイントカスタムドメインも可能

wss://<endpoint>.iot.<region>.amazonaws.co

m/mqtt

payload / 1msg 128Kb (32Kb単位でフレーム化)

128Kb

payloadの型 JSON非JSON場合,$defaultへ

制約なしルールエンジンを使う場合はJSON

接続時間の制約 2h 24h

チャネルの打ち分け Routeベース Topicベース

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/limits.html

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/limits.html


Websocketを実現する際のアーキテクチャ比較

セッション管理

メッセージ送受信

接続情報管理Client

Mobile client

Client

Mobile client

credentialの取得

payload{“action”:”send_chat1”,“data”:”hello”

}

AWS IoTのendpoint URL

カスタムエンドポイント利用可能

topic: send/chat1payload{“data”:”hello”

}

IoT

rule

必要に応じて処理したデータをlambdaからpublish

プロトコル

https://github.com/aws-samples/simple-

websockets-chat-app

https://github.com/aws-samples/simple-websockets-chat-app


1)QoS=1&clean_session=0でsubscriber(hoge/fuga)を張ったが、セッションが切れてしまった

2)QoS=1でpublisher

がデータを送信(hoge/fuga)

subscriber publisher

publishersubscriber

3)QoS=1でsubscriber(hoge/fuga

)をreconnect

4)AWS IoT Coreがsubscriberへ送信(1時間以内) https://docs.aws.amazon.com/iot/latest/developerguide/mqtt-persistent-sessions.html

• メリット• subscriberが切れてしまい、その後の再接続など、セッションが切れてしまった場合のメッセージをAWS IoT Coreが保管、再送ができる。persistent sessionはMQTT v3.1の標準仕様

• 仕様詳細• subscriberがsession作成時に

clean_session=0(False)でセッションを作成する• AWS IoTの保管は1時間*、QoS=1で送られたメッセージが対象(*)1時間はAWS IoTがセッション断を検知したタイミングから。

Tips: MQTTにおいてネットワークの短時間切断に対策したいpersistent sessionの活用

https://docs.aws.amazon.com/iot/latest/developerguide/mqtt-persistent-sessions.html



検討事項

• 認証

• policy設計



グループの活用:Policy設定、デザイン例

Thing種別

Type-A Type-B



Thing種別

Type-A Type-B

/{client-id}



Thing種別

Type-A Type-B



Thing種別

Type-A Type-B

この権限を持っているのと等価になるアプリケーションの仕様変更で使いたいtopicの変更はgroupについているpolicyを修正することで全体に反映可能


policyに記載するtopic情報を変数化できないのか？policyは TOPICと同等のワイルドカードが使えないがいくつかの変数を利用できる。

ThingName

ThingTypeName

Attributes[keyname]

IsAttached

iot:Certificate.Issuer.属性iot:Certificate.Subject.属性

Thing attribute 証明書属性(独自証明書を使うことが前提)

https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/cert-policy-variables.html

policyで利用可能なワイルドカードは*のみで、使い方としては• roomは必ずつくことは保証したい : room-*と記載。( room-1, room-2,....)

• とある１階層をワイルドカード化: data/*/sensor と記載。 (data/fuga/sensor, data/hoge/sensor)

• とある階層以下をワイルドカード化: data/* と記載。 (data/hoge , data/hoge/fuga)

https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/cert-policy-variables.html


Thing Attributesを前提にThingデザイン

工場やビルのフロア単位にIoT-Gatewayを設置する例Thing としてGatewayを登録、付帯情報をthing attributesに登録

building-id: A001

admin: tkoya

mqttのclient-idとしてGWのGW-IDを名乗る=> Policyとして${iot:ClientId}でgw01が取得可能

iot.Connection.Thing.ThingAttributes[key名]=> 省略.ThingAttributes[bill-id]で A001を取得できる

Thing

ThingAttributes

ThingName

GW-ID(gw01)


実際のpolicy記載例

region/acccountid

は環境に合わせて読み替えてください

ThingAtrributesに設定するadmin/bill-id/client-id/*

をpub可能に指定する例


実際のpolicy記載例

前述の例であれば、client-id : gw01

topic:tkoya/A0001/gw01/*

と$aws/rules/*/gw01/*

が利用可能

Policyを正しく設計するためには、Topicデザインも重要



検討事項

• 認証

• policy設計



大量のIoT Thingを作する中での考慮

• 鍵情報の埋め込み• AWS IoT発行/持ち込み証明局から発行したデバイスの埋め込み

• Thing初回起動時のアプリケーション連携によるbootstrapping処理

• AWS への Thing 登録(実際のThingではなくcloudへ登録する仮想的なthing)

• Thing-nameとしてして利用するものの検討（serial-idやmac addressなど)

• ユーザ利用時に登録もしくは工場生産からのバルク登録


証明発行のパターン

1. AWS IoTによる証明書発行AWS IoTの権限、APIが発行できる環境が必要、事前に証明書、関連policy紐付けを完了させる

2. 持ち込みCAによる証明書発行発行の流れは1)と同じ、自分たちで証明書を生成出来るので証明書の期限がコントロール出来る点が1と比較したメリット

3. Just in time registration

デバイス証明書をoff line/AWSの操作権限なしで作成できる。事前にpolicy、証明書のアクティベートなどをしなくてもよく、自前認証局でdevice証明書を発行だけすれば良い

4. Bootstrapping

生産現場とCloudでどうしても連携が難しい場合の手段


bootstrappingの実装例

Amazon

DynamoDB

AWS IoT

AWS IoT

AWS

Lambda

response/topic

プリインする証明書のpolicyは初期化用のMQTT

topicのみが実行できるようにする初回ユーザ登録などと合わせてHTTP requestで証明書を生成して返却する

AWS

Lambda

device

device

Amazon API

Gateway

ユーザ情報登録や、製品チェックロジックの実装を行い証明書を発行

証明書発行

証明書発行

最終的にはdevice個別の証明書でMQTTセッションを再度作成

証明書情報


bootstrappingの実装例HTTPの場合はdeviceが直接ではなく、コンパニオンアプリでも実装可能

Amazon

DynamoDB

AWS IoT

AWS IoT

AWS

Lambda

response/topic

プリインする証明書のpolicyは初期化用のMQTT

topicのみが実行できるようにする初回ユーザ登録などと合わせてHTTP requestで証明書を生成して返却する

AWS

Lambda

device

device

Amazon API

Gateway

ユーザ情報登録や、製品チェックロジックの実装を行い証明書を発行

証明書発行

証明書発行

最終的にはdevice個別の証明書でMQTTセッションを再度作成

証明書情報


AWS IoTへのThing登録

AWS CLI/APIを利用

• 無料で利用可能、ただし秒間での呼び出しの制限がある点は注意

バルクプロビジョニング機能を利用

• templateを用意することで大量のThingの生成を一度にすることができる• 例えば工場で生産したThingのシリアルIDを一括でもらえる環境であるなどが必要

• 東京region利用で、1000デバイスあたり$0.12のコスト

https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/bulk-provisioning.html

https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_iot のAWS IoT Throttlingセクションを参照

https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/bulk-provisioning.html

https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_iot


運用

• アップデート(OTA)

• モニタリング/監査


運用

• アップデート(OTA)• アプリケーション

• 証明書関係



アプリケーションのupdate/OTA

IoT対応製品のupdate/OTAは

- IoT Device Management

- IoT Core shadow

- MQTT pub/sub

などで実現できる。

リアルタイム性が必要ない場合などは、HTTPSをベースにすることができる


DynamoDB API GatewayAWS IoT

Lambda

(4)状態をアップデート (1)アプリからアップデート要求

(2)DynamoDBストリームに更新内容をput

(3)AWS IoTにpublish

インテリジェントシャドウパターン(マルチshadowを利用している場合)

対象シーン - Web/スマホアプリなどからデバイスをコントロールしたい

条件 - shadowを利用している

注意点 - シャドウを利用することが必須(シャドウは8Kbの制約)

(5)Dynamoの仕掛りを完了に

shadowベースの管理デザインパターン


本デザインパターンでの残課題

1. shadow updateによる通知• 大量通知が必要でも１つ１つのデバイスのshadowをupdateする必要が

ある。• ３０万台 : ３０万回のDynamoDB write, Lambda実行、shadow

update API

• 例えば、スロットル回避でsleep(1)とすると、 30万秒 = 約3.5日くらいかかる• 効率的な配信のためのAPI発行プログラムの検討など

2. AWS IoTではなく、DynamoDBの状態が絶対• Shadowの状態を正として動くほうが論理不整合起きにくい


AWS IoT Device ManagementJobs: アップデート機能


運用

• アップデート(OTA)



AWS IoTのログ監視

IoT logv2がJSONフォーマットであるために、 CloudWatch Logs insightsのクエリも表現がしやすい。AWS IoT Coreのlog出力はデフォルトがdisableであるので、手動でenableする必要がある。

{ "timestamp": "2019-05-22 05:19:03.910", "logLevel": "INFO","traceId": ”hoge-fuga","accountId": ”xxxxx","status": "Success","eventType": "Publish-In","protocol": "MQTT","topicName": "device/room01/temp01","clientId": "test_device","principalId": ” certificate_id ","sourceIp": "35.167.x.x","sourcePort": 60631}

AWS IoT Core Amazon CloudWatchIoT thing


CloudWatch Logs insights活用例

AWSIoTLogsV2を選択

対象のフィールドを自動で判断@マークが無いものは@message内のJSON attribute


AWSIoTLogsV2を選択

対象のフィールドを自動で判断@マークが無いものは@message内のJSON attribute


CloudWatch Logs insights活用例

fields @timestamp, protocol, logLevel| sort @timestamp desc| limit 200


CloudWatch Logs insights活用例 (エラーのみ表示)

fields @timestamp| sort @timestamp desc| filter logLevel = ERROR| limit 200


AWS IoTにおける監査とは？

AWS IoT Device Defenderを活用することで以下の監査を簡単に実施することができる

Device Defenderとして以下などが用意されている

• 失効済み証明書を利用したアクセスの検知

• 複数デバイスから同一証明書を利用したアクセスの検知

• Congnito unauthを利用したAWS IoT thingに対する操作の検知

• AWS IoT のpolicyで “*”を利用した広域な権限を持つデバイスの検知

• 証明証期限が30日以内に迫ったデバイスの検知

https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/device-defender-audit.html

https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/device-defender-audit.html


廃棄

モバイルアプリの場合、ユーザ起因でのアプリ削除となるので、Cloudへの削除通知が来ないパターンが考えられる。

ユーザ削除などがあれば、削除契機でのThing削除/証明書無効化を実施

想定される業務

- Thing / 証明書の無効化、削除


まとめ

IoTの仕組みを作る中で重要なのことはThing(モノ)を如何にうまく管理するか？が重要となります。

IT視点で検討をすすめると、コンパニオンアプリやバックエンドのクラウドシステムが検討の中心となり、実際のThingについては忘れがちですが、IoTの要素としては最重要なファクターを持ちます。

ライフサイクルや、プロトコル、認証をThing、クラウド、コンパニオンアプリまで全体デザイン、ライフデザインを初期に検討することは重要です。


(Tips)推奨しないIoT API使い方例

アプリケーションからのコントロールプレイン(*)のAPIコールを許可- CreateThing/ UpdateThing / AttachPolicyなどのAPIは秒間に許されるAPIコールが数10や100程度のものが多い。AWS IoT スロットリングの制限を参照

(*) コントロールプレイン

boto3などのSDK、CLIでの “iot”のオブジェクトに含まれるAPI

対照的にアプリケーション/デバイスから使われるオブジェクトは”iot-data”のデータプレインとなる。

https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html


ご参考IoT Topicデザイン white paper

https://d1.awsstatic.com/whitepapers/Designing_MQTT_Topics_for_AWS_IoT_Core.pdf

IoT Lens

https://d1.awsstatic.com/whitepapers/architecture/AWS-IoT-Lens.pdf

GraphQL

(G-8) AppSync ユースケース/デザインパターン (10/4 17:00-17:45)

(BlackBelt)IoTデバイス管理

https://aws.amazon.com/jp/blogs/news/aws-black-belt-online-seminar-aws-iot-device-management/

IoT デザインパターン 2019(運用、管理)

https://pages.awscloud.com/rs/112-TZM-766/images/A2-02.pdf

https://d1.awsstatic.com/whitepapers/Designing_MQTT_Topics_for_AWS_IoT_Core.pdf

https://d1.awsstatic.com/whitepapers/architecture/AWS-IoT-Lens.pdf

https://aws-seminar.smktg.jp/public/session/view/585

https://aws.amazon.com/jp/blogs/news/aws-black-belt-online-seminar-aws-iot-device-management/

https://pages.awscloud.com/rs/112-TZM-766/images/A2-02.pdf


アンケートご協力のお願いお手持ちの受講票のアンケート用QRコードから

アンケートにお答えいただくと、記念品を差し上げております。

※イメージです

プレゼントの引き換えは、神田明神の会場出口付近（屋外）までお越しください

IT情報安全守護

2019 年 10 月 1 日〜11 月 5 日開催amzn.to/AWSInnovateJP

申し込み受付中

AWS 最新アップデート / コンテナ / AIML / AWS アンチパターン /

認定試験対策講座など60セッション

オンラインで参加できるカンファレンス、全 60 セッション

10/9, 10/15 ライブ配信AWS エキスパートへの

Q&A

修了証明書の発行業務時間に視聴

2019 年 10 月 1 日〜11 月 5 日開催amzn.to/AWSInnovateJP

Application Development

Container

Serverless

オンラインで参加できるカンファレンス、全 60 セッション

おすすめセッション

Thank you!


T O K Y O - pages.awscloud.com · WebフロントでAPI-Gateway / AppSyncの比較 API 認証方式...

Documents

Transcript of T O K Y O - pages.awscloud.com · WebフロントでAPI-Gateway / AppSyncの比較 API 認証方式...