lambda-uploaderの記事を書きましたが続いてchaliceのご紹介を。

chalice

chaliceはAWS謹製のツールで、非常に簡単にLambda + API Gatewayをデプロイできるすぐれものです。
https://chalice.readthedocs.io/en/latest/

インストール〜デプロイ

公式サイトにも記述がありますが、

$ pip install chalice
$ chalice new-project helloworld && cd helloworld
$ chalice deploy

たったこれだけでLambda + API Gatewayのデプロイをしてくれます。
デプロイが完了すると以下のように生成されたエンドポイントをガイドしてくれます。

Creating deployment package.
Creating IAM role: helloworld-dev
Creating lambda function: helloworld-dev
Creating Rest API
Resources deployed:
  - Lambda ARN: arn:aws:lambda:ap-northeast-1:000000000:function:helloworld-dev
  - Rest API URL: https://000000.execute-api.ap-northeast-1.amazonaws.com/api/

Flaskをベースに作られているので、Flaskに馴染みのある方であればすぐにご利用いただけるかと。また、以下のコマンドを実行するとローカルでサービス起動できるので、デプロイ前のローカルテストもできます。

chalice local

Lambdaの設定カスタマイズ

chaliceを使ってデプロイするとIAMロール作成など必要な設定を自動で実行してくれます。ただ、運用によっては困るケースもありますよね。以下の設定ファイル（config.json）をカスタマイズすることで手動で指定することもできます。

$ tree -a
.
├── .chalice
│   └── config.json
├── app.py
└── requirements.txt

例えば、既存のIAMロールを指定したい場合などは以下のように設定します。

{
  "version": "2.0",
  "app_name": "app",
  "stages": {
    "dev": {
      "autogen_policy": true,
      "api_gateway_stage": "dev"
    },
    "beta": {
      "autogen_policy": false,
      "iam_policy_file": "beta-app-policy.json"
    },
    "prod": {
      "manage_iam_role": false,
      "iam_role_arn": "arn:aws:iam::...:role/prod-role"
    }
  }
}

上の例では、３つのステージ（dev, beta, prod）を指定しています。devステージはポリシーを自動生成します。betaステージは設定ファイル（.chalice/beta-app-policy.json）をロードし、IAMロールとの関連付けを行います。prodステージは、IAMロールの変更はされません。Lambda関数に指定されたロール（arn:aws:iam::...:role/prod-role）の設定のみを行います。

詳細は公式を参照してくださいませ。

まとめ

最高ですね。
ただ、このツールがサポートしているのはpythonのみです。サーバーレス環境のバックエンドをpythonで手軽に書きたい方にはオススメです。お試しいかがでしょうか？

AWSソリューションアーキテクト-アソシエイトに合格しました。
合格までに意識したポイントや勉強の流れをご紹介したいと思います。

試験を受けたきっかけ

普段からAWSに携わる機会があるものの、アーキテクチャのベストプラクティスの理解とサービスの知識をより深めたいという思いで勉強目的で受験しました。

勉強の流れ

１、Well-Architected frameworkのホワイトペーパーを読む
２、各種ブラックベルトを読む（2〜3周くらい）
３、ブラックベルトでわからない部分をドキュメントで理解を深める
４、ネットワークを構築してみる
５、書籍で設計パターンの理解と問題演習
６、サンプル問題を解く
７、模擬試験を受ける

まずは、Well-Architected frameworkのポイントをつかむ。設計原則をしっかり学んだ上で各サービスの理解を進める。

また、ネットワークについては実際に構築できることが重要。自分はここが弱いと思ったため、実際にVPC、サブネット、ルートテーブル、セキュリティグループ、ACL、NATゲートウェイ、VPCエンドポイントなど全て設定をしてみて、自分でネットワーク図を書いて実現できるまで試した。

これをやった後は、ネットワーク系の問題の状況が簡単にイメージできるようになり自信になった。

サンプル問題

力試しにチャレンジ。全問正解できるまでブラックベルトで復習。

模擬試験

お金がかかるが受けて良かった。問題のイメージができる。
ここで理解が足りてないところをブラックベルトで復習する。

本試験

<受験した所感>
サンプル問題や模擬試験より難しく問われる状況が更に深い印象。
実際に顧客からアーキテクチャの相談を受けているような気分になる。問題から状況や問題を理解できる最低限のインフラ知識や経験も必要だと感じた。

サーバーレスでアプリを作っていて、日々Lambda関数を生産しています。
コンソールから作成することもできますが、コード管理が煩雑になるのと、IDEの補完機能を使いたいのとで、私はできるだけローカルで作成してからデプロイするようにしています。ただ、ローカルで作成したLambdaをデプロイするには、コードのZip化とファイルのアップロードが必要で地味に面倒です。
そういった作業をサポートしてくれるツールがあるので紹介したいと思います。
まずは手軽なやつから

lambda-uploader

いくつか使っている中で一番手軽なツール（だとおもう）
https://github.com/rackerlabs/lambda-uploader

インストール

pip install lambda-uploader

プロジェクト作成

mkdir myFunction

cd myFunction
touch my_function.py

my_function.pyに所望の実装を施します。

例：my_function.py

def lambda_handler(event, context):
    return {'hello': 'world'}

lambda.jsonを作成します。

例；lambda.json

{
  "name": "myFunction",
  "description": "hello world",
  "region": "ap-northeast-1",
  "runtime": "python3.7",
  "handler": "my_function.lambda_handler",
  "role": "arn:aws:iam::00000000000:role/lambda_basic_execution",
  "requirements": ["pygithub"],
  "timeout": 30,
  "memory": 128,
}

外部ライブラリを利用したい場合は、lambda.jsonにrequirementsを追加します。

{
...snip...
  "role": "arn:aws:iam::00000000000:role/lambda_basic_execution",
  "requirements": ["requests"],
  "timeout": 30,
...snip...
}

（requirements.txtで指定することもできます。）

デプロイ

lambda.jsonを作成したディレクトリで以下のコマンドを実行します。

lambda-uploader

ターミナルに次のようなメッセージが出れば無事成功。

λ Building Package
λ Uploading Package
λ Fin

その他

lambda.jsonにはアカウントに依存した情報（role）が入っています。CI/CDにlambda-uploaderを利用する場合には、lambda.jsonをDevとPrdに分けて、--configオプションで切り替えるようにすると良さそう。

■ AWSのGPUインスタンスの種類について

• GPUインスタンスにはG系とP系が存在

〇 P系のインスタンス：機械学習や金融工学、分子モデルシミュレーションなどの処理向け

• 種類

  • p2.xlarge
  • p2.8xlarge
  • p2.16xlarge
  • p3.2xlarge
  • p3.8xlarge
  • p3.16xlarge
  • p3dn.24xlarge

• 搭載GPU

  • P2インスタンス：NVIDIA Tesla K80
  • P3インスタンス：NVIDIA Tesla V100

〇 G系のインスタンス：3Dレンダリング、動画エンコーディングなどグラフィック処理向け

• 種類

  • g3s.xlarge
  • g3.4xlarge
  • g3.8xlarge
  • g3.16xlarge

• 搭載GPU

  • G3インスタンス：NVIDIA Tesla M60

■ スペック・価格比較について(※2019/05/22の情報)

〇 P系のスペック・価格比較表

インスタンス	GPUの種類	GPU数	ベースクロック(MHz)	CUDAコア数	GPUメモリ(GiB)	vCPU	RAM	価格/h (USD)
p2.xlarge	Tesla K80	1	560	2,496	12	4	61	0.9000
p2.8xlarge	Tesla K80	8	560	19,968	96	32	488	7.2000
p2.16xlarge	Tesla K80	16	560	39,936	192	64	732	14.4000
p3.2xlarge	Tesla V100	1	1245	5,120	16	8	61	3.0600
p3.8xlarge	Tesla V100	4	1245	20,480	64	32	244	12.2400
p3.16xlarge	Tesla V100	8	1245	40,960	128	64	488	24.4800
p3dn.24xlarge	Tesla V100	8	1230	40,960	256	96	768	31.2120

※ 米国東部 (バージニア北部)および米国西部(オレゴン)の価格

〇 G系のスペック・価格比較表

インスタンス	GPUの種類	GPU数	ベースクロック(MHz)	CUDAコア数	GPUメモリ(GiB)	vCPU	RAM	価格/h (USD)
g3s.xlarge	Tesla M60	1	1180	2,048	8	4	30.5	0.7500
g3.4xlarge	Tesla M60	1	1180	2,048	8	16	122	1.1400
g3.8xlarge	Tesla M60	2	1180	4,096	16	32	244	2.2800
g3.16xlarge	Tesla M60	4	1180	8,192	32	64	488	4.5600

※ 米国東部 (バージニア北部)および米国西部(オレゴン)の価格

〇 利用料金について

• AWSのGPUインスタンスの利用料金はGPUインスタンスの利用料金(上記)とElastic Block Store(EBS：ストレージ)の利用料金の和になる

• (AWSのGPUインスタンスの利用料金=GPUインスタンスの利用料金+Elastic Block Storeの利用料金)

• 参考：EBS汎用SSDボリューム⇒1GBあたり月0.100 USD

■ AWSのGPUインスタンスの種類について

• AWSのGPUインスタンスにはG系とP系が存在

〇 P系のインスタンス：機械学習や金融工学、分子モデルシミュレーションなどの処理向け

• 種類

  • p2.xlarge
  • p2.8xlarge
  • p2.16xlarge
  • p3.2xlarge
  • p3.8xlarge
  • p3.16xlarge
  • p3dn.24xlarge

• 搭載GPU

  • P2インスタンス：NVIDIA Tesla K80
  • P3インスタンス：NVIDIA Tesla V100

〇 G系のインスタンス：3Dレンダリング、動画エンコーディングなどグラフィック処理向け

• 種類

  • g3s.xlarge
  • g3.4xlarge
  • g3.8xlarge
  • g3.16xlarge

• 搭載GPU

  • G3インスタンス：NVIDIA Tesla M60

■ GPUインスタンスのスペック・価格の比較(※2019/05/22の情報)

〇 P系のスペック・価格比較表

インスタンス	GPUの種類	GPU数	クロック(MHz)	CUDAコア数	GPUメモリ(GiB)	vCPU	RAM	価格/時間(USD)
p2.xlarge	Tesla K80	1	560	2,496	12	4	61	$0.9000
p2.8xlarge	Tesla K80	8	560	19,968	96	32	488	$7.2000
p2.16xlarge	Tesla K80	16	560	39,936	192	64	732	$14.4000
p3.2xlarge	Tesla V100	1	1,245	5,120	16	8	61	$3.0600
p3.8xlarge	Tesla V100	4	1,245	20,480	64	32	244	$12.2400
p3.16xlarge	Tesla V100	8	1,245	40,960	128	64	488	$24.4800
p3dn.24xlarge	Tesla V100	8	1,230	40,960	256	96	768	$31.2120

※ 米国東部 (バージニア北部)および米国西部(オレゴン)の価格

〇 G系のスペック・価格比較表

インスタンス	GPUの種類	GPU数	クロック(MHz)	CUDAコア数	GPUメモリ(GiB)	vCPU	RAM	価格/時間(USD)
g3s.xlarge	Tesla M60	1	1,180	2,048	8	4	30.5	$0.7500
g3.4xlarge	Tesla M60	1	1,180	2,048	8	16	122	$1.1400
g3.8xlarge	Tesla M60	2	1,180	4,096	16	32	244	$2.2800
g3.16xlarge	Tesla M60	4	1,180	8,192	32	64	488	$4.5600

※ 米国東部 (バージニア北部)および米国西部(オレゴン)の価格

〇 利用料金について

• AWSのGPUインスタンスの利用料金=GPUインスタンスの利用料金(上記)+Elastic Block Store(EBS：ストレージ)の利用料金
  • 参考：EBS汎用SSDボリュームの利用料金⇒1GBあたり月0.100 USD

環境

• AWS CodeStar
• Python: 3.6
• pipenv: 2018.7.1
• pip: 18.0.0
• Django: 1.11.18

執筆したきっかけ

• 研究で開発する実験用システムをデプロイするため
• AWSに（ちゃんと）初挑戦する！
• 開発するシステムをそれなりな環境で動かす必要があるため，herokuじゃ厳しそう
• 毎度手作業でデプロイするのがしんどい

CodeStarとは

AWS CodeStar を使用すると、アプリケーションを迅速に開発および構築して AWS にデプロイできます。
AWS CodeStar

とのこと．
つまり，「CI/CDも含めたWEBアプリの開発環境を，お手軽に構築するよ！」というサービスです．
対応する言語やフレームワークがたくさんあり，困ることはなさそうです．
ちなみに，2019-05-22時点では，

• Go
• Node.js
• Python, (FlaskやDjangoを含む)
• Ruby on Rails
• Lalavel
• Java
  

などがありました．
さらに，

AWS CodeStar に対する追加料金はありません。CodeStar プロジェクトでプロビジョニングした AWS リソース (例: Amazon EC2 インスタンス、AWS Lambda の実行、Amazon EBS ボリューム、Amazon S3 バケット) に対してのみ料金を支払います。実際に使用した分に対してのみ料金が発生します。最低料金や前払いの義務はありません。
AWS CodeStar の料金

嬉しい限りです．

Djangoのテンプレート

テンプレートは2種類ありました．
1. EC2で実行する
2. Elastic Beanstalkを介して実行する

つまり，Dockerを使うかどうかが大きく違うところでしょうか（間違っていたらすみません）
私の場合，大規模開発でもないので，1でやってみました．

プロジェクトを作成する

AWSのコンソールから，CodeStarを選択します

テンプレートから，Djangoを選択します．

プロジェクト名や，ソースコードのリポジトリを選択します．
私は，GiHubを選択しました．GitHubを選択すると，リポジトリ名やリポジトリをprivateかpublicに選択できます．

続いて，AWSCodeStarに権限を付与することを許可します．その他，Amazon ECの設定を編集から，使用するEC2，VPC，サブネットを変更することもできます．

ご丁寧に，作成したリポジトリも案内してくれます．
後はデプロイが完了するまで待機です．

これで，デプロイ完了です．

アプリ自体は，アプリケーションのエンドポイントよりアクセスできます．
今後はGitHub上のmasterへpushすると，CodeStarがそれを検知してデプロイまでやってくれます．

感想

すごい．．．ただし，現状はCIが回っていません．また，DBはSqliteのままです．これから，頑張ります！！
iOS以外の領域にうとい私でもできました．AWS様々です．

補足

CodeStarが作成したリポジトリのREADMEを見ると，各ファイルの説明や，ローカル環境下でDjango製のアプリを起動するまで書かれていました．また，READMEにはvirtualenvを使用した方法を紹介していましたが，私はpipenvを使用しました．

追記（2019-05-23）

提供された buildspec.yml には，マイグレーションに関わる記述がありません．したがって，追記する必要があります．記述内容に自身はありません

phases:
  install:
    commands:
      # Install dependencies needed for running tests
      - pip install -r requirements.txt
      # Migrations
      - python manage.py makemigrations # 追記
      - python manage.py migrate # 追記

参考文献

AWS CodeStarを使っていい感じの開発環境を一瞬で作る

はじめに

イベントソースに SQS を指定した場合、LambdaFunction は同期的に呼び出される。
S3 をイベントソースに指定した場合（非同期な呼び出し）と振る舞いが異なる。
キューの例外処理を設計するにあたって考慮すべきポイントを整理した。

1. 非同期呼び出しになるイベントソースの場合(S3, SESなど)

• リトライなど、失敗時の動作は Lambda Function 側でコントロールする

1.1 失敗時の動作

リトライ

• デフォルトで 2 回リトライされる

失敗の検知、処理

• すべてのリトライで失敗した場合、 Lambda Function に指定した DeadLetterQueue に通知される

1.2 計画的な停止時のふるまい

• イベントソースマッピングを無効化
  • 無効化している間に発生したイベントは失われる(イベントソースマッピングを再度有効化しても処理されない)
• Lambda Function を Throttling
  • 2回リトライし、失敗した場合はイベントが DeadLetterQueue に送られる

2. 同期呼び出しになるイベントソース (SQS)

• リトライなど、失敗時の動作は イベントソース（SQS）側でコントロールする

2.1 失敗時の動作

If you configure an Amazon SQS queue as an event source, AWS Lambda will poll a batch of records in the queue and invoke your Lambda function. If the invocation fails or times out, every message in the batch will be returned to the queue, and each will be available for processing once the Visibility Timeout period expires.

• すべての処理中のバッチはキューに戻される
• 戻されたメッセージは可視性タイムアウトが期限切れになると再処理可能になる

リトライ

• メッセージの再処理に関するSQSのパラメータ
  • 可視性タイムアウト: 0-12 h (default: 30 sec)
    • 他のプログラムが同一のメッセージを処理するのを保留する時間
  • 最大受信数: 1-1000
    • デッドレターキューに送信されるまでにメッセージを受信できる最大回数
  • 保持期間: 1 min - 14 days (default: 4 days)
    • 処理しない状態のメッセージがキューに保持される最大期間

失敗の検知、処理

• SQS側で指定した DeadLetterQueue に入る

2.2 計画的な停止時のふるまい

• イベントソースマッピングを無効化
  • メッセージが削除される条件が満たされるまでキューに残る
• Lambda Function を Throttling
  • メッセージが削除される条件が満たされるまでキューに残る

参考

1. AWS Lambdaの再試行動作
2. チュートリアル：Amazon SQSデッドレターキューを設定する
3. チュートリアル：Amazon SQSキューに可視性タイムアウトを設定する
4. Amazon SQSのDead Letter Queueにメッセージが移動するタイミングを調べてみた

APIGatewayのStepFunctions Integration

API Gatewayの統合タイムアウトの最大は29秒なので、バッチ等の時間がかかる処理を行うAPIを作成する場合は統合先にLambdaではなくStepFunctionsを設定し、StartExecutionだけのレスポンスを得て裏で処理を継続させるパターンがあると思います。

参考資料:
【API Gatewayタイムアウト対策】Step Functionsを組み合わせて非同期処理にしてみる

MappingTemplate

StartExecutionのAPIを叩く場合、リクエストのpayloadにはStepFunctionsで使うInputとMachineARNを付与します。
Inputは、エスケープされたJSONが必要ですが、これはMappingTemplateで処理可能です。

公式ドキュメントにサンプルが載っています

必要なリクエストbody

{
   "input": "{}",
   "name": "MyExecution",
   "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorld"
}

公式のサンプルMappingTemplate

{
    "input": "$util.escapeJavaScript($input.json('$'))",
    "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorld"
} 

$util.escapeJavaScriptを使ってリクエストbodyのJSONをエスケープしています。
また、stateMachineArnを指定しているのでリクエストに含める必要がなくなります。
したがって、このMappingTemplateを適用した場合のリクエストはinputそのものになります。
name属性はExecutionNameなので90日間ステートマシン内で一意である必要があるんですが、
指定しなければAPIGatewayが生成するRequestIdがそのまま使われるようです。

RequestBody

{
   "input_key": "input_value"
}

変換後のbody

{
   "input": "{\"input_key\" : \"input_value\"}",
   "name": "requestId",
   "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorld"
}

inputにrequestContextを含みたい！

サンプルの構成のだとステートマシンに与えられるinputはリクエストbodyのみです。
つまりStepfunctionから呼ばれるLambdaはcontextを参照できません。
それでは少し不便なのでMappingTemplateを少し改良してRequestIdをinputに含めてみましょう。

MapingTemplate

#set( $body = $util.escapeJavaScript($input.json('$')) )
{
  "input": "{\"input\":$body,\"requestContext\":{\"requestId\":\"$context.requestId\"}}",
  "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorld"
}

#set( $body = $util.escapeJavaScript($input.json('$')) )で$bodyにinput jsonを代入します。
$contextでリクエスト時のcontextにアクセスできます。
$context.requestIdとすることで実際のRequestIdを値としてセットしています。
あとは忘れないようにinputの中をエスケープしましょう。
これを忘れるとInternal ServerErrorになってしまいます（泣）

さっきと同じようにリクエストしてみます。

RequestBody

{
   "input_key": "input_value"
}

変換後のbody

{
  "input": "{\"input\":{\"input_key\":\"input_value\"}, \"requestContext\":\"requestId\"}",
  "name": "requestId",
  "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorld"
}

これでステートマシン内のFunctionからRequestIdが拾えるようになりました。

Serverless Frameworkでのデプロイ

AWS SAMでも良いのですがdefinitionの記述だけJSONになってしまうのでこちらを選択しました。
serverless-step-functionsというプラグインを使うことでデプロイ可能です。

serverless.yml

plugins:
  - serverless-step-functions

functions:
  hello:
    handler: handler.hello

stepFunctions:
  stateMachines:
    MyStateMachine:
      name: myStateMachine
      events:
        - http:
            path: /execute
            method: post
            request:
              template:
                application/json: |
                  #set( $body = $util.escapeJavaScript($input.json('$')) )
                  {
                    "input": "{\"input\":$body,\"requestContext\":{\"requestId\":\"$context.requestId\"}}",
                    "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorld"
                  }
      definition:
        Comment: "serverless"
        StartAt: HelloWorld1
        States:
          HelloWorld1:
            Type: Task
            Resource:
              Fn::GetAtt: [HelloLambdaFunction, Arn]
            End: true

providerは省略しています。
こんな感じで簡単にステートマシンとAPIGatewayを作成できます。
基本的な使い方は大体readmeに書いてあり始めやすいです。
非常に使いやすいのですが、構成次第ではちょっと工夫が必要になります。
例えば、

• StartExecution以外のAPI叩きたいとき

デフォルトがStartExecutionになっているようで、Describeを叩きたい場合はResourcesでオーバーライドする必要があります

• APIKeyRequireがデフォルトでオフ

APIKeyの作成は問題なくできますが、メソッドに対する必須条件をつける際はこれもResourcesでオーバーライドしましょう。

• ２つめのAPIGatewayリソースを作成した場合１つ目のMappingTemplateがコピーされる(気がする)

例えばこのような定義をしたとき、

stepFunctions:
  stateMachines:
    MyStateMachine:
      name: myStateMachine
      events:
        - http:
            path: /execute
            method: post
            request:
              template:
                application/json: |
                  #set( $body = $util.escapeJavaScript($input.json('$')) )
                  {
                    "input": "{\"input\":$body,\"requestContext\":{\"requestId\":\"$context.requestId\"}}",
                    "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorld"
                  }
        - http:
            path: /describe
            method: post

これをデプロイすると、
/executeのtemplateが/describeにも装備されてしまうような動作をしました。
これもResourcesで上手くやれば解決します。
あとはMethodResponseとかいろいろありますがServerlessFrameworkのいいところは
pluginが対応していなくてもResourcesで定義してやればなんとかなるところですね。
その分記述量は増えてしまいますが、筆者はよく生のCloudformation templateをガリガリ書いていたので特に抵抗感や苦労はありませんでした。。。

はじめに

引き続き、Udemy にて Stephane Maarek 氏 が提供している「 AWS CloudFormation Master Class 」コースについて紹介していきます。今回の内容は、「 CloudFormation Parameters 」 です。

• これまでの AWS CloudFormation Master Class の記事
  • その①
  • その②
  • その③

CloudFormation Parameters

CloudFormation Parameters について

• パラメータは CloudFormation のテンプレートに入力する値を設定する方法
• テンプレートの作成においてパラメータの設定は重要
• パラメータを設定することで、テンプレートのミスを減らすことができる

パラメータについて

パラメータを作成する際は、以下の設定を行うことができます。

• Type：パラメータのデータの型
  • String：文字列
  • Number：数値
  • List：上記の Type を配列
  • AWS Parameter：AWS 独自のパラメータ
• Description：パラメータの詳細や内容
• Constraints, ConstraintDescription(String)：制約、制約の詳細
• Min/MaxLength：string 型の最小/最大文字数
• Mi/MaxValue：num 型の最小/最大文字数
• Defaults：値を指定しなかった場合の標準設定値
• AllowedValues（array）：パラメータで使用できる値の配列
• AllowedPattern（regexp）：string 型のパターンに使用する正規表現
• NoEcho（Boolean）：値をパスワード入力時の非表示みたいに設定可能

パラメータの見方について

それでは、実際に YAML ファイルの内容を見ながら、パラメータを見ていきましょう。
ダウンロードしたコードから「 0-parameters-hands-on.yaml 」YAML ファイルを選択して表示します。

この1つの YAML のブロックが1つのパラメータで、これはセキュリティグループのパラメータを表しております。

• SecurityGroupDescription：このパラメータの名称
  • Description：セキュリティグループの詳細
  • Type：string 型

セキュリティグループポートのパラメータ

• SecurityGroupPort：このパラメータの名称
  • Description：最小値と最大値を含む、数値パラメータの詳細
  • Type：number 型
  • MinValue：最小数値
  • MaxValue：最大数値

EC2 インスタンスのパラメータ

• InstanceType：このパラメータの名称
  • Description：Web サーバ EC2 インスタンスタイプ
  • Type：string 型
  • Default：この場合、「t2.small」が標準設定とされている
  • AllowedValues：この場合、「t2.small」以外に選べるインスタンスタイプの値

このように、パラメータを設定することで利用できる EC2 のインスタンスタイプを制限することができます。
また、default で t2.small を設定しているため、インスタンスタイプの選択に迷っても問題なく作成することができます。

次のパラメータは、DBパスワードと KeyName というパラメータです。

• DBPwd：パラメータの名称

  • NoEcho：「 true 」と設定しているため、値を隠す事が可能
  • Description： データベース admin アカウントパスワード
  • Type：このパラメータは string 型

• KeyName：パラメータの名称

  • Description：インスタンスに SSH アクセス可能な既存の EC2 キーペア名
  • Type：サポートされている AWS 固有のパラメータータイプ（ 内容は「 Amazon EC2 のキーペア名 」 ）
  • ConstraintDescription：既存の EC2 キーペア名であること

セキュリティグループ Ingress CIDR のパラメータ

• SecurityGroupIngressCIDR：パラメータの名称
  • Description：EC2 インスタンスとの疎通に使う IP アドレス範囲
  • Type：string 型
  • MinLength：最短値
  • MaxLenght：最長値
  • Default：標準設定の IP アドレス
  • AllowedPattern：この形式に沿った IP アドレスのパターンを許可
  • ConstraintDescription：有効な IP CIDR 範囲で x.x.x.x/x. 形式が条件（制約）

一気に3つのパラメータを見てみましょう

• MyVPC：パラメータの名称

  • Description：VPC の動作について
  • Type：AWS 固有のパラメータータイプ（ 内容は「 VPC ID (vpc-a123baa3 など) 」 ）

• MySubnetIDs：パラメータの名称

  • Description：サブネット ID のリスト
  • Type：AWS 固有のパラメータータイプ（ 内容は「サブネット ID (subnet-123a351e など)」 ）

• DbSubnetIpBlocks：パラメータの名称

  • Description：カンマで区切られた3つの CIDR ブロック
  • Type：カンマで区切られたリテラル文字列の配列
  • Default："10.0.48.0/24", "10.0.112.0/24", "10.0.176.0/24" の3つを標準利用

パラメータは AWS が公式でテンプレートを紹介しているので、そちらを元に作成するのをオススメします。

パラメータの内容を確認

パラメータの内容を見てきたことで、この YAML ファイルの内容を知ることができました。それでは、実際にこのファイルをアップロードして、作成していきましょう。

作成するスタックの名前を入力し、下のパラメータを確認すると、先ほど確認したパラメータの条件が、それぞれ反映されているのが確認できます。

パラメータを全て設定したら、「次へ」をクリックして作成していきます。

もし入力したパラメータの内容に間違いがあれば、「 ERROR 」と表示され、その理由も表記されます。

このYAML ファイルのコードを CloudFormation Desinger にコピペすれば、図で内容を確認することもできます。

おわりに

CloudFormation の parameters についての紹介は以上です。これで、これまでアップロードしてきた YAML ファイルの内容について詳しくなっただけでなく、ユーザ自身で YAML を書く方法も学べたかと思います。
次回は、Resource について紹介していく予定ですので、お楽しみに。

AWS DeepRacerをノリと勢いで走らせてみた

前置き

• ノリと勢いだけで評価関数を作成しているので、あまり参考にならないかもしれない
• 拙い無いようなので流し見を推奨します（オイ

とりあえず評価関数（ドン

def reward_function(params):
    # 入力パラメータを読む
    track_width = params['track_width']
    distance_from_center = params['distance_from_center']

    # トラック幅から3区画幅を計算
    marker_1 = 0.1 * track_width
    marker_2 = 0.25 * track_width
    marker_3 = 0.5 * track_width

    # 中央線との距離に応じた報酬を設定
    if distance_from_center <= marker_1:
        reward = 1.0
    elif distance_from_center <= marker_2:
        reward = 0.5
    elif distance_from_center <= marker_3:
        reward = 0.1
    else:
        reward = 1e-3  # クラッシュ/オフトラックに近い

    speed = params['speed'] / 5.0
    steeringStatus = params['steering_angle']
    steeringVal = 1.0 if steeringStatus==0.0 else 0.75

    reward *= (speed * steeringVal)
    return float(reward)

パラメータについて

内容の明記は避けますが、ステアリングの角度をワザと浅く設定しています。
速度は初めてでしたので変調設定を採用（ベタ踏みでも良かったな）

学習結果

4時間学習させた結果がこちらになります（棒○分クッキング

ジワ上がりですけど所々で急降下してるので評価式を見直すべきでしょうが。。。
(どうしたものかワカラナイ　エロい人教えてー）

走行結果

完走することは出来ましたが、如何せん速度が乗り切れていないようで遅いです。

まとめ

DeepRacer 楽しい　(これ大切）
他の方も書かれていると思いますが、パラメータ等の資料は公式ドキュメントを参照するのが良いです。

参考

Train and Evaluate AWS DeepRacer Models Using the AWS DeepRacer Console - AWS DeepRacer
https://docs.aws.amazon.com/deepracer/latest/developerguide/deepracer-console-train-evaluate-models.html

AWS DeepRacerを強化する 報酬関数実装パターンあれこれ ｜ DevelopersIO
https://dev.classmethod.jp/machine-learning/aws-deepracer-pattern-of-reward-function/

AWS DeepRacerで報酬関数の実装をあれこれ試してみた
https://qiita.com/kai_kou/items/8a45c687baca8c9465f6

やりたいこと

• テスト用にEC２を用意して、Basic認証をかけて開発中アプリケーションを公開しておきたい
• Basic認証はhtaccessで管理

困ったこと

• htaccessの設定で、ALBからのヘルスチェックにもbasic認証をかけてしまったために、ヘルスチェックが通らない
• その影響で、CodeDeployのAllowTrafficフェーズで失敗する

解決策

• ヘルスチェックのアクセスはBasic認証しないようにする

<Files ~ "^\.(htaccess|htpasswd)$">
  Deny from all
</Files>

Satisfy Any
AuthType Basic
AuthUserFile /path/to/.htpasswd
AuthName "Please ENter your ID and password"
Require valid-user
setEnvIf User-Agent "^ELB-HealthChecker.*$" noAuth
order Deny,Allow
Deny from all
Allow from env=noAuth

あんまり使うことないかもしれないですが、ちょっとハマってしまったので、記録しておきます。

CloudFront+S3の環境構築にデプロイ

nuxtアプリのmode: 'universal'モードにて
アプリケーションから静的ファイルを生成する。

npm run generate

静的なホスティングサイトにデプロイする準備が整ったものが全て入った dist フォルダが作成されます。

デプロイはAWS S3に先程生成されたファイルを配置することでデプロイできます。

「/」以外のURLでリロードした場合に403(access denied)エラーとなる

This XML file does not appear to have any style information associated with it.!~~~~
AccessDenied
AccessDenied

対応策

エラーの原因として対応するファイルがないため、ブラウザリロードすると 403 エラーになってしまうようです。

CloudFrontのError Pagesで設定

403のときに/index.html（今回は「/」）へ転送するよう設定することでこの現象を回避することができます。

Custom Error Response で追加設定

HTTP Error Code:　403:Forbidden
Error Caching Minimum TTL (seconds):　0
Customize Error Response:　Yes
Response Page Path:/
HTTP Response Code:　200:OK

以上の設定でリロードしてもエラーとならずページが表示されます。

こちらのサイトの記事を参考に解決することができました。
https://dev.classmethod.jp/cloud/aws/s3-cloudfront-spa-angular-403-access-denied/
ありがとうございます！！