서버리스는 어떤 서비스나 조직에 적합할까?
2020-09-18서버리스(Serverless)를 ‘서버가 없다’고 정의하고 시작한다면, 뒤에 나올 이야기들을 이해하는데 어려움이 생길 수 있다.
사실상 서버를 사용하지 않는다는 의미가 아니라, 항시 가동 중인 가상머신 혹은 서버를 통해 작업이 처리되는 것이 아님을 의미한다.
이는 서버 사양이나 인프라에 대한 부분을 신경 쓰지 않고 코드와 함수를 통해 주문하듯 서비스를 실행할 수 있다는 말인데,
여기에 대해서는 아래 본문에서 더 자세히 설명하고 있다. 우선 서버리스의 개념부터 차근차근 이해해 보도록 하자.
서버리스는 마치…
식당에 가면 종업원을 부르기 위한 벨이 있고, 종업원은 벨을 누른 테이블에 서비스를 제공한다.
종업원은 항상 우리 테이블만 쳐다보며 기다리지 않는다. 서버리스는 벨을 눌러 종업원을 부르는 시스템에 가깝다. 이는 서버리스의 기본적인 개념의 이해를 돕기 위한 비유로 사용자가 가상 머신이나 서버를 소유하고 있는 것이 아니라, 필요에 따라 서비스를 프로비저닝한다는 것을 의미한다. 그렇게 되면 인프라 비용을 항시 지불하지 않아도 되는 큰 장점이 있다.
서버리스 컴퓨팅은 어떻게 작동할까?
크게 두 가지 방식 FaaS(Function as a Service)와 BaaS(Backend as a Service)로 나눌 수 있다.
FaaS
FaaS는 기능을 하나의 함수로 구현해두고 실행할 때마다 서버 자원을 할당받아 사용하는 것을 말한다. FaaS에서 서버는 이벤트가 발생할 때마다 함수를 실행한다. 대부분의 로직을 개발자가 작성하므로 BaaS에 비해 제어 범위가 넓다고 볼 수 있다.
FaaS의 예시로는 AWS 람다(AWS Lambda), Azure 펑션(Azure Function), Google 펑션(Google Functions)이 있다.
BaaS
BaaS는 애플리케이션 개발 시 필요한 로그인, 데이터 관리, 회원 관리 같은 기능을 클라우드 공급자가 제공하는 서비스를 이용해 구현하는 것을 말하며, 서비스형 서버리스라고도 부른다. 애플리케이션에 당연히 요구되지만 구현하기는 번거로운 데이터 저장소, 파일 저장소, SNS 연동, 위치 정보 검색, Push 알림 등 기능을 API 방식으로 제공하기 때문에 애플리케이션 내에 필요한 기능을 호출하여 사용할 수 있다.
Google Firebase가 대표적인 예시이며, 클라우드 공급업체가 제공하는 서비스를 사용하게 되므로 FaaS보다는 개발이 간단해진다는 장점이 있다.
서버리스는 어떤 서비스나 조직에 적합할까?
서버리스는 새로운 아이디어를 빠르게 테스트해야 하는 조직에 적합하다. 그에 대한 예로 스타트업의 경우를 보면, 시도와 실패를 반복하며 구현한 기능을 서비스에 빠르게 녹여 신속히 출시해야 시장에서 경쟁력을 갖출 수 있다. 사실 이는 스타트업에만 해당하는 일은 아니다. 부가 기능은 BaaS를 사용하고 개발자는 서비스의 핵심 기능 구현에만 집중하도록 하면 생산성을 높이고 개발 주기를 앞당길 수 있다. 또한 FaaS는 최소 기능 단위로 함수를 작성하기 때문에 코드 유지보수나 신규 기능 추가를 효율적으로 수행할 수 있다.
단기간 이벤트성 트래픽을 감당해야 하는 경우에도 서버리스가 효과적이다. 필요할 때 동적으로 자원을 할당받아 사용하기 때문에 급격한 트래픽 변화에 유연하게 대응할 수 있다.
또한, 예상되는 반복적인 배치(batch) 처리 형태의 기능이 서버리스를 활용하기에 적절하다. 예를 들어 실시간 라이브 동영상 스트리밍에 대한 로그 분석, 음성이나 텍스트를 기반으로 학습된 데이터를 제공하는 인공지능 기능 등 반복적으로 타 시스템과 연계하여 비즈니스 요구사항에 맞는 결과를 도출하는 기능에 특화되어 있다.
장점을 정리해 보면,
– 관리보다 개발에 집중하여 서비스 출시를 앞당김
– 함수 단위 로직으로 코드 유지보수나 기능 추가에 효율적
– 이벤트 기반 실행으로 경제적이며 유연한 대응 가능
– 반복적으로 타 시스템과 연계하여 비즈니스 인사이트를 도출할 때 유용
서버리스가 항상 답이 될 수 있을까?
모든 서비스가 그렇듯 모든 것을 만족시키는 만능 서비스는 없다. 서버리스 역시 제약이 있다. 그렇기 때문에 어떤 서비스에 서버리스를 적용하면 좋을지 장단점을 따져본 후에 적용해야 한다. 우선, 서버리스는 사용한 만큼 과금하는 대신 다른 클라우드 컴퓨팅 자원보다 비싸다.
따라서, 사용량이 꾸준히 많은 서비스나 함수 호출량이 매일 일정한 횟수 이상인 서비스에는 적합하지 않다. 비슷한 이유로 서버리스 아키텍처에서는 하나의 함수가 한 개의 기능만 담당하도록 하는 것이 좋다. 함수가 무거워질수록 사용하는 자원이 늘고, 그에 따라 비용도 증가하기 때문이다.
서버리스는 항상 대기하는 전용 서버가 없어서 실행을 완료하면 자원을 반납해야 한다. 즉, 각 서비스의 처리 결과에 따라 상태를 따로 저장하는 작업이 필요하다.
또한, 서버리스, 특히 FaaS는 느리다.
함수가 이벤트 기반으로 호출되어 동작하는 과정은 시간이 걸린다. 호출과 동시에 컨테이너를 실행하는데 대기 시간이 발생하기 때문이다. 미리 끓고 있는 물에 면을 넣어 익히는 것과 주문과 동시에 물을 끓이기 시작하는 것 중 어느 쪽이 더 빨리 면을 익힐 수 있을까?
물론 요청할 때마다 환경을 새로 만드는 것은 아니다. 최초 요청 시 만든 환경을 재사용할 수 있는 옵션도 있다.
하지만 일정 유지 시간이 만료되고 나면 여전히 같은 문제가 발생한다.
단점을 정리해보면,
– 장기간 지속하 작업에는 기능적/비용적으로 부적합
– 기존 컴퓨팅 자원 대비 고가의 서비스 비용 (동일한 가동 시간 가정)
– ‘콜드 스타트’를 깨기 위한 시간 필요
– 서비스 처리 결과에 대한 데이터 저장 필요
서버리스를 적절히 활용하면 신규 서비스나 기존 기능을 저렴하게 운영할 수 있다는 것은 분명하다.
따라서, 서버리스를 잘 활용하기 위해 ‘우리 서비스가 서버리스에 적합한지’, ‘어떤 기능을 서버리스로 구현할지’ 선택하여 그에 맞는 아키텍처를 고민하고 공부해야 할 것이다.
