컴퓨터의 역사를 되돌아보면, 여러 차례에 걸쳐 큰 "패러다임의 전환"들이 있었습니다. 처음에는 단순한 계산을 수행하는 컴퓨터에 사람들이 경이로워했던 시절이 있었습니다. 그러나 가상 머신의 등장으로 물리적인 하드웨어의 제약에서 벗어나, 더 유연하고 효율적인 컴퓨팅 환경을 구성할 수 있게 되었습니다. 그리고는 컨테이너 기술이 나타나, 서버 환경과 그 설정을 덜 복잡하게 만들어, 개발자가 문제 해결의 핵심에만 집중할 수 있게 해 주었습니다. 이러한 패러다임의 전환들로 인해 컴퓨팅의 많은 생태계가 발전되어 왔죠. 이번에 소개할 서버리스 또한 이러한 패러다임의 새로운 전환점을 차지하고 있습니다.
Serverless란?
서버리스(Serverless)는 클라우드 서비스의 한 종류로, 개발자가 서버의 관리에 신경 쓰지 않고, 코드만 입력하면 적재적소에 해당 코드를 실행할 수 있도록 해줍니다.
기존의 클라우드 서버는 원격으로 머신을 한대를 빌려 모든 관리과 유지보수 등을 개발자가 직접 진행해야 했다면, 서버리스에서는 개발자가 서버 관리로부터 자유로워졌기에, 비즈니스 로직이나 코드 작성에만 집중할 수 있게 되었죠.
우리가 캠핑을 하기 위해 텐트도 챙겨야하고, 캠핑 장비도 구해야 하고, 짐 보따리를 한 뭉치 들고 캠핑장으로 가게 되겠죠. 일반인이라면 가기도 전에 벌써 지칠 것입니다. 하지만 잘 구축된 글램핑을 가게 된다면, 단순히 몸만 가서 즐기다 올 수 있습니다. 서버리스는 이러한 글램핑과 비슷한 이점이 있다 볼 수 있겠네요.
서버가 없어서 Serverless일까?
이때 Serverless(server + less)라고 해서 진짜 서버가 없는것은 아닙니다. 실제로 서버리스 아키텍처 내에는 함수가 실행되기 위한 서버가 존재합니다. 하지만, 서버의 관리 및 운영은 클라우드 서비스 제공자(AWS, GCP 등)가 전담하기 때문에 개발자는 서버에 대한 걱정을 할 필요가 없어진 것이죠. 이런 의미에서 '서버가 없는 것처럼' 개발할 수 있기에 "서버리스(Serverless)"라는 이름이 붙여지게 되었습니다.
Serverless 작동 방식
Serverless는 필요한 순간에만 코드를 실행 시킵니다. 이처럼 특정 사건(이벤트)에 의존해서 실행하는 방식을 Event-Driven 아키텍처라고 합니다. 여기서 이벤트는 사용자의 웹 요청이 될 수도 있고, 파일 업로드, 데이터베이스의 상태 변화, 메시지 큐의 새로운 메시지 등 다양한 형태를 가질 수 있습니다.
Event-Driven이 아닌, 기존 서버 기반 모델에서는 지속적으로 실행되는 서버가 있고, 해당 서버가 요청을 기다리는 상황이 일반적입니다. 이렇게 지속적으로 실행되는 서버는 자원을 계속 소비하게 됩니다. 반면에 이벤트 드리븐 모델에서는 특정 이벤트가 발생한 경우에만 컴퓨팅 자원을 사용하여 코드를 실행하게 됩니다. 이런 방식은 컴퓨팅 자원을 효율적으로 사용하면서도, 빠르고 확장 가능한 기능을 구현할 수 있게 합니다.
Serverless의 장점, 단점
서버리스는 동적으로 서버의 자원을 할당하게 됩니다. 이러한 메커니즘에서 서버리스의 장점과 단점이 명확히 구별 됩니다. 대표적인 장단점만 살펴보겠습니다.
[장점]
1. 관리가 용이합니다.
위에서도 언급했지만, 서버리스의 최대 장점입니다. 서버의 관리를 하나부터 열까지 개발자가 직접 담당할 필요가 없습니다. 심지어 트래픽의 변화에 대응할 수 있도록, 오토 스케일링을 지원해주기도 하죠.
2. 비용이 저렴
서버리스는 일반적으로, 호출되는 사용량 만큼만 비용을 지불하게 됩니다. 하루 중 특정 시간대만 사용되는 함수인데, 이를 위해 서버를 종일 빌리고 있으면 불 필요한 과금이 나오겠죠. 서버리스는 사용되는 동안만 자원이 할당되어 사용한 만큼만 비용을 지불하기에 비용이 훨씬 저렴할 수 있습니다.
[단점]
1. 콜드 스타트
서버리스는 필요한 경우에만 동적으로 서버 자원을 할당합니다. 때문에 함수가 일정 시간 동안 호출되지 않으면, 시스템은 '이 함수는 현재 사용되지 않는다'라고 판단하여 리소스를 회수하고 다시 대기 상태로 전환합니다. 이런 대기 상태에서 새로운 호출이 발생하면, 시스템은 필요한 리소스를 다시 할당하고 함수를 초기화해야 하므로 응답 시간이 늘어날 수 있습니다. 이를 콜드 스타트라고 합니다. 콜드 스타트에 대한 더 자세한 내용은 아래 자체 QnA에서 다루겠습니다.
2. 실행 시간과 리소스 제한
대부분의 서버리스 플랫폼은 함수가 실행될 수 있는 최대 시간을 정해놓기 때문에, 이를 초과하면 실행이 강제로 종료됩니다. 예를 들어, AWS Lambda의 경우 최대 15분까지만 함수의 실행이 허용됩니다. 이러한 시간제한 때문에 긴 작업을 수행하기에는 서버리스가 적합하지 않을 수 있습니다. 또한, 서버리스 환경에서는 CPU, 메모리 등의 리소스도 사전에 정의된 범위 내에서만 사용할 수 있기 때문에, 리소스 집약적인 작업에는 한계가 있을 수 있습니다. 이런 제한 사항들이 있기에 개발자가 신중히 고려해야 하는 요소입니다.
Cold-Start & Warm-Start
서버리스에서 함수의 상태는 일반적으로 "콜드(Cold) 스타트"와 "웜(Warm) 스타트"로 구분됩니다. 아래는 AWS에서 제공하는 Serverless 서비스인 Lambda의 LifeCycle입니다.
- 콜드 스타트(Cold Start): 함수가 처음 호출되거나 일정 시간 동안 호출되지 않았을 때의 상태를 의미합니다. 이때는 런타임 환경을 새로 구성해야 하므로, 함수의 실행이 느려질 수 있습니다.
- 웜 스타트(Warm Start): 함수가 최근에 호출되어 실행 환경이 이미 준비된 상태를 의미합니다. 이 상태에서 함수를 호출하면 콜드 스타트 때보다 빠르게 실행됩니다.
웜 스타트 상태가 얼마나 지속되는지, 언제 콜드 스타트 상태로 전환되는지는 서비스 제공자의 정책과 알고리즘에 따라 다릅니다. 이러한 콜드 스타트를 방지하기 위한 여러가지 방법론들이 있습니다. 간단하게는 특정 주기를 가지고 강제로 함수를 호출하여 웜 스타트를 계속 유지할 수 있도록 하는 방법이 있습니다. 또한 AWS에서는 프로비저닝 된 동시성(Provisioned Concurrency)이라는 기능으로, 함수가 cold start로 되지 않도록 항시 대기 상태로 둘 수 있는 방법도 제공해 주고 있습니다. 하지만 위의 방법들은 추가적인 비용이 더 들기에, 개발자가 서버리스 환경을 잘 설계할 필요가 있습니다.
[Reference]
