경고: 게시된 모든 콘텐츠는 내 지식을 상기시키거나 유지하기 위한 것이며 귀하의 학습 여정에도 도움이 되기를 바랍니다.
이 게시물은 실시간이며 정기적으로 업데이트됩니다.
결함이 있거나 누락된 부분이 있으면 개선할 수 있도록 도와주세요 :)

애플리케이션 성능에 대한 요구가 점점 더 늘어나고 있다는 생각을 하신 적이 있습니까?
우리는 매일 더 빠르게 작업을 수행해야 하는 과제에 직면해 있으며 이를 통해 결과를 달성할 수 있는 솔루션과 아키텍처를 평가하게 됩니다.

그래서 AWS Lambda의 서버리스 애플리케이션 성능을 상당한 향상시키는 데 도움이 될 수 있는 새로운 진화에 대해 알리는 짧은 게시물을 올리려는 아이디어입니다. 이 솔루션은 LLRT Javascript입니다.

LLRT Javascript(낮은 지연 시간 런타임 Javascript)

AWS 팀에서는 새로운 Javascript 런타임을 개발 중입니다.
현재 실험 중이며 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를 사용하지 않는 접근 방식이 사용됩니다. 따라서 Just-In-Time 컴파일을 위해 리소스를 할당하는 대신 코드 자체 내에서 작업을 실행하기 위해 이러한 리소스를 절약합니다.

하지만 걱정하지 마세요. 모든 것이 장밋빛인 것은 아닙니다. 절충안이 있습니다(끔찍한 말장난, 저도 알아요 ㅋㅋㅋ).
따라서 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를 평가하고 비교하기 위해 두 가지 테스트를 수행합니다. 테스트 중 하나는 소수 계산을 위한 것이고 다른 하나는 간단한 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가 얼마나 많은 것을 제공할 수 있고 여전히 우리에게 제공해야 하는지 확인하는 것은 멋진 일입니다. 


즐거웠기를 바라며, 무언가에 대한 이해를 높이는 데 도움이 되었거나 새로운 지식에 대한 길을 열었기를 바랍니다. 콘텐츠를 개선하고 커뮤니티에 항상 최신 정보를 제공할 수 있도록 여러분의 비판과 제안을 부탁드립니다.