【レポート】コンテナだけどサーバーレス! AWS Lambda の最新機能をご紹介 #AWSSummit
CX事業本部@大阪の岩田です。5月31日までアーカイブが視聴可能なAWS Summitですが、Developer Zoneという開発者向けの特設サイトが存在することをご存知でしょうか?公式サイトでは以下のように案内されています。
より多くの技術情報に触れたいとお考えの開発者の方向けに、エキスパートによるテクニカルトーク、ライブ解説付きのデモ、AWS Robot Delivery Challenge, AWS DeepRacer リーグなど、多彩なコンテンツを備えた特設サイト「Developer Zone」をご用意しました。
少しカジュアルな雰囲気の中、よりディープに AWS サービスを活用した開発のノウハウを知ることができます。テクニカルトーク、ライブ解説付きのデモでは、参加するお客様からのご質問にもその場でお答えしますので、ぜひご参加ください。
この記事はDeveloper Zoneのセッション「コンテナだけどサーバーレス ! - AWS Lambda の最新機能をご紹介 -」のレポートとなります。
セッション概要
2020 年 12 月、AWS Lambda はコンテナイメージのサポート開始を発表しました。これにより、最大 10 GB までのコンテナイメージをサーバーレスな基盤上で動作させることが可能となり、より便利に AWS Lambda をご利用いただけるようになりました。この動画では、本機能の使いどころに加えて、AWS SAM CLI を利用し実際に開発およびデプロイする様子を、デモを通してご覧いただきます。
スピーカー
アマゾン ウェブ サービス ジャパン株式会社 プロトタイプソリューションアーキテクト 今村 優太氏
セッション動画
コンテナだけどサーバーレス! - AWS Lambda の最新機能をご紹介 -
セッション内容
Lambdaのコンテナイメージサポートについて
Lambda関数のデプロイ方法
- マネコンからソースコードを編集する
- ZIPファイルをアップロードする
- S3に配置したZIPファイルをデプロイする
昨年末のアップデートにより、上記の3つに加えてECRに配置したコンテナイメージをデプロイする方式が利用可能に
コンテナサポート機能の特徴
- デプロイ可能なファイルサイズが大きい
- ZIPパッケージは解凍後に250Mが上限
- コンテナイメージの場合は最大10GBまでデプロイ可能
- AWSが以下ランタイムのベースイメージを提供しており、非コンテナのLambdaと同様の言語が選択可能
- Node.js
- Python
- Java
- .NET
- Go
- Ruby
- ベースイメージ以外をもとにしたイメージも起動可能
- LambdaランタイムAPIに準拠した実装が必要
- プログラミングモデルはLambdaのモデルに則る必要がある
- ベースイメージはLambdaのサービス基盤にキャッシュされているため、ベースイメージ以外と比較してコールドスタート時間が早い
ユースケース
- ファイルサイズが大きい場合
- 従来Lambdaで大容量ファイルを扱う場合はS3から/tmpにファイルをDLするようなアーキテクチャが選択されていた
- /tmpディレクトリの利用可能な上限は512MBまでに制限されている
- コンテナイメージ形式の場合は事前に大容量ファイルをコンテナイメージ内に含めることができ、イメージサイズの上限も10GBと比較的大きい
- 学習済みのモデルを利用する機械学習、計算系ライブラリを利用するようなデータ分析のワークロードに最適
-
パッケージマネージャを利用してOSにインストールするようなソフトウェア、ミドルウェアが必要な場合
-
Lambdaがサポートしていないバージョンや言語を利用したい場合
デモ
デモで実現する内容
- OCR(Optical Character Recognition)をテーマにしたサンプルアプリ
- Amazon Textractは現状日本語に対応していないため、日本語のOCRをサポートするOSSを利用して、Lambda上でテキストデータの抽出処理を実現する
-
- PyOCRというPythonのライブラリ経由で利用
- dnfやyumを使ってコンテナイメージにインストールして利用
- SAM CLIを利用したコンテナイメージのビルド/デプロイ
- S3に画像をアップロードするとLambdaが起動、画像からテキストを抽出してCloudWatchにログを出力する
開発の流れ
sam init
でひな形作成- ベースイメージの選択
- プロジェクト名の設定
- ひな形のアプリケーションテンプレート選択
- SAMテンプレートの編集
- S3バケットの作成
- LambdaとS3のイベントを紐付け
- S3の読み取り権限追加
- Dockerfileの編集
yum
によるTesseractのインストール処理を追加requirements.txt
に必要なライブラリを追加
- Lambdaの処理を実装
- 非コンテナイメージのLambdaと全く同様のプログラミングモデル
- SAM CLIの
generate-event
を使うと簡単にイベントデータの構造が確認できる sam local generate-event s3 put
- コンテナイメージのビルド
sam build
コマンドを実行するだけでコンテナイメージをビルド可能
- ECRのリポジトリを作成
- リポジトリのURLはデプロイ時に利用
- SAM CLIでデプロイ
sam deploy --guided
- 対話形式で諸々のパラメータを指定 ECRのリポジトリURIもここで指定
- ビルドが完了するとコンテナイメージがECRにプッシュされる
- プッシュが完了するとCFnテンプレートのデプロイが実行される
動作確認
- Lambdaのドキュメントの画像を切り出してS3にアップロードし、日本語を検出できるかテストする
- ドキュメントの日本語がほぼそのままログに出力できている
- 初期化に6秒、OCR処理に17秒ほどの処理時間
- 非コールドスタートの場合は初期化の約6秒のオーバーヘッドが削減される
まとめ
- Lambdaのパッケージフォーマットとしてコンテナイメージを選択することで、よりサイズの大きなライブラリや、OSにインストールが必要なライブラリが利用できるようになった
- プログラミングモデルは非コンテナイメージのLambdaと同様なので、従来通りの開発が可能
- コンテナイメージのサポートによってLambdaが利用できるワークロードの幅がさらに広がった
所感
re:invent2020で発表されたLambdaのコンテナイメージサポートについておさらいできるセッションでした。 今回紹介されていたようなユースケース以外でも、ECSをメインの基盤に採用しつつもAWSサービスとの連携部分だけ一部Lambdaを利用したいといったケースでコンテナイメージが有効に利用できそうです。 例えばですがFargate上でRuby on Railsのアプリを動かしつつ、一部のユースケースではS3へのPutObjectをトリガーにLambdaを起動してなにかしらのビジネスロジックを実行したいとします。Lambdaがコンテナイメージをサポートしたことで、PutObjectをトリガーにRIC(AWS Lambda Runtime Interface Clients)導入済のRailsコンテナが起動できるので、Lambda上で動かすビジネスロジックからRailsの豊富な機能が利用できるのです。
また、個人的に興味深かったのが、AWSが提供するベースイメージはLambdaのサービス基盤にあらかじめキャッシュされているという点です。以前コンテナイメージからデプロイしたLambdaのコールドスタート時間を計測した時に、予想よりもはるかに高速に起動するという結果が出たのですが、ベースイメージを利用していたことが要因の1つとして挙げられそうです。また別のイメージを使って検証してみたいと思います。