AWS Lambda란? 람다의 적용 판단 기준
AWS Lambda란
서버리스 컴퓨팅 서비스
서버리스 = 개발자가 서버를 관리할 필요가 없음(클라우드가 서버 관리) -> 코드에만 집중
서버리스란?
서버리스 아키텍쳐 = 서버를 직접 관리할 필요가 없는 아키텍처
람다의 특징
이벤트 기반으로 즉시 실행 (단일 함수가 간단한 작업을 수행)
이벤트 구독하여 비동기적으로 실행 가능
람다의 동작 방식
- 이벤트 트리거
- 실행 환경 구축
- cold start or 활성화 인스턴스 재사용 :
- 함수 코드 실행
- 이벤트 처리
함수 호출 -> 새로운 컨테이터 생성 -> (계속 요청) 컨테이너 재사용 -> (5분 요청 끊기면) 컨테이너 초기화
즉 하나의 기능(함수)만 들어있는 컨테이너를 생성
Lambda 장점
사용한만큼만 돈을 냄 (비용저럼 하여 절감)
자동 스케일업, 높은 가용성
서버 관리 없이, 코드 개발만 가능
Lambda 단점
cold start : 람다가 깰때 최대 지연시간 1s -> 실시간 서비스에 적합하지 않음
서버 제공자에 의존(aws)
긴시간을 소요하는 작업에 불리
코드 재사용이 어려움 / 상태 비저장 : 이벤트로 트리거 될때마다 새로운 환경에서 호출 -> 새로운 컨테이너 띄우는 방식
람다 적용에 유리한 서비스
이벤트 기반(트리거)
메시지 큐에 쌓인 메시지 처리 작업
로그 데이터의 실시간 처리
Lambda 적용 판단 기준
실행주기 | 짧은 주기에 적합 하나의 이벤트에 실행 후 인스턴스 소멸 |
적합 |
트래픽/부하 | 이벤트에 응답해 자동으로 확장 | 적합 |
비용 구조 | 실행된 코드에 대한 요금 적용 실행시간/메모리/초당실행횟수/데이터 전송비용/coldstart 발생 |
확인필요 피크시간/아닌시간 |
cold start 영향 | 최초 실행시 지연시간 첫 실행(새 인스턴스 생성) 람다 계속 실행시 재사용 -> 멈추는 경우 발 |
부적합/확인필요 |
코드 크기 / 제약사항 | 함수 크기/실행시간에 제한 | 적합 |
자동확장 | 자동 확장 가능. 중요한 요소인 | 적합 |
로그 모니터링 | 기존과 다름 aws cloudwatch logs로 관리 |
- |
설계 / 개발 경험 | 기존 개발 프로세스와 다름 | - |
EC2보다 Lambda가 유리한 경우
- 서비스 특성 (람다:간단한 단일 함수, EC2:특정 인스턴스가 전체 서비스 담당)
- 트래픽 패턴 (람다:불규칙하고 짧은 실행시간 , EC2:안정적이고 지속적인 트래픽)
- 리소스 사용 (람다: 함수 사용에 필요한 리소스만 사용 , EC2:지속적으로 설정한 리소스 사용)
- 비용 (람다:초당 실행시간=>짧은 실행시간&불규칙한 트래픽에 효과 , EC2:일정한 예약, 사용량에 따라 비용 발생)
결론
단순한 로직이라 람다에 적합할 것이라 생각
장점 : 서버리스, 자동 스케일업, 비용절감, 이벤트 드리븐 아키
치명적인 cold start 단점: 첫 시작시 1초 지연 가능
따라서 비용 구조 / cold start 영향도 확인 필요
peak시간 : 자동확장
아닐때 : 비용 최적화(절감)
EC2에 비해 비쌈. 온디맨드 적용시 더 비쌈 -> 하지만 원래 서버는 가용률보다 높게 운영해서, 쓴만큼만 지불
단, peak로 올라갈때 cold start 발생
인스턴스 미리 늘리기 가능 (온디맨드로 인스턴스 수 설정 -> 콜드 스타트 없이 즉시 실행)