AWS Lambdaでタイムアウトを発生させてみる

AWS Lambdaで関数実行中にタイムアウトするとどうなるのか見たことが無かったのでためしにやってみました。

Lambdaで空の関数を作成し、ランタイムにPython3.6を選択したときに作成されるコードをsleepで10秒止めてみます。

import time

def lambda_handler(event, context):
    time.sleep(10)
    return 'Hello from Lambda'

テスト実行するだけなのでLambdaの設定はデフォルトのままにしました。 タイムアウトの時間はデフォルトで3秒なので、関数がsleepで止まっている間にLambdaが処理を終了させるはずです。

テストしてみたところ実行結果にタイムアウトのエラーメッセージが出力されました。

{
  "errorMessage": "2017-09-05T02:03:28.155Z xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Task timed out after 3.00 seconds"
}

ついでなので、CloudWatchのアラームでLambdaの実行エラー時にSNSが送信されるように設定*1しました。

アラーム作成後にLambda関数をテスト実行すると、アラームの状態がデータ不足からアラームに変わります。

同時に、アクションに設定していたSNSトピックの送信先メールアドレスにメッセージが送信されます。

Amazon Web Services実践入門 (WEB+DB PRESS plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

*1:本来はLambdaのリトライを考慮したうえでCloudWatchのアラートの閾値と間隔を設定すべき。

GitリポジトリにAWS CodeCommitを使用する

AWS CodeCommitを使用できるようになるまでの手順。

IAM(Identity and Access Management)の設定

グループの作成

• IAM(Identity and Access Management)のダッシュボードから[グループ]を選択する。

• [新しいグループの作成]を選択する。

• グループ名を入力し[次のステップ]を選択する。

• グループにアタッチするポリシーの一覧が表示されるのでCodeCommitポリシーのいずれかをアタッチし[次のステップ]を選択する。 CodeCommitポリシーについては以下の3つから選択する。今回はリポジトリに変更を加えるのでAWSCodeCommitPowerUserをアタッチした。

ポリシー	アクション
AWSCodeCommitFullAccess	CodeCommitのすべてのアクションを実行可能。
AWSCodeCommitPowerUser	リポジトリの削除以外のアクションを実行可能。
AWSCodeCommitReadOnly	リポジトリのプルのみ可能で内容を変更できない。

• 確認で表示される内容で問題がなければ[グループの作成]を選択する。

ユーザーの作成

• IAM(Identity and Access Management)のダッシュボードから[ユーザー]を選択する。

• ユーザー名を入力する。AWSアクセスの種類は[プログラムによるアクセス]を選択し[次のステップ:アクセス権限]を選択する。マネジメントコンソールへのアクセスが必要であれば[AWSマネージメントコンソールへのアクセス]も選択しておく。

• ユーザーのアクセス権限を設定する。作成しておいたグループを選択し[次のステップ:確認]を選択する。

• 確認で表示される内容で問題がなければ[ユーザーの作成]を選択する。

• 作成したユーザーのアクセスキーIDとシークレットアクセスキーはGitリポジトリへのアクセスの際必要になるので控えておく。念のため[.csvのダウンロード]でアクセスキーが記載されたCSVファイルもダウンロードしておく。

CodeCommitの設定

リポジトリの作成

• AWS CodeCommitのダッシュボードから[リポジトリの作成]を選択する。

• リポジトリ名と説明を入力したら[リポジトリの作成]を選択する。

• リポジトリが作成されると接続方法が表示される。

アクセス確認

• HTTPSでリポジトリに接続する。リポジトリ作成後に接続方法が表示されるので接続タイプに[HTTPS]、オペレーティングシステムに任意のOSを選択する。 リポジトリクローンを作成するステップに表示されるGitコマンドを実行後、リポジトリURLを指定してクローンを実行する。このとき、アクセスキーIDとシークレットアクセスキーの入力を要求される*1ので、ユーザー作成後に表示されていたアクセスキーを入力するとクローンが実行される。あとは通常のGitリポジトリと同様の手順で操作できる。

使ってみて

非公開リポジトリを使用したかったのでCodeCommitを利用してみたけど、 思うほど設定が面倒でなかったし、5人までで利用するぶんには無料枠内で運用できる*2ので、AWSユーザーでプライベートリポジトリを運用したい人には便利で良いサービスだと思う。

AWS CodeCommit

aws.amazon.com

docs.aws.amazon.com

Amazon Web Services実践入門 (WEB+DB PRESS plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

*1:Windows 10の場合。Linux、Macでは未確認。

*2:有料でも十分安いと思うけど、あくまでリポジトリサービスであるということについては、GitHubなどからの移行を考える際には少し注意すべきかもしれない。

AWS Summit Tokyo 2017に行った

www.awssummit.tokyo

今更なんだけど昨年に続きAWS Summitに行った。 今年は事前予約をしていたものの、 色々あって1週間前まで行けるか微妙な中だったので無事参加できて良かった。

現地で色々書いていたけど、既に講演動画と資料が公開されているので感想だけ残しておく。

aws.amazon.com

雑感

セッションを聞いて感じたのは、AWSが推していることもあるんだろうけどキーワードはサーバーレス。 どれも構成のコアになる部分にLambdaが出てくるのが印象的だった。 同時に、全体的にオンプレをとりあえずEC2主体に移行して運用するというフェーズから AWSへの最適化フェーズに移りつつあるのかなとも思った。

AWSにデプロイするのに案外CodeCommitは使われてないような気がした。 バージョン管理はGitHub一強な印象。まあ何となくわかる。

何となく考えていたこと

あるセッションを聞いてから、クラウドベンダーにロックインしないシステム設計の必要性があるのかという事について考えていた。 そんな事を考えたらマネージ型サービスなんて使えないという結論に至ると思うし、 インフラがごっそり変わるなら作り変えになるんだろうけど。 なら使えるものはとにかく使ってパフォーマンス上げる方がメリットが大きいはずという事を考えると、 そういう考えのもとに設計する必要性はない気はするけど微妙にモヤっとしている。

うれしかったこと

一度は生で聞いてみたかった、テスト駆動開発で有名な和田さんのセッションを見ることができたのと、 よくブログを参考にさせて頂いているElasticの大谷さん(たぶんご本人だと思う)とお話できたのはうれしかった。

来年に向けて

AWS認定資格取得者専用ラウンジに入るべくソリューションアーキテクト認定に向けて勉強の密度を上げる。上げたい。

Amazon Web Services実践入門 (WEB+DB PRESS plus)

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)