서론
간단하게 서버리스 컴퓨팅을 사용할 일이 생겨서 생겨서 클라우드플레어 워커를 사용해봤습니다. 다른 서버리스 서비스와 비교했을 때 차이점과 클라우드플레어 워커의 특징에 대해 알아보겠습니다.
서버리스(serverless)란?
먼저 서버리스는 물리 서버가 존재 하지 않아서 붙여진 이름이 아닌 '서버를 관리할 필요가 없어서' 서버리스 라고 불립니다. 서버를 관리하는 것을 클라우드 제공 업체에 맡기고, 사용한 만큼만 비용을 지불하는 방식입니다. 서버를 관리할 필요가 없기 때문에 개발자는 비지니스 로직에만 집중할 수 있습니다.
따라서 개발자는 원하는 함수를 작성하고 원할 때만 실행할 수 있습니다.
서버리스를 사용하는 이유는 함수를 특정 상황에 실행할 수 있다는 것에 있습니다. 서버를 띄우지 않아서 비용이 절약되고 유지보수할 필요가 없습니다. 또한 배포도 서버리스 서비스 업체에서 해주기 때문에 개발자는 배포에 신경쓸 필요가 없습니다. cron이나 트리거를 사용해서 특정 시간에 함수를 실행할 수 있습니다.
cloudflare를 선택한 이유
일반적인 사용자에게는 두 회사 모두 널널하고 무료 범위를 넘기가 어렵습니다. 각 회사의 대표적인 장점은 다음과 같습니다.
- AWS: 세분화된 함수 스펙
- Cloudflare: 추과 과금 방지
과거에는 AWS가 시간 측정을 할 때 100ms 단위로 올림을 했었습니다. 하지만 최근에는 1ms로 반올림해서 측정하게 변해서 그나마 있던 Cloudflare의 장점이 사라졌습니다.
따라서 현재는 Lambda가 더 좋은 선택이지만 개인적으로 Cloudflare를 애정하고 응원하기 때문에 Wokers를 사용하게 됐습니다.
그래도 특정 상황에서는 Workers를 사용하는게 좋은 선택일 수 있습니다.
Workers VS Lambda
워커랑 람다를 일대일 대응을 할 수 없지만 비교해보겠습니다.
- 무료 사용량
항목 Workers Lambda 무료 호출 횟수 10만/일 1백만/월 무료 컴퓨팅 시간 10ms cpu time/실행 400,000GB-초/월
호출 횟수는 워커가 월로 환산하면 약 3배가량 많습니다. 컴퓨팅 시간을 비교하려면 단위를 정확히 알아야 하는데 그러기 위해서 구체적인 스펙을 알아야 합니다.
자세히 비교 하면 끝도 없어서 대표적으로 이런 차이가 있습니다.
- 상세 스펙
항목 Workers Lambda Language JavaScript, TypeScript, Python, Rust Java, Go, PowerShell, Node.js, C#, Python, Ruby CPU time 10ms(무료), 30초, 15분(cron, queue) 측정 X Duration(wall-clock time) 무제한 15분 Memory 128MB 128MB ~ 50GB 전 세계 배포 기본 @Edge 사용
Lambda의 Free Tier로 비교 해보겠습니다.
Lambda@Edge는 유료이므로 제외 하겠습니다. 최소 메모리인 128MB로 비교하면 3.2초가 걸리는 함수를 1백만번 호출할 수 있습니다. 호출 횟수/10회로 줄이면 실행시간*10초 까지를 무료로 실행할 수 있습니다.
결론적으로 Free Tier에서는 많은 메모리가 필요로 하면 Lambda가 더 좋은 선택이 됩니다. 하지만 무료 Edge server배포가 필요하면 Workers가 더 좋은 선택이 됩니다.
CPU time과 Duration(wall-clock time)
눈여겨 볼만한 점은 실행 시간을 측정하는 방식 입니다. 클라우드플레어에서는 CPU time과 wall-clock time이라는 개념을 도입합니다. 공식 블로그인 New Workers pricing에서 자세한 설명이 나옵니다.
대부분의 애플리케이션은 CPU를 사용하는것 보다 I/O를 대기하는데 더 많은 시간을 사용합니다. 그래서 cloudflare는 CPU time에만 비용을 부과하고, Duration(wall-clock time)에 비용을 부과하는 것을 숨은 비용이라고 칭합니다.
마치 택시를 탔는데 택시에 기름을 넣고 밥을 먹기 위해서 멈췄지만 미터기는 계속 작동하는것과 같습니다. 이처럼 목표를 향해 다가가지 않는 동안에도 비용을 지불하고 있는것 입니다. 이제 운전자가 기름을 넣는 동안 미터기가 일시 중지되었다고 상상해 봅시다. 이것이 바로 CPU time과 wall clock time의 차이입니다.
과금 범위 비교
- 10억 requests/월
- 7ms CPU time/request
- 200ms duration/request
콜드 스타트
일반적인 서버리스 환경에서는 콜드 스타드가 발생합니다. 콜드 스타트란 함수가 처음 실행될 때 초기화 시간이 발생하는 것을 말합니다.
- (cold)내부 S3 버킷에 저정된 함수 다운
- (cold)지정된 메모리, 런타임 및 구성을 사용하는 환경 생성
- (duration)핸들러 외부 초기화 코드 실행
- (durtaion)핸들러 코드 실행
콜드 스타트가 발생한 이후 실행 환경을 반환하기 전에 함수가 다시 실행된다면 콜드 스타트가 발생하지 않습니다. 이를 웜 스타트라고 합니다.
하지만 언젠가는 실행 환경이 삭제되기 때문에 콜드 스타트를 피할 수 없고, 이를 최소화하기 위해 다양한 전략이 있습니다.
자세한 내용은 aws 람다 실행 환경을 참고하세요
워커의 콜드 스타트(?)
반면 워커는 콜드 스타트가 발생하지 않습니다. Workers는 Chrome V8에서 직접 실행되며 spin-up(콜드 스타트) 시간이 5ms 미만입니다.
그리고 핸드셰이크 시간동안 진행되므로 이론상 콜드 스타트가 발생하지 않습니다.
또한 CloudFlare는 CDN서비스를 중점으로 해서 더 많은 Edge서버를 가지고 있습니다. 따라서 전 세계 범위에서 빠른 응답을 기대할 수 있습니다.
참고 자료: Workers로 콜드 스타트 제거, 서버리스 컴퓨팅 성능을 향상 하는 방법
Workers의 단점
V8 엔진의 제한
V8엔진이 콜드 스타트를 최소화 하지만 개발 언어가 제한됩니다. JS와 TS정도만 멀쩡히 사용 가능하고, WebAssembly를 지원하는 Python과 Rust는 사용은 가능하지만 번거롭습니다.
외부 라이브러리를 사용하는 것도 제한적입니다. 예를 들어 express를 사용할 수 없어서 hono나 itty-router를 사용해야 합니다.
제한적인 서비스
Workers가 사용할 수 있는 CloudFlare의 서비스도 아쉽습니다.
key-value 스토리지인 KV, SQLite를 사용하는 D1, 버킷 스토리지인 R2등 있을건 있지만 AWS의 서비스에 비하면 제한적입니다.
로깅과 모니터링
Workers에서 불가능한건 아니지만 추가 설정이 필요하고, AWS의 CloudWatch에 비교하면 불편합니다.
결론
각 서비스의 장점을 요약하면 다음과 같습니다.
- AWS Lambda
- 128MB를 초과하는 메모리 사용
- 다양한 언어 사용
- 10ms를 초과하는 CPU time을 무료로 사용
- Cloudflare Workers
- 무료 Edge server 배포
- I/O 작업이 많은 경우
- 콜드 스타트를 피하고 싶은 경우
- Duration이 15분 초과(제한적)
- 혹시 모를 과금 방지
Workers를 추천하려고 적은 글이지만, 대부분의 상황에서 Lambda가 더 좋은 선택인것 같습니다.
하지만 Cloudflare를 응원하고 Workers의 발전이 기대가 된다면 Workers를 사용해보는게 어떨까요??