서버리스 컴퓨팅의 한계와 전환: 서버리스는 미래가 아니었다

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

• 개발자 및 DevOps 엔지니어
• 서버리스 아키텍처를 도입 중인 팀
• 난이도: 중간 (서버리스의 한계와 전환 전략을 이해해야 함)

핵심 요약

• 서버리스는 전용 도구로 한정된 사용 사례에서만 효과적
• FaaS (Function-as-a-Service)는 비동기 처리, 웹훅, 배치 작업 등에 적합하지만, 데이터베이스 연동, 상태 관리, 장기 실행 로직은 비효율적
• Deno의 전략 변화: 전역 서버리스 배포 축소 → 지역 고정 및 장기 실행 프로세스 지원
• KV 저장소, Durable Objects, 배경 작업 추가로 컨테이너와 유사한 기능 제공
• 서버리스의 주요 한계: 쿨 스타트, 메모리 제한, 플랫폼 종속성
• Cloudflare Workers의 Node.js 호환성 문제 등 디버깅 어려움 발생

섹션별 세부 요약

1. 서버리스의 기존 비전과 현실

• 기존 서버리스의 핵심 주장:
• "인프라 관리 없이 함수 배포 → 플랫폼이 스케일링"
• AWS Lambda, Vercel, Cloudflare Workers 등으로 확산
• 현실 문제:
• 장기 실행 로직, 데이터베이스 연동, 상태 관리 시 쿨 스타트, 지연, 복잡한 워크어라운드 발생
• 대부분의 앱은 단일 지역에 고정된 데이터베이스 사용 → 글로벌 배포 효용성 부족

2. Deno의 전략 변경 사례

• Deno Deploy의 글로벌 지역 축소:
• 35개 지역 → 6개 지역으로 축소, 성능 개선
• 엣지 컴퓨팅의 한계로 인한 결정 (데이터베이스 사용 시 지역 고정 필요)
• 새로운 기능 추가:
• 지역 고정 (Region Pinning)
• KV 저장소, Durable Objects, 배경 작업, 캐싱, 빌드 파이프라인
• 컨테이너와 유사한 기능 재구성

3. 서버리스의 한계와 플랫폼 종속성

• 기본적인 FaaS 한계:
• 실행 시간, 메모리, 동시성 제한
• 쿨 스타트 (Cold Start)로 인한 첫 요청 지연
• Node.js 호환성 문제 (Cloudflare Workers)
• 플랫폼 종속성 (Vendor Lock-in):
• Cloudflare (KV, Durable Objects), Deno (지속적 컴퓨팅), Vercel (Fluid Compute) 등 프로피리터리 서비스
• 오픈 소스 기술이지만, 인프라 확장성은 플랫폼에 종속

4. 서버리스의 적절한 사용 사례

• 서버리스가 효과적인 경우:
• 무상태 엣지 컴퓨팅 (Stateless Edge Compute)
• 빠른 API, 스케줄링 작업, 배경 작업
• 서버리스가 적합하지 않은 경우:
• 데이터베이스 연동, 상태 관리, 장기 실행 로직
• 전역 배포가 필요한 앱
• 예시: UserJot은 서버리스로 엣지 로직 처리 → 주요 기능은 컨테이너로 구현

결론

• 서버리스는 전용 도구로 한정된 사용 사례에만 활용
• 비동기 처리, 웹훅, 배치 작업 등에 적합하며, 앱 개발에는 컨테이너 또는 단일 지역 인프라 사용 권장
• 플랫폼 종속성과 한계를 고려하여, 서버리스는 FaaS 모델의 한계를 인식하고 전략적으로 사용해야 함
• "서버리스는 기초가 아닌 도구" → 사용 시점과 범위를 명확히 정의