AWS - Lambda 성능 개선 및 개념 정리 (동작원리/ColdStart..)
기존 서비스 중에 이미지를 AWS S3 저장소를 이용하였는데 업로드하는 과정에서 이미지 변환 작업이 추가로 필요하게 되어 람다의 S3를 트리거로 등록하여 구성을 하려다 성능상 이슈가 존재하여 람다를 사용할 때 성능적 이슈를 해결하기 위한 방법과 람다의 기본 동작 원리에 대해서 정리한다.
AWS - Lambda 성능 개선 및 개념 정리 (동작원리/ColdStart..)
Cold Start
람다 함수는 서버리스로 항상 활성화 되어 있는 상태가 아니다. 최초의 람다함수로 요청이 들어오게되면 람다함수를 실행시키기 위해 부수적인 설정들이 필요하게 되는데 이 과정에서 적게는 x초 ~ 수십초까지의 딜레이가 발생한다.
이러한 현상을 'Cold Start' 라고 부른다.
이런 점이 람다의 최대 단점으로도 꼽힌다. 이렇게 딜레이가 발생하면 응답을 그만큼 늦게 제공받기 때문이다.
이러한 현상을 개선 할 수 있는 방법에 대해서 정리한다.
메모리 UP
먼저 가장 간단히 생각해볼수 있는 방법 중 사양을 높이는 것이다. 람다에서는 메모리의 크기를 설정할 수 있으며, 메모리 크기를 늘리게되면 람다 인스턴스의 사양이 올라가 처리 속도 자체가 높아질 수 있다.
메모리를 늘리는 방법은 람다의 접속하여 구성 탭 -> 일반 구성 탭 -> 편집을 눌러 메모리에서 설정을 할 수 있다.
메모리 설정은 128MB ~ 10240MB (약 10기가)까지 설정이 가능하다.
하지만 뭐든지 무조건 사양을 높이거나 아니면 사양을 높여도 성능 문제가 생길 수 있으니 다른 방법도 알아본다.
컨테이너 재사용하기 (성능 개선)
처음에 Cold Start 에 대해서 정리할 때 람다함수를 실행하기 위해 부수적인 설정들을 하는 과정에서 생기는 시간 딜레이라고 했다.
최초에는 설정이 안되어 있기 때문에 최초 한번은 이러한 설정들을 할 수 밖에 없지만 람다의 특성상으로 한번 호출이 되고 다음 호출이 5분 이내에 동일한 함수가 호출이 된다면 람다는 기존 컨테이너를 재사용하여 함수를 실행하게 된다.
이는 Cold Start 시간을 줄여 성능을 개선 시킬 수 있다.
여기서 이러한 Cold Start 시간을 줄이기 위해서 5분마다 람다에 요청을 보내 Cold Start가 되는 상황을 만들지 않을 수도 있다. 해당 방법으로는 CloudWatch를 통해 5분마다 람다를 호출하거나 Route53의 HealthCheck를 이용하는 방법이 있다.
하지만 이러한 호출도 다 비용이기 때문에 상황에 맞게 사용해야 된다.
참고로 컨테이너 재사용에 대한 제한시간 5분은 람다 서비스의 고정 설정이기 때문에 변경이 불가능하다.
람다 비용
위에서 비용 얘기가 나와 람다의 과금 방식에 대해서 알아본다.
람다의 과금 방식은 다음과 같다.
메모리 별 가격 x 요청 처리 시간 x 요청 수
여기서 알아볼 수 있는건 메모리를 올리게 되면 비용이 늘어날 것이다. 하지만 메모리를 올려 성능이 좋아지게 되면 요청 처리 시간이 낮아지게 되어 비용이 감소 할수도 있다.
이런 현상이 나타나는 이유는 람다의 메모리를 늘릴수록 CPU의 성능도 향상되는 구조를 갖고 있기 때문이다.
정확한 비용 계산은 아래 AWS 람다 요금을 확인하기 바란다.
https://aws.amazon.com/ko/lambda/pricing/
서버리스 컴퓨팅 – AWS Lambda 요금 – Amazon Web Services
aws.amazon.com
AWS 람다 동작 원리
이제 마지막으로 람다의 동작 원리에 대해 알아본다.
보통은 동작원리 같은 개념은 초반에 나오지만 앞에서 알아보면 Cold Start, 컨테이너 재사용의 개념을 알고나서 보게 되면 이해가 훨씬 쉬어서 순서를 이렇게 잡았다.
먼저 람다함수의 동작 과정은 다음과 같다.
1. Download your code - 첫번째 동작으로 람다 핸들러가 실행될 AWS 내부 인스턴스에서 작성한 코드를 다운로드 하는 단계이다. 지정된 스토리지 위치에서 코드 패키지를 다운로드한다.
2. Start new execution environment - 새로운 execution environmet를 생성하는 단계이다. 이때 람다 핸들러가 실행될 환경에 필요한 지정된 크기의 메모리, CPU 및 기타 리소스 등을 구성하게 된다.
3. Execute initialization code - 람다 핸들러 바깥의 전역 코드를 실행하는 단계이다.
4. Execute handler code - 람다 핸들러의 내부 함수 코드를 실행하는 단계이다.
다음 위에 동작 과정의 이미지와 동작 과정의 설명을 보게 되면 느낌이 오는 것이 있을 것이다.
바로 1~3 단계 까지가 위에서 알아보았던 'Cold Start'의 과정이다. 그리고 마지막 단계인 4번째 단계를 'Warm Start'라고 부른다.
마지막으로 람다를 구성할 때 런타임 설정을 하게 되는데 런타임 설정에 따라서도 'Cold Start'의 시간이 달라질 수 있다.
Java 런타임을 Node.js나 Python에 비해 더 큰 메모리 공간과 더 복잡한 클래스 로딩 프로세스로 인해서 초기화에 더 많은 시간이 발생되어 Cold Start 시간이 더 길어질 수 있다.