들어가며
혹시 '서버리스(Serverless)' 아키텍처에 대해 알고 계신가요?
저는 Next.js를 사용한 프로젝트를 진행하면서 처음 접하게 되었는데요. 오늘은 서버리스가 뭔지, 정말 서버가 없는 것인지 가볍게 알아보려고 합니다.
We build on Serverless (AWS Lambda) because we don’t think managing servers is a core part of our business. Instead, we focus on building business logic and data transformation. We start small, only pay for what we need, and the service automatically scales for us
Vadim Parizher
Vice President of Engineering and Analytics, Taco Bell.
서버리스란
서버리스는 클라우드 컴퓨팅의 한 형태로, 이름 그대로 보면 '서버 없음'을 의미합니다. 그러나 이는 실제로 서버가 없다는 것을 의미하는 것이 아니라, 개발자가 서버에 대한 관리를 하지 않아도 된다는 것을 의미합니다.
이 때문에 "서버리스"라는 용어는 종종 오해를 불러일으키곤 합니다.
클라우드 컴퓨팅이란, 간단히 말해 인터넷을 통해 원격으로 컴퓨터 시스템 리소스와 데이터 처리를 제공하는 기술을 말합니다.
어떻게 구성되어 있나
서버리스는 두 가지 주요 개념을 포함합니다.
- FaaS(Function as a Service)
이벤트 트리거(예: HTTP 요청, DB 트랜잭션 등)에 의해 실행되는 개별 함수입니다. 개발자들이 클라우드에 기능의 일부를 업로드할 수 있게 해 주고 독립적으로 실행가능하게 해 줍니다. AWS Lambda, Google Cloud Functions, Azure Functions 등이 이에 해당합니다. - BaaS (Backend as a Service)
개발자가 데이터베이스, 사용자 인증, 푸시 알림 등과 같은 서버 측 로직을 처리하는 클라우드 서비스입니다. Firebase, AWS Amplify, Parse 등이 이에 해당합니다.
이 둘은 같이 사용되기도 합니다. 예를 들어, 사용자의 요청이 들어오면 FaaS가 이를 처리하고, 필요한 경우 BaaS에 있는 데이터베이스나 다른 서비스를 호출합니다.
어떻게 작동하는 거지?
그러면 FaaS가 어떻게 작동하는지를 살펴보겠습니다.
- 개발자는 특정 작업을 수행하는 함수를 작성하고 이를 서버리스 플랫폼에 배포합니다.
- 함수를 배포한 후, 이 함수가 어떤 이벤트에 의해 호출되어야 하는지를 설정합니다.
- 트리거 이벤트가 발생하면, 서버리스 플랫폼은 자동으로 해당 함수를 실행합니다. 각 함수 호출은 독립적인 컨테이너 또는 실행 환경에서 실행되며, 이는 함수의 실행 도중에 발생하는 모든 상태를 격리합니다.
- 함수가 작업을 완료하면, 그 결과를 호출자에게 반환합니다.
- 함수가 작업을 완료하고 결과를 반환한 후, 서버리스 플랫폼은 함수의 실행 환경을 자동으로 종료합니다.
AWS 서버리스 아키텍처 다이어그램 예시를 보겠습니다.
이 다이어그램은 AWS Lambda, Amazon S3, API Gateway, and DynamoDB를 사용해 날씨 데이터를 얻는 예시를 보여줍니다.
API Gateway는 클라이언트로부터 HTTP 요청을 수신하고 이를 적절한 Lambda 함수로 라우팅 하는 데 사용됩니다. 그다음 Lambda 함수가 요청을 처리하고 응답을 반환합니다.
그래서 뭐가 좋은 건데?
서버리스는 다음과 같은 주요 장점들을 가지고 있습니다.
- 높은 확장성
트래픽이 증가하면 자동으로 확장되며, 트래픽이 감소하면 자원을 자동으로 축소합니다. - 비용 효율성
실행 시간에 따라 비용이 청구되므로, 사용하지 않는 시간에는 비용이 발생하지 않습니다. - 개발 효율성
애플리케이션 코드에만 집중할 수 있으므로 개발 시간을 줄일 수 있습니다.
서버리스도 완벽하지는 않다
언뜻 보면 장점이 가득한 것 같지만 다음과 같은 단점들도 가지고 있죠.
- 높은 플랫폼 종속성 (Vendor lock-in)
특정 클라우드 제공 업체의 서버리스 플랫폼에 종속되는 경향이 있습니다. - 콜드 스타트 (Cold starts)
콜드 스타트는 서버리스 함수가 처음 실행될 때 (또는 장시간 동안 사용되지 않았을 때), 해당 요청을 처리하기 위해 신규 인스턴스를 시작하는 데 걸리는 시간을 말합니다. - 디버깅과 모니터링의 어려움
서버리스 환경에서는 각 함수가 독립적으로 실행되며 자신의 로그를 생성하므로, 통합적으로 관리하고 분석하는 것이 어려울 수 있습니다.
그럼 언제 사용해야 할까
그러면 서버리스는 언제 사용하는 게 좋을까요?
다음과 같은 상황에서 특히 유용할 수 있습니다.
- 유동적인 트래픽을 가진 경우
- 빠른 시장 반응이 필요한 경우
- 사용량이 적거나 불규칙한 경우
사용 예시
- 파일 업로드 처리
- 데이터 변환 및 처리
- 실시간 스트림 처리
- 이메일 발송
어떻게 사용하는 거지?
서버리스 아키텍처를 지원하는 수많은 도구들이 존재합니다.
AWS Lambda, Google Cloud Functions, Azure Functions 등의 서버리스 컴퓨팅 서비스나 Zappa, Claudia.js, Vercel 등의 서버리스 프레임워크를 통해 서버리스 환경을 쉽게 구축할 수 있습니다.
마치며
앞서 살펴보았듯 서버리스는 여러 이점을 가지고 있어, 많은 애플리케이션에서 널리 사용 중인 아키텍처입니다. 이를 통해 개발자들은 서버 구축과 유지보수에 대한 부담을 덜고, 더 중요한 비즈니스 로직에 집중할 수 있게 되었습니다. 그러나 모든 상황에 적합하지는 않을 수 있으니 여러 요소를 판단해 적절한 선택이 필요합니다.
오늘도 글을 읽어주셔서 감사합니다 :D
지적이나 다른 의견은 언제나 환영합니다.