API Gateway+Lambdaで稼働中のアプリケーションをApp Runnerに置き換え可能かどうか検証してみた
稼働中のとあるアプリケーション(API)を App Runner に置き換え可能かどうか検証してみました。
アプリケーションの特性
- 構成: API Gateway + Lambda で単一のエンドポイント。ランタイムは Nodejs。
- 処理内容: リクエストで指定された画像をサーバから HTTP で取得して加工して返す。加工には sharp を利用。
- パフォーマンス要求: 平時は 1req/s 以下だが、たまに 100 件程度の同時リクエストがある。
パフォーマンス
アプリケーションが同時に 100 件のリクエストを受けたときのパフォーマンスを比較します。
※ レイテンシはネットワーク時間を含みます。リージョンはバージニアを利用しています。
Lambda
現状のパフォーマンスは以下の通りです。
1 リクエストごとに 1Lambda が起動し、スロットルされることなくすべて処理できています。
| メモリ | 平均レイテンシ |
|---|---|
| 128MB | 4~5s |
| 2048MB | 1~2s |
App Runner
Lambda と全く同じリソース設定にはなりませんが、インスタンスのリソースは 1vCPU,2GBメモリ で検証しました。
| 同時実行 | 最小サイズ | 平均レイテンシ | 備考 |
|---|---|---|---|
| 80(デフォルト) | 1(デフォルト) | 6~7s | すべて 200 レスポンス |
| 40 | 1 | 6s | 20%程度が 429 レスポンス |
| 10 | 1 | 3s | 75%程度が 429 レスポンス |
| 10 | 10 | 2~3s | 15%程度が 429 レスポンス |
同時実行を超えたとき、瞬時にアクティブインスタンスが増えてリクエストが処理されることを期待していたのですが、実際には受けきれなかった時点でスロットリングされ、その後アクティブインスタンスを増やすという動きになるようです。
最小サイズ（プロビジョニングされたコンテナ数）を上げることでアクティブインスタンスが増えるまでの時間は短くなるようですが、それでもリクエスト量によってはスロットリングの発生を防ぐことは難しそうです。
コスト
App Runner のコストは、コンテナに対する課金のみです。プロビジョニングされたコンテナ（Provisioned container instances）はメモリだけのコストがかかり、アクティブなコンテナ（Active container instances）はメモリと vCPU のコストがかかります。
プロビジョニングされたコンテナは、サービス提供中のときは最低 1 台は必要なので、全くリクエストがなくても約$10/month(0.007 * 2 * 24 * 30 = 10.08)のコストがかかります。
これが 24 時間アクティブな場合、1vCPU あたり約$46/month(0.064 * 24 * 30 = 46.08)のコストが追加されます。
まとめ
- 検証結果から今回のアプリケーションの場合は、パフォーマンス的にもコスト的にも Lambda の方が有利であることが分かりました。
- 内部的には Amazon Linux Docker image が使われているということなので、Lambda とのアーキテクチャの違いは理解した上で利用する必要があります。とはいえ AutoScaling によるスロットリングの緩和はもう少し改善されることを期待します。
- テスト環境など普段全くリクエストがない環境でもコストがかかってしまうので、最小サイズを0にできるようになることを期待します。
Discussion