LoRaWANとSORACOMFunnelのAWSIoTアダプタを使ってDynamoDBにデータを書き込む

はじめに

つい先日、SORACOMFunnelがAWSIoTに対応したというニュースを耳にしました
ちょうど仕事の関係でSORACOMのシールドが届いたし、会社にLoRaWANのPublicGWもあることだし・・・
ということでちょいと触ってみた
SORACOM公式ブログにも手順が書いてありましたが、ちょっと躓いたところがあったりしたので、まとめてみました

やりたいこと

  1. LoRaデバイスからLoRaゲートウェイを通ってAWSIoTにセンサーデータを投げる
  2. AWSIoTが受け取ったデータを加工するためのLambdaファンクションをキックする
  3. Lambdaがデータを加工してDynamoDBに格納する

SORACOM Funnelって?

SORACOM Funnel(以下、Funnel) は、デバイスからのデータを特定のクラウドサービスに直接転送するクラウドリソースアダプターです。
Funnel でサポートされるクラウドサービスと、そのサービスの接続先のリソースを指定するだけで、データを指定のリソースにインプット
することができます。

http://soracom.jp/services/funnel/より抜粋
要するに、デバイスからAWSなどのクラウド上に閉域網でデータを送信することができるサービス(合ってるかな・・・)

AWSIoTって?

AWS IoT によって、さまざまなデバイスを AWS の各種 Services や他のデバイスに接続し、データと通信を保護し、
デバイスデータに対する処理やアクションを実行することが可能になります。
アプリケーションからは、デバイスがオフラインの状態でもデバイスとのやり取りが可能です。

https://aws.amazon.com/jp/iot-platform/how-it-works/より抜粋
うーん、なるほどわからん。とりあえず使ってみよう

デバイス側の設定

同じ部署の電気系強いお方が気づいたらセッティングしていただいていましたので割愛
この時点でSORACOM Harvestにてデータが送信されているのを確認できている状態

AWSIoTの設定

Funnelでデータを送信する先のAWSIoTを作成します

エンドポイントを控える

Funnelを設定する際に必要なAWSIoTのエンドポイントを控えておきます

AWSIoT_TOP.PNG

Ruleを作成する

左のサイドメニューから「Rule」を選択し、「Create a rule」をクリック

AWSIoT_Rule.PNG

「Name」と「Description」を入力する(Descriptionは任意)

AWSIoT_Rule_name.PNG

「Attribute」に「*」、「Topic filter」に「IoTDemo/#」を入力
「Using SQL version」は「2016-03-23」で問題なければそのままでOK

AWSIoT_Rule_massage.PNG

「Set one or more actions」の「add action」をクリック

AWSIoT_Rule_set_action.PNG

今回はLambdaでデコードする必要があるため「Invoke a Lambda function passing the message data」を選択

AWSIoT_Rule_select_lambda.PNG

「Configure action」を選択

AWSIoT_Rule_select_lambda_button.PNG

キックするLambda Functionを選択
今回は初めて作成するので、Lambdaが呼ばれたときのeventの中身をログに吐き出すLambdaを作成して、それをキックするようにします
※DynamoDBに格納する処理は後ほど実装

「Create a new resouce」をクリック。Lambdaのページに遷移します

AWSIoT_Rule_lambda_create.PNG

「Blank Function」を選択

Lambda_create.PNG

Lambdaのトリガーを設定
「IoTタイプ」は「カスタムIoTルール」を選択
「ルール名は」現在作成中のルール名
「SQLステートメント」は作成中の「Rule query statement」の中身をコピー
「次へ」をクリック

Lambda_trigger.PNG

「名前」はお好きなFunction名をつけてください
「ランタイム」は筆者の好みによりNode.jsです
コードには

exports.handler = (event, context, callback) => {
    console.log(event);
};

と書いておいてください。

Lambda_setting.PNG

あとは、DynamoDBの権限を持ったロールを選択(作成)して、ページ下部の「次へ」をクリックしてLambdaFunctionを作成してください

AWSIoTのページに戻って、先ほど作成したLambdaFunctionを選択し、「Add action」をクリック

AWSIoT_Rule_add_lambda.PNG

その後「create Rule」をクリックするとRuleが作成されます
これでAWSIoTのRule作成が完了です

SORACOM Funnelの設定

まず、SORACOMコンソールにログインし、再度メニューから「LoRaグループ」⇒「追加」をクリックします
ポップアップが出てきてグループ名を入力するように言ってくるので、任意のグループ名を入力しグループを作成します

作成したグループを選択し、設定画面に移動します

転送先サービス:AWS IoT
転送先URL:https:///rule内で作成したSQLTopicFilter/#{deviceId}
認証情報:AWSIoTの権限を持ったIAMアカウント情報で作成したもの
送信データ形式:無難にJSON

funnel_setting.PNG

※転送先URLにはプレースホルダーを作成することができます
  - SIMを利用する場合:{imsi}
  - LoRaデバイスを利用する場合:{deviceId}

これでFunnelの設定は完了です

Lambdaの実装

デバイスの電源を入れ、データが送信されるようになると、Lambdaが起動してeventの中身をログに吐き出していると思います
↓こんな感じ

2017-06-23T04:13:59.850Z 62014535-57ca-11e7-b4e4-9fbd147f2037 { 
  operatorId: '0123456789',
  timestamp: 1498191237793,
  destination: { 
    resourceUrl: 'https://xxxxxxxxx.iot.ap-northeast-1.amazonaws.com/xxxxxxx/#{deviceId}',
    service: 'aws-iot',
    provider: 'aws' 
  },
  credentialsId: 'iot-sys',
  payloads: { 
    date: '2017-06-23T04:13:54.276320',
    gatewayData: [ [Object] ],
    data: '7b2268223a36312e367d',
    deveui: '1234567890' 
  },
  sourceProtocol: 'lora',
  deviceId: '1234567890' 
}

センサーから送られてくるデータはevent[“payloads”][“data”]にHEX形式で格納されているので、取り出してデコードする必要があります。


const data = event["payloads"]["data"];
const decodeData = new Buffer(data, "hex").toString("utf8");

デコードすると「7b2268223a36312e367d」⇒「{“h”: 61.6}」のようなString型になります(これは一例)

Object型のほうが使い勝手がよいので、parseしてしまいましょう


const parseData = JSON.parse(decodeData); // {h : 61.6}

あとはDynamoDBにputで投げつけます

index.js
"use strict";

const AWS = require("aws-sdk");
const co = require("co");
const moment = require("moment-timezone");

const dynamodb = new AWS.DynamoDB.DocumentClient({
  region: "ap-northeast-1"
});

const dynamoPutData = require("./lib/dynamo_put_data");

exports.handler = (event, context, callback) => {
  // UTCなのでJSTに変換
  const date = event["payloads"]["date"];
  const time = moment(date).tz("Asia/Tokyo").format();
  // HEX形式をデコード
  const data = event["payloads"]["data"];
  const decodeData = new Buffer(data, "hex").toString("utf8");
  // Object型に変換
  const parseData = JSON.parse(decodeData);
  // deviceIdを取得
  const deviceId = event["deviceId"];

  // DynamoDBにPUTするItem
  const item = [{
    deviceId: deviceId,
    time: time,
    value: parseData
  }];

  co(function *() {
    yield dynamoPutData.putDynamoDB(dynamodb, item[0]);
  }).then(() => {
    console.log("success!")
  }).catch((err) => {
    console.log(err);
  });
};

dynamo_put_data.js
"use strict";

class dynamoPutData {
  /**
   * DynamoDBへのPUT処理
   * @param {DocumentClient} dynamoDB
   * @param item
   * @returns {Promise}
   */
  static putDynamoDB(dynamoDB, item) {
    const params = {
      TableName: "TABLE_NAME",
      Item: item
    };
    return dynamoDB.put(params).promise();
  }
}

module.exports = dynamoPutData;

dynamo_put_data.js中の”TABLE_NAME”にはデータを投げつけるテーブル名を書いてください
関数を外だしして複数ファイルがあるので、Lambdaにはソースコード一式をZIPに固めてアップする方法でデプロイを行います
データが送られてきてLambdaがキックされると、DynamoDBにデータが格納されていると思います

まとめ

日ごろからAWSのサービスを使っていましたが、AWSIoTを利用する機会がなくとてもいい経験になりました。
今回はデバイスからクラウドといった方向でしたが、AWSIoTを利用すればその逆方向も実現することができるらしいので、近々そういった実装もしてみたと思います

では!

続きを読む

AWS 認定ソリューションアーキテクト – アソシエイト 合格までに勉強したこと

概要

AWS 認定試験には「これを勉強すればいいよ!」という教科書があるわけではないので、何を勉強したらいいか分からず困っている人も多いと思います。
なので、私の勉強記録を共有します。

勉強前のスペック

AWSの初級者です。
EC2インスタンス起動やEBSのスナップショット取得の経験があるくらいでした。

勉強方法概要

AWS活用本を一冊読んで、
あとはAWS クラウドサービス活用資料集にある BlackBelt のスライド(PDF)を淡々と読みました。

その後、模擬試験を受けて本試験を受験しました。

勉強方法詳細

少し前に買っていた以下の本を読みました。分かりやすいです。

Amazon Web Services 定番業務システム12パターン設計ガイド

BlackBelt

自分が読んだ資料に○を付けました。
また、模擬試験と本試験を受けた経験から、各資料の重要度を評価しました。
※当たり前ですが、読んでいない資料の重要度は評価していません。また、重要度の正確性も保証しません。

コンピューティング

資料 読んだ  重要度 
[Amazon EC2] 
[Amazon EC2] Windows
[Amazon EC2] HPC
[Amazon EC2] リザーブドインスタンス
[Amazon EC2] スポットインスタンス
[Amazon EC2] Instance Store & Elastic Block Store
[Amazon EC2] VMImport/Export
[Elastic Load Balancing]
[Elastic Load Balancing] ロードバランサと Socket 接続を使用したイベント通知サーバの負荷分散
[Elastic Load Balancing] ELBを評価するためのベストプラクティス
[Auto Scaling]
[Amazon EC2 Container Service]
[AWS Elastic Beanstalk]
[AWS Lambda]
[AWS Lambda] update
[Amazon Lightsail]
[AWS Batch]

ストレージ & コンテンツ配信

資料 読んだ  重要度 
[Amazon EBS]
[Amazon S3] 
[Amazon CloudFront]
[Amazon CloudFront] Flash Media Server on AWS
[Amazon CloudFront] CloudFront 上限緩和申請 計算方法&申請手順
[Amazon CloudFront] まだ間に合う! Amazon CloudFront で ATS 対応
[Amazon Glacier]
[Amazon Glacier] 機能編
[AWS Storage Gateway]
[Amazon Elastic File System]

データベース

資料 読んだ  重要度 
[Amazon RDS]
[Amazon RDS] Aurora
[Amazon DynamoDB]
[Amazon ElastiCache]
[Amazon ElastiCache] Redis QA資料
[Amazon Redshift] 
[Amazon Database Migration Service]

ネットワーキング

資料 読んだ  重要度 
[Amazon VPC]
[Amazon VPC] VPN接続設定 参考資料
[AWS Direct Connect] 
[Amazon Route53]

開発者用ツール

資料 読んだ  重要度 
[AWS CodeCommit]
[AWS CodeBuild]
[AWS CodeDeploy]
[AWS CodePipeline]
[AWS SDK]
[AWS SDK] Java & .NET
[AWS SDK] PHP & Ruby & Boto(Python) & Javascript in Node.js
[AWS SDK] AWS Client side SDK Android & iOS & Javascript
[AWS CLI]
[AWS AWS Tools for Windows Powershell]

管理ツール

資料 読んだ  重要度 
[Amazon CloudWatch]
[AWS CloudFormation]
[AWS CloudTrail]
[AWS Config]
[AWS OpsWorks] AWS OpsWorksのご紹介
[AWS OpsWorks]
[AWS OpsWorks] ハンズオン
[AWS Service Catalog]
[Trusted Advisor] AWS サポート & Trusted Advisor
[Amazon EC2 Systems Manager]

セキュリティ & アイデンティ

資料 読んだ  重要度 
[Identity and Access Management (IAM)] 
[AWS CloudHSM] CloudHSM & Key Management Service
[AWS Key Management Service]
[AWS Directory Service]
[Amazon Inspector]
[AWS WAF]
[AWS Certificate Manager]

分析

資料 読んだ  重要度 
[Amazon EMR(Elastic MapReduce)]
[AWS Data Pipeline]
[Amazon Elasticsearch Service] Amazon CloudSearch & Amazon Elasticsearch Service
[Amazon Kinesis]
[Amazon QuickSight]
[Amazon Athena]

AI

資料 読んだ  重要度 
[Amazon AI]]

IoT

資料 読んだ  重要度 
[AWS IoT]

ゲーム開発

資料 読んだ  重要度 
[Amazon Lumberyard]

モバイルサービス

資料 読んだ  重要度 
[Amazon Cognito]
[Amazon Cognito] Amazon Cognito update
[Amazon Cognito] Amazon Cognito / Amazon Mobile Analytics
[AWS Device Farm]
[Amazon Mobile Analytics] Amazon Cognito / Amazon Mobile Analytics
[Amazon SNS] Amazon SNS/SQS
[Amazon SNS] モバイルプッシュ通知
[Amazon Pinpoint]  

アプリケーションサービス

資料 読んだ  重要度 
[Amazon API Gateway] 
[Amazon AppStream]
[Amazon CloudSearch] Amazon CloudSearch & Amazon Elasticsearch Service
[Amazon Elastic Transcoder]
[Amazon SES]
[Amazon SES] Amazon SES-Easy DKIM 設定サポート資料
[Amazon SQS] Amazon SNS/SQS
[Amazon Simple Workflow Service (SWF)]

エンタープライズアプリケーション

資料 読んだ  重要度 
[Amazon WorkSpaces]
[Amazon WorkDocs]
[Amazon WorkMail]
[Amazon Chime]

その他

資料 読んだ  重要度 
[Cost Explorer]
[AWS Management Console]

補足

重要度の低い資料も読んだ方がいいです。
なぜなら、マネージドサービス自体がAWSの活用事例であり、それらを知ることでシステム設計の勘所が分かるようになるからです。
また、重要度の高い機能との連携についての記載があることもあり、理解が深まります。

続きを読む

AWS Summit Tokyo 2017 参加レポート Day4 (6/2)

会社の外部研修として『AWS Summit Tokyo 2017』に6月1日(木)~2日(金)の計2日間参加して来ました。

当エントリでは6月2日(Day4)に聴講した内容をレポートします。(Day3のレポートはこちら
※注)記事には個人的なメモや感想が含まれています。予めご承知ください。


展示ブース見学1 (9:00 ~ 10:00)

基調講演開始までの待ち時間、Pavilion 展示ブースを見て回りました。

立ち寄ったブース

  • IoT.kyoto

  • Sony Global Education:KOOV

    • 子供向けIoT学習キット
    • レゴブロックのようなパーツを自由に組み合わせ
    • アプリで日本語による論理パズルのようなものを使いビジュアルプログラミング
  • tv asahi:MP360LIVE
  • レコチョク:RECOLab
  • PIXELA:パノミル
    • VRコンテンツ配信プラットフォーム
  • AUCNET:Andy ニコパス
    • 来店客などの顔認識⇒LINEやSlackなどで通知&顧客管理
    • オフィスなどの入退室管理にも
    • 感情なども判別
      • 顧客満足度のデータ化
      • 従業員のストレスチェック

基調講演(Key Note) (10:00 ~ 11:30)

スピーカー:茂木 健一郎 氏 (脳科学者)

>人工知能、”Innovation” をテーマにトーク

もはやAIと人間の脳を比較すること自体がナンセンス

 人間の意識:128bit/sec 説
  チェス等⇒チャンピオンの一生分を機械なら~1か月?
  人間=並列処理 限界ある:AI並列化し放題
 e.g. 雪道走行経験欲しい ⇒自動運転=雪国からデータを持ってくればいい

人間の脳ってみじめじゃないですか?

 ギブソン:アフォーダンス理論
  >「脳は情報処理不要」「情報は環境の中にある」

Amazon Echo早く日本で出ない?遅れてますよね

 MIT 子供の過去三年間の会話データを全て記録した話
  >BigData、機械学習で出来ること、可能性は計り知れない

人間の脳なんてもう気にしなくていい

 人工知能と人間の恋の映画
  >AI:「今2万人と同時に会話してる」「数百人と恋に落ちてる」

なんだかAIに申し訳ないなって思いました

重要なのは個性

人間の感情・パーソナリティのデータモデルはまだない
 パーソナリティ5大要素⇒人工知能にインプリメンテーションまだ無理
  ⇒ソース:由来がわからない(⇔脳の情報処理の動きは比較的判明している)

人工知能が目指すものは人間の脳とはおそらく違う

 SNSなど今のシステム⇒人間のアテンションによりすぎ

 近代平均IQは上がり続けてる
  ⇒情報処理が増えたからと言われる
   ⇒それで人間は幸せになっている?

 現代はリアルとサイバースペースの二重生活
  ⇒リアルを整理するコスト=わずらわしい(Amazon robotics Home欲しい)
   ⇒メールなど=まだ人間のアテンションが必要

 Amazonでショッピング(本、靴、ズボンなど)
 ⇒勝手に買っておいてほしい(サイズ、好みなどの把握)
   心地よさのスクリーン

 子供の脳が最高(ルーティンがない、大人がやってくれているから)
  大人はつまらない
 AIが仕事を奪う⇒歓迎、ルーティンワークは任せるべき
  ⇒遊んでいるだけの人間が一番クリエイティブ
  天才の遺伝子はない(突然変異?)
  アメリカの功績は遊ぶように働くスタイルを確立したこと

 未来の義務教育の内容
  ⇒ほぼAIがやってくれる
   ⇒小学から論文など始めるのもあり

 人間の最終目標⇒幸せになること

子供のころ無邪気に遊んでた頃が幸せじゃありませんでした?

エンジニアへ

これからのイノベーションの主役はあなた方
人間の脳、キャパシティなんて気にせず
 個性を大事に
新しいものを産み出していってほしい

スピーカー:Kris Davies 氏 (Amazon Dashサービス シニア・プロダクトマネージャー)

IoTはあらゆるレベルの変革を可能に

ショッピングのイノベーション

 (昔)店舗⇒PC⇒スマホ⇒IoT:Dashボタン(今ここ)⇒ゼロクリック(Next!)

 店でよくあること=買うものを忘れる
 ・メモを忘れる
 ・消耗品のストックを忘れる
 ・既に買ったものを忘れる

 Dash Replenishment Service(DRS)
 スマート家電
  e.g. 掃除機>ゴミパックの状態を把握⇒クラウドに
      ⇒満タンになりそう⇒自動検出して替えを発注

  • 家庭には多くのデバイス(=変革の種?)がある

    • 「もし」ではなく「いつ」が検討すべきポイント
  • カスタマーからのフィードバックが大切
  • 全てのネット接続されたデバイスが役に立つわけではない
    • 本当に役立つ「モノのインターネット」を

スピーカー:Jeff Blankenburg 氏 (Amazon Alexa Evangelist)

Alexa
 スマートホーム
 デバイスに話しかける

ALEXA エコシステム
 スキル(ASK):デベロッパーが作成可能

音声⇒テキスト⇒自然言語解析⇒意図からスキルを探す⇒処理⇒レスポンス

ボイスエクスペリエンスのデザイン⇒開発⇒テストと認証

意思の解析が難しい
 e.g. 天気予報の取得⇒言い方がいろいろある
 e.g. テレビのリモコン⇒ボタン単位でコード化を考える

スピーカー:Andy Pollock 氏 (Amazon Robotics Software Development Manager)

Amazon Robotics

 e.g. 大図書館から本を探す状況
  ⇒手をかざしたら本が降ってくる を想像/創造した

Amazon 倉庫内で起きていること

 商品入荷⇒Podに収納⇒棚ごと移動⇒保管場所へ
  注文⇒担当者のもとに棚自身が来る⇒梱包、出荷

効率化アルゴリズム

数え切れないほどの商品の種類・数万単位の同じ商品
 ⇒どれを取りに行くか?
 動かす棚、ロボットの判定
  ⇒商品自身の位置だけじゃなく、間の障害物、作業員、一度に運べる個数など
   ⇒複雑な演算が必要
    ⇒AWS使用

次のイノベーションへ

「Its stil day one」(我々はまだ”1日目”である)

クロージング

Amazon

「どうか一つでも多く、イノベーションの種をお持ち帰りください」


展示ブース見学2 (12:00 ~ 14:00)

続いてDay3では回れなかったEXPO 展示ブースを見て回りました。
ついでに認定者ラウンジに立ち寄って昼食と、前日貰い損ねた折り畳み傘をGET。

立ち寄ったブース

  • Datadog Inc.

    • サーバ運用監視・モニタリングツール
    • AWS以外も対応サービスの数がスゴイ
  • 日商エレクトロニクス株式会社:New Relic
    • サーバ運用監視・モニタリングツール
    • 上記Datadogと競合
  • ソニーネットワークコミュニケーションズ株式会社:Cloud Portal
    • AWSサービスの構成管理ツール
    • 実際の設定から構成図などのドキュメントを生成可能、PDF出力も可(←この機能欲しかった)
  • 株式会社インターナショナルシステムリサーチ:CloudGate KeyManager
    • サーバ接続するユーザとSSH鍵を一括管理するツール

      • 有効期限付きのSSH Key発行・管理
      • 鍵の受渡し⇒指紋認証・2要素認証・ワンタイムパスワードなど選択可
  • パロアルトネットワークス株式会社
  • 富士ソフト株式会社
    • ストレスの度合?をリアルタイムで測定するIoTデバイスのデモを見せて頂いた
    • モニタリングした心拍数に数学的な処理・フィルタリングを施しグラフにして可視化?
      • 詳しく説明して頂いたが正確に理解出来たか怪しい
  • クラスメソッド株式会社

    • 日本のAWSユーザでこちらの会社のブログ記事を読んだ事が無い人はいないと思う
    • AWSおみくじを引かせて頂いた(結果はELBとt2.nanoでした;)

AWS Dev Dayの会場へ移動

Session:サーバレスで王道 Web フレームワークを使う方法 (14:20 ~ 15:00)

スピーカー:塚田 朗弘 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

サーバレスアーキテクチャでアプリケーションを開発するとき、いつも使っているフレームワークをそのまま使うことができたら嬉しいと思ったことはないでしょうか。AWS Lambda では Node.js、Python、Java、C# といったプログラミング言語をサポートしています。このセッションでは、AWS のサーバレスアーキテクチャ上で代表的な Web アプリケーションフレームワークを使う実践的な方法をご紹介します。

Express.js on serverless

aws-serverless-express使用

npm install aws-serverless-express

app.js ⇒ lambda.js に変更

Spring Framework on serverless

aws-serverless-java-container使用

コードサンプル

どちらも Code Star にプロジェクトテンプレートあり
 ⇒手軽に始められるので是非


Session:[タワーズ・クエスト]Serverless 時代のテスト戦略(仮) (15:20 ~ 16:00)

スピーカー:和田 卓人 氏 (タワーズ・クエスト株式会社 取締役社長)

セッション概要(タイトルリンク先より引用)

Serverless 時代においても、自分のコードにテストは書きたいものです。まだベストプラクティスが確立されていない Serverless 時代のテストを考えていきます。

レガシーコードのテストをかいてみる

お題:lamdbaの公式チュートリアルにテストをつける

このコードはtestableだろうか?
デプロイなし、ローカルでテストしたい!

サイズとピラミッドとループ

テスト自動化ピラミッドとアンチパターン

“Test Sizes” at Google
https://testing.googleblog.com/2010/12/test-sizes.html

small:ネットワーク、データベース、ファイル、全てのI/Oなしの独立したテスト
medium:ネットワークはlocalhostのみ、外部サービスは非推奨
large:外部サービスも含め、本番と同じ条件のテスト

テスト数:small > medium > large

small:例外系テスト

medium:ローカルテストするには ⇒FakeObjectが鍵

  • Test Double(テストの為の”代用品”)

    • Test Stub
    • Test Spy
    • Mock Object
    • Fake Object
    • Dummy Object

 https://github.com/atlassian/localstack を活用
  ⇒各種AWSサービスのローカルテスト用Fake実装

レガシーコードのジレンマ
 多くの場合、テストを描くにはコードを変更する必要がある

教訓:テストしてないコードは動かない

large:運用監視とは継続的なテスト
 品質の良いシステム
 ・バグが少ない
 ・すぐになおる

本番環境の不具合をテストに写し取る
不具合が出たら再現テストコードを書いて、落ちることを確認してから修正コードを書く

サービス間(E2E)テスト

= XLarge Test (largeの上)

マイクロサービス間テストの課題
 >モックのリクエストやレスポンスが本番と異なる為、テストは通るが本番で落ちてしまう可能性。
 ⇒Consumer-Driven Contracts testing (CDCテスト)

pactを使ったCDCテストをCIで回す
 >Consumer側をMock/Stub感覚で書く


メイン会場へ移動

Session:[ソニーモバイルコミュニケーションズ] スマートホームシステムの開発 〜AWS を活用した新規サービスの立ち上げ〜 (16:20 ~ 17:00)

スピーカー:井宮 大輔 氏 (ソニーモバイルコミュニケーションズ株式会社)

セッション概要(タイトルリンク先より引用)

新規サービスは受容性が分からないため契約者数の予測が難しく、初期開発投資をなるべく抑え素早く市場に投入することが要求されます。上記を実現すべく、スマートホームシステム開発では AWS を最大限に活用しました。本セッションでは、システム開発において直面した課題と、それを AWS IoT などのサービスを用いていかに解決したかについてご紹介します。

スマートホームシステム

コンセプト
 家庭内デバイスをネット接続
  ⇒データ収集
   ⇒適切な制御

“スマートホームHub”を通してデバイスを制御

最大の課題=セキュリティ
 ・家族(ユーザ)の認証
 ・デバイス認証

 アカウント管理・認証
  ・ユーザ管理
  ・トークンアクセス
  ・パス、Email変更

1.ユーザ認証
 ⇒Cognito User Pool使用
  ・自前のユーザアカウント可
  ・SMS、MFAが実現可能
  ・カスタム属性で独自のデータ追加可能

2.デバイス認証
 ⇒AWS IoT使用
  デバイス数万台分のThingを作成
  ⇒工場でクライアント証明書・暗号鍵埋め込み
   ⇒一台ずつポリシーを作成(他のデバイスの機能にアクセス不可)

3.メッセージ 双方向通信
 ⇒IoT Topic・ルール使用

4.データ同期
 IoT Thing Shadow
  課題:最大8KB
   ⇒一つのデバイスに複数のThingを対応させて解決


Session:AWS マネージドサービスで実現する CI/CD パイプライン (17:20 ~ 18:00)

スピーカー:千葉 悠貴 氏 (AWSジャパン株式会社 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

CI/CD ツールは DevOps の実践に不可欠なものですが、ツール自体の構築・運用は不可価値を生まない重労働です。AWS のマネージドサービスを使うことで、開発者は自社ビジネスに価値を与える開発に集中できます。本セッションでは、AWS CodePipeline や AWS CodeBuild といった DevOps サービスの概要と、その他の AWS マネージドサービスを組み合わせた CI/CD の実践方法をご紹介します。

CI/CDを実現する”ツールとしての”AWSサービス

CI:継続的インテグレーション

フロー
1.Source>2.Build>3.Test>4.Production

必要なもの

・ソースコードのVer管理:CodeCommit
・ビルド自動化:CodeBuild
・デプロイ自動化:CodeDeploy/Beanstalk/Formation
・ワークフロー管理:CodePipeline

全て東京リージョンで使用可

⇒4つを統合したサービス:CodeStar(現在USのみ)
 ほぼ2ステップで完了
 ・Step1.プロジェクトテンプレート選択
 ・Step2.開発ツールセットアップ
  ⇒パイプライン作成
  ⇒ダッシュボード作成(JIRA統合メニュー)

CD:継続的デリバリー

安全に本番環境にデプロイ
 リリース判断/タイミング

本番環境の継続的監視・デプロイ判断

1.シンセティックトラフィックでの常時監視
  CloudWatch+Lambdaで定期実行

2.デプロイメントヘルスチェック・ロールバック
  CodeDeployの機能を使う
   ・ValidateServiceフック
   ・Minimum Healthy Hosts
   ⇒失敗と判断⇒自動でロールバック

3.デプロイ単位のセグメンテーション
  カナリアデプロイ:部分的に適用⇒運用してみてから範囲を広げていく手法
  CodeDeploy
   ・デプロイメントグループ(セグメント分割)
  CodePipeline
   ・Approvalアクション:管理者にSNSで通知する機能(Lambdaに渡せば完全自動化可能)

4.プロダクション昇格の無効化
  デプロイ先ホストの健全性を確認してからデプロイする
   ⇒本番環境の一部に問題があればリソースを無効化
  CodePipeline
   ・トランジションの無効化

5.BlackDayゲート
  ビジネス的にセンシティブな時期/時間を考慮
   パイプラインにデプロイ停止日のカレンダーを導入
    ⇒e.g. LambdaでDynamoDB上のカレンダーを参照など

「CodePipeline をカスタマイズすることでビジネスに最適な CI/CD パイプラインが作れる」


所感・備忘録

  • 基調講演待ってる間に周れるとこは周るべし
  • 基調講演は情報・刺激の宝庫
  • 講演者についてもっと事前に調べておく
  • AWSの方のセッションはそろそろ上級向けに絞ってもいいかもしれない
    • 初級~中級はググればすぐ出てくる内容がそこそこ
  • Dev Dayはコアな内容(コードとか)まで突っ込んでくれるので実入り多し
  • 夜イベントは早めに行く(公演優先して後から行ったら料理が既になかった;)
  • Twitter情報は重要、なるべくチェック
  • 会場のWifiは時々繋がらなくなる(キャパのせい?)
  • やはりAWSサミットは楽しい
    • 来年も、出来れば全日参加したい

続きを読む

AWS Summit Tokyo 2017 参加レポート Day3 (6/1)

会社の外部研修として『AWS Summit Tokyo 2017』に6月1日(木)~2日(金)の計2日間参加して来ました。

当エントリでは6月1日(Day3)に聴講した内容をレポートします。(Day4のレポートはこちら
※注)記事には個人的なメモや感想が含まれています。予めご承知ください。


基調講演(Key Note) (10:00 ~ 11:30)

ホストトーク:オープニング

by Werner Vogels 氏 (Amazon.com CTO)

  • AWSは急速に成長している

    • 成長率はIT企業の中でもTOP
    • 毎月のユーザー増加数 = 日本では10万以上
    • 各国のリージョン、AZ、エッジロケーションも随時拡大中
  • 本イベントを通してAWSを色々学んで行って欲しい。

気になったワードメモ

  • AWS Activate
  • One Amazon
  • Osaka リージョン開始

ゲストトーク:株式会社ソラコム

by 安川 健太 氏 (株式会社ソラコム 最高技術責任者)

SORACOMのサービス展開

IoTはネットワークセキュリティが課題
>3G/LTE網でInternetに出ないIoTネットワーク(デバイスとクラウドの直接接続)を提供

SORACOM Funnel
>デバイスからクラウドへのデータ転送を疎結合に管理
 利用例:デバイス>Funnel>Kinesis>Lambda>AWS IoT
  ⇒Funnelから先の切り替え(=新サービス追加など)が容易

ホストトーク:AWS – SUPER POWERS 1

by Werner Vogels 氏 (Amazon.com CTO)

「AWSは開発者に『SUPER POWERS※』を与える。」 (※ネタ元:スーパーマン)

SUPER POWER – ‘SPEED’ (超音速)

  • EC2新インスタンス:F1(FPGA利用可)
  • 今の時代 検索は必須>Elastic Search等ですぐに実装可
  • CloudはInfraへの関心を省き、Productに集中させてくれる>開発を加速
  • AWSは色々な選択肢を提供>ビジネスに合わせて適切なものを

ゲストトーク:NTT東日本

by 中村 浩 氏 (東日本電信電話株式会社 取締役)

CloudGateway re:connect
>FLETS光の高速・閉域網でAWSと再接続

社内で開発・利用して便利だったものを社外にも利用してほしい
クラウドと企業間の距離が一番近い国に

ホストトーク:AWS – SUPER POWERS 2

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘INVISIBILITY’ (目に見えない)

⇒開発者がインフラを気にしなくていい ⇒サーバーレス機能群紹介

  • AWS Lambda

    • サーバーレスコンピュート
  • AWS Step Functions
    • ビジュアルワークフローで分散アプリケーションのコンポーネント管理
  • AWS X-Ray
    • 分散アプリケーションの分析とデバッグ
  • Amazon DynamoDB Accelerator(DAX) :new:
    • 完全マネージド型インメモリキャッシュクラスタでクエリ超高速化

ゲストトーク:ソニーモバイルコミュニケーションズ

by 川西 泉 氏 (ソニーモバイルコミュニケーションズ株式会社 取締役 EVP)

SonyモバイルのIoTへの取り組み:『カーリングビジネスの実現』

製品紹介
– XPERIA Ear
– XPERIA Touch
– XPERIA Agent
  >http://av.watch.impress.co.jp/docs/news/1018278.html

スマートホームシステム
 AWS IoTを活用
 製品例:自宅のLED照明>センサーで子供の帰宅感知>仕事(外出)中の親に通知>LED付属のスピーカで会話

ホストトーク:AWS – SUPER POWERS 3

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘FLIGHT’ (飛び立つ)

IoTデバイスはサーバを必要としない

  • AWS Greengrass
     ⇒サーバ側の役目だった処理をローカルで構築可能に

これまでのデータベース=実機やベンダー由来の様々な制約や障害があった
クラウド+オープンソースのDBで”制約”から飛び立とう

  • AWS Database Migration Service
  • Amazon Aurora
    • 完全MySQL互換のRDB
    • PostgreSQL互換も提供開始

ゲストトーク:グリー株式会社

by 藤本 真樹 氏 (グリー株式会社 開発・人事統括 取締役 執行役員常務 CTO)

オンプレで10年運用してきた環境をクラウドへ移行した話

技術選択の判断は難しい、基準には色々な軸がある
敢えて上げるならば、”is that faster?”
>速さは裏切らない(コンピュータが速くて困ることは絶対にない)

⇒ AWS(の機能やサービス展開速度)はこれらに応えられる

ホストトーク:AWS – SUPER POWERS 4

by Werner Vogels 氏 (Amazon.com CTO)

SUPER POWER – ‘X-RAY VISION’ (透視)

⇒ データの集計・可視化

  • Amazon Athena

    • S3に保存されたデータを標準SQLで簡単に分析
  • Amazon EMR
    • Hadoopなどのビッグデータフレームワークを手軽に実行・分析可能
  • Amazon Redshift
    • 複雑なクエリ・超高速パフォーマンスを提供するペタバイト級データウェアハウス
  • Amazon Redshift Spectrum :new:
    • S3のデータを直接クエリ可能
    • エクサバイト規模のクエリ>Hiveで5年想定の処理を155秒で完了

SUPER POWER – ‘PRECOGNITION’ (予見)

⇒ Amazon AI – 人工知能サービス

  • Amazon Machine Learning

    • カスタム予測モデルの学習
  • Amazon Rekognition
    • 画像から顔と感情を認識
  • Amazon Polly
    • 文章をリアルな音声に変換(感情付加など)
  • Amazon Lex
    • 自動音声認識・自然言語理解

SUPER POWER – ‘IMMORTALITY’ (不朽)

⇒ スタートアップ企業生き残りの鍵 =『デジタルトランスフォーメーション』

AWSは『イノベーション』を続ける


AWS 認定試験 (12:30 ~ 13:50)

Summit特設会場でソリューションアーキテクトアソシエイト試験を受験(特典の50%OFFクーポン目当てです ^^; )

試験終了後すぐに認定者限定ラウンジに行ってみましたが、ノベルティの折り畳み傘はとっくに品切れでした;;
やはり一日数量限定は午前中に行かないと無理な模様。( ⇒ Day4で無事GET!!)

限定ラウンジではお菓子や飲み物が無料、座ってPCなどの充電が出来て中々快適でした。
モニタなど設置して講演中のセッションを視聴できればいいなと考えましたが、逆に人が溢れて寛げなくなりそう?


Session:『AWS Shield と AWS Lambda@Edge で構築するセキュアで柔軟性の高いアプリケーション』 (14:20 ~ 15:00)

スピーカー:Prasad Kalyanaraman 氏 (Vice President, AWS Edge Services)

セッション概要(タイトルリンク先より引用)

AWS Edge Services では、Amazon CloudFront に加え、AWS Shield、 AWS Lambda@Edge などの革新的な新サービスを発表しています。本セッションでは、AWS Shield の DDoS 防御機能と、AWS Lambda@Edge の CDN 上でのスクリプト実行により、セキュリティを担保しつつ柔軟でカスタマイズ性の高いアプリケーションの実現方法をご紹介します。

エッジでのセキュリティ活用

セキュアコンテンツ配信にCloudFrontが使える
 >エンドユーザー付近をセキュア通信の終端にする

Lambda@Edge

=Lambda関数のデリバリーサービス
 ・Bot 判定
 ・バリデーション
 ・認証処理
  ⇒エンドユーザ付近で実行できる
 ・ユーザ毎にコンテンツカスタマイズ可能
  e.g.
   ・PC/モバイル判定>アクセス先分岐
   ・エッジでHSTSヘッダを埋込み

DDoS対策 (スクラビングセンター)

 >AWS Shield (全Edgeロケーションで使用可)
  >Standard
   ・エッジで攻撃を検知し、遮断
   ・リアルタイムで悪意のあるトラフィックを検出
   ・無料で自動適用
  >Advanced
   ・攻撃データの可視化、およびイベント後の分析と調査を容易に
   ・DDoS攻撃で請求金額が跳ね上がるのを防ぐ「DDoS コスト保護」
   ・専門サポート
   ・有料

AWS WAF

 >L7(アプリケーションレイヤー)防御
 >Lambdaで独自のセキュリティチェック可 (e.g. 特定のIPを一定時間ブロック等)


Session:『Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム』 (15:20 ~ 16:00)

スピーカー:松田 和樹 氏 (株式会社インティメート・マージャー 開発本部)

セッション概要(タイトルリンク先より引用)

インティメート・マージャーではビジネスの都合上、50 種類ものジョブワーカーを運用しております。増え続けるビジネス要件に対応するため、Amazon ECS と SpotFleet を軸に Amazon S3、Amazon SQS、Autoscaling を組み合わせることで、低コストかつスケーラブルな docker 基盤を構築致しました。本セッションでは、その docker 基盤を中心にお話しします。

公演に使用されたスライドが公開されてます。

構築背景

  • 20以上の社外システムとデータ受渡し

    • 異なるデータ形式
    • 異なる接続方式
  • データ肥大化
    • スケールする仕組みが必要
    • 特定のジョブのみスケールさせたい

第一世代

処理フロー

S3ファイルUP>イベントをSQS通知>Cloud Watchでキュー数監視>EC2のワーカーをAutoScaling (Spot)
 >SQSキュー&S3ファイルを取得し処理>後続処理は別のS3へ

課題

  • スポット高騰時など特定のワーカーが起動不可となる
  • リソース(InstanceType)効率が悪い
  • 待機時間が長い
  • スケーリング設定多く、運用負荷高い

第二世代

変更点

  • 全ワーカーの実行環境をコンテナに
  • docker基盤共用
  • ECS採用
  • spot fleet採用
  • ワーカー毎にコンテナをスケール

Amazon ECS

  • 52のサービスが稼働 ( 50種のワーカー + Mackerel(監視) + Fluentd(ログコレクタ) )
  • コンテナレジストリ ⇒ Amazon ECR

Spot fleet

  • 168 vCPU
  • 自動入札(一つ一つ設定も可能だが手間)
  • InstanceType:7種 主にC4、M4系

運用のポイント

ログのハンドリング

  • 目的で集約先使い分け

    • 常時監視 ⇒logdna
    • 長期分析 ⇒BigQuery
    • 直近データ分析、参照 ⇒Aurora

環境構築・デプロイ

  • Terraform採用
  • CircleCIからAPIでデプロイ
     ⇒docker対応CIサービスがおすすめ

強制ターミネート(Spotインスタンス)

  • コンテナ強制終了
  • 検知する仕組み必要
    • メタデータをポーリング⇒クラスタから退役

AMI

  • ECS-Optimized AMI 使用
  • AMIのカスタマイズはしない
  • 設定はcloud-initで

ECSの課題

  • クラスタ管理

    • agent方式⇒ラグが多々
    • ゾンビワーカー
  • docker全機能は使えない
  • コンソール画面がまだまだ
  • 学習コストそこそこ

ECSの強みは他AWSサービスとの連携


Session:『AWS で実現するセキュリティ・オートメーション』 (16:20 ~ 17:00)

スピーカー:桐山 隼人 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

クラウドは、今までやってきたことを効率的にするだけでなく、今までできなかったことを可能にします。本セッションでは、セキュリティをクラウド環境で実現することで可能となる、運用統合と自動化(オートメーション)をご紹介します。セキュリティ・オートメーションは、貴社の運用が変わるだけでなく、セキュリティ戦略そのものを見直すきっかけにもなります。オートメーションによる次世代のセキュリティを考えてみませんか?

※スライドは公開されていないようですが、ほぼこれと同じだったかと思います。

クラウド移行に関するアンケート

日:クラウドに移行しない理由 1位 ⇒セキュリティ
米:クラウドに移行した理由 1位 ⇒セキュリティ
 ⇒まだ正確な認識が普及していないせいと思われる

クラウドだからできるセキュリティ

オートメーションとは=戦略策定の基盤
AWSはセキュリティオートメーション前提に設計されている ⇒基盤として活用してほしい

  • 戦略策定

    • SFA、マーケティングに活用
    • やること やらないこと を決められる
  • 何を自動化すべきか? (考える主軸 ⇒)

    • 対策主体(人、組織、技術)
    • 対策対象(サーバ、ネットワーク、クライアント)
    • 対策場所(入口、内部、出口)

ガートナーの『適応型セキュリティアーキテクチャ』

サイクルを回す:
 防御⇒検知⇒対応⇒予測⇒~

 防御:CloudFront、WAF ~
 検知:VPC Logs、Auto Scaling ~
 対応:SNS、Lambda ~
 予測:EC2 Config、3rd party レピュテーション、Inspector ~

実用例

CloudFrontアクセス⇒WAF⇒LambdaでレピュテーションリストDL&判定
 ⇒Lambdaでセキュリティ評価⇒Amazon Inspector⇒SNS⇒LambdaでNACL/SG変更
 ⇒攻撃検知⇒ブロックログ⇒EBSなどsnapshot⇒CloudTrail(操作ログ)
全レイヤー、ノードのログが取れるので
 ⇒VPC Flow Logs/Elastic Search/Kibanaなどで可視化
攻撃者のドメイン生成は自動化されている:Domain Generation Algorithm(DGA)
 ⇒AWS WAF + Amazon MLで怪しいドメインを学習
Machine Learningでリスク分析
 ⇒設定変更などの意思決定まで自動化


Session:『Machine Learning on AWS』 (17:20 ~ 18:00)

スピーカー:志村 誠 氏 (AWSジャパン 技術統括本部 ソリューションアーキテクト)

セッション概要(タイトルリンク先より引用)

AI や機械学習という言葉が話題になる遥か前から、Amazon では機械学習技術を活用したさまざまな取り組みを行ってきました。本セッションでは AWS の上でご利用いただける機械学習サービスについてご紹介するととともに、それらをどのように使い分けるか、また機械学習をどのように皆さまのサービスに役立てて行くかについてご紹介します。

どんなサービスで機械学習を活用するか?

ビジネス主体で考える(使いたい技術から考えない)

  • 良質なデータが継続的に入るか
  • 自動化の価値ある予測か
  • 費用対効果

機械学習はあくまでツール
需要に反し解決していない問題に対して検討する

代表的な活用例>
– レコメンド
– 異常検知
– 画像認識
– クラスタリング(ユーザの分類分けなど)

AWSで提供する機械学習サービス

グルーピング>

  • Service
  • platform
  • Engines
  • Hardware

AI Hardware

  • EC2:P2 instance

    • GPU特化
  • Greengrass
    • デバイスに学習モデル
    • エッジで推論処理

AI Engines

典型的な機械学習フレームワークをインストール済みのAMIを提供

AI platform

  • Amazon Machine Learning
  • Amazon EMR

AI Service

  • Polly
  • Rekognition
  • Lex

その他

Kinesis Analytics >異常検知
Elastic Search >検索を機械学習に利用
Data Pipeline >EMRのジョブをスケジューリング

ゴールを明確に

  • 解決すべき課題
  • アウトプット

続き⇒Day4

続きを読む

AWS IoTの利用手順

AWS IoTに関する基本的な内容をまとめてみたものです。AWS IoTに関する、Web上にすでにある解説コンテンツをまとめたサイトの抜粋です。
AWS IoTの利用手順

AWS IoTを使うための手順

1) デバイスの作成
まずは、「Register -> Things」メニューの中の、 Register Thingsを選択して、デバイスを作成します。名称を指定して登録すると、AWS IoTの中にその名称のThingsおよびシャドウが作成されます。
その次に、そのデバイスのRuleを設定します。Ruleとは、どのデータに対してどういう条件のときにアクションを実行するかを決める情報です。

2) 証明書の作成
次にデバイスに登録する証明書を作成します。「Security -> Certificates」メニューの中の、Create a certificatesを選択して、証明書を作成します。

3) ポリシーの作成
次にデバイスに対して、AWS IoTの各種操作を許可するためのポリシーを作成します。全ての操作を許可するのか、一部の操作だけを許可するのか、許可する操作の定義です。「Security -> Policies」メニューの中の、Create a policyを選択して、ポリシーを作成します。

4) 証明書にデバイスとポリシーを割り当てる
作成した証明書とポリシーを関連づけします。証明書を作成した後に、「attach a policy」を選択して、関連付けしたいポリシーを設定、「attach a thing」を選択して割り当てしたいデバイスの設定をします。

マネジメントコンソールの設定は以上です。

デバイスの作成からデータを受信できるまで

AWS マネジメントコンソールは、Amazon IoT リソースのすべてにアクセスして管理するためのウェブベースのインターフェイスを提供しますが、プログラムから AWS IoT へのアクセスは、AWS CLI と AWS SDK を使用して有効にできます。

ハードウェアデバイス、センサー、モバイルアプリケーション、モノを接続するには、AWS IoT デバイス SDK を使用します。AWS IoT に接続が実装された AWS スターターキットから 1 つ選択します。それに加えて、AWS IoT は、幅広い種類のサードパーティ製のツールおよびゲートウェイでサポートされています。

AWS IoTデバイスSDK
AWS IoT デバイス SDK にはオープンソースライブラリ、サンプルの付属した開発者ガイドおよび移植ガイドが含まれているので、お客様の選択したハードウェアプラットフォームに革新的な IoT サービスを構築できます。

証明書と秘密鍵
マネジメントコンソールで作成した証明書と秘密鍵は、マネジメントコンソールからダウンロードしてデバイス側に設定します。

以上の作業で、デバイスからのデータのpublish/subscribeが可能となります。

AWS IoTへの各種アクセス方法

AWS IoT サービスには AWS マネジメントコンソール、AWS SDK、AWS CLI、AWS IoT API を使用してアクセスできます。接続されたデバイスからは AWS IoT デバイス SDK を使用して AWS IoT サービスと簡単に通信できます。
AWS IoT API およびコマンドは、コントロールプレーンオペレーションと、データプレーンオペレーションに大きく分かれています。コントロールプレーンオペレーションでは、セキュリティの設定、デバイスの登録、ルーティングデータのルールの設定、ログ記録の設定などのタスクを実行することができます。データプレーンオペレーションでは、接続されたデバイスから AWS IoT へ大規模に低レイテンシーかつ高スループットレートでのデータ取り込みを可能にします。

続きを読む

AWS IoTのルールエンジンとシャドウ

AWS IoTに関する基本的な内容をまとめてみたものです。AWS IoTに関する、Web上にすでにある解説コンテンツをまとめたサイトの抜粋です。
ルールエンジンとシャドウ

ルールエンジンによりデバイスのデータに基づいたアクションを設定

AWS IoTでは、ルールエンジンによって、接続されたデバイスによって生成されるデータを収集し、処理し、分析し、データに基づいたアクションを実行するアプリケーションを構築します。

ルールエンジンで直感的にルールを設定し、SQL に似たシンタックスでインバウンドデータを自動的にフィルタおよび変換できます。AWS IoT サービスから他のいくつかの AWS のサービスまたはお客様がお使いのサードパーティサービスへルーティングするルールを設定できます。

例)
• 受信メッセージのフィルタリングおよび変換、DynamoDB へ時系列データとして保存。
• センサーからのデータが特定のしきい値を超えた時、SNS を経由してプッシュ通知を送信。
• ファームウェアファイルを S3 に保存。
• Kinesis を使用して複数のデバイスからのメッセージを同時に処理。
• 受信データのカスタム処理を行うため Lambda を呼び出し。
• 自動再発行して、デバイスのグループへコマンドを送信。

ルールはSQLライクな構文にて指定

AWS IoT のルールは 2 つの主要な部分で構成されます。

SQLステートメント:
SQL ステートメントでは、ルールを適用するトピック、必要に応じて実行するデータ変換、およびルールを実行する際の条件を指定します。ルールは指定されたトピックに発行されたすべてのメッセージに適用されます。

アクションリスト:
受信メッセージがSQLステートメントで定義された条件と一致した時、アクションリストで定義されたアクションが実行されます。

ルールの定義は JSON ベースのスキーマを使用しています。直接 JSON を編集、または AWS マネジメントコンソールのルールエディタを使用できます。

デバイスシャドウによるデバイスの状態管理の仕組み

デバイス シャドウは、デバイスの現在のステータス、アプリケーションから要求されたステータスを管理するJSONドキュメントであり、デバイスシャドウには、デバイスがオフライン状態のときでも、各デバイスについて最後に報告された状態と、希望する今後の状態が保持されます。最後に報告された時点の状態の取得や、希望する今後の状態の設定は、API またはルールエンジンによって実行されます。

デバイスシャドウでは、REST API が常時利用できるため、デバイスと協働するアプリケーションの構築が容易になります。さらに、アプリケーションではデバイスの現在の状態を取得することなく、希望する今後の状態を設定できるようになります。希望する状態と最後に報告された時点の状態との相違は AWS IoT によって比較され、相違を補うようデバイスに対してコマンドが送られます。

デバイスのシャドウには、デバイスの状態を最大 1 年間無料で保存できます。最低 1 年間に 1 度更新していれば、デバイスのシャドウは無期限に継続できます。更新しなかった場合は消去されます。

続きを読む

AWS IoTの実現するセキュアな双方向通信

AWS IoTに関する基本的な内容をまとめてみたものです。AWS IoTに関する、Web上にすでにある解説コンテンツをまとめたサイトの抜粋です。
AWS IoTの実現するセキュアな双方向通信

IoTサービスでサポートする通信プロトコル

AWS IoT では数十億のデバイスと数兆のメッセージをサポートし、それらのメッセージを AWS エンドポイントおよび他のデバイスに確実かつ安全に処理しルーティングします。AWS IoT では、断続的な接続を許容し、デバイスのコードフットプリントを削減し、必要なネットワーク帯域幅を削減するよう特にデザインされた HTTP、WebSockets、および MQTT といった軽量の通信プロトコルをサポートしています。

HTTP:
HTTPプロトコルでの通信をサポートしており、デバイス側からrestAPIで呼ぶことが可能
MQTT:
MQTTは軽量でリソースの限られているデバイスとの通信に広く使われているプロトコル。
AWS IoTは、MQTT 3.1.1ベースで実装
WebSockets:
MQTT over WebSocketsをサポートしているので、ブラウザベースのアプリケーションがAWS IoTと接続しているデバイスと双方向通信を行うことが可能。WebSocketはTCP port443での通信が可能のため、大部分のファイアウォールやwebプロキシーサーバを通すことが可能

軽量でリソースを消費しないMQTTプロトコル

MQTT は軽量の pub/sub プロトコルでネットワーク帯域幅とデバイスリソースを最小限に抑えるよう設計されています。MQTT では TLS を使用した安全な通信もサポートされています。MQTT は IoT ユースケースで頻繁に使用されています。MQTT v3.1.1 では OASIS 標準で、AWS IoT デバイスゲートウェイはほとんどの MQTT の仕様をサポートしています。

MQTTの軽量・リソースを消費しない点をHTTPS通信と比較すると、下記のようになります
(出展; http://stephendnicholas.com/posts/power-profiling-mqtt-vs-https)
・スループットが93倍
・メッセージ送信において消費電力が1/12
・メッセージ受信において消費電力が1/180
・コネクション維持において消費電力が1/2
・ネットワークオーバーヘッドが1/8

デバイスとの双方向通信

AWS IoTは、長期間のセッション保持によるクラウドを介したメッセージの送受信を実現します。クライアント(デバイスやアプリ)は制御信号やコマンドなどをクラウドから受信することができます。

AWS IoT では、断続的な接続を許容し、デバイスのコードフットプリントを削減し、必要なネットワーク帯域幅を削減するよう特にデザインされた HTTP、WebSockets、および MQTT といった軽量の通信プロトコルをサポートしています。AWS IoT では他の業界標準およびカスタムプロトコルをサポートし、複数の異なるプロトコルを使用しているデバイス同士でも相互に通信できます。

AWS IoT ではデバイスの最新の状態情報を保存し、いつでも読み込みまたは設定できるので、デバイスが常にオンラインであるかのようにアプリケーションに出現させることができます。これはデバイスとの通信が切断されていてもアプリケーションがデバイスの状態を読み込むことができ、デバイスが再接続された時にもデバイスの状態を設定し実装できることを意味します。

また、AWS IoTのMQTTでの通信では、ベストエフォート型と品質保障型のふたつの通信モードをもっています。ベストエフォート型はメッセージの到達は保障していませんが、オーバーヘッドは少なく、保障型ではメッセージの到達を保障しているものの、オーバーヘッドがベストエフォート型よりは大きくなります。

TLSによる相互認証

AWS IoT では接続するすべてのポイントで認証とエンドツーエンドの暗号化を提供し、デバイスと AWS IoT 間で身元が証明されたデータのみが交換されます。それに加え、詳細なアクセス権限のポリシーを適用することによってデバイスとアプリケーションに安全にアクセスできます。

AWS IoT では、AWS の認証メソッド (「SigV4」と呼ばれます) および X.509 証明書ベースの認証がサポートされています。HTTP による接続ではこれらの方法のいずれかを使用できます。MQTT による接続では証明書ベースの認証、WebSockets による接続では SigV4 を使用できます。AWS IoT では、AWS IoT によって生成された証明書、および推奨される認証機関 (CA) によって署名された証明書を使用できます。それぞれの証明書に対するロールやポリシーの選択をマッピングでき、デバイスに触れることなく、デバイスやアプリケーションによるアクセスを認証したり、考えが変わったときにすべてのアクセスを取り消したりできます。

続きを読む