서버리스(Serverless)는 말 그대로 ‘서버(Server)가 없다(-less)’는 뜻으로 애플리케이션의 확장을 관리할 필요가 없는 클라우드 컴퓨팅 모델을 가리킵니다. 이름 때문에 물리적인 서버가 아예 없고 클라이언트에서 모든 것을 처리하는 구조로 착각할 수 있습니다. 하지만 실제로 서버가 없는 구조는 아닙니다. 서버에서 처리하는 작업을 클라우드 기반의 서비스로 처리해서 서버 구축 및 관리 비용을 줄이는 구조입니다. 따라서 개발 기간과 비용을 단축할 수 있을 뿐 아니라, 서버 운영과 유지 보수의 어려움을 크게 줄일 수 있습니다.
회원가입을 하면 원하는 문장을
저장 할 수 있어요!
다음
개발
3.1K클라우드 컴퓨팅을 통해 서버 구축 기간과 비용, 관리 및 유지보수의 비용을 줄이는 방법입니다. 어떤 장점과 단점이 있는지, 그리고 Baas와 Faas, 콜드스타트 문제와 비용가성비 문제에 대해 살펴볼게요.
서버리스(Serverless)는 말 그대로 ‘서버(Server)가 없다(-less)’는 뜻으로 애플리케이션의 확장을 관리할 필요가 없는 클라우드 컴퓨팅 모델을 가리킵니다. 이름 때문에 물리적인 서버가 아예 없고 클라이언트에서 모든 것을 처리하는 구조로 착각할 수 있습니다. 하지만 실제로 서버가 없는 구조는 아닙니다. 서버에서 처리하는 작업을 클라우드 기반의 서비스로 처리해서 서버 구축 및 관리 비용을 줄이는 구조입니다. 따라서 개발 기간과 비용을 단축할 수 있을 뿐 아니라, 서버 운영과 유지 보수의 어려움을 크게 줄일 수 있습니다.
이점이 또 있습니다. 서버리스는 개발자가 인프라는 대부분 무시하고 코드에 집중할 수 있도록 합니다. 서버 사양이 개발자에게 영향을 주지 않으므로 ‘서버리스’인 것입니다. 물론 물리적 서버는 여전히 존재하지만 클라우드 제공업체가 서비스 중 서버가 하는 관리한다는 점이 다르며 이 점이 개발자 및 서비스 환경이 서버에 신경을 쓰지 않아도 된다는 이점을 이끌어냅니다.
서버를 사용해야 하는 경우, 그러니까 표준 IaaS(Infrastructure as a Service) 모델에서 사용자는 용량 단위를 미리 구매합니다. 이는 애플리케이션을 실행하기 위해 ‘상시 가용할 수 있는’ 서버 구성 요소에 대한 비용을 지불하는 것입니다. 서버리스의 모델들은 이와 다릅니다. 이벤트를 실행할 애플리케이션 코드를 트리거(특정한 작용에 대응하여 자동으로 반작용이 실행되게끔 만드는 논리적 장치)하면 클라우드 제공업체는 해당 코드에 리소스(서버 자원)를 동적으로 할당하고, 사용자는 코드 실행이 끝나면 비용을 지불하지 않습니다.
장점도 있고 단점도 있습니다. 장단점을 살펴보고 어떤 환경에 어울릴지 그려보세요.
- 유연한 확장성: 애플리케이션을 활용하여 자유자재로 확장을 구현할 수 있습니다.
- 높은 가용성: 고정된 서버가 없음은 제한된 가용성이 아님을 의미합니다. 가용성을 위한 별도의 설계가 필요 없습니다.
- 유휴 용량에 대한 비용: 사용하지 않는 것에 대해선 비용을 지불할 필요가 없습니다. 실행하지 않을 때는 비용이 발생하지 않습니다.
- 개발자 생산성을 높이고 운영 비용을 줄일 수 있습니다.
- 콜드스타트(Cold-Start): 빠른 응답이 필요한 제품(서비스)의 경우 서버리스로의 전환은 부적합할 수 있습니다. 이는 실행할 함수를 호출하기 위해 컨테이너가 실행되는 대기 시간이 존재하기 때문인데, 서버를 항시 가동하지 않는 서버리스의 특징에 기인합니다.
- 무상태(Stateless)적인 기능의 구현 불가: 작은 기능으로 잘게 나눠진 함수들은 요청마다 새로 기동하도록 호출되기 때문에 기동 전후의 상태를 공유할 수 없습니다. 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없습니다.
- 벤더 종속의 문제: 함수가 사용할 수 있는 최대 메모리, 최대 처리 가능 시간 제약 등의 제약을 서버리스 서비스 벤더가 설정하며 서버리스 사용자 및 서버리스 기반의 서비스는 이에 종속됩니다. 이에 맞춰 벤더가 설정한 제약을 벗어나는 큰 기능은 잘게 나누어 구현해야 합니다.
서버리스 컴퓨팅에는 두 가지 대표적인 방법이 있습니다. 완전한 서버리스 애플리케이션(혹은 서비스)를 구축하거나, 일부는 서버리스로, 일부는 전통적인 마이크로서비스로 구성으로 수 있습니다.
주로 모바일 앱, 웹 앱에 쓰기 때문에 서비스로서의 모바일 백엔드(Mobile BaaS, MBaaS)로도 알려져 있습니다. 단일 웹페이지나 모바일 앱 기반의 서비스에서 필요한 서버 기능들을 사용하기 위해 이용하는 써드파티(Third Party) 애플리케이션, 혹은 클라우드 서비스입니다. 애플리케이션 개발 시 복잡한 백앤드(Back-End) 기능들을 개발자가 직접 개발하지 않고 클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현합니다. 예컨대 클라우드 제공업체가 인증 서비스와 추가 암호화, 클라우드 액세스 가능한 데이터베이스, 상세한 데이터 사용량 모니터링 등을 ‘완성해’ 제공하고, 개발자 및 서비스는 그것을 바탕에 둔 애플리케이션 및 서비스를 구성하는 것이죠. 보통 클라우드 제공업체가 설정한 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API) 호출을 통해 액세스합니다. 이러한 기능은 일반기능이며 클라우드 특성에 맞춘 최적화가 필요하기에, 프로젝트를 위해 새로 개발하는 것보다 클라우드 시스템에 통합되어 클라우드 공급자가 제공하는 것을 사용하는 편이 훨씬 간단합니다. 유명한 것으로는 Firebase, Auth0 등이 있습니다.
함수(로직)은 개발자가 설계하되 그것이 일반적인 서버가 아닌 클라우드 제공업체가 관리하는 클라우드 컨테이너에서 작동하는 경우를 의미합니다. 함수를 개발자가 특정 프로젝트(서비스)를 위해 작성하기에 BaaS보다 높은 수준의 제어 기능을 포함합니다. 즉, 보다 고도화되거나 특성화된 서비스 수행에 적합합니다.
확장성이 매우 뛰어나단 장점을 가지고 있습니다. FaaS를 사용하지 않을 경우 일반적으로 다양한 트래픽에 유연한 대응하기 위해 AWS의 Auto Scaling 같은 기술을 사용합니다. 이를 통해 CPU 사용량, 네트워크 처리량에 따라 서버의 개수(=처리할 수 있을 트래픽의 양)를 증감하는 방식으로 대응합니다. 그런데 FaaS를 사용하면 이 대응을 보다 정교하게 만들 수 있습니다. 특정 조건에 따라 자동으로 자원사용량을 가감하는 것이 아닌, 함수를 1초에 1개가 호출하면 자원소모(=컴퓨팅) 1개가 발생하고, 100,000,00 개가 호출되면 100,000,00 개의 자원을 소모하는 식으로 정교하게 트래픽 처리가 발생하게 끔 만들 수 있습니다. 그리고 호출된 횟수만큼 클라우드 사용료를 내면 됩니다.
서버리스는 특성 상 고정 서버 방식과는 달리 서버가 호출을 항상 대기하고 있지 않습니다. 정적 상태에서 최초로 함수를 호출하면 해당 함수가 준비되는데 일정한 지연 시간이 발생합니다. 이것을 콜드스타트(Cold-start)라고 부릅니다.
콜드스타트 후 해당 함수는 웜(Warm, 작동가능) 상태가 되며 상태전환 이후 다시 호출하면 빠르게 작동합니다. 하지만 약 5분 정도의 시간동안 호출되지 않는다면 다시 정적상태(Cold status)로 돌아갑니다. 이 상태전환시간(지연시간) 및 역행시간은 개발 언어나 설정한 메모리양 등의 변수에 의해 제각각이기 때문에, 제공할 서비스가 가진 특성에 맞춰 서버리스를 이용할 것인지, 쓴다면 어떤 언어로 개발할 것인지 등을 선택해야 합니다. 항상 작동가능상태(Warm status)를 유지하기 위해 5분에 한 번씩 호출하도록 설정하는 ‘꼼수’를 쓰기도 합니다.
표 1: 콜드스타트 시 언어 별 평균 소요시간 예시(ms)
표 2: 웜스타트 시 언어 별 평균 소요시간 예시(ms)
앞서 설명한 것처럼 서버리스는 실행시간과 메모리 사용량에 따라 가변적으로 비용을 하며 더 높은 성능을 위해서는 사용 가능 메모리를 더 늘리고 역시 더 많은 비용을 지불해야 합니다. 중요한 점은 비용을 지불한만큼 성능이 정비례하여 올라가는 것이 아니란 점입니다. 사용할 함수의 실행시간과 메모리양에 따라 가성비 구간이 존재합니다. 함수의 실행 시간과 메모리 사용량을 고려하여 알맞은 성능을 선택해야 합니다.
표 3: 메모리에 따른 실행소요시간과 과금액 예시
메모리를 128MB 사용할 때 11초가 걸리며 0.024628$씩 지불해야 하는 것이, 1024MB로 설정하면 요청당 0.00001$를 더 지불하되 10배 정도의 속도 개선을 얻을 수 있습니다. 이처럼 상황(제공할 서비스)에 맞도록 실행시간, 사용할 메모리, 비용의 세 축을 조절하면 비용감소와 성능강화 모두를 노릴 수 있습니다.
좋아요
댓글
공유
공유
같은 분야를 다룬 글들을 권해드려요.
OTT 콘텐츠 많이들 보시나요? 지금 당장 생각나는 것만 해도 넷플릭스, 유튜브, 웨이브, 티빙, 왓챠 같은 많은 OTT 서비스들이 떠오르네요. 그런데 프론트엔드 개발을 조금이라도 해봤다면 웹 브라우저에서 저작권에 민감한 콘텐츠를 재생할 수 있다는 것이 매우 이상하게 느껴질 것입니다. 왜일까요? 개발자 도구를 쓸 줄 안다면 비디오 파일의 원본 URL을 쉽게 확인할 수 있고, 심지어 다운로드까지 할 수 있기 때문입니다. 그렇다면 여러 OTT 서비스들은 콘텐츠의 저작권을 보호하기 위해 어떤 기술을 사용하고 있을까요? 웹 브라우저에서 OTT 콘텐츠를 안전하게 재생하기 위해서 어떤 절차를 거쳐야 할까요?
요즘 인기있는 이야기들을 권해드려요.
지금 회원가입하고,
요즘IT가 PICK한 뉴스레터를 받아보세요!
