Easel.sh、AWS Lambda Web Functionsのアイドルメモリ課金を回避するためカスタムコンピューティングを構築

200ミリ秒の単一リクエストの後に345秒間のアイドル状態が発生した場合、AWS Lambda Web Functionsでは、リクエスト時間の約1,700倍に相当するメモリ課金が発生する可能性があります。この発見を受け、Webアプリケーションの実行プラットフォームであるEasel.shは、リソース割り当てとコストを制御するため、同サービスを放棄し、独自のコンピューティングインフラを構築することに決めました。

5分間のアイドル問題

AWS Lambda Web Functionsはゼロへのスケーリングを目的として設計されていますが、プラットフォームは実行環境の全寿命にわたって消費されたメモリに対して課金します。Easel.shは、これらの環境がリクエスト終了直後に終了するのではなく、5〜7分間アクティブなまま残ることを発見しました。

6つの代表的な環境にわたる実験では、アイドル期間は313秒から411秒の間で測定されました。これらのウィンドウを短縮するための設定可能なアイドルタイムアウトが存在しないため、アプリケーションが何も作業をしていない時でもメモリコストが発生し続けます。

この図は、Easel.shがAWS Lambda Web Functionsのテスト中に発見した特定のアイドル期間を示しています。

HN Digestによる図表（easel.shの報告数値に基づく。数値はソースの通りに表示）。

低トラフィックなワークロードへの経済的影響

この課金構造は、予測不可能なトラフィックを持つアプリケーションにとって特有の課題となります。リクエストが絶え間なく続く場合、アイドルメモリのコストは多くのインタラクションに分散されます。しかし、1日に数回しかリクエストを受け取らないアプリの場合、単一のリクエストのコストは、その後のアイドル期間によって支配される可能性があります。

Easel.shは、テストにおいてメモリが計算されたコンピューティングおよびリクエストコストの約88%を占めたと指摘しました。数千の独立したデプロイをサポートするプラットフォームにとって、これらの累積的なアイドル料金は、高ボリュームで持続的なトラフィックとは異なる経済的プロファイルを生み出します。

パフォーマンスとインフラのトレードオフ

課金問題を解決するため、Easel.shはアプリケーションの実行を自社で運用するサーバーに移し、従来のLambdaはオーバーフロー時のみに使用するように変更しました。この移行により、単一のマシン上で複数のアプリケーション間でキャパシティを共有できるようになり、環境ごとのアイドル料金を排除しました。

この図は、アイドル時間のコストを軽減するための共有キャパシティへのアーキテクチャの移行を説明しています。

初期のベンチマークでは、このカスタムインフラが、JSON APIやサーバーサイドレンダリングを含む様々なワークロードにおいて、中央値のウォームリクエスト時間を1.5〜3倍高速化することが示されました。さらに、カスタムホストは、12分間のアイドル期間の後のコールドスタートにおいて、AWS Lambda Web Functionsと比較して3.5倍高速な結果を達成しました。

このチャートは、ウォームリクエストのシナリオで観察されたパフォーマンスの向上に関するデータを提供します。

この視覚資料は、自社運用インフラにおける大幅に高速なコールドスタートに関する主張を裏付けています。

調査結果の限界

Easel.shによって提供されたパフォーマンスデータは、単一のリージョン（us-east-1）および特定のNext.js 16アプリケーションに基づいています。同社は、これらは初期の結果であり、包括的なマルチリージョン・パフォーマンス調査や、持続的なスループットのベンチマークを構成するものではないと述べています。

自社運用コンピューティングへの移行は、これらのテストにおいてより優れたコスト管理とパフォーマンスを提供しますが、同時に、キャパシティの管理、障害への対応、および多様なユーザーアプリケーション間での効率的なリソース分配を確保する責任を伴います。