AWS CloudFrontとLambda勉強まとめ

CloudFront

CDN
– Contents Delivery Network
– エッジのキャパシティを利用して効率的かつ高速にコンテンツ配信
→ユーザに最も近いサーバに誘導して、配信を高速化
→エッジサーバではコンテンツのキャッシングを行い、オリジンに負荷をかけない

・最適なエッジへの誘導方法
①ドメイン名問い合わせ(クライアント→DNS)
②IPアドレス問い合わせ(DNS→CloudFrontDNS)
③最適なEdgeアドレス応答(CloudFrontDNS→DNS)
④最適なEdgeへアクセス(クライアントからEdge)
⑤キャッシュがある場合:コンテンツ配信
キャッシュがない場合:オリジンサーバから取得

・CloudFront特徴
– 84拠点のエッジサーバ
– 予測不可能なスパイクアクセスへの対応
– ビルトインのセキュリティ機能(WAF連携、DDoS対策)
– 充実したレポート

・動的コンテンツ:ELBでEC2に負荷分散。HTML
静的コンテンツ:S3などで保存

・84エッジロケーション→11リージョナルキャッシュ→オリジン
→オリジンに対するコンテンツ取得を削減

CloudFront Distribution
– ドメインごとに割り当てられるCloudFrontの設定
– 40Gbpsもしくは100,000RPSを超える場合上限申請必要
– HTTP/2対応
– IPv6対応
– CNAMEエイリアスを利用して独自ドメイン名の指定可能
→Route53と合わせたZone Apex(wwwがないもの)も利用可能

Gzip圧縮機能
エッジでコンテンツをGzip圧縮することでより高速にコンテンツ配信
※S3はGzip圧縮をサポートしていないので有効

キャッシュコントロール
– キャッシュヒット率の向上がCDNのポイント
→URLおよび有効化したパラメータ値の完全一致でキャッシュが再利用

キャッシュの無効化
コンテンツごとの無効化パス指定

ダイナミックコンテンツ機能
オリジンサーバに対して下記情報をフォワードすることで、動的なページの配信にも対応
– ヘッダー(必要最小限)
– Cookie(Cookie名と値をセットでCloudFrontがキャッシュ)
– クエリ文字列パラメータの値

ダイナミックキャッシング
リクエストパターンをもとにオリジンへのアクセスルールを個別指定可能

カスタムエラーページ
4xx系:クライアントエラー。オリジン側で対処
5xx系:サーバエラー。CloudFrontで対処
参考URL:https://goo.gl/NcUQiY

読み取りタイムアウト
CloudFrontがオリジンからの応答を待つ時間を指定
デフォルトは30秒

キープアライブタイムアウト
接続を閉じる前に、CloudFrontがオリジンとの接続を維持する最大時間
デフォルトは5秒

・セキュリティ
– HTTPS対応
– SSL証明書
→専用IPアドレスSSL証明書には申請必要
ビューワーSSLセキュリティポリシー
→クライアントとCloudFront間のSSL/TLSプロトコルとCipherの組み合わせを指定可能
– オリジン暗号化通信
– オリジンカスタムヘッダー
GEOリストリクション
→地域情報でアクセス判定。制御されたアクセスには403を応答
署名付きURL
→プライベートコンテンツ配信。
→署名付きURLを生成する認証サイトにクライアントから認証リクエスト
→認証サイトからEdgeにアクセス※署名付き出ない場合は、403を返す
-オリジンサーバーの保護
→Origin Access Identitiy(OAI)を利用
S3のバケットへのアクセスをCloudFrontからのみに制限
– AWS WAF連携
AWS ShieldによるDDoS攻撃対策
ブロック時は403応答
– AWS ShieldによるDDoS攻撃対策
デフォルトで有効

・CloudFrontレポート・アクセスログ機能
任意のS3バケットに出力可能

・CloudWatchアラームの活用
リアルタイム障害・異常検知

・S3オリジン自動キャッシュの無効化(Invalidation)
S3にアップロード→Lambdaファンクション呼び出し→CloudFront Invalidation APIの呼び出し→CloudFront上でキャッシュの無効化

Lambda

高度にパーソナライズされたウェブサイト
ビューワーリクエストに応じたレスポンス生成
URLの書き換え
エッジでのアクセスコントロール
リモートネットワークの呼び出し

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-blackbelt-online-seminar-2017-amazon-cloudfront-aws-lambdaedge

続きを読む

Amazon Transcribeを調べてみた

Amazon Transcribeとは

Amazon Transcribeは一言で言うと”Speech to Text”と呼ばれる、音声をテキスト情報に変換するサービスです。
話されている言語を機械学習の技術で識別し、テキスト情報に変換します。

この技術は以下のような新しいサービスやプロダクトの提供に役立ちます。

  • 映像ファイルから音声を認識し、クローズドキャプションを生成
  • コールセンター業務などでの問い合わせ内容の分析
  • 医療分野や法律分野での活用

また、”Amazon Translate”や”Amazon Polly”と連携して、生成したテキスト情報を翻訳し、再度翻訳した言語で音声に変換することなどもできます。

何ができるのか

Amazon Transcribeには以下の3つのオペレーションがあります。

  • StartTranscriptionJob : 非同期で音声をテキストに書き起こす
  • ListTranscriptionJobs : 開始された音声認識ジョブのリストを返す。 返して欲しいJobをステータスで絞り込むことができる
  • GetTranscriptionJob : 音声認識の結果を返す。結果にはJSON形式に変換された結果へのリンクが含まれている

Speech Input

インプットするファイルはS3 bucketに保管されている必要があります。
インプットファイルの仕様は以下のみ

  • FLAC、MP3、MP4、WAV
  • 尺は2時間未満

言語、フォーマット、サンプリングレートを指定する必要があります。

  • PCM 16ビットエンコーディングのFLACやWAVなどのロスレスフォーマットを使用。
  • サンプリングレートは8000 ~ 16000Hz

Amazon TranscribeのS3とその中のファイルへのアクセスを許可する必要があります。

Output JSON

Jobが完了するとJSONが含まれた結果が生成され、テキストファイルがS3に置かれます。
ファイルのIDはユーザー固有のURIとなっており、そのURIを利用することで結果を取得できます。

Ex)

 {
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.874,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }
 

始め方

始めるにはAWSアカウント、ID、IAMユーザーが必要です。CLIの利用も可能です。

Step.1 AWSアカウント設定

いつも通りなので割愛

Step.2 CLI設定

いつも通りなので割愛

Step.3 コンソールでの利用開始

Jobの作成

1.各種情報の入力
 - Transcription job name : AWSアカウント毎にユニークである必要がある
 - Amazon s3 input URL: 音声ファイルが格納されているS3 busket。Transcribeと同一リージョンである必要がある
 - Language:インプットファイルの言語を選択
 - Format:インプットファイルのフォーマットを選択
 - Media sampling rate(Hz):インプットファイルのサンプリングレートを8000 ~ 48000Hzの間で指定。8000~16000Hzが推奨
2.「Create」を押す

Jobの確認

Jobのリストを表示。「Availability」にサーバーに結果が保管される残り期間が表示される。結果の保管期間は90日
Jobをクリックすると、詳細(Job名、残りの保管期間、I/OのファイルのS3パス)と結果の文字列が表示される。
「Code Samples」で該当JobについてのJSONファイルを取得可能

Step.4 API

CLI

Transcribeのテストをする場合

1.InputファイルをS3 バケットに配置する(Transcribeと同じリージョンに)
2. ファイル情報を含んだJSONファイルを作成する

{
    "TranscriptionJobName": "request ID", 
    "LanguageCode": "en-US", 
    "MediaFormat": "wav", 
    "Media": {
        "MediaFileUri": "https://S3 endpoint/test-transcribe/answer2.wav"
    }
}

3.下記コマンドを実行
json
aws transcribe start-transcription-job
--endpoint-url endpoint
--region region
--cli-input-json file://test-start-command.json

・下記レスポンスが返れば成功
“`json

{
“TranscriptionJob”: {
“TranscriptionJobName”: “request ID”,
“LanguageCode”: “en-US”,
“TranscriptionJobStatus”: “IN_PROGRESS”,
“Media”: {
“MediaFileUri”: “https://S3 endpoint/test-transcribe/answer2.wav”
},
“CreationTime”: timestamp,
“MediaFormat”: “wav”
}
}
“`

Jobのリストを取得

1.Jobが完了していた場合、下記コマンドでステータスを取得する

aws transcribe get-transcription-job-results 
   --endpoint-url endpoint 
   --region endpoint 
   --request-id "DocTest-01"

・成功すればレスポンスは下記通り返ってくる

{
    "TranscriptionJob": {
        "TranscriptionJobName": "request ID",
        "LanguageCode": "en-US",
        "TranscriptionJobStatus": "COMPLETED",
        "Media": {
            "MediaFileUri": "input URI"
        },
        "CreationTime": timestamp,
        "CompletionTime": timestamp,
        "Transcript": {
            "TranscriptFileUri": "output URI"
        }
    }
}
```json

2.Output URIを使って翻訳されたテキストを取得

```json
{
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.87,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }

SDK for Python(Boto)

・InputファイルをS3 バケットに配置する(Transcribeと同じリージョンに)。ファイル情報を含んだJSONファイルを作成する

from __future__ import print_function
import time
import boto3
transcribe = boto3.client('transcribe')
job_name = "job name"
job_uri = "https://S3 endpoint/test-transcribe/answer2.wav"
transcribe.start_transcription_job(
    TranscriptionJobName=job_name,
    Media={'MediaFileUri': job_uri},
    MediaFormat='wav',
    LanguageCode='en-US'
)
while True:
    status = transcribe.get_transcription_job(TranscriptionJobName=job_name)
    if status['TranscriptionJob']['TranscriptionJobStatus'] in ['COMPLETED', 'FAILED']:
        break
    print("Not ready yet...")
    time.sleep(5)
print(status)

・成功すればレスポンスは下記通り返ってくる

 {
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.87,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }

認証とアクセスコントロール

・AWS Transcribeの利用にはCredentialが必要です。Credencialには認証とアクセスコントロールの設定を行う必要があります。

認証

・認証には以下のいずれかを使用します。
– AWS Account ルートユーザー(非推奨)
– IAM role
  (1) ユーザーごとの許可
  (2) AWSサービスのからのアクセス
  (3) EC2からのアクセス許可

アクセスコントロール

TranscribeへアクアセスするためのPermissionの管理

アクセスとアクションの確認

・誰が何にアクセスするかはは下記方法で定義します。
 - IAMポリシー:IAMユーザーやIAM roleに権限を付加する
 - リソースベースのポリシー:各AWSのサービスにAPIでアクセスする際に要求されるポリシー主にResource,Action,Effect,Principalなど

TranscribeのためのIAM ポリシー

・StartTranscriptionJobを実行するためのIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "transcribe:StartTranscriptionJob"
             ],   
            "Resource": "*"
        }
    ]
}

・コンソールでTranscribeを使用するためのIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "transcribe:*"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

・音声を取得するためにIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "transcribe.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::bucket name/*"
        }
    ]
}

・KMSを使ったS3の暗号化を行うための IAM roleの例

{
      "Sid": "Allow-Transcribe",
      "Effect": "Allow",
      "Principal": {
        "Service": "transcribe.amazonaws.com”
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }

APIに対する権限のリファレンス

・Amazon TranscribeのAPIは下記通り
 - GetTranscriptionJob:
   API: transcribe:GetTranscriptionJob
   Resource:*
 - ListTranscriptionJobs:
   API: transcribe:ListTranscriptionJobs
   Resource:*
 - StartTranscriptionJob:
   API: transcribe:StartTranscriptionJob
   Resource:*

ベータ版のガイドラインと制限

・現在は下記リージョンのみ
 -リージョン:US East (N. Virginia)
 - Endpoint::https://transcribe.us-east-1.amazonaws.com
 - プロトコル:HTTPS
・推奨素材は以下
 - ロスレスFLAC、ロスレスWAV、PCM(16ビット)
 - サンプリングレート 8000 ~ 16000Hz
・制限は以下の通り
 - 尺は最長2h

APIリファレンス

・別紙参照(https://docs.aws.amazon.com/ja_jp/transcribe/latest/dg/API_GetTranscriptionJob.html)

続きを読む

Amazon S3 に Git LFS サーバを超簡単に立てる

元ネタはこちら。
Serverless Git LFS for Game Development – Alan Edwardes
Amazon API Gateway + Amazon Lambda + Amazon S3 を使うんだそうです。

準備: AWS のアカウントをとる

AWSのアカウントがなければとります。
作成の流れは 公式のドキュメント でだいじょうぶです。

アカウントをとったら初期設定しておきます。以下のエントリが参考になりました。
AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ – Qiita

サーバ作成手順

Screen_Shot_2018-01-21_at_22_29_22-fullpage.png

  • 「次へ」をクリックします → オプションの設定ページはスルーで「次へ」をクリックします。
  • 「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックして「作成」をクリックします。

Screen_Shot_2018-01-21_at_23_05_08-fullpage.png

  • スタックのリストに新しいスタックができて(スタックがなければリロードして下さい)、「CREATE_COMPLETE」と表示されたら成功です。

Screen_Shot_2018-01-21_at_23_10_18-fullpage.png

  • スタックの詳細画面に入って、出力を確認すると、Git LFSのエンドポイントのURLが表示されているので、リンクをコピーします。

Screen_Shot_2018-01-21_at_22_34_53-fullpage.png

Git LFS に lfs.url を設定

Git LFS は導入してあることとします。

以下のコマンドで、 .lfsconfig を作成します。

git config -f .lfsconfig lfs.url <表示されたエンドポイントのURL>

git lfs env で確認して、Endpoint= の行が設定したURLになってたらOKです。

git push すると、S3の方にLFSオブジェクトがpushされるようになります。

問題点

URL を見ればわかると思いますが、この方法で作成するとリージョンが 欧州 (アイルランド) に作成されます。
東京リージョンにS3を立てたいと思って、 URL の region=eu-west-1 の部分を region=ap-northeast-1 に変えてみましたが、リージョンを変えると成功しないみたいです。

alanedwardes/Estranged.Lfs – Github

どなたか検証お願いします。 m(_ _)m

続きを読む

AWS IoT device managementのJob機能の動きをデバイス視点で見てみる

はじめに

公式ページはこちらになります。(2018/1/20時点では英語のマニュアルのみとなっております)
同じく、投稿時点では、javascript IoT Device SDKはjobの処理が入っているようですが、pythonなどはまだSDKに入っていないようですので、本説明にあわせてご自分でシーケンスをコードで表現する必要があるようです。
デバイス側でどういったことを考えてシーケンスを書くかや、request/responseのjsonについての理解が深まるようにまとめようと思います。

デバイスが意識すべきjob用のtopic

以下、topoic中の{}で区切ったものは変数となるものです。 device名やjobIdなど。

job情報取得で使えるtopic

新規job待受用のsubscribe topic

  • $aws/things/{thingName}/jobs/notify
  • $aws/things/{thingName}/jobs/notify-notify

新規jobが作成されると下記2つにpublishされます。つまり新規jobを受け取るために、動作中のデバイスがsubscribeしたままにすべきtopicということになります。2つのtopicの情報の差を含めて見ましょう。

$aws/things/{thingName}/jobs/notify
=> job一覧入ってきます。jobDocumentはありません。

{
  "timestamp": unixtime,
  "jobs": {
    "IN_PROGRESS": [
      {
        "jobId": "作成したjob名",
        "queuedAt": unixtime,
        "lastUpdatedAt": unixtime,
        "startedAt": unixtime,
        "executionNumber": 1,
        "versionNumber": 3
      }
    ],
    "QUEUED": [
      {
        "jobId": "作成したjob名",
        "queuedAt": unixtime,
        "lastUpdatedAt": unixtime,
        "startedAt": unixtime,
        "executionNumber": 1,
        "versionNumber": 1
      }
    ]
  }
}

$aws/things/{thingName}/jobs/notify-next
=> 次にやるべきjob情報のみが、通知されます。
jobDocumentにある、test:testは job生成時に指定したS3のjob fileの中身(json)が入っています。

{
  "timestamp": unixtime,
  "execution": {
    "jobId": "job名",
    "status": "QUEUED",
    "queuedAt": unixtime,
    "lastUpdatedAt": unixtime,
    "versionNumber": 1,
    "executionNumber": 1,
    "jobDocument": {
      "test": "test"
    }
  }
}

注意:通知対象のdeviceに”IN_PROGRESS”のstatusがある場合、notify-nextは発行されません。
複数の処理を通知して、デバイス側でupdate処理が重複しないための考慮だと思います。

この場合、デバイスが “testjob-20180120-00” のtaskの終了通知(後述のupdate通知をSUCCEEDEDでpublish)すると、AWS IoTがnotify-nextへ通知します。

能動的にjob statusを確認するためのtopic

起動時などにjobを確認する用途 publishすると、acceptedへ返却される

  • $aws/things/{thingName}/jobs/get (publish)
  • $aws/things/{thingName}/jobs/get/accepted (publish前にsubscribeしておく)

上記の通り、シーケンスとしては acdepted topicを先にsubscribeしてから、get topicへpublishすることとなります。acceptedへのsubscribeへの返却は以下のようなjsonとなります。先に説明したnotifyと少しjsonフォーマットが異なりますが、取得できる内容はほぼ同じです。
こちらはデバイスが起動したばかりなどで前回の終了状態が分からない場合や電源off時などにupdateが来ていないかなど、最初にチェックするような用途になるかと思います。

{
  "timestamp": unixtime,
  "inProgressJobs": [],
  "queuedJobs": [
    {
      "jobId": "Job名",
      "queuedAt": unixtime,
      "lastUpdatedAt": unixtime,
      "executionNumber": 1,
      "versionNumber": 1
    }
  ]
}

deviceがAWS IoTにreportするためのtopic

$aws/things/thingName/jobs/jobId/update
requestのjson format

{
  "status": ["IN_PROGRESS", "FAILED", "SUCCEEDED", "REJECTED"],
  "statusDetails": {
    "progress": "0%"
  },
  "expectedVersion":"",
  "clientToken":""
}

statusは上記の4つの状態のみを指定可能
statusDetailsのjsonについては自由に記載できます。ここでは例として”progress”としています。
管理者視点で見ると、統計などが見れる機能があるので、デバイス側のupdate処理内で定期的に呼び出して置くと良いかと思います。

AWS IoTのテスト画面を使っての動作確認

device想定のsubscribe設定

AWSのマネージメントコンソールから、AWS IoTを選択し左側メニューの “Test” を選択します。
Subscription topicへ”$aws/things/+/jobs/#”を入力し、subscribe to topicを押下して、受信状態のままにしておきます。

意味を説明すると$aws/things/(+ = すべてのthingName)/jobs/(# = ここ以下すべてのレイヤtopic)
を受信することになります。

スクリーンショット 2018-01-21 21.39.56.png

test Jobの作成

事前作業

AWS IoTの作成

今回は、AWS IoTのテスト画面しか使わないので名前だけあれば良いです。(証明書やpolicyなどは使いません)
本投稿では qiita-thing としています。

job通知のjsonドキュメント配置

S3へjsonドキュメントを置きます。このjsonドキュメントがjobのjobDocumentとして通知されます。
ここでは、 {“test”:”test”}としておいておきます。

AWS IoTからjob作成

先程の受信状態のコンソールをそのままにして別タブなどでもう一つ AWS IoT画面を開き、Manage => Jobsを選択します。画面右上にあるCreateを押下して、jobの作成をしてみます。

Select a job で、Create custom jobを選択。次の画面で以下を設定
– Job IDに qiita-test
– device updateに、先程作ったthingを一つ選択、
– job fileに 先程おいたS3のjson fileを選択
– job typeに snapshotを選択
createを実行。createを実行するとjob通知が自動で発行されます。

通知の確認とupdateで通知

AWS IoTのtest画面の方に戻ります。
先程のjob作成でsubscribeにnotifyとnotify-nextの通知がきています。
スクリーンショット 2018-01-21 22.09.31.png

本test画面の Publish の topicを以下とします。
$aws/things/qiita-thing/jobs/qiita-test/update

updateのpayloadに以下を設定

{
  "status": "IN_PROGRESS",
  "statusDetails": {
    "progress": "0%"
  },
  "expectedVersion":"",
  "clientToken":""
}

状態を確認

Publishのtopicを以下に変更して、publishを実行します。
$aws/things/qiita-thing/jobs/get
mqttのpayloadは設定しなくともよいです。

test画面のsubscribeの画面に以下が表示されました。想定通り、queueからinProgressへ変化しています。

{
  "timestamp": 1516540819,
  "inProgressJobs": [
    {
      "jobId": "qiita-test",
      "queuedAt": 1516540026,
      "lastUpdatedAt": 1516540699,
      "startedAt": 1516540699,
      "executionNumber": 1,
      "versionNumber": 2
    }
  ],
  "queuedJobs": []
}

AWS IoTコンソールのjob詳細画面もin progressとなっています。
スクリーンショット 2018-01-21 22.28.08.png

複数jobを通知してみる

notifyとnotify-nextの動きを確認するために、再度jobを作成して送信してみます。
jobIdは qiita-test-2としてみます。それ以外は先程同じにしています。

説明済みですが、notifyのみが通知されました。

{
  "timestamp": 1516541383,
  "jobs": {
    "IN_PROGRESS": [
      {
        "jobId": "qiita-test",
        "queuedAt": 1516540026,
        "lastUpdatedAt": 1516540699,
        "startedAt": 1516540699,
        "executionNumber": 1,
        "versionNumber": 2
      }
    ],
    "QUEUED": [
      {
        "jobId": "qiita-test-2",
        "queuedAt": 1516541383,
        "lastUpdatedAt": 1516541383,
        "executionNumber": 1,
        "versionNumber": 1
      }
    ]
  }
}

最初のjobを完了させてみる

updateの通知と同様の手順で以下のtopicに payloadを”SUCCEEDED”として送信してみます。

topic : $aws/things/qiita-thing/jobs/qiita-test/update

{
  "status": "SUCCEEDED",
  "statusDetails": {
    "progress": "100%"
  },
  "expectedVersion":"",
  "clientToken":""
}

完了通知に合わせて自動でnotifyとnotify-nextが送られてきました。
ということで、notify-nextをsubscribeしておけば良いことがわかります。
スクリーンショット 2018-01-21 22.37.56.png

まとめ

ということで、AWS IoTのdevice managementのjob機能についてdeviceの観点で簡単に整理してみました。実際にはjob documentのデザイン(プログラムDLのS3 urlをセット)やプログラム更新をする部分というところがdevice updateの本質なので、主にシーケンス/request方法についての説明となりますが、AWS IoT側でこのくらい作られていれば、device updateプログラムの開発に集中出来るのではないでしょうか?

免責

本投稿は、個人の意見で、所属する企業や団体は関係ありません。
ご自身でもドキュメントの確認や、動きを確認してからの利用をおすすめします。

続きを読む

AWS S3勉強まとめ

ブロックストレージ
EBS, インスタンスストア
→EC2にマウントして活用
→Block番号で管理

オブジェクトストレージ
S3, Glacier
→安価かつ高い耐久性を持つオンラインストレージ
→オブジェクト、それに付随するメタデータ、そのオブジェクトにアクセスするためのユニークなIDで構成

ファイルストレージ
EFS
→EC2から同時マウントできる共有ストレージサービス
→ファイルシステム

・S3特徴
→容量無制限、安価なストレージ(1GB3円)、データ容量に依存しない性能(RAIDやサーバー台数を考える必要なし)

・S3用途
①コンテンツ配信、保管サーバ
②ログ&データハブストレージ
③バックアップやDR

バケット
オブジェクトの保存場所。デフォルト100個/1アカウントまで作成可能。名前はグローバルでユニークな必要あり。
オブジェクト
データ本体。URLが付与される
キー
オブジェクトの格納URL
メタデータ
オブジェクトに付随する属性情報。システム定義メタデータ、ユーザ定義メタデータあり
リージョン
バケットを配置するAWSのロケーション
アクセスコントロールリスト(ACL)
バケットやオブジェクトのアクセス管理

・ストレージクラス
スタンダード
標準低頻度アクセスストレージ:スタンダードに比べて安価だが、データの読出し容量に対して課金
Glacier:最も低コスト。データの取り出しにコストと時間
低冗長化ストレージ:Glacierから取り出したデータの置き場所として利用

結果整合性(Eventual Consistency Readモデル)
「更新はそのうち全体に反映される」
読み取り一貫性
– あるトランザクションがデータを変更中のとき、ほかのトランザクションからは変更される前のデータを参照します。
– ほかのトランザクションからは変更前の確定されたデータを参照します。
– あるユーザーAが値をUPDATEしたとき、ユーザーBがそのデータを参照すると、戻ってくる値はUPDATE前の値となります。
– あるトランザクションで変更した確定前のデータをほかのトランザクションから参照することはできません。

・パソコンのファイルシステムやデータベースと同じようにロックやトランザクション処理は行われない
参考URL:https://dev.classmethod.jp/cloud/amazon-s3-eventually-consistent-and-consistent-read/

・アクセス管理
①ユーザポリシー
→IAMuserに対して権限設定
②バケットポリシー
→バケットごとに権限設定。クロスアカウントで使用する際など
③ACL
→バケット、オブジェクトごとに指定可能(オブジェクトACLが優先)

署名付きURL
AWS SDKで作成。S3のプライベートなオブジェクトに対して一定時間アクセスを許可

・Webサイトホスティング機能
静的なWebサイトをS3のみでホスティング可能
– バケット単位で指定
– 独自ドメインの設定→ドメイン名をバケット名として指定
– リダイレクト機能→任意のドメインにリダイレクト設定が可能
CloudFrontとの経由で配信することを推奨。バケットポリシーでHTTP/HTTPSリクエストのみを許可可能

VPCエンドポイント
プライベートサブネットからNATゲートウェイなどを経由せずに直接S3とセキュアに通信可能
同一リージョンのみ

S3 support for IPv6
追加費用なし
静的ウェブホスティングは使用不可

・暗号化
– サーバーサイド暗号化(サーバリソースを利用して格納データの暗号化)
– クライアントサイド暗号化(クライアント側で暗号化したデータをS3にアップロード)

クロスリージョンレプリケーション
異なるリージョン間のS3バケットオブジェクトのレプリケーションを実施
→オブジェクトに対する動作を非同期でレプリケーション
→対象元バケットはバージョニングの機能を有効にする必要あり
※リージョン間データ転送費用が発生

バージョン管理機能
誤操作による削除対策に有効
バケットに対して設定
任意のオブジェクトを参照可能
バージョニングのオブジェクト分も課金。保存期間も指定可能

ライプサイクル管理
バケット内のオブジェクトに対して、ストレージクラスの変更や、削除処理の自動化
データ登録→Standard保存(一定期間過ぎたら削除)→Standard-IA移動(一定期間過ぎたら削除)→Glacierにアーカイブ(一定期間過ぎたら削除)

・アーカイブ
S3上のデータを削除でGlacier側のデータも削除
S3には8KBのオブジェクト名とメタデータのみ保管

・復元
オブジェクトごと
一時的にS3の低冗長化ストレージに指定日数複製(Glacierと低冗長化ストレージ両方課金)
復元にかかる時間の選択肢は3つ
①Expedited:緊急のアクセス
②Standard:3-5時間。標準的
③Bulk:大量のデータ。5-12時間
それぞれによってコストが異なる

・オブジェクト移動
Standard⇔Standard-IA→Glacier
→Glacier

S3分析
Standard-IAとGlacierどちらにいつ移動すればいいだろうかという疑問に答える可視化ツール
→ライフサイクルポリシーの設定値の参考になる

S3インベントリ
S3のオブジェクトのリストを一気にcsvファイルで取得
スケジュールかも可能

・イベント通知
SNS:メール送信
SQS:キューメッセージの登録
Lambda:ファンクションの実行

・CloudWatchによる監視
ストレージメトリクス:バケット単位。1日単位でのレポート。追加費用なし
リクエストメトリクス:オブジェクト単位。通常のCloudWatch料金

CloudTrailによるAPI(操作ログ。Get, Delete, Putなど)管理
S3への操作ログを収集
監査対象とは別のS3バケットの用意推奨

Logging
バケットに対するアクセスログの出力設定可能

Tag管理
バケット/オブジェクトに対してタグの指定可能

・パフォーマンスの最適化
大きなサイズのファイルをアップロード、ダウンロード
RANGE GETを活用。マルチパートアップロード機能
大量のGETリクエストが発生する場合はCloudFrontを併用することを推奨

Transfer Acceleration(高速ファイル転送サービス)
AWSのエッジネットワークから最適化されたAWSのネットワークを経由する。
S3のデータ転送コストとは別に加算
※通常の転送より高速でない場合は、課金されない

コンテンツ配信サーバ
データをS3に配置、CloudFrontでキャッシュさせる
CloudFrontで静的コンテンツ配信。CloudFrontの料金はかからない
Webサーバーで動的コンテンツは処理

ログ&データハブストレージ
オンプレ:Direct Connectでログデータ収集
外部データソース;Kinesisで収集
AWS;S3に保管。Glacierにアーカイブ
分析:Redshift, EMR, Atenaなど

バックアップ、DR
クロスリージョンでデータの複製を保持
リージョン内でもDR設定

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-amazon-s3

続きを読む

AWS RDS勉強まとめ

・RDSの制限事項
バージョンが限定
キャパシティに上限
OSログインやファイルシステムへのアクセス不可
など

上記が許容できない場合はOn EC2かオンプレミスで構築

Multi-AZ
同期レプリケーションと自動フェイルオーバー
インスタンスやハードウェア障害時など

リードレプリカ
デフォルトで5台増設可能
マルチAZやクロスリージョン対応も可能
マスタと異なるタイプに設定可能
読み取り専用などに設定し、スループット向上

・スケールアップ、スケールダウン可能

・ストレージタイプ
汎用SSD
プロビジョンドIOPS
マグネティック

・バックアップ
自動スナップショット+トランザクションログをS3に保存
1日1回設定した時間に自動スナップショット取得、保存期間は0日~35日、手動スナップショットも可能

・リストア
スナップショットをもとにDBインスタンス作成
指定した時刻の状態にすることも可能(Point-in-Time)

・スナップショットはDBインスタンスのサイズと同サイズまでコスト無料
・自動スナップショットはDBインスタンス削除と同時に削除
※手動スナップショットは削除されないので、削除前に最終スナップショットをとること推奨
・スナップショット実行時にI/Oが停止するが、マルチAZの場合はスタンバイから取得するためアプリへの影響なし

リネーム
RDSに接続する際のエンドポイントを切り替える機能
旧本番インスタンスをリネーム→新本番インスタンス(スナップショットからリストア)をリネーム

・リネームの注意点
DNSはすぐに切り替わるわけでない
CloudWatchのMetricNameは引き継がない
マスターをリードレプリカの関係、タグ、スナップショットは引き継ぐ

・RDSにかかわる制限事項
RDSインスタンス数:40
1マスターあたりのリードレプリカ数:5
手動スナップショット数:100
DBインスタンスの合計ストレージ:100TB
必要に応じて上限緩和申請

・デフォルトではDBインスタンスに対するネットワークアクセスはオフ
→セキュリティグループで制御し、アクセス許可のポートなどを指定

・DBインスタンスとスナップショットの暗号化可能

オンデマンドDBインスタンスVSリザーブドインスタンス
リザーブドインスタンス:予約金を支払うことで価格割引

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/20170510awsblackbeltrds

続きを読む

AWS EBS勉強まとめ

2017年新しい機能追加
==
・起動ボリュームの暗号化をサポート

スループット最適化HDD
高スループットを必要とするワークロード(MapReduce、Kafka、ETL処理、ログ処理、データウェアハウスなど)向けのタイプ; 1GBあたり月額0.054ドル
コールドHDD
同様のワークロードでアクセス頻度が低いユースケース向け; 1GBあたり月額0.03ドル
プロビジョンドIOPS SSD
I/O性能に依存するNoSQLデータベースやリレーショナルデータベース
汎用SSD
起動ボリューム、低レイテンシを要求するアプリケーション、開発・テスト環境
マグネティック
アクセス頻度の低いデータ
参考URL:https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-cold-storage-and-throughput-options/

・汎用SSDボリュームのバーストクレジットの残高がCloudWatchで確認可能(残高はパーセンテージ)

・稼働中のEBSをオンラインのまま、ダウンタイムなく、変更することを可能にするエラスティックボリューム機能をリリース

・現行世代のインスタンスに関しては下記可能
①容量の拡張
②IOPS値の変更(PIOPSボリュームのみ)
③ボリュームタイプの変更(汎用SSD→コールドHDDなど)
→CloudWatchとCloudFormationやAWS Lambdaなどで自動化も可能

参考URL:https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-elastic-volumes-change-everything/

・EBSスナップショットにコスト配分タグをサポート
→コスト集計ができるようになった
==

・EBSスナップショットはS3に保存
・AZごとに独立。同一AZのインスタンスのみから利用可能
→しかし、Snapshotから任意のAZに復元可能
・EC2に複数のEBSを接続可能だが、反対は不可

・EBSはレプリケートされているので、冗長化は不要
・セキュリティグループによる制御の対象外。全ポートを閉じてもEBSは利用できる

・インスタンスストアVSEBS
インスタンスストア:揮発性。EC2のローカルディスク。仮想マシンが止まるとデータ消去。一時的なデータの置き場所などに利用。
EBS:永続化ストレージ。OSやDBのデータなど永続化のデータ用。

・スペックは下記の順
プロビジョンドIOPS→汎用SSD→スループット最適化HDD→コールドHDD→マグネティック

SSDの種類は下記2種類
汎用SSD
I/O機能を一時的に3000IOPSまで上げるバースト機能付き
→I/O Creditが必要。CloudWatchで監視可能。上限(540万I/Oクレジット)に対するパーセント
容量:1GB~16TB
IOPS:ベースは100IOPS。最大10000IOPS
スループット:128MB/秒~160MB/秒

プロビジョンドIOPS
容量:4GB~16TB
IOPS:50IOPS/1GB。最大20000IOPS
スループット:最大320MB/秒

HDDの種類は下記2種類
→小さいデータのランダムアクセスになりがちな処理、起動ボリューム、データベース、ファイルサーバー等への利用は非推奨
→ログ処理などのシーケンシャルアクセス用途。アクセス頻度が低いもの

スループット最適化HDD
容量:500GB~16TB
IOPS:最大500IOPS
スループット:40MB/秒がベース

コールドHDD
容量:500GB~16TB
IOPS:最大250IOPS
スループット:12MB/秒がベース

マグネティック
磁気ディスクタイプ
容量:1GB~1TB
IOPS:100IOPS
スループット:40MB/秒~90MB/秒
I/Oリクエスト回数による課金が唯一ある

EBS最適化インスタンス
EC2とEBSの独立した帯域を確保し、I/O性能の安定化

事前ウォーミング
Snapshotから復元したボリュームへの初回アクセス時に設定

・EBSのパフォーマンス改善
①EC2インスタンス側のスループット
EBS最適化を有効にする
EBSからのスループットの上限値に到達していないかをCloudWatchのVolume Read/Write Bytesの合計値で確認

②EBSが処理できるIOPS
CloudWatchのVolume Read/Write Opsを参照

③各EBSボリュームのスループット
CloudWatchのVolume Read/Write Bytesの合計値で確認

・Snapshot
EBSのバックアップ機能
S3に保管。2世代目以降は増分バックアップ。1世代目を削除しても復元可能
ブロックレベルで圧縮して保管するため、圧縮後の容量に対して課金
データ整合性を保つため、静止点を設けることを推奨
別AZに移動したい場合や、容量変更などもSnapshot経由で行う

・バックアップと静止点
EBSへのI/O停止→Snapshot作成指示→作成指示レスポンス→EBSへのI/O再開
※Snapshotの作成完了前にEBSへのI/O再開してよい

・Snapshotの削除
1世代目を削除しても、1世代目にしかないデータは削除されない

・リージョン間コピーをサポート
リージョン間でのコピーも可能

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-elastic-block-store-ebs

続きを読む

AWS Auto Scaling勉強まとめ

・需要に応じて自動的にサーバーが増減し、コストカット

Auto Scaling Group
・設定した最小値~最大値に起動インスタンスを収める
・起動台数をAZ間でバランシング
・AZ障害時は他のAZでインスタンス起動

Launch Configuration
・AMIやインスタンスタイプ、IAMなどを設定して起動する

Scaling Plan
・どのようにインスタンスを起動するか
①Auto Scaling Planの維持
最小台数を維持する。
Auto Healing:インスタンスに障害発生時に自動的にサービスから切り離し、健全なインスタンスをサービスイン

②手動管理
インスタンスを手動で変更

③スケジュールベース
CLI/SDKで定義
スケーリング開始は最大2分遅れる場合があるので注意

④動的スケーリング
監視:CloudWatchに応じたインスタンスの増減

上記の複数のプランを組み合わせることも可能

ヘルスチェック
①EC2ヘルスチェック:インスタンスのステータスがrunning以外を以上と判断
②ELBヘルスチェック
・ヘルスチェックの猶予期間がある。インスタンス起動からヘルスチェック開始までの時間。アプリケーションデプロイを考慮
・異常と判断されたインスタンスは自動的に終了

クールダウン
スケーリングアクション実行後指定した時間は次にスケーリングアクションを実行しない仕組み
→インスタンス初期化中の無駄なスケーリングを回避するため
※シンプルスケーリングポリシーにのみ対応

ターミネーションポリシー
①OldestInstance/NewestInstance:起動時刻
②OldestLaunchConfiguration:最も古いLaunch Configuration
③ClosestToNextInstanceHour:課金のタイミングが近い
④Default:②③の順に適用。複数インスタンスが残ればランダム

インスタンス保護
任意のインスタンスを削除されないよう保護できる

・インスタンスのデタッチ、アタッチ、スタンバイ

ライフサイクルフック
Auto Scalingの起動/終了時に一定時間(デフォルトは1時間、最大48時間)待機させ、カスタムアクションを実行できる

・スケールアウト時の初期化処理
①設定済みのAMIを用いる
②user-dataで初期化スクリプトを実行(Bootstrap処理)
③ライフサイクルフックで初期化

・サーバーをステートレスにする
ステートレス:サーバーにセッション情報などがない。スケールアウトに向いている
ステートフル:サーバーにセッション情報あり。常にサーバー間で同期が必要なので、スケールアウトに向いていない

・突発的なスパイクには向いていない
→インスタンス作成~アプリ起動の時間がかかるため。
対応策としては、
①CloudFrontなど大きなキャパシティを持ったAWSサービスに処理をオフロードする
②スパイクを裁くのを諦め、スロットリング機能(処理性能の上限)を設ける
③一定以上の負荷を超えたら静的ページに切り替える

・ユースケース
①ELB配下のWebサーバーをAuto Scaling
→EC2は複数AZに分散し、高可用性
ELBのリクエスト数、EC2の平均CPU使用率などがトリガー

②SQSのジョブを処理するWorkerをAuto Scaling
キューのメッセージ数などがトリガー

③Blue/Green
Blue/Green
デプロイ時に、既存のインスタンスとは違うインスタンスを作成し、一気に/徐々に作成したインスタンスを使用するようにする。
移行方法は下記
・DNSのWeighted round robinを使用して、徐々にトラフィックを移行
→DNSのTTLを考慮する必要あり。
・ELBを利用して、移行する
→Elastic Container Service(ECS。Dockerコンテナを格納する場所)を利用して、新しいインスタンスを作成することも可能

In place
デプロイ時に既存のインスタンスを操作することで対応する

参考URL:http://aws.typepad.com/sajp/2015/12/what-is-blue-green-deployment.html

Elastic MapReduce(EMR)

<Hadoop(分散処理をしてくれるソフトウェア)を動かせる環境を提供してくれるサービス
参考URL:http://mgi.hatenablog.com/entry/2014/05/04/085148

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-auto-scaling

続きを読む

Alexa からの smart home skill イベントを SQS でデバイスに送信して結果を受信 【Python】

Alexa のスマートホームスキルで呼ばれる lambda で取得したイベントを SQS を使ってデバイスに送る方法を紹介します。目的は AWS の勉強ですので正直プロダクトじゃない場合はこの辺は自作せず買った方が良い気がします。
これは以前の記事にも書きましたが AWS greengrass でもっときれいに実現できる(と思います)。一応 python でスマートホームスキル書いたのでそれの軽い解説もしておきます。

前提

  • python 3.6
  • Alexa での smart home skill の作り方は知っている
  • 私は初めてのホームスキル作成

参考サイト

Alexa のスキルに対応するコード

Alexa のメッセージが送られて来る Lambda の部分です。namespacenameに合わせて処理内容を書きます。今回は基本的に Discovery のイベント以外はラズパイに投げてしまい、ラズパイで色々な作業をします。

smartHomeSkill.py
def my_handler(event, context):
    logging("DEBUG", "Request", event)
    header = event['directive']['header']
    namespace = header['namespace']
    name = header['name']

    # Discovery request だったら Lambda で処理
    if namespace == ALEXA_DISCOVERY and name == DISCOVER:
        return handleDiscovery(event, context)

    # 今回は Lambda 側ではあまり作業はせずにイベントをデバイスに渡してしまう
    # configファイルの読み込み
    ini = configparser.ConfigParser()
    ini.read("./config.ini")

    # 現在(2018/01/14)日本語の Alexa スキルはオレゴンでしか実行できないので
    # 東京リージョンのSQSを使うためにリージョンを指定
    sqs = boto3.client('sqs', region_name='ap-northeast-1')
    requestQueUrl = ini['sqs']['requestQueUrl']
    responseQueUrl = ini['sqs']['responseQueUrl']

    # イベントを送信
    result = sendQueBody(sqs, requestQueUrl, event)
    if result is False:
        return createErrorResponse(event, 'INTERNAL_ERROR', "Failed to send request to the device")
    # 結果を受信
    response = receiveQueBody(sqs, responseQueUrl)
    if response is None:
        return createErrorResponse(event, 'INTERNAL_ERROR', "Failed to receive a device's response")

    logging("DEBUG", "Response", response)
    return response

requestQueUrlresponseQueUrlには SQS の URL を設定ファイルから読み取っています。https://sqs.ap-northeast-1.amazonaws.com/XXXXXXXXXX/YYYYYYYYYってかんじのやつです。
SQS クライアントは作った場所のリージョンを指定する必要があるので気をつけてください。
スキルの作成時にどこで実行するのかを選べるのでおそらくエッジロケーションで lambda は実行されていると思います。Far-east と指定ができるのでおそらく日本付近で実行されているのではないかと。なので SQS も日本に作っておくのが良いと思います。

まずは本題の SQS の部分の説明、次におまけでhandleDiscovery(event, context)を紹介します。

SQS の送受信

sendQueBody()receiveQueBody()の実装です。

utils.py
# -*- coding: utf-8 -*-
import json
import hashlib

# url で指定した SQS に body を json で送信
def sendQueBody(sqs, url, body):
    jsonBody = json.dumps(body)
    response = sqs.send_message(
        QueueUrl=url,
        DelaySeconds=0,
        MessageBody=(
            jsonBody
        )
    )

    # 送信に成功したか確認
    if response['MD5OfMessageBody'] != hashlib.md5(jsonBody.encode('utf-8')).hexdigest():
        logging("ERROR", "sendQueBody", "Failed to send sqs")
        return False

    return True

# SQS からメッセージを受け取る
# returnType: dict
def receiveQueBody(sqs, url):
    response = sqs.receive_message(
        QueueUrl=url,
        AttributeNames=[
            'SentTimestamp'
        ],
        MaxNumberOfMessages=1,
        VisibilityTimeout=0,
        WaitTimeSeconds=20
    )

    # キューになにもない場合
    if 'Messages' not in response:
        return None

    message = response['Messages'][0]
    body = json.loads(message['Body'])

    # メッセージを削除するための情報を取得
    receipt_handle = message['ReceiptHandle']

    # 場合によっては処理が完了してからメッセージを削除するが
    # 今回は受信した時点で削除する
    sqs.delete_message(
        QueueUrl=url,
        ReceiptHandle=receipt_handle
    )

    return body

SQS からデータを削除するタイミングは場合によると思いますが、今回は Alexa に命令したものが一回失敗したら次も失敗する想定だったのでリトライとか考えずに受信したら削除してしまいます。sqs.send_message()MD5OfMessageBodyによって送信ができているかが確認できます。

handleDiscovery(event, context)

Alexa にスマートホーム家電を見つけてなどと指示をしたときの処理をする部分です。これで「電気をつけて」などに対応できることを Alexa に伝えられます。対応する部分は別に実装する必要があります。

smartHomeSkill.py
# Alexa の Discovery request に対応するためのコード
# ここでこのスキルで使えるデバイスの内容を全て返してあげる。
def handleDiscovery(event):
    payload = {
        "endpoints": [
            {
                # 電気
                "endpointId": RIGHT_00["endpointId"],
                "manufacturerName": COMPANY_NAME,
                "friendlyName": RIGHT_00["friendlyName"],
                "description": "This is smart device",
                "displayCategories": [RIGHT_00["displayCategories"]],
                "capabilities": [{
                    "type": "AlexaInterface",
                    "interface": "Alexa",
                    "version": "3"
                },
                    {
                        "interface": "Alexa.PowerController",
                        "version": "3",
                        "type": "AlexaInterface",
                        "properties": {
                            "supported": [{
                                "name": "powerState"
                            }],
                            "retrievable": True
                        }
                    }
                ]
            },
            {
                # TV
                "endpointId": TV_00["endpointId"],
                "manufacturerName": COMPANY_NAME,
                "friendlyName": TV_00["friendlyName"],
                "description": "This is smart device",
                "displayCategories": [TV_00["displayCategories"]],
                "capabilities": [{
                    "type": "AlexaInterface",
                    "interface": "Alexa",
                    "version": "3"
                },
                    {
                        "interface": "Alexa.PowerController",
                        "version": "3",
                        "type": "AlexaInterface",
                        "properties": {
                            "supported": [{
                                "name": "powerState"
                            }],
                            "retrievable": True
                        }
                    }
                ]
            },
            {
                # エアコン
                "endpointId": THERMOSTAT_00["endpointId"],
                "manufacturerName": COMPANY_NAME,
                "friendlyName": THERMOSTAT_00["friendlyName"],
                "description": "This is smart device",
                "displayCategories": [THERMOSTAT_00["displayCategories"]],
                "capabilities": [{
                    "type": "AlexaInterface",
                    "interface": "Alexa",
                    "version": "3"
                },
                    {
                        "interface": "Alexa.PowerController",
                        "version": "3",
                        "type": "AlexaInterface",
                        "properties": {
                            "supported": [{
                                "name": "powerState"
                            }],
                            "retrievable": True
                        }
                    }
                ]
            }
        ]
    }
    header = event['directive']['header']
    header['name'] = "Discover.Response"
    logging("DEBUG", 'Discovery Response: ', ({'header': header, 'payload': payload}))
    return {
        'event': {'header': header, 'payload': payload}
    }

所感

Alexa スキルが Lambda で実装されていることをしり、面白そうだなと Alexa 予約してスキルを作っています。JSONでの送受信フォーマットが違うと Alexa は毎回「XXの応答がありません」としか返してくれないのでデバックがやりにくいです。またいざ自分で作ってみると日本語に対応していない API が多いようでがっかりしています。早く対応してほしい。これからさかんになる IoT の実装を体験できたのは良い勉強だったのではないでしょうか。

まとめ

今回は Lambda から SQS の送受信を説明しました。また Alexa に Discovery 部分も軽く紹介しました。今度はラズパイでの家電を実際に動かす実装を紹介します。

続きを読む

scrapy でクローラーを実装し、画像を収集してみる

AWS Rekognition を使う時にクローラーも使ってなんかできないかなと思い scrapy を利用してみました。とりあえず今回はドメインと画像収集のところまで。いかがわしいことには絶対利用しないでください

今回はスタートのページからどんどんリンクを辿り、ドメイン名のフォルダごとに、辿った時のページの画像を保存します。今度そのフォルダごとに画像を AWS Rekognition に投げて、そのドメインがどんなドメインなのかを画像から判別しようと考えています。

前提

  • scrapy 1.5.0
  • python3
  • scrapy インストール済み

参考サイト

Spider のコード

クローラーの肝となる部分です。参考サイトではCrawlSpiderクラスを継承して利用している場合が多かったです。そっちの方が大抵の場合は楽だと思います。

WebSpider.py
# -*- coding: utf-8 -*-
  import scrapy
  from tutorial.items import TutorialItem
  import re
  from scrapy.exceptions import NotSupported
  from urllib.parse import urlparse


  class WebSpider(scrapy.Spider):
      name = 'web'
      # 見つけたドメインを入れる
      tracked_domains = []
      # 全てを対象
      allowed_domains = []
      # 最初に見に行くサイト
      start_urls = ['http://XXXXXXXXXXXXX']

      # response を毎回処理する関数
      def parse(self, response):
          try:
              # データ処理
              # この関数内の処理が終わると続きを実行する
              # dataPipeline を利用した場合もここに戻って来る
              yield self.parse_items(response)

              # リンクを辿る
              for link in response.xpath('//@href').extract():
                  if re.match(r"^https?://", link):
                      yield scrapy.Request(link, callback=self.parse)
          except NotSupported:
              # GET のレスポンスが txt じゃなかった場合
              # Spiders の logging 機能が用意されているのでそれを利用
              self.logger.info("Raise NotSupported")

      # ドメインごとにページに表示された画像を保存する
      def parse_items(self, response):
          # domain の抽出
          url = response.url
          parsed_url = urlparse(url)
          domain = parsed_url.netloc

          # 同じ Domain は一回しかチェックしない
          if domain in self.tracked_domains:
              return

          self.tracked_domains.append(domain)

          item = TutorialItem()
          item['domain'] = domain

          # title の抽出
          title = response.xpath(r'//title/text()').extract()
          if len(title) > 0:
              item['title'] = title[0]
          else:
              item['title'] = None

          # 画像 URL をセット
          item["image_urls"] = []
          for image_url in response.xpath("//img/@src").extract():
              if "http" not in image_url:
                  item["image_urls"].append(response.url.rsplit("/", 1)[0]
                         + "/" + image_url)
              else:
                  item["image_urls"].append(image_url)

          # item を返すと datapipeline に渡される
          return item

start_urlsに設定したURLを元にクローラーが動きます。
私はそんなことはしませんが、ここにいかがわしいサイトを指定するとリンクを辿って新しいいかがわしいサイトのドメインが見つかるかもしれません。私はそんなことしませんが。

基本的にはparse()関数が scrapy のレスポンスごとに呼ばれて処理を行います。
今回は途中でparse_items()を呼び出し、まだ保存していないドメインであればフォルダを作成してそのページ上の画像を保存します。

settings.py で scrapy の設定を記述

parse_items()itemを return すると、ImagePipeline に渡されます。
その設定は以下の通りです。自作 Pipeline の説明は後述。

settings.py
  # 自作 pipeline に繋げる
  ITEM_PIPELINES = {'tutorial.pipelines.MyImagesPipeline': 1}
  # データの保存場所
  IMAGES_STORE = '/Users/paper2/scrapy/tutorial/imgs'
  # リンクを辿る深さを指定
  DEPTH_LIMIT = 5
  # LOG_LEVEL = 'ERROR'
  DOWNLOAD_DELAY = 3

pipelines.py で pipeline をカスタマイズ

デフォルトの ImagePipeline ですとドメインごとのフォルダを作成して、、、などといった追加の作業ができないので継承して自分で作成します。

pipeliens.py
# -*- coding: utf-8 -*-
from scrapy.pipelines.images import ImagesPipeline
import os
from tutorial import settings
import shutil


class MyImagesPipeline(ImagesPipeline):
    def item_completed(self, results, item, info):
        # DL できたファイルのパス
        file_paths = [x['path'] for ok, x in results if ok]

        # ドメインごとのフォルダに move
        for file_path in file_paths:
            img_home = settings.IMAGES_STORE
            full_path = img_home + "/" + file_path
            domain_home = img_home + "/" + item['domain']

            os.makedirs(domain_home, exist_ok=True)
            # DL した結果同じファイルのことがある
            if os.path.exists(domain_home + '/' + os.path.basename(full_path)):
                continue
            shutil.move(full_path, domain_home)

        # parse() の続きに戻る
        return item

これで完成です。

実際に回してみる

しばらく回すと色々なドメインから画像が集まりました。
Screen Shot 2018-01-20 at 20.07.47.png

うん?よくみたらいかがわしいサイトのドメインが混ざっているぞ、、、画像もいかがわしいものが、、、、ということで次回はこのいかがわしいドメインを取り除く (逆にそれだけ残す??)のを AWS Rekognition でやってみようと思います。

続きを読む