[AWS] Lambda Warm Start / Cold Start

제일 중요한(뇌피셜) 개념을 다뤄보려 한다..

사실 내가 이걸 먼저 보려고 했었는데...😂

---

Warm Start / Cold Start

Lambda 동작 순서

lambda code 작성 & 배포 → Load Code as .zip → Download to container → Bootstrap code(compile, load code to container) → run code

https://velog.io/@milkcoke/Lambda-Cold-start

(Bootstrap: 특정 언어에 대해 컴파일하여 기록하는 것)

 

Warm Start

• 이미 실행 준비가 완료된 상태

 

Cold Start

• 배포 패키지의 크기와 코드 실행 시간 및 코드의 초기화 시간에 따라 새 실행 환경으로 호출을 라우팅할 때 지연 시간이 발생
• 쉽게 얘기하면 잠시 절전 모드의 컴퓨터를 키는 느낌 이랄까...
• 발생 원인
  • 인스턴스 자체가 떠있지 않은 상황:
    • 컨테이너를 실행시키기 위해선 인스턴스가 활성화되어 있어야하는데 요청과 요청 사이의 간격이 너무 크거나, 최초의 요청이여서 인스턴스가 내려가있을 수 있다.
  • ENI 적용 시간:
    • Lambda도 결국엔 서버이다. 통신을 위해선 ENI가 컨테이너에 붙어야 한다. 특히, VPC를 사용하는 Lambda의 경우 반드시 적용된다.
    • 예를 들면, DB와 연결할 때, DB는 내부 서버에게만 열어야하기 때문에..
    • 이를 해결하려면 VPC + ENI의 성능을 향상시켜야 한다!
      • 아래의 사이트가 VPC 성능 개선 시킨 모델(?)
      • 그래도... 최대한 가볍게 쓰는게 좋을 듯 싶다..?😅
      • https://aws.amazon.com/ko/blogs/korea/announcing-improved-vpc-networking-for-aws-lambda-functions/
  • Dwell Time:
    • lambda 구조에서도 봤듯이 요청이 들어오면 컨테이너로 바로 들어가는게 아니라 큐에 쌓이게 된다.
    • 큐에서 요청을 꺼내 컨테이너로 보내는 시간: Dwell Time
    • 이 시간은 언제 길어질까?
      • 한 계정에 동시에 띄울 수 있는 최대 컨테이너 수(Max Concurrent Executions)는 제한되어 있음
      • 요청이 엄청 들어왔다고 가정했을 때, 컨테이너가 어떻게 증가할까?
        • 아마 컨테이너가 하나씩 선형적으로 증가하는 그림은 아닐듯
      • 한 계정에는 하나의 서비스를 만들기 위해 여러 종류의 Lambda를 사용하게 된다. 각 Lambda에서 생성될 수 있는 컨테이너 수를 제한하는데(Reserved Concurrent Executions) 이 설정보다 많은 요청이 동시에 들어오면 Throttle 발생!

 

Cold Start 해결 방법

• Lambda 메모리 늘리기:
  • 메모리를 올리면 인스턴스의 사양(cpu)이 올라가 처리 속도 자체가 빨라질 수 있다고 한다.
  • but, 비용 고민: (메모리별 가격) * (요청이 처리되는 시간) * (요청 수)
  • 메모리가 올라가 요청이 처리되는 시간이 줄어들 수도 있고 그냥 메모리만 올라가면 음... 계산기 잘 두드려라
• lambda 컨테이너 재사용:
  • 한번 호출되고, 다음 호출이 5분 이내인 경우 그 후속 호출에 컨테이너 재사용
  • 자체적인 Warm Start 구성이라고 생각해도 될듯?
  • 여기서 꼼수를 쓰자.. 요청 없어도 5분마다 강제 실행을 시키는 것!
    • CW 활용, Route 53 HealthCheck를 람다 API Gateway Endpoint 설정 등...
    • but, 쓸데 없는 지출이 증가됨
  • 시간이 오래 걸리는 코드는 global로 선언하는 게 좋다
    • 재사용할 때 돌아가지 않도록!
    • 예를들면 db_connection과 같은 작업?

warm-cold-start-test func

let isWarmStart = false;

exports.handler = async () => {
  let message;
 
  if (isWarmStart) {
    message = "warm start";
  } else {
    message = "cold start";
    isWarmStart = true;
  }
 
  return {
    statusCode: 200,
    body: JSON.stringify({ message }),
  };
};

그냥 아주 단순한 코드.. global로 isWarmStart 변수 선언하고 handler 실행되면 true로 값 바꿈.

처음에 실행한 결과값

그 이후 두번째 실행한 결과값

 

일정 시간 뒤에 다시 실행해보면 cold start를 다시 출력할 것이다..

• Provisioned Concurrency:
  • AWS에서 Warm Start를 하게끔 도와준다.
  • but, 비용 발생
• Autoscaling with Provisioned Concurrency:
  • 트래픽이 급증하는 시간대에 맞춰 프로비저닝 오토스케일링 해라 - 방법이 어려움..
  • https://aws.amazon.com/ko/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/
  • https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency
  • https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/invocation-scaling.html
• 가장 이상적인 것!   "일정량의 요청, 꾸준히"
  • 꾸준히 일정량의 요청이 들어와 그 요청을 처리할 수 있는 컨테이너가 계속 떠있는 상황이라면  Cold Start 문제 최소화.. 근데 이게 특정 선을 넘어가면 EC2를 운영하는게 나을 수도...? 판단이 중요