개요
개발과 운영의 현대화
- MSA 아키텍처
- 서버리스 운영 모델
- 애자일한 개발 프로세스
서버리스 애플리케이션
- 서비스를 제공받으면서 서버 인스턴스를 관리할 필요가 없음
AWS Lambda
- 서버없이 이벤트 발생시 작성한 코드(함수)가 실행되는 대표적인 서버리스 컴퓨팅 서비스
- 코드를 실행할 때 사용할 메모리용량'만' 지정
- 사용사례: 로그분석, 배치서버 등
Lambda 실행모델
트리거 방식
- 동기- Amazon Api Gateway
- 비동기 - AmazonSNS, S3
- 스트림 , DynamoDB, Kinesis 등
Lambda 특징
- 컨테이너 이미지 지원- 대규모 애플리케이션(최대 10GB) 배포가능
- 최대 10GB 메모리 프로비저닝 (coumpute 성능)→ 집약적 워크로드 활용 가능
- 함수 결제 기간 단위 1ms 로 축소→ 비용측정시 고려
- function URL - 서비스에 대한 퍼블릭 엔드포인트를 제공하여 API Gateway 없이도 람다 호출 가능
AWS Lambda 내부
(동기방식 위주)
- Frontend - iam 인증 필요, 샌드박스(실행환경) 할당 요청
- Worker manager - 샌드박스 생성 요청
- Placement - 샌드박스 배치
- 콜드 스타트 - 최초의 상태에서 동작, 시간 간격이 생김
- 웜 스타트 - worker가 동작하고 있는 상태에서
일반적 아키텍처
- 동기식API(API Gateway)
- 관계형 데이터베이스(RDS)
- Lambda에서 다양한 로직
→ Problems: DB부하 가능, 실행시간에 ㄸ른 비용증가, 타임아웃(API Gateway:29초, 람다 : 15분) , 스로틀링 오류 발생 가능
Lambda 스로틀링
- 동시성에 의해, 람다가 트래픽을 처리를 하지 못하는경우 (403 Error)
- 동시성 : 주어진 시간에 요청을 처리하는 인스턴스의 수
- 동시성 계산방법: 평균 함수 실행 시간 (초) * 평균 요청/초
- 컨텍스트 재사용으로인해, 동시성이 RPS와 매핑되지는 않음
- 동시성을 줄이기 위해서는 실행시간을 줄여야함
- conclusion: 람다 최적화 필요
Lambda 스케일링
- 버스트 한도← 초기 트래픽 급증시 사용(기본은 동시성한도)
- 버스트한도 500-3000: 리전마다 상이
- 1분마다 500개 확장
- Provisioned Concurrency Scaling
AWS Lambda 최적화
- 람다에서 많은 로직을 수행하는것을 지양 → 패키지사이즈를 최소화(실행시간 최소화)
- Step Functions 사용(Async)→ 코드 외부에서 오케스트레이션 유지 , 많은 서비스와 통합 가능
- 실행 컨텍스트 재사용 활용
- 스로틀링에 대비
Amazon RDS Proxy
- DB 연결 풀링 하는 완전관리형
- AWS Secrets Manager 와 IAM 을 통한 보안
AWS API Gateway
- Rest API( 서버-클라이언트 아키텍처, Stateless) 기반 서비스
- 단일 EndPoint , 라우팅, 사용자 인증 제공 + 캐싱, 로깅
- 개발에 시간/비용을 줄일 수 있음
Endpoint
- Edge-Optimized EndPoint
- Regional EndPoint
- Private EndPoint
Protocol
- RESTful APIs
- WebSocket APIs
모범사례
- 액세스 로그 활성화
- RPS에 따른 람다 프로비전 구성
- RDS proxy로 DB 커넥션 관리
- 람다 Insights 사용 가능
워크샵 데모
https://bit.ly/aws-serverless-applications
Module 1.나의 첫 AWS Lambda
Amazon S3 에 파일이 업로드 되는 이벤트 가 발생하면 Amazon SNS 를 통해 사용자에게 email 로 알람을 전송
결과)
Module 2.REST API 기반 서버리스 애플리케이션
Amazon API Gateway 와 AWS Lambda 뿐만 아니라 Amazon RDS 를 연결
Module 3.서버리스 애플리케이션의 DB 사용 경험 개선
AWS Secrets Manager 와 Amazon RDS Proxy 를 활용
