はじめてのAws lambda

はじめての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公式より抜粋

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

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

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

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

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

AWS Lambda の概要まとめ
・処理内容の function（関数）コードとイベントトリガーを定義しておくと、
イベントトリガーの発火条件が満たされると用意した処理内容を自動で実行
・イベントトリガーは、AWSサービス内の何かの変更や、cron形式の一定時間間隔実行など
・ユーザ側で用意するのは、イベントトリガーの指定と実行されるfunctionコードだけ
（自前でサーバなどインフラを用意する必要なし）
・通常用途であれば、実質ほぼ無料で利用可能

Chapter2 ：AWS Lambda の使い方
概要が分かったところで、
実際に作成して動かしてみましょう！

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

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

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

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

今回はS3への変更をイベントトリガーにしたblueprintを選択した為、以下の4項目を設定します。
・Bucket
→ 対象となるバケットを指定します。指定したバケットへの変更だけがイベントトリガー
として認識されるようになります。
（その他のバケットへの変更を、イベントトリガーの対象外とします）
今回の例では、「test-masakimisawa-dcube」というバケットを対象にしています。
・Event Type
→ S3に対してどのような操作を行った場合にイベントを発火させるか指定します。
ファイルが作られた時、ファイルが削除された時、など指定することができます。
今回の例では、ファイルが作られた時（コピーも含む）をイベントトリガーに設定しています。

・Prefix
→ 指定したファイルパスから始まるファイルへの変更だけが
イベントトリガーとして認識されるようになります。
* ファイル名ではなく、バケット直下のディレクトリパスであることに注意してください
今回の例では、「test-dir/」を設定しているので、
test-masakimisawa-dcube / test-dir / 配下のファイルだけが対象となります。
・Suffix
→ 指定したファイル名で終わるファイルへの変更だけが
イベントトリガーとして認識されるようになります。
ファイル名に規則性を持たせている場合の、特定のパターンだけを指定する場合や、
拡張子名を指定して特定の拡張子ファイルだけを対象とする場合が多いです。
今回の例では、「.txt」を設定しているので、
.txt の拡張子ファイルだけが対象となります。

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

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

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

・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 を選択しています。

6. 処理内容の function(関数) コードの、実行内容部分を設定

・Code entry type
→ 実行内容のコードを、以下の3項目のうちどの形式で保存するかを設定します。
- AWSコンソール上でコードを書いてそのまま保存
- 自前で用意したファイルをzip圧縮してアップロード
- S3に保存済みのファイルをアップロード
1ファイルで完結しライブラリのインポートが不要な単純な処理の場合は、AWSコンソール
上でコードを書いてそのまま保存する形が楽ですが、クラスを何個も作るような規模の
処理を書く場合や、言語がデフォルトで対応しているライブラリ以外をインポートして使う
必要があるような場合は、自前で処理を作成後にzip圧縮してアップロードする形式を選択
する必要が有ります。
今回の例では、 AWSコンソール上でコードを保存する形式を選択しています。

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

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

・Enable encription helpers
→ function 内で使用する環境変数に対して、KMS（Key Management Service）を
使用するかの設定です。
チェックを付けると、環境変数を暗号化してセキュアに扱うことができます。
* 使用する為には、別途KMS のキーを作成する必要があります。
今回の例では、使用していません。
・Environment variables
→ function 内で使用する環境変数の key と value の設定です。
定数でセットするような値を、ここでまとめて管理することができます。
実装が待たれていた機能で、昨年冬にようやく使えるようになりました！

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

・Role
→ function の実行権限を、既存のrole設定を使用するか、新しく作成するかの設定です。
新しくrole設定を作成する場合は、各AWSサービスへのアクセスを行う為のデフォルト
テンプレートが用意されているのでそれを使うか、カスタムrole設定を使うかを選択できます。
今回の例では、既に作成済だった為既存のrole設定を使っています。
・Existing role
→ 既存のrole設定を使用する場合の設定項目で、どの設定を使用するかの選択項目です。
それぞれのrole設定に、個別に各AWSサービスへのアクセスポリシーが設定されています。
今回の例では、S3へのアクセスが必要な為「lambda_s3_exec_role」を選択しています。

8. 処理内容の function(関数) コードの、詳細項目を設定

・Memory（MB）
→ 処理実行時に使用するメモリ量の設定です。
処理性能は基本的にメモリ設定に依存する為、値を増やすと比例して処理性能も上がります。
* 料金も使用メモリに比例して上がる為、処理性能に問題を感じた場合に設定値を上げるくらいが丁度良いです。
今回の例では、最小設定の128MBにしています。
・Timeout
→ function の実行時間を最大で秒数までにするかの設定です。
実行時間がここの設定時間を超過すると、タイムアウトエラーになり処理が終了します。
デフォルトの設定値が3秒になっているので、設定値を増やした方が安全かもしれません。
最大で300秒（5分）まで設定可能です。
* 料金も実行時間に比例して上がりますが、設定値ではなく実行時間に料金は比例するようです。
今回の例では、デフォルトの3秒にしています。

・DLQ Resource
→ Dead Letter Queueの設定です。
処理実行中にエラー発生した場合など、指定したSQS or SNSに通知を送ることができます。
これまで Lambda のエラーハンドリングは、Cloud watchで個別にアラーム設定しなければ
ならず、運用コストが高い状態だった為、昨年冬の同機能実装以降大幅に改善されました。
ただ、1エラー発生につき通知も毎回飛ぶ為、小さなfunctionを何千、何万回も発火させる場合
には、これまで通りCloud watchでアラーム設定した方がよいなど、使い分けが必要です。
・VPC
→ Lambda function を起動するVPC 、およびセキュリティグループの設定です。
デフォルトでは実行サーバのIPは可変とされている為、コード内でのアクセス先リソース側で
アクセス元の制限をかけている場合にアクセスする事ができませんが、起動元側でVPCと
セキュリティグループを指定しておけば、アクセス先リソース側のアクセス元設定で起動する
VPCのセキュリティグループを許可することでアクセスが可能になります。
主に、アクセス元を絞ったデータベースへ接続する時などに設定する項目です。

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

9. 作成した内容を確認して、Lambda function を新規作成

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

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

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

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

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

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

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

Bad1. 実行時ログの確認の運用コストが非常に高い
これは Lambda function のイマイチな所というよりも CloudWatch のイマイチな所でも
あるのですが、処理結果が期待内容と異なった場合に実行時のログを確認しようとした場合に
対象の実行時ログをCloudWatchから探すのが非常に大変で運用コストがかかります。
ex. - 実行時ログが時系列順に並んでいない
- 複数回の実行ログが一つのログファイルにまとめられていたり、いなかったりでバラバラ

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を！

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

はじめてのAws lambda

More Related Content

What's hot (20)

Similar to はじめてのAws lambda (20)

More from dcubeio (20)

はじめてのAws lambda