はじめての AWS Lambda

2017/02/02 D-Cube 勉強会株式会社ビズリーチ エンジニア 三澤正木

【登壇者プロフィール】 ミサワ マサキ名前 : 三澤 正木職業 : エンジニア（現在の業務は、主に WEB アプリ開発担当）所属 : 株式会社ビズリーチ キャリアトレック事業部 http://careertrek.com

社歴 : 入社して 4 年弱。弊社ではベテランの扱いになるらしい…GitHub: https://github.com/MasakiMisawa

Slideshare: http://www.slideshare.net/MisawaMasaki

趣味 : 野球（観る専）、ランニング、旅行 etc

以下の URL から閲覧、 DL 可能です。* イベント終了後もしばらく公開しておきますが、削除する可能性もあるので必要な方は DL しておいてください。

【今回のスライド】

http://www.slideshare.net/MisawaMasaki

アジェンダ

・ Chapter1 AWS Lambda とはなにか？　→ AWS Lambda の簡単な概要説明です・ Chapter2 AWS Lambda の使い方　→ 作成から発火させるまでの一連の流れの説明です　　　（ AWS Lambda の作成を数パターン実演を交えて説明します）・ Chapter3 AWS Lambda のよい所、イマイチな所　→ 自分なりに考える、 AWS Lambda のよい部分と、イマイチだと思う部分の説明です・ Chapter4 AWS Lambda を使った簡単な実例紹介　→ 実際に使ってみた簡単な実例の紹介です・ etc 質疑応答　→ さいごに質疑応答の時間を 15 分程度設ける予定でいます

Chapter1： AWS Lambda とはなにか？

AWS Lambda はサーバーをプロビジョニングしたり管理しなくてもコードを実行できるコンピューティングサービスです。AWS Lambda は必要に応じてコードを実行し、 1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケーリングします。使用したコンピューティング時間に対してのみお支払いいただきます。（コードが実行中でなければ料金はかかりません。）AWS Lambda によって、実質どのようなタイプのアプリケーションやバックエンドサービスでも、管理なしでコードを実行できます。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 amazon 公式より抜粋

Chapter1： AWS Lambda とはなにか？

ざっくり言うと…処理内容の function( 関数 ) とイベントトリガーを定義しておくと、自動で実行してくれるサービス

Chapter1： AWS Lambda とはなにか？任意のイベントトリガーを発火起点に、あらかじめ用意しておいた function （関数）が自動実行される（イベントトリガーの指定と実行されるコードを用意するだけなので、サーバの用意などが不要）

Chapter1： AWS Lambda とはなにか？同じことを AWS Lambda 以外で実現しようとすると、サーバなどインフラ環境を用意し、AWS サービスを定期的に polling する自作処理をイベントトリガーの数だけ作成する必要があります。

Chapter1： AWS Lambda とはなにか？【料金体系】

・使用した分だけの料金が発生・料金は、 function へのリクエスト件数と実行時間により変動

・ 1 か月に 1,000,000 件のリクエスト、および 400,000 GB- 秒の　コンピューティング時間までを無料利用枠として使用可能*1 無料枠の秒数は、 function に割り当てるメモリ量により増減*2 無料枠超過後は、 1 リクエストにつき 0.0000002 USD が料金発生*3 function 内で行う各種 AWS サービスへのアクセスなど、通信費用は別途発生

Chapter1： AWS Lambda とはなにか？

月 10000 アクセスまで無料 = 毎時間 13.44 アクセスまでなら無料できるので…通常用途であれば、実質ほぼ無料で使用可能！

Chapter1： AWS Lambda とはなにか？AWS Lambda の概要まとめ

・処理内容の function （関数）コードとイベントトリガーを定義しておくと、　イベントトリガーの発火条件が満たされると用意した処理内容を自動で実行

・イベントトリガーは、 AWS サービス内の何かの変更や、 cron形式の一定時間間隔実行など

・ユーザ側で用意するのは、イベントトリガーの指定と実行される function コードだけ（自前でサーバなどインフラを用意する必要なし）

・通常用途であれば、実質ほぼ無料で利用可能

Chapter2： AWS Lambda の使い方

概要が分かったところで、実際に作成して動かしてみましょう！

Chapter2： AWS Lambda の使い方

1. AWS コンソール TOP から Lambda を選択2. Get Staetd Now を選択（既に作成済の Lambda が存在する場合は、 Create a lambda function を選択）

1 2

Chapter2： AWS Lambda の使い方3. Select blueprint から任意のイベントトリガータイプを選択

* Blueprint は、 Lambda を使って何をしたいのかの青写真で、AWS側で予め用意してある該当処理を行う上でのテンプレートです。

ex. S3 にファイルが作られたことをイベントトリガーにした Lambda function を 作ろうとした場合、 Blueprint に「 s3-get-object」を選択することで、指定した S3 バケット & パスにファイルが作られると Lambda function が自動で発火し、 該当ファイルのオブジェクトを取得した状態の function コードがデフォルトで 作成された状態で新規に作成することができます。 （上記 Blueprint を選択しないでも同じ動作を行う処理を作成する事はできますが、イベントトリガーの設定、 および作られたファイルのオブジェクトを取得する処理を自前で実装する必要が有ります）

Chapter2： AWS Lambda の使い方今回は、 S3 へのファイル変更をトリガーにした Lambda function を作ってみましょう。選択する blueprint に、「 s3-get-object-python」を選択します。（今回は実行されるコードの言語を python で行う為、上記 blueprint を選択しましたが、 python 以外でも問題ありません）

Chapter2： AWS Lambda の使い方4. イベントトリガーの条件を設定　（選択した blueprint により、ここの設定内容は変わります。）

Chapter2： AWS Lambda の使い方今回は S3 への変更をイベントトリガーにした blueprint を選択した為、以下の 4項目を設定します。

・ Bucket　→ 対象となるバケットを指定します。指定したバケットへの変更だけがイベントトリガー　　 として認識されるようになります。　　 （その他のバケットへの変更を、イベントトリガーの対象外とします）　　 今回の例では、「 test-masakimisawa-dcube」というバケットを対象にしています。

・ Event Type　→ S3 に対してどのような操作を行った場合にイベントを発火させるか指定します。　　 ファイルが作られた時、ファイルが削除された時、など指定することができます。　　 　　 今回の例では、ファイルが作られた時（コピーも含む）をイベントトリガーに設定しています。

Chapter2： AWS Lambda の使い方・ Prefix　→ 指定したファイルパスから始まるファイルへの変更だけが　　 イベントトリガーとして認識されるようになります。　　 * ファイル名ではなく、バケット直下のディレクトリパスであることに注意してください　　 今回の例では、「 test-dir/」を設定しているので、　　 test-masakimisawa-dcube / test-dir / 配下のファイルだけが対象となります。

・ Suffix　→ 指定したファイル名で終わるファイルへの変更だけが　　 イベントトリガーとして認識されるようになります。　　 ファイル名に規則性を持たせている場合の、特定のパターンだけを指定する場合や、　　 拡張子名を指定して特定の拡張子ファイルだけを対象とする場合が多いです。　　 今回の例では、「 .txt」を設定しているので、　　 .txt の拡張子ファイルだけが対象となります。

Chapter2： AWS Lambda の使い方また、イベントトリガーの blueprint に何を選択したかに関わらず、以下の項目を設定します。

・ Enable trigger　→ 対象の Lambda function が作成完了したタイミングでイベントを有効化するか、　　 下書き状態で一旦作成だけを行うかのチェック項目です。　　 チェックを付けると、 Lambda function が作成完了した直後からイベントが有効化され、　　 外すと、下書き状態で一旦作成だけを行います。　　 今回の例ではチェックを外しているので、下書き状態で一旦作成だけを行っています。

Chapter2： AWS Lambda の使い方5. 処理内容の function( 関数 ) コードの、基本項目を設定　（ * が付いた項目は必須入力、付いていない項目は任意入力項目です）

Chapter2： AWS Lambda の使い方・ Name　→ function 名です。　　 他に作成した function 名と同じ名前は設定できず、ユニークである必要があります。　　 今回の例では、「 test-dcube-function-name」としています。

・ Description　→ function の説明文です。　　 作成した function の一覧画面上で表示されるので、　　 何をしている処理なのかが一目で分かるような説明文を付けると管理がしやすくなります。　　 * 日本語も入力できるように見えますが、日本語で登録すると文字化けして保存されてしまうようです…　　 今回の例では、「 test-dcube-function-description」としています。

Chapter2： AWS Lambda の使い方・ Runtime　→ 実行するプログラム言語の設定です。　　 2017/02 現在では、以下の 5 つが指定可能です。　　 （ Lambda の登場以降、指定可能言語が何度か増えているので、今後も増えていきそうです）　　 - C#

　　 - Java8

　　 - Node.js 4.3

　　 - Edge Node.js 4.3

　　 - Python 2.7

　　 今回の例では、 blueprint に「 s3-get-object-python」を選択したこともあり、　　 Python 2.7 を選択しています。

Chapter2： AWS Lambda の使い方6. 処理内容の function( 関数 ) コードの、実行内容部分を設定

Chapter2： AWS Lambda の使い方・ Code entry type　→ 実行内容のコードを、以下の 3項目のうちどの形式で保存するかを設定します。　　 - AWS コンソール上でコードを書いてそのまま保存　　 - 自前で用意したファイルを zip圧縮してアップロード　　 - S3 に保存済みのファイルをアップロード

　　 1 ファイルで完結しライブラリのインポートが不要な単純な処理の場合は、 AWS コンソール　　 上でコードを書いてそのまま保存する形が楽ですが、クラスを何個も作るような規模の　　 処理を書く場合や、言語がデフォルトで対応しているライブラリ以外をインポートして使う　　 必要があるような場合は、自前で処理を作成後に zip圧縮してアップロードする形式を選択　　 する必要が有ります。　　 今回の例では、 AWS コンソール上でコードを保存する形式を選択しています。

Chapter2： AWS Lambda の使い方・コードエディタ部分　→ 実行する処理内容をここに記述します。　　　　 今回の例では、デフォルトで作成されるテンプレートをそのまま使用しています。

Chapter2： AWS Lambda の使い方7. 処理内容の function( 関数 ) コードの、使用する環境変数と実行ロールを設定

Chapter2： AWS Lambda の使い方・ Enable encription helpers　→ function 内で使用する環境変数に対して、 KMS （ Key Management Service ）を　　 使用するかの設定です。　　 チェックを付けると、環境変数を暗号化してセキュアに扱うことができます。　　 * 使用する為には、別途 KMS のキーを作成する必要があります。　　 今回の例では、使用していません。

・ Environment variables　→ function 内で使用する環境変数の key と value の設定です。　　 定数でセットするような値を、ここでまとめて管理することができます。　　 実装が待たれていた機能で、昨年冬にようやく使えるようになりました！　　 今回の例では、使用していません。

Chapter2： AWS Lambda の使い方・ Handler　→ 処理が開始時の一番初めに呼ばれる function 名の設定です。　　 「 { ファイル名 }.{function 名 }」の形式で指定します。　　 ex. 「 hoge_file.hoge_function」と設定すると、 hoge_file に書かれた　　 hoge_function 関数が処理開始時の一番初めに実行される処理になります。　　 今回の例では、デフォルト設定の「 lambda_function.lambda_handler」にしています。　　 * AWS のコンソール画面上にコードを書いて実行する場合は、ファイル名が lambda_function になるようです。

Chapter2： AWS Lambda の使い方・ Role　→ function の実行権限を、既存の role 設定を使用するか、新しく作成するかの設定です。　　 新しく role 設定を作成する場合は、各 AWS サービスへのアクセスを行う為のデフォルト　　 テンプレートが用意されているのでそれを使うか、カスタム role 設定を使うかを選択できます。　　 今回の例では、既に作成済だった為既存の role 設定を使っています。

・ Existing role　→ 既存の role 設定を使用する場合の設定項目で、どの設定を使用するかの選択項目です。　　 それぞれの role 設定に、個別に各 AWS サービスへのアクセスポリシーが設定されています。　　 今回の例では、 S3 へのアクセスが必要な為「 lambda_s3_exec_role」を選択しています。

Chapter2： AWS Lambda の使い方8. 処理内容の function( 関数 ) コードの、詳細項目を設定

Chapter2： AWS Lambda の使い方・ Memory （ MB ）　→ 処理実行時に使用するメモリ量の設定です。　　 処理性能は基本的にメモリ設定に依存する為、値を増やすと比例して処理性能も上がります。　　 * 料金も使用メモリに比例して上がる為、処理性能に問題を感じた場合に設定値を上げるくらいが丁度良いです。　　 今回の例では、最小設定の 128MB にしています。

・ Timeout　→ function の実行時間を最大で秒数までにするかの設定です。　　 実行時間がここの設定時間を超過すると、タイムアウトエラーになり処理が終了します。　　 デフォルトの設定値が 3 秒になっているので、設定値を増やした方が安全かもしれません。　　 最大で 300 秒（ 5 分）まで設定可能です。　　 * 料金も実行時間に比例して上がりますが、設定値ではなく実行時間に料金は比例するようです。　　 今回の例では、デフォルトの 3 秒にしています。

Chapter2： AWS Lambda の使い方・ DLQ Resource　→ Dead Letter Queue の設定です。　　 処理実行中にエラー発生した場合など、指定した SQS or SNS に通知を送ることができます。　　 これまで Lambda のエラーハンドリングは、 Cloud watch で個別にアラーム設定しなければ　　 ならず、運用コストが高い状態だった為、昨年冬の同機能実装以降大幅に改善されました。　　 　　 ただ、 1 エラー発生につき通知も毎回飛ぶ為、小さな function を何千、何万回も発火させる場合　　 には、これまで通り Cloud watch でアラーム設定した方がよいなど、使い分けが必要です。　　 今回の例では、使用していません。

・ VPC　→ Lambda function を起動する VPC 、およびセキュリティグループの設定です。　　 デフォルトでは実行サーバの IP は可変とされている為、コード内でのアクセス先リソース側で　　 アクセス元の制限をかけている場合にアクセスする事ができませんが、起動元側で VPC と　　 セキュリティグループを指定しておけば、アクセス先リソース側のアクセス元設定で起動する　　 VPC のセキュリティグループを許可することでアクセスが可能になります。　　 主に、アクセス元を絞ったデータベースへ接続する時などに設定する項目です。　　 今回の例では、使用していません。

Chapter2： AWS Lambda の使い方・ KMS key　　 KMS （ Key Management Service ）の使用設定です。　　 アカウントのクレデンシャルなどセンシティブな情報を暗号化して扱うことができます。　　 * 使用する為には、別途 KMS のキーを作成する必要があります。　　 今回の例では、デフォルトの aws/lambda をそのまま使用しています。

Chapter2： AWS Lambda の使い方9. 作成した内容を確認して、 Lambda function を新規作成

Chapter2： AWS Lambda の使い方10. 作成した Lambda function を有効化 ステータスが Enabled でないとイベントが発火しない（下書き状態）ので、有効化させます。

↓

Chapter2： AWS Lambda の使い方

作成が完了したところで、実際に S3 の指定パスにファイルをアップロードしてみましょう！

Chapter2： AWS Lambda の使い方11. 実行ログを見て、正常に動作していることを確認 - AWS コンソール TOP から CloudWatch を選択 - ログ を選択

→

Chapter2： AWS Lambda の使い方 - 対象の Lambda function のセルを選択 - イベント時刻が対象のイベント発火時刻直前になっているログのセルを選択

↓

Chapter2： AWS Lambda の使い方 - 発火イベントのログ詳細を確認し、エラーなどがなく正常動作していることを確認して完了

Chapter3： AWS Lambda のよい所、イマイチな所Good1. サーバなど、インフラの用意が不要スライド冒頭でも触れましたが、処理を実行するサーバなど、インフラの用意が不要な点は大きなメリットです。同じことを Lambda function を使わずに実現しようとした場合のコストは馬鹿になりません。

Chapter3： AWS Lambda のよい所、イマイチな所Good2. 処理実行数のスケールがし易いイベントトリガーの定義と処理内容の function （関数）コードを用意しておくだけでよい為、同じ処理を繰り返し行いたい場合の処理数を増やしていくスケールがし易いのもメリットです。（一つ Lambda function を作っておけば、あとは発火条件を複数回満たせば処理が並列で走る）1回の処理は一瞬で終わるものの、同じ処理を複数回繰り返し行うバッチ処理などにも向いています

Chapter3： AWS Lambda のよい所、イマイチな所Bad1. 実行時ログの確認の運用コストが非常に高いこれは Lambda function のイマイチな所というよりも CloudWatch のイマイチな所でもあるのですが、処理結果が期待内容と異なった場合に実行時のログを確認しようとした場合に対象の実行時ログを CloudWatch から探すのが非常に大変で運用コストがかかります。

ex. - 実行時ログが時系列順に並んでいない - 複数回の実行ログが一つのログファイルにまとめられていたり、いなかったりでバラバラ

Chapter3： AWS Lambda のよい所、イマイチな所Bad2. function 内から別の function を明示的に呼べないLambda function は、一つの処理の実行可能最大時間が 5 分までであることなどから、小さな処理を複数回実行させながら処理を繋いでいく用途が非常に多い。が、現状では Lambda function を明示的に指定して実行する方法が存在しない為、function 内から引数を渡して別の function を呼び出すといった繋ぎ方ができない。* function 内で別の function のイベントトリガーを発火させる繋ぎ方はできるが、引数を渡して実行させるような繋ぎ方が困難

Chapter4： AWS Lambda を使った簡単な実例紹介Dynamo のレコード変更を Redshift にリアルタイム反映させる

詳細 URL: http://tech.dcube.io/2016/05/dynamo_to_redshift.html

結論：AWS Lambda は、 function を実行しているだけなので発想次第でなんでもできる！みなさんもよい Lambda life を！

ご静聴ありがとうございました。