コンテナ利用者に捧げる AWS Lambda の新しい開発方式 ! 第 2 回
Author : 下川 賢介
第二回 コンテナ Lambda を開発、まずは RIC と RIE を使ってみよう !
こんにちは、サーバーレス スペシャリストソリューションアーキテクトの下川 (@_kensh) です。
今回はこのコンテナイメージサポート Lambda 関数のローカル動作確認方法について触れていきたいと思います。
「第一回 コンテナ Lambda の ”いろは”、AWS CLI でのデプロイに挑戦 !」では、AWS CLIを使ってコンテナ Lambda 関数を実際に AWS Lambda サービスにデプロイして動作確認をしてみました。AWS Lambda サービスにデプロイして動作確認する方法は実際の本番動作環境により近い環境で動作を確認できるという点でお勧めの方法でもあるのですが、一方でテストや検証のために毎回デプロイをするのが時間的に大変だったり、AWS アカウントが払い出されていない場合やインターネット環境が無い場合に手軽に動作を確認したいという要求もあることと思います。
そこで今回はローカルでコンテナLambda関数の動作確認をする方法を紹介します。そしてその前に AWS Lambda サービスについても少し説明を加えておきます。
この連載記事のその他の記事はこちら
- 選択
- 第 1 回 コンテナ Lambda の”いろは”、AWS CLI でのデプロイに挑戦 !
- 第 2 回 コンテナ Lambda を開発、まずは RIC と RIE を使ってみよう !
- 第 3 回 コンテナ Lambda をカスタマイズして、自分好みの PHP イメージを作ろう !
- 第 4 回 コンテナ Lambda を AWS SAM でデプロイしよう !
- 第 5 回 コンテナ Lambda の CI/CD パイプラインの考え方
- 第 6 回 コンテナ Lambda の CI/CD パイプラインを SAM Pipeline で作ろう !
- 第 7 回 コンテナLambdaでサイドカーパターンは実現可能なの ?
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
このクラウドレシピ (ハンズオン記事) を無料でお試しいただけます »
毎月提供されるクラウドレシピのアップデート情報とともに、クレジットコードを受け取ることができます。
AWS Lambda サービスとの対話
AWS Lambda のデプロイ形式としてコンテナがサポートされた当初よく受けた質問が、「AWS Fargate などで使っているコンテナイメージをそのまま Lambda でも使えるのか ?」というものですが、実は Fargate でご利用のイメージをそのまま持ってきて Lambda で動かそうとしても期待通りには動きません。
その理由として AWS Lambda において、Lambda 関数を実行するには Lambda サービスとサービスにデプロイしたランタイムの間で、実行や応答、そしてエラーについて対話が必要になるからです。この対話の形式は AWS Lambda サービス側の仕様として AWS Lambda ランタイム API という形で公開されています。
ZIP 形式の Lambda では開発者が意識してデプロイする ZIP ファイルの中にランタイム API と対話する仕組みを入れる必要はなく、自動的にランタイム API と対話するようになっていました。[1]
コンテナ形式の Lambda では、コンテナイメージの中に明示的にランタイム API と対話する実装を入れておく必要があります。
[1] カスタムランタイムを公開する 場合は、この Lambda サービスとの対話を実装する必要があります。
ランタイム API との対話
上図にあるように、開発者が実装するランタイムは Lambda サービスに対して対話を行います。next API を呼び出すことで次のイベントを取得します。このレスポンス本文には、呼び出しのペイロードが含まれます。 response API は Lambda 関数の実行レスポンスを Lambda サービス に送信します。
このようにして、対話することで Lambda サービスが持つ運用性、可用性、耐久性やセキュリティ、そしてスケーラビリティの仕組みを Lambda 関数の実装者は独自に実装することなく利用できるわけですね。そして、この対話の実装をコンテナ Lambda ではコンテナイメージの中に入れ込んでおく必要があります。
ここで、あれ ? っと思った読者の方もいらっしゃるかもしれませんね。前回の「第一回 コンテナ Lambda の ”いろは”、AWS CLI でのデプロイに挑戦 !」では、特にこの対話の仕組みについて何の解説もなく、何も意識することなくコンテナ Lambda 関数を Lambda サービスにデプロイして実行まですることができていました。実は、AWS が提供する AWS Lambda のベースイメージであれば、あらかじめこの AWS Lambda サービスとの対話に関する実装が組み込まれているのです。ですので、AWS が提供する AWS Lambda のベースイメージをご利用になる限りは独自に Lambda サービスとの対話を実装する必要はありません。
以下の表のようにカスタムランタイム用のベースイメージも用意されています。例えば PHP のカスタムランタイムイメージを作成したい場合にご利用になれます。注意としては、カスタムランタイム用のベースイメージには、Lambda サービスとの対話実装が含まれていないため、独自に実装するか AWS 提供の RIC (後述) を導入する必要があります。一方で RIE (後述) はカスタムランタイム用のベースイメージに含まれています。
| Tags | Runtime | Operating system |
|---|---|---|
| al2 | provided.al2 | Amazon Linux 2 |
| alami | provided | Amazon Linux |
カスタムランタイム用のベースイメージ
AWS ではサポートされている各種ランタイム言語ごとに、Runtime Interface Client (RIC)という名称でオープンソースとして公開しています。
| 言語 | リポジトリ管理 | リポジトリ |
|---|---|---|
| Node.js | github | aws-lambda-nodejs-runtime-interface-client |
| Ruby | github | aws-lambda-ruby-runtime-interface-client |
| Python | github | aws-lambda-python-runtime-interface-client |
| .NET | github | aws-lambda-dotnet |
| Java | Maven | com.amazonaws:aws-lambda-java-runtime-interface-client |
| Go | N/A | GoについてはRICとしての個別公開はありません |
Runtime Interface Client (RIC)
実際のカスタムランタイムイメージや RIC の導入方法については AWS Blog 「AWS Lambda の新機能 – コンテナイメージのサポート」で紹介されていますので参照ください。
ローカル環境で AWS Lambda の動きをエミュレートしてみよう
さて、ここから今回の本題であるローカルでコンテナ Lambda 関数の動作確認をする方法をご紹介します。
Lambda Runtime Interface Emulator (RIE) は、実際の AWS Lambda サービスで提供されているランタイム API をローカル環境でエミュレートする代替機能 (プロキシ) として動作します。これによりコンテナイメージとしてパッケージ化された Lambda 関数をローカルでテストすることが可能になります。
この Lambda のランタイム API のプロキシは、HTTP リクエストを JSON イベントに変換し、実際の AWS Lambda サービスの Lambda ランタイム API との機能的な同等性を確保するための軽量のウェブサーバーとして動作します。これにより、curl や Docker CLI などの使い慣れたツールを使用して関数をローカルでテストできます (コンテナイメージとしてパッケージ化された関数をテストする場合のみ)。
コンテナイメージにRIEを含めることで、Lambda へのデプロイに必要な JSON イベントの代わりに HTTP リクエストを受け入れるようにすることができます。
※ この RIE は、Lambda のオーケストレーターやセキュリティおよび認証の機能はエミュレートしません。
実は、さきほど紹介した RIC と同様に、RIE も AWS が提供する AWS Lambda のベースイメージにデフォルトで含まれています。それ以外のカスタムランタイムイメージを利用する場合は、RIE をダウンロード してイメージのビルド時に梱包するか、docker run 実行時に --entrypoint でローカルにインストールした RIE を参照してください。
※ AWS提供以外のカスタムイメージの場合、RIEを直接イメージに含めるより、実行時に--entrypointでRIEを差し込む方が、商用環境に不要なRIEを持ち込まないという面で有益です。
前回 ビルドしたコンテナイメージをそのまま利用することにします。
$ docker run -p 9000:8080 func1:latestRIE が 8080 ポートでリスニングするのでポートマッピングで 9000 ポートにマッピングしています。これで別のターミナルで curl でこの 9000 ポートにアクセスできるようになっているはずです。
$ curl -XPOST "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
{"statusCode": 200, "body": "{\"message\": \"hello world\"}"}動作しましたね ! このように、ローカルで Lambda サービスのエミュレートができました。
まとめ
AWS Lambda のエミュレーターを使用して、関数コードを素早くローカルで実行できることを確認しました。これにより AWS Lambda サービスにイメージをデプロイする前にロジックが正常に実行され、期待される出力を提供するかどうかをテストできます。
受け渡す Event データを、さまざまなイベントソースに合わせて組み上げることで、イベントソースからのイベントをモックできます。
もちろん、これまでと同様に AWS SAM CLI を利用してローカルフェイクサーバーを立ててローカルテストすることも変わらず実行可能です。ローカルテストを上手に活用して効率の良い開発ができれば良いですね。
次回以降ではさらに、コンテナサポート Lambda 関数の特徴や利点を追っていきたいと思います。
この連載記事のその他の記事はこちら
- 選択
- 第 1 回 コンテナ Lambda の”いろは”、AWS CLI でのデプロイに挑戦 !
- 第 2 回 コンテナ Lambda を開発、まずは RIC と RIE を使ってみよう !
- 第 3 回 コンテナ Lambda をカスタマイズして、自分好みの PHP イメージを作ろう !
- 第 4 回 コンテナ Lambda を AWS SAM でデプロイしよう !
- 第 5 回 コンテナ Lambda の CI/CD パイプラインの考え方
- 第 6 回 コンテナ Lambda の CI/CD パイプラインを SAM Pipeline で作ろう !
- 第 7 回 コンテナLambdaでサイドカーパターンは実現可能なの ?
筆者プロフィール
下川 賢介 (@_kensh)
アマゾン ウェブ サービス ジャパン合同会社
シニア サーバーレススペシャリスト ソリューションアーキテクト
Serverless Specialist Solutions Architect として AWS Japan に勤務。
Serverless の大好きな特徴は、ビジネスロジックに集中できるところ。
ビジネスオーナーにとってインフラの管理やサービスの冗長化などは、ビジネスのタイプに関わらず必ず必要になってくる事柄です。
でもどのサービス、どのビジネスにでも必要ということは、逆にビジネスの色はそこには乗って来ないということ。
フルマネージドなサービスを使って関数までそぎ落とされたロジックレベルの管理だけでオリジナルのサービスを構築できるという Serverless の特徴は技術者だけでなく、ビジネスに多大な影響を与えています。
このような Serverless の嬉しい特徴をデベロッパーやビジネスオーナーと一緒に体験し、面白いビジネスの実現を支えるために日々活動しています。
AWS を無料でお試しいただけます