今回はServerless技術の中心役となっているLambdaについて、いくつかの実装事例を紹介したいと思います。AWSの他のサービスと連携してシステムのServerless化することも最近増えてきてます。またAWS Lambdaと連携できるサービスもどんどん増えているので今度はAWSのManagedサービスを利用して簡単実装できるサービスと増えることが期待できます。AWS Lambda は自分たちが使いなれている言語で
Lambdaについて一言
我々が管理する必要なく必要なだけ利用して利用したンピューティング分の料金だけ支払えば利用できるコンピューティングサービスのことです。詳細はこちらの公式サイトのAWS Lambda とはで参考できます。
コードを書いてLambdaへDeployするだけで、ワークロードのサイズに合わせてスケールされます。AWS Lambda では、コードが実行される 100 ms ごとの請求になるため、従来のシステムよりも大幅にコスト削減できます。
AWS Lambda の概念
AWS Lambda でコードを実行するために関数というリソースが必要です。AWS LambdaはEventというJson形式のドキュメントを関数へ渡すことで実行されます。そのリソースが開発者が使いなれている言語で書くことができます。各言語とLambda関数の間Eventを渡すことはランタイムが行います。そのランタイムがAWSが現在Node.js, Python, Ruby, Java, Go, .NET のランタイムをDefaultで提供している。それ以外の言語でコードを書いた場合はカスタムランタイムを準備して関数のデプロイパッケージ、またはレイヤーに含めてDeployします。Lambdaを実行するEventはAWS のサービス、開発するアプリケーション、イベントソースマッピングなどからTriggerされる。このようないろいろなソースから発生するEventを同時に実行することができますが同時実行できる数についてはリージョンレベルの制限を設けれあります。
Lambdaの制限
AWSの他にサービスと同じくAWS Lambdaにもいくつかの制限あります。同時実行数,関数とレイヤーストレージはサポートセンターコンソールで申し込むすることで制限引き開けることが可能です。ですが関数のメモリ割り当て、一回の実行タイムアウト時間、各関数ごとの環境変数、リソースベースのポリシー、各関数で利用できるレイヤー数、同時実行数のバースト数、呼び出しペイロード 、呼び出しの頻度 、デプロイパッケージサイズ 、テストイベント数、/tmp ディレクトリのストレージ 、ファイルディスクリプタ、実行プロセス/スレッド数、 VPCごと利用できるENIについては引き上げできないのは現状です。
詳細および最新情報はAWS Lambda の制限で確認するには良いでしょう。
AWS Lamdbdaのベストプラクティス
- Memory量とタイムアウト時間の設定がただしくする。
- MethodごとにLambdaFunctionを分ける。
- 失敗した場合の処理を正しく考える。
- CloudWatchLogsを十分び活用する。
- セキュリティの設定に気をつける。
- 利用している外部モジュールをできるだけ複雑にしないようにする。
- Lambdaハンドラーをコアロジックと分離する。
- 環境ごとに変わる値を環境変数を利用する。
詳細は公式なLambda ベストプラクティスにて参考にしてください。
モニタリング
開発していく上でモニタリングが非常に重要です。Lambdaの場合も以下方法にてモニタリングができます。
- Amazon CloudWatchを利用する
- リクエスト数、リクエストごとの実行時間、エラーになったリクエスト数などのメトリックを確認できます。
- Amazon CloudTrailを利用する
- AWSインフラストラクチャ全体のアクションに関連するアカウントアクティビティを記録、継続的に監視、保持することができます。
- AWS X-Ray を利用する
- X-Rayのエンドツーエンドビューににて全てのLambdaを通過するリクエストのマップを確認できる、これによってアプリケーションの分析することができます。
- AWS Configを利用する
- IAM実行ロール、サブネット、およびLambda関数（削除された関数を含む）、ランタイム環境、タグ、ハンドラー名、コードサイズ、メモリ割り当て、タイムアウト設定、同時実行設定の構成変更を追跡できます
ユースケース
あらゆる分野のServeless化にAWS Lamdaが中心的な役割を持ちます。山ほど存在するユースケースの中で身近にある以下のような例が挙げられます。
- 画像変換処理
- Webアプリケーションのバックエンド
- リアルタイムのストリーム処理
- Chatbots
- データ解析処理の自動化
- 社内管理ツール
- メール配信処理
- スケーラブルなバックエンド（モバイルアプリ、loTデバイス）
Re:invent Updates
- Python 3.8をサポートしました
- Java 11をサポートしました
- Node.js 12をサポートしました
- イベントソースとして Amazon SQS FIFOをサポートされました。
- イベントを順番に処理するため、今までいろいろ自前でロジックを書く必要だったが
- 非同期呼び出しの最大イベント経過時間と最大再試行回数をサポートしました
- 今までLambdaがDefaultで関数が実行でエラーを返すとさらに２回実行しますがこちらを０〜２で設定できるようになりました。
- 最大イベント経過時間もDefaultに最大６時間だったのを60秒から６時間まで自由に設定できるようになりました。
- KinesisおよびDynamoDBイベントソースの障害処理機能をサポートしました
- Bisect on Function Errorが設定できるようになりました。これによって関数がエラーを返すと処理するデータレコードを２つに分ける処理されるようなり、繰り返すとエラーになるレコードだけが残るようになります。
- 最大レコード経過時間を60秒から7日間に設定可能になりました。設定時間に到達するとデータレコードの処理をスキップする。
- 最大際実行数を０〜10,000まで設定可能になりました。
- 失敗時の宛先を指定できるようになりました。失敗したらSNSで通知できる、SQSにて別のQueueに入れるなどできるようになりました。
- KinesisおよびDynamoDBイベントソースの並列化係数をサポートしました
- Parallelization Factorを介してシャードからポーリングする並行バッチの数を指定できるようになりました。こちらも1〜10まで自由に設定できます。
- Amazon CloudWatch メトリクスでパーセンタイルのサポートを追加
- 今までの 平均値、最小値、最大値に加えてこれによって、パーセンタイルに対してのアラームを発することができます。
参考
Lambda以外のUpdateもこちらから参考できます。
re:Invent 2019に向けて 2019年11月後半アップデートのまとめ 第一弾
re:Invent 2019に向けて 2019年11月後半アップデートのまとめ 第二弾
re:Invent 2019に向けて 2019年11月後半アップデートのまとめ 第三弾
re:Invent 2019に向けて 2019年11月後半アップデートのまとめ 第四弾