TL;DR

  • 거의 전적으로 AWS Lambda로 구축된 제품의 검색 기능에서 메모리를 512MB에서 1,769MB로 늘려 콜드 스타트와 웜 호출 시간을 약 3.2배 단축함.
  • AWS Lambda는 메모리 할당량에 따라 CPU 성능도 달라지며, 1,769MB에서 1 vCPU에 해당하는 컴퓨팅 용량을 제공함.
  • 기존 설정인 512MB는 약 0.29 vCPU에 해당해, 함수가 웜 상태일 때도 CPU 부족 상태임을 보여줌.
  • 콜드 스타트 중앙값은 6,569ms에서 2,049ms, 웜 호출 중앙값은 577ms에서 181ms로 줄어듦.
  • 메모리와 컴퓨팅 자원이 결합된 구조에서는 메모리 증설이 낭비처럼 보일 수 있지만, 실행 시간이 짧아져 전체 비용이 오히려 낮아짐.

검색 기능의 콜드 스타트

  • 거의 전적으로 AWS Lambda로 구축된 제품의 검색 기능을 빠르게 개선하는 요청을 받음.
  • 해당 Lambda의 콜드 스타트는 약 7초로, 웹사이트에서 버튼을 누른 뒤 기다리기에는 긴 시간임.
  • 이 문제를 근본적으로 해결할 방법을 찾으려 했지만, 기존 기술적 장애물이 많아 적절한 해결책을 찾기 어려움.
  • 당시에는 Lambda를 프로비저닝할 때 CPU 용량을 직접 고르는 대신 메모리 용량을 선택하며, CPU가 더 필요하면 메모리를 더 할당해야 한다는 점을 알지 못함.

메모리 할당과 CPU 용량

  • Lambda에는 512MB가 할당돼 있었으며, AWS 기준으로 약 0.29 vCPU에 해당함. 이는 vCPU 컴퓨팅 용량의 3분의 1에도 못 미치는 수준임.
  • 1 vCPU를 제공하면 성능에 큰 영향을 줄 것이라는 막연한 예상이 있었으며, 이에 해당하는 메모리 할당량이 1,769MB임.
  • 메모리는 128MB부터 10,240MB까지 1MB 단위로 설정 가능함. 1,769MB에서는 함수가 1초마다 vCPU 1초분의 크레딧을 받는, 1 vCPU에 해당하는 컴퓨팅 용량을 제공함.
  • CPU, 네트워크 또는 메모리가 병목인 함수라면 메모리 설정을 높여 성능을 크게 개선할 수 있음.

Lambda 함수 메모리 설정

메모리 설정별 실행 시간

  • 배정된 메모리가 성능을 제한하는 주요 요인이었음을 측정 결과가 보여줌.
  • 메모리와 컴퓨팅 용량이 결합돼 있지 않았다면 이 Lambda는 128MB조차 필요하지 않았을 것임. 메모리를 더 할당하는 것은 낭비처럼 보이지만, 실행 시간이 짧아져 전체 비용은 오히려 낮아짐.
  • 메모리 증설 후 콜드 스타트와 웜 호출이 모두 약 3.2배 빨라져, 웜 상태에서도 Lambda의 CPU가 부족했음을 보여줌.
  • 기존 설계 문제로 인해 모든 측정값에 추가 오버헤드가 포함돼 있음.
  • 512MB
  • 콜드 호출: 최소 5,089ms, 중앙값 6,569ms, 최대 7,990ms
  • 웜 호출: 최소 498ms, 중앙값 577ms, 최대 2,168ms
  • 1,769MB
  • 콜드 호출: 최소 1,777ms, 중앙값 2,049ms, 최대 2,757ms
  • 웜 호출: 최소 161ms, 중앙값 181ms, 최대 289ms

각주: 마이그레이션과 기존 설계

  • 마이그레이션은 계획이 부실했고 이전 시스템과 같은 실수를 여러 차례 반복함. 애플리케이션을 처음부터 다시 구축할 수 있는 그린필드 접근 기회가 있었던 점을 고려하면 특히 실망스러운 결과임.
  • 레거시 코드와 아키텍처를 그대로 옮겨 여러 Lambda가 뒤섞인 구조를 만들었으며, 낮은 코드 품질과 단위 테스트 및 통합 테스트의 부재도 그대로 이어짐.
  • ASP.NET Core를 Lambda에서 그대로 사용할 수 있음에도, ASP.NET Core와 비슷한 맞춤형 의사 미들웨어 프레임워크를 만들기 위해 소스 생성기를 사용하는 등 불필요한 복잡성도 더해짐.
  • 따라서 기능 개선에는 Lambda 콜드 스타트뿐 아니라 추가된 오버헤드도 함께 다뤄야 하는 상황임.