Serverless란 ?

GonnabeAlright·2022년 3월 1일

devops

Serverless란 ?

"No server is easier to manage than no server." - Werner Vogels

의역하면 "서버를 제일 잘 관리하는 방법은 서버가 없는 것이다." 아마존 CTO가 2015년 re:Invent 기조 연설에서 언급한 내용입니다.

개발자 혹은 스타트업 IT 대표에게 묻습니다.

서버가 왜 필요하신가요 ?

"이번에 우리가 만든 서비스를 고객에게 제공하기 위해서 파일을 저장하기 위한 서버도 필요하고, 데이터를 저장할 디비 서버도 필요하고, 웹을 보여줄 웹서버도 필요하고..."

이제 기술적인 것을 떠나서 관점을 달리봐야 할 때입니다. 비즈니스 관점에서 고객에게 서비스를 전달하기 위해서 물리적인 서버가 필요했던 것이 아니고, 그것을 제공하기 위해서 물리적인 서버 위에 서비스를 구축하는 방식으로 물리적인 서버를 두었을 뿐이지 애초에 누구도 서버 자체가 필요했던 것은 아니었습니다. Serverless 기술이 좋고 나쁘고를 떠나서 비즈니스 전달이 목적이지 애초에 물리적 서버 자체가 목적이 아니면 필요가 없다는 것입니다.

그럼에도 불구하고 "서비스 = 서버 필요"가 공식처럼 따라 붙은 것은 서비스 제작을 위한 도구형 서비스들이 내 비즈니스를 온전히 다 구축하기에 부족했기 때문입니다. 그러나 이제 기술의 발달로 인해 내가 원하는대로 구축이 가능한 도구형 서비스들이 나왔고 이것이 효율적이고 싸고 빠르기 때문에 이제 관점을 달리해야 한다고 한 것입니다. 이런 기술들이 대부분 서버가 아닌 서비스의 형태로 제공되기 때문에 Serverless라고 칭합니다.

요즘 나오는 대부분의 트렌디한 기술들은 생산성과 유지보수에 초점을 맞춰 왔습니다. 서버 하나하나의 CPU, 메모리, 네트워크 등을 관리하고 사용량에 따라 Scale Up/Out 하는 등의 관리를 직접하지 않다보니 인프라 관리가 쉬워지고 이는 유지보수와 생산성을 높이는데 직결됩니다.

이번에는 클라우드 서비스 벤더들 입장에서 보겠습니다. AWS나 GCP 같이 클라우드 서비스를 제공하는 입장에서는 물리적인 서버를 항상 넉넉하게 준비해야 합니다. 즉 수용량을 항상 여유 있게 할 수 밖에 없습니다. 여유있게 서비스를 준비해 놓는다는 것은 사용자 입장에서 좋은 것이지만 운영하는 입장에서는 그다지 환영할 만한 일이 아닙니다. 지속적으로 전기세, 관리비, 감가상각 등이 빠져나가기 때문입니다.

전 세계적으로 보았을 때 웹 서비스의 점유율이 지배적입니다. 웹 서비스라는 것은 본래 유저에게 보여줄 내용을 미리 준비해놓거나 찾아서 전달해주는 것인데 시간을 단축하기 위해서는 선택한 방법이죠. 사이트가 느리면 손님이 떠나기 때문입니다. 대부분의 웹 서비스에서 로직 실행 시간은 1초 미만이고 아무리 길어봐야 몇 분인데 서버를 통째로 대여해주는 것이 아니라 몇 분 단위로만 대여를 해주면 어떨까? 어차피 남는 서버들이 소모하는 비용을 활용할 수 있고 수용량에 대한 대처도 쉽고 수익률도 향상 되지 않을까? 이것이 Functions 서비스(AWS:Lambda, GCP: Cloud Functions, Azure: Functions)입니다.

개발자 입장에서는 인프라 관리가 쉬워지고 클라우드 서비스 벤더들 입장에서는 수익률이 향상되니 서로 윈윈한는 서비스가 Serverless 기술이고 최근 몇 년을 기점으로 해외에서는 폭발적으로 사용량이 증가하고 있습니다.

Serverless를 기술적으로 보면 주로 Functions + Managed Service의 조합입니다. 가장 기본적인 형태의 웹 서비스를 AWS에서 구성해 보자면 S3 + Cloud Front + Lambda + DynamoDB 정도가 될 것입니다. 이어서 설명할 BaaS(Backend as a Service)형태의 Amplify, Firebase의 Cloud Functions 같은 서비스는 기본적으로 모두 Serverless 형태를 취하고 있습니다.

Serverless 장점

비용

서버를 사용하던 안하던 24시간 켜놓을 수 밖에 없는 레거시 방식에 비해서 Serverless는 정확히 사용한 시간만큼에 비례하여 비용을 지불하므로 비용 절감에 큰 효과가 있습니다. 구성 내용에 따라서 비용이 수백 배도 차이가 날 수 있습니다. 인스턴스 방식의 구성도 Auto Scale을 통해서 비용 조절이 가능하지만 Serverless 만큼 마이크로 컨트롤은 힘듭니다. 단, Serverless라고 하여 구성에 따라서 무조건 싼 것은 아니니 오래 걸리는 작업은 Spot 인스턴스를 이용한다든지 비용에 최적화된 설계가 필요합니다.

확장(Scale Up/Out)

대부분 아무런 설정 없이도 자동으로 확장이 됩니다. Auto Scale, CPU/메모리 사용량 등을 걱정할 필요가 없습니다. 세부 설정을 통해 Scale Up/Out에 대한 조절도 가능합니다.

관리 및 보안

인프라를 일일히 셋팅하고 관리하지 않아도 되므로 시간도 아끼고 편리합니다. 보안패치 업데이트 및 방화벽 구성이나 DDOS 방어등 보통 서비스단에서 알아서 제공합니다.

벤더 특화 기능

AWS의 DynamoDB, Firebase의 FireStore등 각 벤더 별로 최적화하여 특화된 서비스들을 사용할 수 있습니다. 일반적으로 인스턴스에 설치하여 사용하는 오픈 소스 도구들보다 고성능이나 고가용성을 자랑합니다.

모듈화

Serverless 기반에서 보통 로직을 Function으로 사용하기에 서비스 자체를 모듈화 하기가 좋습니다. 이를 마이크로서비스라고 합니다. 레거시 인스턴스 방식이라고 마이크로서비스를 구축하지 못하는 것은 아니지만 Serverless는 마이크로서비스에 더 최적화되어 있습니다.

Serverless의 단점

제한

Function을 기반으로 한 서비스를 호출 시 시간 제한, 메모리 제한이 있습니다. 일반적으로 5분, 2M 같이 제한이 있고 세부 설정을 통해 증액은 가능하나 인스턴스 같이 크게 확장을 할 수는 없습니다. 또한 시간 제한이 있다보니 WebSocket 같이 연결지향형 프로토콜을 사용하기가 힘듭니다. 오랜 시간이나 메모리를 많이 사용하는 작업은 Serverless보다는 Spot 인스턴스를 같이 사용하게끔 설계하는 것이 좋습니다.

의존성

벤더 특화된 기능을 사용 시 의존성이 생길 수 밖에 없습니다. 의존성을 너무 강하게 설계할 경우, 클라우드의 이전이나 멀티 클라우드의 구성이 힘들어 질 수 있습니다.

가격 예측

가격 계산이 복잡합니다. 사용한 시간에 비례하여 비용을 내는 것이나 초단위가 아닌 마이크로 초단위로 계산을 하고 메모리를 조금 더 쓰고 덜 쓰고에 따라서는 가격이 두 배도 차이가 납니다. DB의 경우 인스턴스 방식은 한달 사용량 당 몇 달러 이런 식으로 고정되어 있지만 Serverless의 경우 읽기는 백만 쿼리당 $0.x, 쓰기는 백만 쓰기당 $0.x 얼마 이런 식으로 총 얼마를 읽고 쓰고 지우고 트랜잭션을 걸고 하는 것에 따라서 세세하게 가격이 책정됩니다. 유저가 서비스를 이용하면서 평균 세션 타임, 페이지 뷰 수, 페이지 내에서 쿼리량, 쿼리량 중에 읽고 쓰는 비율, 업로드한 파일 사이즈 평균, 다운로드한 사이즈 일평균, DAU, MAU 등등 아주 세세한 데이터가 모두 있으면 이론적으로는 계산이 가능하나 특히 스타트업의 비즈니스는 초기에 이런 식으로 예측이 불가합니다. 대부분 Serverless 기반으로 제작된 서비스들은 몇 달 정도 돌려보면서 이용량을 바탕으로 역추산을 합니다.