프로덕션을 위한 AWS Lambda 최적화 팁 4가지

포스트는 AWS Lambda (람다) 최적화에 관한 내용을 다루고 있으며, 람다 함수의 지속적인 모니터링과 개선, 오류 작업 실패에 대한 알림을 받을 있도록 하는 워크플로우 개발을 목적으로 하고 있습니다. 

서버리스는 지난 몇 년 동안 최고의 위치에 자리매김했으며 앞으로도 백엔드 개발에서 더 큰 역할을 할 것으로 보입니다.

AWS 람다는 오늘날 서버리스 공간에서 가장 많이 사용되고 있는 성숙 단계에 있는 제품이며 Dashbird가 제공하는 서비스의 핵심이기도 합니다. 이러한 이유에서 최적화된 성능과 비용으로 프로덕션에 준비된 람다를 구축하기 위한 몇 가지 팁과 권장 사항을 공유하고자 합니다.

aws lambda monitoring

1. 람다의 성능 및 비용 추적

어떠한 기능을 변경하기 전에는 함수에 대한 성능 추적을 미리 설정해두는 것이 좋습니다. 람다 함수의 호출 , 처리 시간, 메모리 사용량 비용을 모니터링함으로써 문제점을 정확히 찾아내고 정보에 입각한 신속한 결정을 내릴 수 있기 때문입니다. 그리고 이는 Dashbird 를 사용함으로써 쉽게 설정이 가능합니다. Dashbird는 클라우드 와치 로그에 연동되는 툴로, 클라우드 와치 로그 보다 사용하기 더 쉽고 업무수행에 중요한 AWS 데이터에 대한 빠른 액세스 및 시각화를 제공합니다. 더 자세한 내용은 AWS 클라우드 와치와 Dashbird의 주요 기능 비교에 관한 글을 통해 확인하실 수 있습니다.

monitor aws lambda

계속해서, 사용자 함수를 강화하기 위한 다양한 전략들을 살펴보겠습니다.

2.최적의 메모리 프로비저닝(Provisioning) 및 람다 성능 조정

람다 함수에 할당된 가상 CPU 코어의 양은 해당 함수에 할당된 메모리와 연관됩니다. 가령, 256MB의 메모리를 가진 함수는 128MB 함수에서 배의 CPU 갖습니다. 그리고 현재로서 최대치인 10GB 메모리를 구성하면 6개의 가상 CPU 코어가 제공됩니다. 메모리 크기 또한 콜드 스타트 시간에 비례적으로 영향을 미칩니다. 

개발자는 많은 메모리의 비용 증가를 고려하여 속도 또는 비용에 맞는 최적화를 꾀해야 합니다.

다음은 알렉스 카살보니 (Alex Casalboni)의 ‘비용 및 속도 최적화’의 좋은 예입니다.

RAMDynamoDBSNS Message sendingBilled timeCost
128MB110ms120ms300msCheapest & slowest
1024MB80ms70ms200msMost expensive
1536MB35ms45ms100msOptimal

비용 측면에선 128MB 구성이 가장 저렴할 것입니다. (그러나 매우 느립니다!) 흥미롭게도, 1536MB 구성을 사용하는 것이 1024MB를 사용하는 것보다 빠르고 저렴합니다. 왜는하면, 1536MB 구성이 1.5배 더 비싸지만 사용 시간의 절반만 지불하면 되므로 전체 비용의 약 25%가 절약되기 때문입니다.

람다 성능 조정수동 또는 외부 을 통해 수행할 수 있습니다. 성능 조정은 다양한 메모리 구성으로 사용자의 함수를 여러 번 실행합니다. 그리고 그 데이터를 바탕으로 사용 목적에 가장 적합하다고 생각되는 항목을 선택할 수 있습니다.

3. 람다 컨테이너 재사용

AWS 다음 호출이 5 이내인 경우 후속 호출에 람다 컨테이너를 재사용합니다. 이를 통해 개발자는 리소스를 캐시하고 연결 풀링을 구현할 수 있습니다. 다음은 이러한 방식을 시도하고자 할 때 체크해야 할 사항입니다.

  • 요청(Request)간에 변경되지 않는 모든 것을 함수 코드 외부에 배치합니다. Node.js 런타임에서 핸들러 함수 외부의 코드는 콜드 스타트 시 한 번만 실행됩니다.
  • 최초 실행 후 외부 구성 및 종속 항목들을 로컬로 저장 및 참조하고, 변수 및 객체가 모든 호출에서 재 초기화 되는 것을 제한합니다. 대신 정적(Static) 초기화 및 생성자, 전역(Global) 및 정적 변수, 싱글턴(Singletons) 유지하여 사용하고, 첫 번째 호출에서 설정된 연결(HTTP, 데이터베이스 등)을 재사용 하십시오.

구체적인 방법은 아래 링크된 자료를 참고하세요.

  1. MongoDB를 위한 연결 풀링
  2. PostreSQL및 MySQL을 위한 연결 풀링
  • 임의의 기준이 충족될 때까지 함수가 자동으로 자신을 호출하는 재귀 코드를 람다 함수에서 사용하지 마십시오. 이로 인해 의도하지 않은 양의 함수 호출 및 비용 상승이 발생할 수 있습니다.

잘못된 방법:

exports.handler = async (event, context) => {
      const client = clientModule.configure({
        apiKey: process.env.API_KEY
      });
      ...
};

올바른 방법:

const client = clientModule.configure({
      apiKey: process.env.API_KEY
      });
exports.handler = async (event, context) => {
      ...
};
  • LRU 방법으로 재사용 가능한 리소스를 캐시합니다. 이는 바인딩 되지 않은 데이터의 성능을 향상하는 방법입니다. 바인딩 없이 데이터가 증가하면 어느 지점에서 메모리에 맞지 않게 될 수 있습니다. 그렇더라도 사용자는 가장 중요한 항목에 캐싱 전략을 적용하고 자주 사용되지 않는 항목은 폐기할 수 있습니다.

다음 코드 예제에서 메모리내캐시는최대 100개의항목만저장한다음가장오래된항목을삭제하기시작합니다. 이렇게 하면 데이터바인딩이해제되었을때메모리가오버플로되지않습니다. 캐시에서항목을찾을수없는경우에만 expensiveApiCall 함수를호출합니다.

const cache = [];
function fromCache(id) {
  return cache.find(item => item.id === id)
}
function toCache(item) {
  cache.push(item);
  if(cache.length >= 100) cache.shift();
}
exports.handler = async (event, context) => {
  const {id} = event.queryStringParameters;
  let item = fromCache(id);
  if (!item) {
    item = expensiveApiCall(id);
    toCache(item);
  }
  return {statusCode: 200, body: JSON.stringify(item)};
}
  • 여기서 최대 10GB로 프로비저닝 된 메모리에 주의하십시오! 람다의 메모리 한계가 증가하여 현재는 10GB가 되었습니다. 또한 6개의 vCPU가 함께 제공되므로 대부분의 요구 사항을 맞출 수 있습니다. 데이터가 10GB에 맞지 않고 캐싱이 가능하지 않은 경우 여러 람다 호출을 확장해야 합니다. 수직이 아닌 수평으로 확장합니다.
  • 람다 함수에서 직접 람다 함수를 호출하지 마십시오. 자기 자신이나 다른 함수에서 재귀적으로 수행하지 않아야 합니다. 만약 람다 함수에서 직접 람다 함수를 호출하고 결과를 기다리는 경우 대기 함수와 호출되는 함수, 두 가지 비용을 지불하게 됩니다. 그러므로 여러 람다 함수를 연결해야 하는 경우 SQS, SNS, Kinesis 또는 Step 함수가 상호 작용을 처리하도록 합니다. 이렇게 하면 사용자의 함수가 빠르게 처리되며, 더 저렴한 서비스를 통해 후속 함수를 기다릴 수 있습니다.

4. 로그 기반 람다 모니터링 및 오류 처리

AWS 람다의 실행속도가 느린가요?

서버의 경우, 성능 메트릭 수집과 실패한 실행 추적에 대해서는 일반적으로 에이전트가 수행하는데, 에이전트는 원격 분석 오류 정보를 수집하여 HTTP를 통해 전송합니다. AWS 람다로 이 접근 방식을 사용하면 함수가 느려지고 시간이 지남에 따라 상당한 비용이 추가될 수 있습니다. 많은 양의 람다 함수 처리를 위한 타사 에이전트의 추가( 유지) 발생하는 추가적인 오버헤드 문제도 간과할 수 없습니다.

람다 함수의 가장 좋은 은 모든 성능 지표와 로그가 AWS 클라우드 와치로 전송된다는 것입니다. 클라우드 와치 자체가 오류 처리를 관찰하고 설정하기에 완벽한 툴은 아니지만, 일부 서비스가 클라우드 와치 상에서 작동하며 사용자의 서비스에 대한 가시성을 제공하는 데 우수합니다.

Dashbird는 AWS 람다를 위한 로그 기반 모니터링 및 오류 처리 솔루션입니다. 이는 사용자가 서버리스 아키텍처의 모든 계층을 모니터링하고 서비스에서 발생할 수 있는 모든 오류를 몇 초 안에 알 수 있도록 합니다.

결론

서버리스 스택을 최적화 할 수 있는 방법은 다양하며, 그 모든 것은 올바른 방법을 숙지하고 문제점을 찾아내는 에서부터 시작됩니다. 위에 소개된 모든 방법을 직접 시도해보고, 람다 함수를 변경하여 성능 차이를 테스트해 보실 것을 권장해 드립니다. API 엔드 포인트 함수는 실행 볼륨이 커질수록 성능에 영향을 미칩니다. 그러므로 시스템을 최상의 상태로 유지하기 위해서는 서버리스 대시보드의 사용이 필수적입니다.

Read our blog

Introducing easy custom event monitoring for serverless applications.

Today we are excited to announce scheduled searches – a new feature on Dashbird that allows you to track any log event across your stack, turn it into time-series metric and also configure alert notifications based on it.

Why and How to Monitor Amazon OpenSearch Service

One of the most vital aspects to monitor is the metrics. You should know how your cluster performs and if it can keep up with the traffic. Learn more about monitoring Amazon OpenSearch Service.

Why and How to Monitor AWS Elastic Load Balancing

Dashbird recently added support for ELB, so now you can keep track of your load balancers in one central place. It comes with all the information you expect from AWS monitoring services and more!

More articles

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.