EC2
Elastic Compute 라는 이름입니다. 소위 클라우드의 서버를 의미합니다. Bigdata에서 EC2는, 세가지 특성이 있습니다.
1. On demand, Spot & Reserved instances
사용 방식에 따라 세가지 특징이 있습니다.
- Spot: 손실을 감안하고, 저 비용으로 사용합니다. 머신러닝 등에서 체크포인트 방식으로 활용하면 이 방식이 좋습니다.
- Reserved: 장기간 클러스터, 데이터베이스를, 최소 1년이상 사용할 때 저렴하게 쓸 수 있습니다.
- On demand: 그 외에 모든 워크로드에 해당합니다. (돈이 가장 많이 듭니다.)
2. Auto Scaling(자동확장)
- EMR의 레버리지 등으로 활용합니다.
- 자동화된 DynamoDB, ASG 등의 사례가 있습니다.
3. EC2 is behind EMR
- 마스터 노드(Master Nodes)
- 콤퓨트 노드(Compute Nodes, 데이터를 포함) + Task Nodes (데이터 없음)
AWS Graviton
- 아마존 자체 프로세서 및 파워 패밀리, 여러 EC2 인스턴스 타입마다 목적이 있습니다.
| 목적 | 타입 |
| General purpose 일반 목적 | M7, T4 |
| Compute optimized 계산 최적화 | C6, C7 |
| Memory optimized 메모리 최적화 | R7, X2 |
| Storage optimized 스토리지 최적화 | lm4, ls4 |
| Accelerated computing 가속 계산 (게임 스트리밍, ML 추론) |
G5 |
- 최상의 가격 성능을 제공합니다.
- 데이터 엔지니어링 서비스에 옵션 제공 : MSK, RDS, MemoryDB, 엘라스틱캐시, 오픈서치, EMR, 람다, Fargate
Lambda
- 서버리스 데이터 처리에 적합한 도구 (다른 용도로도 사용 가능합니다.)
Lambda 정의
- "클라우드"에서 코드 스니펫 실행하는 방법:
1) 서버리스
2) 지속적인 스케일링(자동 확장/축소) - 데이터가 이동할 때 처리하는 데 자주 사용됩니다.
- 한 서비스에서 다른 서비스로 이동하면서 코드를 자동 실행.
- 빅데이터에서 활용하기 좋습니다.
예시
- 서버리스 웹사이트 만들기(고객 - API GW - Lambda - Cognito & DynamoDB)
- 진짜 다이나믹 웹사이트는 불가능하다. HTML, Ajax 정도로 운용되는 서버는 가능하다. 다룰 것은 Ajax 호출입니다. 시스템 내부로 보낸다.
- 로그인 요청을 API GW보내고, 람다로 보내어 그 로그인 요청을 Cognito에게 인증되었는지 확인하고 토큰을 받습니다. 이걸 다시 웹사이트로 보냅니다. 결국 API, Cognito의 백엔드를 맡습니다.
- 사용자 ID 채팅 기록을 보려면, DyanamoDB 채팅 히스토리를 보고 람다가 다시 웹사이트로 보냅니다.
- 이렇게 일종의 접착제 역할을 합니다.
- 주문 히스토리 앱(로그 - Kinesis Data Streams - Lambda - DynamoDB - 모바일 고객)
- 키네시스 데이터 스트림과 EC2 역할을 했었는데, 이제는 람다를 사용하면 됩니다.
- 람다는 트리거로 이벤트를 받고, 고객 데이터를 받아 DynamoDB에 적습니다.
- 트랜잭션 평점 알람(로그 - Kinesis Data Streams - Kinesis Data Analytics - Kinesis Data Streams - Lambda - SNS)
- 트랜잭션이 특정 조건을 만족시 알람을 전달하기만 하면 되는 경우가 있습니다.
- 트리거를 받아 람다가 휴대폰 메시지로 SNS을 통해 알림을 보냅니다.
왜 서버를 운영하지 않는거죠?
- 서버 관리(패치, 모니터링, HW 장애 등)
- 서버는 저렴하지만, 확장(scaling) 비용은 매우 빨리 비싸집니다.
- 사용하지 않는 프로세스 시간에 따른 비용 내고싶지 않아요. 비용 절감에서 좋다.
- 프론트와 백엔드 사이 개발을 분리하기 더 쉽습니다. 프론트는 정적인 작업을 람다 함수로 웹사이트에서 처리할 수도 있죠!
Lambda의 주 사용 사례
- 실시간 파일 프로세싱
- 실시간 스트림 프로세싱
- ETL(추출 변환 로드) 작업
- 크론 작업 대체(cron) : 크론 대신 람다로 트리거를 이용합니다. 언제든 람다 기능을 주기적으로 호출하게 합니다. 특정 작업의 시작에서 많이 씁니다.
- AWS 이벤트 프로세스 : 람다를 트리거로 생성해서 이벤트에 적용할 수 있습니다.
Lambda 지원 언어
- Node.js, Python, Java, C#, Go, Powershell, Ruby* 매우 다양한 언어를 지원합니다.
- 람다가 코드만 있다면, AWS 외 다른 서비스에도 적용할 수 있어요. 서버리스 상태로요!
람다 트리거
- 이벤트 트리거로 쓸 수 있는 다양한 서비스가 있습니다. 위에 제시된 거 외에도 다양합니다. 모두 API가 있다면 람다를 트리거로 활용할 수 있겠습니다.
사례1. Lambda & Amazon Opensearch Service
오픈서치를 엘라스틱 서치입니다. 오픈서치는 검색 엔진으로, 분석 도구로도 사용할 수 있습니다. 검색, 쿼리, 시각화 가능합니다. 로그 데이터를 입력하고, 그 로그 데이터를 시각화해서 에러 개수를 활용해봅니다. 다만, S3와 오픈서치를 직접 연결 못하므로, 람다를 넣습니다.
데이터가 들어오면, 람다가 데이터 처리를 위해 자동 트리거 됩니다. 람다, 새로운 데이터가 있다면, 변환하고 오픈서치에 맞게 구조화하고, 그 정보를 실시간으로 오픈서치에 전달합니다. 오픈 서치의 내장 기능으로 시각화 등이 가능합니다. 일종의 GLUE 역할을 할 수 있겠네요.
사례2. Lambda & Data Pipeline
데이터 파이프라인이 S3를 검사하기 위한 사전조건으로 스케줄링 할 수 있습니다. 그러나 Lambda가 이를 랜덤하게 활성화해야 합니다. 보통 데이터 파이프라인은 이걸 스케줄해서 전제조건으로 활용합니다. 보통 시작 전에 하면 되는데, 람다를 사용하면 언제든 가능합니다.
S3에 새 데이터오면 람다가 이를 알아차리고 데이터 들어올때마다 파이프라인을 생성합니다. 미리 정의된 스케줄이 필요없죠.
사례3. 람다 & Redshift
레드쉬프트로 데이터 로딩하는 방법은 COPY 커맨드입니다. 데이터 복사해서 레드쉬프트에 넣는 것입니다. s3가 새로운 데이터 받으면 람다를 트리거하고, 레드쉬프트로 보냅니다. 근데 람다는 상태비저장(stateless)방식이므로 중간에 이 놓친 것을 저장할 공간이 필요합니다. 이런 경우, 지속해서 저장을 위해 DynamoDB를 사용합니다. 즉, 무엇이 로드될 지를 추적하려면, DynamoDB를 사용합니다. Lambda는 COPY와 함께 새로운 데이터를 batch up하고, 로드할 수 있습니다.
사례4. Lambda + Kinesis
- 람다 코드는 stream 기록의 하나의 batch와 함께 이벤트를 받습니다. 최대 1만 레코드까지, 트리거를 설정할 때, 배치 사이즈를 구체화합니다. 너무 큰 배치 사이즈는 timeouts를 일으킬 수 있습니다. Batch는 또한, 람다의 페이로드 리밋(6MB)를 넘어서면 분리할 수 있씁니다. 람다가 15분 시간 제한과 payload 6MB 제한이 있다는 점을 고려해야겠습니다.
- 람다는 데이터가 만료되거나 성공될 때까지 batch를 재시도할 것입니다. 이는 에러를 적절히 다룰 수 없다면, shard에 넣을 수 있습니다. 에러로 인해 전체적으로 지연되지 않도록, 더 많은 shard를 사용하세요.
- 람다는 shard data를 동기화하여 처리합니다. (synchronous) 동기화된 데이터를 가지고 람다가 짧은 시간내에 통과되게 하세요.
Cost Model
- "사용한만큼 지불하세요."
- 일반 프리 티어 제한 (1M 요청량 / 매달, 400K GB-초당 계산 시간당)
- $0.2 / 백만 요청량
- $0.00001667 GB/초당 계산량 비용
Other Promises
- 고가용성: scheduled 다운타임 없음, 실패 코드 3번 재시도 가능.
- 무제한 확장성: 리전별로 1000개 동시 실행 안전 스로틀이 있습니다.
- 고성능
- 수초내 새로운 함수 호출 가능합니다.
- 밀리세컨드 내에서 이벤트 처리됩니다.
- 코드는 자동으로 캐싱됩니다.
- 그러나 timeout을 구체화해라! 이게 문제를 야기할 수 있습니다. 최대가 15분이에요.
Anti-patterns: 안쓰면 좋은 패턴
- 장기간 실행하는 어플리케이션: 이런것은 EC2를 쓰거나 체인 함수를 쓰세요.
- 다이나믹 웹사이트: 람다가 "서버리스"앱을 개발하는데 사용하지만, 클라이언트-사이드 AJAX를 의존합니다.
- Stateful 어플리케이션(상태저장): 이것은 DynamoDB, S3로 상태를 추적할 수 있겠습니다.
File Systems Mounting
- 람다 함수는 EFS 파일 시스템에 접근할 수 있습니다. VPC 내 실행한다면요.
- 람다는 초기화동안 로컬 디렉토리로 EFS 파일 시스템을 마운트하기 위한 환경설정을 합니다.
- EFS AP(접근 포인트)를 레버리지 해야만 합니다.
- 한계점: EFS 연결 리밋(단일 함수 인스턴스 = 한번의 커넥션)을 유의하고, connection 버스트 리밋도 유의합시다.
- 너무 많이 만들면 버스트 리밋에도 걸리겠네요.
Lambda - Storage Options
AWS Lambda, S3, EFS 등의 스토리지 옵션에 대한 특징을 비교했습니다. 임시 저장소는 진짜 임시에요. 모종의 이유로 람다가 중단되면 사라지겠네요. 가장 빠른 데이터 검색이 가능합니다. 별도 공유는 안되어요.
람다 레이어는 5개, 최대 250MB를 가집니다. 적절한 허가가 있어야 합니다. 데이터 접근 속도는 굉장히 빠르고, 모든 람다 호출에 공유되지만, 람다 레이어에서 데이터 수정은 안됩니다.
S3는 durable하고 동적입니다. 다만 가격이 비쌉니다. IAM의 적절한 권한도 필요하고, 네트워크 속도에 따라 다르지만, 전반적으로 빠른 편이지만, 완전히 빠르지는 않습니다.
EFS는 빠르고 좋지만, 매우 비쌉니다. 전송비용에 저장비용, throughput 모두 부과됩니다. 네트워크를 바탕으로 모든 람다의 호출을 바탕으로 공유될 수 있습니다.
Lambda의 다양한 연동 가능한 스토리지를 비교해보았습니다. 람다 레이어, 임시 저장소 정도는 생소할 수 있네요. 각 유형별 특징을 눈으로 익혀봅시다.
'AWS' 카테고리의 다른 글
| [AWS] Compute: SAM, Batch (2) (1) | 2024.09.19 |
|---|---|
| [AWS] Lambda를 활용한 요금 SNS 서비스 구축하기 핸즈온 리뷰 (0) | 2023.11.27 |