서버리스 1년 써보고 느낀 장단점

서버 SSH 접속해서 로그 뒤지기가 싫었다

패치 적용, 디스크 용량 관리, 장애 나면 서버 들어가서 tail -f 치기. 이런 일들에서 벗어나고 싶었다. 그게 서버리스를 선택한 이유의 전부다.

AWS Lambda + API Gateway + DynamoDB 조합으로 사이드 프로젝트를 시작했고, 나중에 회사 프로젝트 하나도 이 구조로 만들었다. 1년이 지났다.

이전에 EC2 t3.small로 운영하던 내부 도구가 있었다. 하루 요청이 500건 정도. 월 비용이 2만원.

Lambda로 전환하니 월 비용이 300원이 됐다. 300원. 요청이 없으면 비용도 0이다. 사이드 프로젝트처럼 트래픽이 들쭉날쭉한 서비스에서 이 장점은 결정적이다.

1년 동안 인프라 관련 장애가 한 번도 없었다. 코드 버그로 인한 에러는 있었지만, 서버가 죽어서 생긴 장애는 제로. OS 업데이트 걱정도 없고, 배포도 serverless deploy 한 줄이면 끝이다.

근데 여기까지가 좋은 얘기다.

"별거 아니지 않나?" 싶었는데 실제로 써보면 다르다. Node.js 런타임 기준으로 평균 200-400ms. 사용자가 적은 시간대에 첫 요청이 들어오면 눈에 띄게 느리다.

Provisioned Concurrency를 쓰면 해결되는데, 그러면 비용 장점이 사라진다. 이 딜레마가 좀 짜증났다.

(월 300원의 행복이 콜드 스타트 하나로 흔들린다.)

사실 서버리스 아키텍처의 가장 큰 불편함이 이거다. serverless-offline 플러그인을 쓰면 어느 정도 시뮬레이션이 가능한데, DynamoDB Local, S3 로컬 에뮬레이터까지 세팅하면 "이게 서버리스의 간편함이 맞나?" 싶어진다.

"로컬에서는 되는데 배포하면 안 돼요" 상황이 자주 발생했다. 통합 테스트를 실제 AWS 환경에서 돌리는 게 더 확실했는데, 그러면 피드백 루프가 느려진다.

Lambda의 최대 실행 시간은 15분이다. 대부분의 API 요청은 문제없는데, CSV 10만 건을 파싱해서 DB에 넣는 작업에서 시간 초과가 났다. Step Functions로 쪼개서 처리했는데, 단순한 작업이 갑자기 복잡한 워크플로우가 돼버렸다.

SSH로 서버 들어가서 로그 보는 것보다 답답하다. 로그가 흩어져 있고, 검색이 느리고, 실시간 확인이 어렵다. 중간에 Datadog을 도입했고, 그제야 편하게 디버깅할 수 있었다. 근데 Datadog 비용이 또 들어가니까 서버리스의 비용 장점이 희석됐다.

서버리스에서 가장 중요한 투자는 로깅과 모니터링이다. 이걸 제대로 안 하면 문제가 터져도 어디서 터졌는지 모른다.

트래픽이 적거나 변동이 큰 서비스, 이벤트 기반 처리, 빠른 프로토타이핑. 이런 경우엔 강력히 추천한다. 안정적인 트래픽이 있는 서비스, 긴 처리 시간이 필요한 작업, 복잡한 상태 관리가 필요한 경우엔 전통적인 서버가 낫다.

1년 써보니 서버리스는 마법이 아니라 도구다. 적재적소에 쓸 때 빛나는.