1 서버리스
클라우드 제공자의 주요 트렌드 중 하나인 서버리스는 개발자와 데이터 엔지니어가 뒤에서 서버를 관리하지 않고 애플리케이션을 실행할 수 있게 한다.
1.1 서버리스의 스펙트럼
서버리스는 AWS Lambda(FaaS) 이전부터 존재했다. BigQuery는 데이터 엔지니어가 백엔드 인프라를 관리하지 않고, 시스템이 제로에서 대규모 쿼리까지 자동 확장하는 서버리스 시스템이다. 쿼리가 소비하는 데이터량과 스토리지 비용만 지불한다.
| 서버리스 유형 | 특성 | 예시 |
|---|---|---|
| FaaS (Function as a Service) | 이벤트 기반 코드 실행, 필요 시에만 실행 | AWS Lambda, Google Cloud Functions |
| 서버리스 DB/분석 | 백엔드 인프라 관리 불필요, 자동 확장 | BigQuery, Aurora Serverless |
| 서버리스 컨테이너 | 컨테이너를 클러스터 관리 없이 실행 | AWS Fargate, Google App Engine |
| 컨테이너화된 함수 플랫폼 | 이벤트 트리거 컨테이너, Lambda보다 유연한 런타임 | OpenFaaS, Knative, Google Cloud Run |
1.2 서버리스의 비용 함정
서버리스 함수는 매우 편리하지만 잠재적으로 비쌀 수 있다. 적은 이벤트를 처리할 때 비용이 낮지만, 이벤트 수가 증가하면 비용이 급증한다. 이것은 서프라이즈 클라우드 청구서의 빈번한 원인이다.
높은 이벤트 빈도에서 함수 호출당 하나의 이벤트를 처리하는 것은 재앙적으로 비싸질 수 있다. 특히 멀티스레딩이나 멀티프로세싱 같은 더 단순한 접근법이 훌륭한 대안일 때 그렇다.
교재의 조언: 모니터링하고 모델링하라.
| 활동 | 목적 |
|---|---|
| 모니터링 | 실제 환경에서 이벤트당 비용과 최대 실행 시간 파악 |
| 모델링 | 이벤트당 비용으로 전체 비용을 이벤트 빈도 증가에 따라 예측 |
| 최악의 시나리오 | 봇 스웜이나 DDoS 공격 시 비용 시뮬레이션 |
2 컨테이너
서버리스, 마이크로서비스와 함께 컨테이너는 현재 가장 강력한 운영 기술 트렌드 중 하나이다.
컨테이너는 격리된 사용자 공간(파일시스템과 프로세스)을 패키징한다. 전통적 VM이 전체 운영체제를 감싸는 반면, 많은 컨테이너가 단일 호스트 OS 위에 공존할 수 있다. 가상화의 주요 이점(의존성과 코드 격리)을 전체 OS 커널의 오버헤드 없이 제공한다.
컨테이너와 Kubernetes의 관계: Kubernetes는 일종의 서버리스 환경이다. 개발자와 운영 팀이 배포되는 머신의 세부사항을 걱정하지 않고 마이크로서비스를 배포할 수 있게 한다.
컨테이너 클러스터는 완전한 VM과 동일한 수준의 보안과 격리를 제공하지 않는다. 컨테이너 탈출(container escape) — 컨테이너 내 코드가 OS 수준에서 컨테이너 외부의 권한을 얻는 익스플로잇 — 은 멀티테넌시에 대한 위험으로 간주될 만큼 흔하다. Kubernetes 클러스터는 상호 신뢰 환경(예: 단일 회사 내부)에서만 코드를 호스팅해야 한다.
컨테이너는 분산 모놀리스 문제의 부분적 해결책이다. 각 작업이 자체 격리된 의존성으로 컨테이너에서 실행되면, 의존성 충돌이 크게 줄어든다.
3 서버 vs 서버리스 평가
서버리스 대신 자체 서버를 운영하려는 주된 이유는 비용, 커스터마이징, 파워, 제어이다. 사용량과 비용이 서버 운영·유지 비용을 초과할 때 서버리스의 경제적 이점이 줄어들고, 서버 운영이 더 매력적이 된다.
3.1 서버리스 평가 기준 6가지
| 기준 | 서버리스 적합 | 서버 적합 |
|---|---|---|
| 워크로드 규모/복잡도 | 단순·이산적 작업 | 복잡·많은 이동 부품, 높은 연산/메모리 |
| 실행 빈도/지속시간 | 간헐적, 짧은 실행 | 높은 RPS, 장시간 실행 |
| 요청/네트워킹 | 단순 네트워킹 | VPC, 방화벽 등 고급 네트워킹 필요 |
| 언어 | 플랫폼 공식 지원 언어 | 비지원 언어 |
| 런타임 | 제한된 런타임 이미지로 충분 | 완전한 OS 추상화 필요 |
| 비용 | 이벤트 수 적음 | 이벤트 수 많아 서버리스 비용 급증 |
3.2 서버 운영 시 고려사항
서버, 특히 클라우드에서 서버 리소스가 임시적(ephemeral)인 환경에서:
| 원칙 | 설명 |
|---|---|
| 서버 실패를 예상하라 | “특별한 눈송이(special snowflake)” 서버를 피하라. 부트 스크립트나 이미지를 사용하라 |
| 클러스터와 오토스케일링을 사용하라 | 수요에 따라 자동 수평 확장 |
| 인프라를 코드로 취급하라 | Terraform, CloudFormation 등 배포 관리자 사용 |
| 컨테이너를 사용하라 | 복잡하거나 무거운 워크로드에 Kubernetes 위 컨테이너 |
교재의 결론: 추상화가 이기는 경향이 있다(abstraction tends to win). 서버리스를 먼저 검토하고, 서버리스를 벗어나야 할 때 서버(가능하면 컨테이너와 오케스트레이션)를 사용하라.
4 벤치마크 전쟁
교재는 벤치마크 해석에 대해 강력하게 경고한다.
4.1 비유: 787 비즈니스 제트 vs 테슬라 모델 S Plaid
어떤 것이 더 나은 성능인가? 하나는 대륙간 운항을 위한 와이드바디 프라이빗 제트이고, 다른 하나는 전기 수퍼카이다. 이런 사과 대 오렌지 비교가 데이터베이스 벤치마크에서 항상 일어난다.
4.2 벤치마크의 일반적 트릭
| 트릭 | 설명 | 대응 |
|---|---|---|
| 1990년대 빅데이터 | 페타바이트 규모를 주장하면서 스마트폰 스토리지에 들어가는 벤치마크 데이터셋 사용 | 예상 실제 데이터와 쿼리 규모를 시뮬레이션하라 |
| 무의미한 비용 비교 | 임시 시스템과 장기 실행 시스템을 초당 비용으로 비교 | 비교 대상의 운영 모델이 동일한지 확인하라 |
| 비대칭 최적화 | 자사 시스템에 최적화된 데이터 모델과 튜닝 적용, 경쟁 시스템에는 비적용 | 두 시스템에 동일한 수준의 튜닝이 적용되었는지 확인하라 |
구매자는 주의하라(Caveat Emptor). 벤더 벤치마크에 맹목적으로 의존하여 기술을 평가·선택하기 전에 숙제를 하라. 실제 유스케이스에 맞는 자체 벤치마크를 수행하는 것이 가장 신뢰할 수 있다.
5 핵심 요약
첫째, 서버리스는 단순하고 간헐적인 워크로드에 적합하다. 이벤트 빈도가 높거나 복잡한 워크로드에서는 비용이 급증하므로, 서버(컨테이너 + 오케스트레이션)가 더 나은 선택이다.
둘째, 컨테이너는 분산 모놀리스의 의존성 충돌 문제를 해결하는 핵심 기술이다. 단, 보안 격리가 VM보다 약하므로 멀티테넌시에 주의하라.
셋째, 벤치마크는 “어떤 것이 더 빠른가”가 아니라 “내 유스케이스에서 어떤 것이 더 적합한가”의 관점에서 해석해야 한다. 벤더 벤치마크는 구조적으로 편향되어 있다.
6 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.4 §4.9-4.10.