QCon New YorkでJohn Chapin氏が"恐れ知らずのAWS Lambdas"というプレゼンテーションをした。JVMがサーバレスコードをデプロイする先となるよいプラットフォームであるだけでなく、JavaベースのAWS Lambdaファンクションから最高のパフォーマンスを引き出す手引きが提供されているとも主張した。鍵となる点は次のことである。開発者がファンクションの"コールドスタート"のインパクトを減らし分割して返済すべきであること、現実世界のパフォーマンスを見極めるために広くファンクションのベンチマークを取るべきであること、固有のオプションよりも完全な機能を備えたロギングとメトリクスライブラリを使うべきであること、である。
Chapin氏は、Symphoniaの共同創立者であるが、"サーバレス"コンピューティングの核となる特徴の考察で話を始めた。長命のホスト（サーバ）管理やアプリケーションインスタンスはない。自己オートスケーリング/プロビジョニングはロードベースである。コストは正確な使用量をベースとする。まったく使わなければコストもゼロとなる。パフォーマンス性能はホストのサイズや数以外の条件で定義されている。プラットフォームは高可用性を暗黙的に提示している。オライリーのフリーのミニブック"サーバレスとは何か？"がこのトピックをさらに検討している。これはChapin氏とMike Roberts氏が最近執筆したものだ。
AWS Lambdaはファンクション・アズ・ア・サービス(FaaS)のサーバレスプラットフォームの1実装として導入された。言語サポートははJavaScript(node.js)とPython、C#が提供されているが、このプレゼンテーションではJavaとJVMに純粋に焦点を当てている。ラムダの実行環境は関数に割り当てたメモリ、これは128MBから1.5GBのRAMであるが、それに基づき設定を変更できる(そして費用は100ms単位での実行時間となる)。CPUやネットワークI/Oのような他のリソースは比例的に割り当てられる。 ファイルシステムにある500MBの/tmpディレクトリへのアクセスは提供されており、STDOUTとSTDERRはAWS Cloudwatchログにリダイレクトされる(AWSコンソールを通じて閲覧できる)。開発者から完全に抽象化されているが、LambasはAWS EC2上のLinuxコンテナ内で実行され、要求に応じて作成されidleまたはold、obsoleteのとき回収される。
下層のJava AWS Lambdaプラットフォームのパフォーマンスを特徴づけることは抽象化とイベントハンドリング、再試行、自動スケーリングの層が原因となり難しい試みだ。しかしChapin氏はJava Lambdaのベンチマークを作成した。これは2つのスレッドを活用し、フィボナッチ数列を計算するものだ。さまざまなメモリの設定で動作させることができ、1.5GBのメモリ設定をしたLambdaは128MBだけのLambdaより12倍早く実行されると当初仮定していた。ベンチマークの直近の実行結果は以下の通りで、仮定は証明された(以前の他の実行は時々一貫性のないパフォーマンスを描いていることには注意だが)。
"コールドスタート"の概念は次で議論するが、これは下層の実行時のコンテナ、つまりJVMとしてもっとも遅い関数のレスポンス時間という結果となり、アプリケーションは既存の関数インスタンスがイベントトリガを提供する準備ができていないことが原因で初期化をしなければならない(イベントトリガまたは下層のプラットフォーム操作のどちらかが欠如していることを通じてとなる。たとえばハードウェアの再起動だ)。コールドスタートを監視する長時間の実行実験の結果は議論されており、us-west-2リージョンでLambdaを実行した2日間のデータは128MBのRAMを設定したLambdaは1.8%の時間で再起動があり、1.5GBのRAMのLambdaは0.97%の時間で再起動があったことを示している。
JavaのLambda関数のデプロイには単純にzip圧縮した成果物のアップロードが必要となる。これにはアプリケーションコードとすべての依存ライブラリが含まれる。Chapin氏はmaven-shade-pluginのようなツールを使って単一のJARを作成することを推奨している。マルチLambdaプロジェクトでは同様にmulti-module Maven projectsを使って作成できる。AWS Bill-Of-Materials (BOM)は、複数のAWSライブラリに依存するとき互換性のあるAWS SDKモジュールのバージョンをインポートするために使われる。デプロイできる成果物の作成に加えて、他の関連するランタイムクラウドインフラストラクチャはAWSサーバレスアプリケーションモデル(SAM)を使って指定できる。AWS SAMはサーバレスアプリケーションが必要とするAmazon API Gateway APIやAWS Lambdaファンクション、Amazon DynamoDBテーブルを定義するための簡略化された方法を提供するためにAWS CloudFormationを拡張している。
話の最後から2番目のセクションでAWS Lambda上のJVMランタイムを調査した。Lambdaの下層にあるランタイムを問い合わせると、JVMがOpenJDK 1.8のサーバVMで、以下のフラグを設定していることが明らかとなった。
- -XX:MaxHeapSize = 設定したLambdaメモリの85%
- -XX:+UseSerialGC
- -XX:+TieredCompilation
- -Xshare:on
Java LambdaのコールドスタートはJavaアプリケーションの典型的なライフサイクルをフォローする。クラスローディングやコンストラクタ、staticブロック初期化、代替言語のランタイムのローディング(たとえばClojure)、JITコンパイルだ。Chapin氏はもっともよい起動時間のためには容赦なく不要な依存性を削除する"Lambdaダイエット"が適用されるべきだと述べた。
プレゼンテーションの最後のトピックは、ロギングとメトリクスであったが、System.out/errの出力はCloudwatchに向けられ、デフォルトではLambdaごとに1つの"ロググループ"にするという議論で始まった。System.out.printlnの使用はどんなJavaアプリケーションでも同様に同じ理由で抑止される。ロギングライブラリを使うことでより細かい制御とメタデータを含めることが許可される。Lambdaランタイムは現在RequestIdをLog4Jのログに追加できるが、現行のaws-lambda-java-log4jライブラリはLog4J 1.2を使っており、これは古く、サポートされていないバージョンである。代わりに、Symphoniaが作成したオープンソースのlambda-loggingを使うことが推奨された。これは現行バージョンのSLF4JとLogbackを利用している。
AWS Lambdaプラットフォームは現在"ビジネスメトリクス"を容易に取り込むようなサポートをしていない。代わりにLambdaプラットフォームのメトリクス、たとえばエラー、持続時間、呼び出し、スロットルに焦点を当てている。Chapin氏は警告した。元々のCloudwatchのメトリクス収集アプローチは危険であり、as CloudwatchはアカウントレベルのAPI制限を持っており、これは簡単に越えてしまえる(これは全アカウントのログ出力を失敗させてしまう！)からだ。Cloudwatchメトリクスフィルタが利用できるが、Cloudwatchのログデータは"特別な(細かい)パターン"を使って収集されなければならない。Cloudwatchメトリクスを生成し投稿するためだ。代替として、Chapin氏とSymphoniaのチームはオープンソースのlambda-metricsライブラリを作成してきた。これはCodahaleメトリクスとlambda-loggingから成る。そしてMavenプラグインを使ってCloudwatchログを収集し、Cloudwatchメトリクスへ投稿するメトリクスフィルタを構築する。
Chapin氏はビジネスアプリケーション構築にLambdaのJVMランタイムを使うことを推奨しており、開発者はコールドスタートのインパクトを減らし分割して返済することに焦点を当て、広く関数のベンチマークを取り、本物のロギングとメトリクスを使うべきであると述べて話を要約した。John Chapin氏のプレゼンテーション"恐れ知らずのAWS Lambdas"の追加情報はQCon New Yorkのwebサイトにあり、数ヶ月以内にビデオ録画がInfoQ上で閲覧できる予定である。
Rate this Article
- Editor Review
- Chief Editor Action