콜드 스타트란?

서버리스 컴퓨팅의 맥락에서 "콜드 스타트"는 오랫동안 호출되지 않은 후 함수가 처음으로 처리를 시작하는 데 걸리는 시간 또는 대기 시간을 말합니다. 예를 들어, 컴퓨터를 끄고 켠 후에는 최적의 성능을 발휘하는 데 시간이 걸릴 수 있습니다.

콜드 스타트는 서버리스 아키텍처를 시작하는 모든 사람에게 기본적입니다. 특히 가능한 가장 짧은 시간 내에 타임아웃 기간을 충족해야 하는 상호 작용과 관련하여 애플리케이션의 성능과 유용성에 영향을 미칩니다.

콜드 스타트는 다음과 같은 상황에서 발생합니다.

• 첫 번째 호출: 두 가지 경우가 있습니다. 첫 번째는 애플리케이션 배포 후 또는 코드 업데이트 후 처음으로 함수가 호출되는 경우입니다.
• 확장성 0에서: 함수가 발생하지 않고 잠시 작동하지 않은 후 호출을 받는 경우입니다.
• 리소스 재할당: 클라우드 공급자가 리소스를 재할당합니다. 또는 함수의 기본값이 다른 호스트로 변경되면 콜드 함수 인스턴스가 발생할 수 있습니다.
• 시간 초과 또는 만료: 함수 인스턴스가 최대 실행 시간에 도달하거나 유휴 시간을 초과하면 종료될 수 있습니다. 다시 호출되면 새로 시작된다는 의미입니다.

콜드 스타트와 관련된 주요 과제는 추가적인 지연 시간입니다. 이 지연 시간은 다음과 같은 형태로 관찰할 수 있습니다.

• 지연된 응답: 일반적으로 앱이 신속하게 답변을 제공하지만, 사용자는 가끔 경험에 영향을 미칠 수 있는 지연을 겪을 수 있습니다.
• 저하된 처리량: 콜드 스타트는 특히 사용량이 많은 기간 동안 동시 요청을 처리하는 애플리케이션의 기능을 점진적으로 늘릴 필요가 있을 수 있습니다.
• 성능 차이: 콜드 스타트 지속 시간이 시간이 지남에 따라 변화하는 정도는 애플리케이션 효율성에 영향을 미쳐 응답 시간을 간소화하고 일관성을 강화할 가능성을 제시합니다.

Lambda 콜드 스타트의 지속 시간은 다음과 같은 다양한 요인에 따라 달라질 수 있습니다.

• 함수 크기 및 종속성: 함수가 클수록 관련된 종속성이 많아지고 일반적인 콜드 스타트에 걸리는 시간이 길어집니다.
• 런타임 환경: 초기 런타임 환경(예: Node.js, Python, Java 등)은 초기화 및 로딩 프로세스의 차이로 인해 콜드 스타트 시간과 같은 요인을 필연적으로 결정합니다.
• 클라우드 공급자 최적화: 시간이 지남에 따라 클라우드 공급자는 콜드 스타트 시간을 최대한 줄이기 위한 최적화를 지속적으로 제공하지만, 이는 고정되거나 예측 가능하지 않습니다.

전반적으로 Lambda의 콜드 스타트는 0.5초에서 몇 초 사이에서 달라질 수 있습니다. 따라서 정확한 데이터를 얻고 콜드 스타트 지속 시간이 함수와 환경의 요구 사항을 어떻게 반영하는지 관찰하여 정확한 통찰력을 얻으십시오.

다음은 Lambda의 콜드 스타트를 줄이거나 적어도 처리할 수 있는 몇 가지 방법입니다.

• 함수 최적화:
  • 사용하지 않는 코드와 종속성을 삭제하여 함수 크기 줄이기
  • 초기화 중 로드된 코드 양 줄이기 위해 트리 셰이킹 또는 코드 분할 방법 사용
  • 패키지 배포 및 패키지 종속성 해결 워크플로 개선

• 프로비저닝된 동시성:

프로비저닝된 동시성 구성하여 특정 수의 함수 인스턴스를 활성 상태로 유지하여 들어오는 요청으로 인해 해당 인스턴스에 콜드 스타트가 발생하지 않도록 함

• 워밍업 요청:

실제 사용자 요청이 도착했을 때 함수가 워밍업되도록 가끔 가짜 요청을 보내야 합니다.

• 비동기 처리:

중요하지 않은 작업의 경우, 다른 비동기 패턴을 도입하여 함수에서 사용자 요청을 리팩토링하는 것이 더 나을 수 있습니다. 이렇게 하면 콜드 스타트의 영향을 최소화할 수 있습니다.

• 캐싱:

자주 액세스하는 데이터나 사전 계산된 결과를 저장하는 적절한 캐싱 메커니즘을 도입하여 함수 호출 횟수를 줄이고 콜드 스타트 발생 횟수를 줄입니다.