警告: 投稿されたすべてのコンテンツは、私の知識を思い出させたり維持したりすることを目的としており、あなたの学習の旅にも役立つことを願っています。
この投稿は公開されており、定期的に更新されます。
欠陥を見つけたり、何かが欠けていることに気付いた場合は、改善にご協力ください:)

アプリケーションのパフォーマンスに対する要求がますます高まっていると考えたことはありますか?
私たちは日々、それらを高速化することに挑戦しており、それによって結果を達成できるソリューションとアーキテクチャを評価することになります。

そこで、AWS Lambda のサーバーレス アプリケーションのパフォーマンスを 大幅に 向上させるのに役立つ新しい進化について短い投稿を投稿することが目的です。このソリューションは LLRT Javascript.

LLRT Javascript(低遅延ランタイム Javascript)

新しい Javascript ランタイムが aws チームによって開発されています。
現在は実験段階であり、2024 年末までに安定したバージョンをリリースするよう取り組んでいます。

AWS が提供する説明を参照してください:

LLRT (Low Latency Runtime) は、高速かつ効率的なサーバーレス アプリケーションに対する需要の高まりに対応するために設計された軽量の JavaScript ランタイムです。 LLRT は、AWS Lambda で実行される他の JavaScript ランタイムと比較して、起動が最大 10 倍以上高速で、全体的なコストが最大 2 倍低くなります
Rust に組み込まれており、QuickJS を JavaScript エンジンとして利用し、効率的なメモリ使用と素早い起動を保証します。

他の JS ランタイムよりも最大 10 倍高速に何かを提供することを目指していることがわかります。

この構築はすべて、高性能言語である Rust と、小型で効率的で最新の ECMAScript 仕様と互換性を持つように設計された軽量で高性能な JavaScript エンジンである QuickJS を使用して行われます。クラス、async/await、モジュールなどの最新の機能。さらに、JITを使用しないアプローチが使用されます。したがって、ジャストインタイム コンパイルにリソースを割り当てる代わりに、コード自体内のタスクを実行するためにこれらのリソースが保存されます。

でも心配しないでください、すべてがバラ色というわけではありません、それはトレードオフです（ひどい駄洒落ですね、笑）。
したがって、LLRT JS の採用を検討する前に考慮すべき重要な点がいくつかあります。 AWS の意見を参照してください:

大規模なデータ処理、モンテカルロ シミュレーション、数十万回または数百万回の反復を伴うタスクの実行など、LLRT が JIT を利用したランタイムと比較して顕著なパフォーマンス上の欠点を示すケースが多くあります。 LLRT は、データ変換、リアルタイム処理、AWS サービス統合、認可、検証などのタスク専用の小規模なサーバーレス機能に適用すると最も効果的です。すべてを包括的に置き換えるものとしてではなく、既存のコンポーネントを補完するように設計されています。特に、サポートされている API が Node.js 仕様に基づいているため、代替ソリューションに戻るには最小限のコード調整が必要です。

さらに、LLRT JS は、node.js の代替ではなく、今後も代替される予定はないという考えです。

見て：

LLRT は Node.js API の一部のみをサポートします。これは Node.js の代替品ではありませんし、今後もそうなりません。以下は、部分的にサポートされている API とモジュールの概要です。詳細については、API ドキュメントを参照してください。

評価試験

AWS 自体が述べた適用性を考慮して、LLRT と NodeJS を評価および比較する 2 つのテストを実行します。テストの 1 つは素数の計算用で、もう 1 つは単純な API 呼び出し用です。

なぜ素数の計算を使用するのですか?
その答えは、素数を識別するために必要な高度な処理は、素数を検証するために多くの数学的演算 (除算) を実行する必要性、素数の予測不可能な分布、および数値のサイズの増加に伴う複雑さの結果であるということです。これらの要因が組み合わさって、特に大規模な場合、素数検査と素数の検索が計算量の多いタスクになります。

それでは実践してください...

nodejs を使用して最初のラムダ関数を作成します:

それでは、LLRT JS で関数を作成してみましょう。レイヤーオプションを使用することにしました。

レイヤーの作成:

次に関数を作成します:

そして、作成した LLRT JS 関数にこのレイヤーを追加します:

素数テストには、次のコードを使用します:

let isLambdaWarm = false
export async function handler(event)  {

    const limit = event.limit || 100000;  // Defina um limite alto para aumentar a complexidade
    const primes = [];
    const startTime = Date.now()
    const isPrime = (num) => {
        if (num 



API テストには、以下のコードを使用します:


let isLambdaWarm = false
export async function handler(event) {

  const url = event.url || 'https://jsonplaceholder.typicode.com/posts/1'
  console.log('starting fetch url', { url })
  const startTime = Date.now()

  let resp;
  try {
    const response = await fetch(url)
    const data = await response.json()
    const endTime = Date.now() - startTime
    resp = {
      statusCode: 200,
      body: JSON.stringify({
        executionTime: `${endTime} ms`,
        isLambdaWarm: `${isLambdaWarm}`
      }),
    }
  }
  catch (error) {
    resp = {
      statusCode: 500,
      body: JSON.stringify({
        message: 'Error fetching data',
        error: error.message,
      }),
    }
  }

  if (!isLambdaWarm) {
    isLambdaWarm = true
  }

  return resp;
};






  
  
  テスト結果


ここでの目的はより教育的なものであるため、各テストのサンプルは 15 個のウォーム スタート データと 1 個のコールド スタート データで構成されています。

メモリ消費量

LLRT JS - 両方のテストで、同じ量のメモリが消費されました: 23mb。

NodeJS - 素数テストの場合、nodejs は 69MB を消費し始め、106MB まで増加しました。 

API テストの場合、最小値は 86mb、最大値は 106mb でした。 

実行時間

外れ値を削除した後の結果は次のとおりです:





最終レポート

メモリ消費量 - メモリ消費量については、LLRT が、nodejs と比較して、利用可能なリソースをより適切に利用していることが観察されました。

パフォーマンス - 高度な処理シナリオでは、コールド スタートとウォーム スタートの両方で、ノードが LLRT よりもはるかに優れたパフォーマンスを維持していることがわかりました。

低処理シナリオでは、特にコールド スタートにおいて、LLRT に一定の利点がありました。

最終結果を待ち、さらに大幅な改善ができることを願っていますが、JS の柔軟性を確認し、JS がどれだけのことを私たちに提供できるか、そしてこれからも提供しなければならないことを知るのは素晴らしいことです。 


楽しんでいただき、何かについての理解を深めたり、新しい知識への道を開いたりするのに役立ったなら幸いです。コンテンツを改善し、コミュニティのために常に最新の状態に保つことができるよう、批判や提案をお待ちしています。