서버리스(Severless) 컴퓨팅 도입에 앞서 고려할 사항들

컴퓨팅 환경은 물리 서버에서부터 가상 머신, 컨테이너, 그리고 서버리스 컴퓨팅까지 빠르게 변화하는 수요에 맞추어 진화해왔습니다. 이는 인터넷 서비스를 이용하는 사람이 보다 본질적인 것에 집중할 수 있는 방향으로 발달되어온 셈입니다. 최근 주목을 받고 있는 서버리스 컴퓨팅 기술 또한 개발자가 백엔드 관리에 에너지를 쏟지 않고 애플리케이션 개발에 보다 집중할 수 있도록 해준다는 점에서 이와 동일한 맥락이라 할 수 있습니다.

하지만 그 편리함에도 불구하고, 서버리스 컴퓨팅 기술이 지닌 한계점도 분명 존재합니다. 운영하는 비즈니스 아키텍처에 서버리스 컴퓨팅을 활용할지 결정하기에 앞서 여러 요소들을 면밀히 검토할 필요가 있습니다. 이에 최근 주목을 받고 있는 서버리스 컴퓨팅에 대한 간략한 정의와 및 도입 시 고려해야 할 사항들에 대하여 알아보겠습니다.

서버리스(Serverless)란?

‘서버리스 컴퓨팅’ 혹은 ‘서버리스 아키텍처’로 알려진 기술은 클라우드 컴퓨팅의 세분화된 모델이라고 할 수 있습니다. 2014년 아마존의 AWS Lambda(AWS 람다)가 출시된 이후 MS와 Google이 뒤이어 Azure Functions와 Google Functions 서비스를 시작하였습니다. 서버리스의 개념은 애플리케이션 관점에서 BaaS(Backend as a Service)와 FaaS(Function as a Service)를 포괄하는 개념입니다. ‘서버리스’를 구성하는 각각의 개념에 대하여 간략히 알아보겠습니다.

BaaS(Backend as a Service)

웹이나 모바일 애플리케이션을 만들고 이를 서비스하기 위해서는 백엔드 서버 개발을 진행하게 됩니다. 데이터의 기록 및 관리, 사용자 인증이나 서비스 구동 등과 같은 기능이 서버에 구현됩니다. 이렇게 서버 상에 구현되는 많은 기능들 중 필수적이고 중복되는 기능들을 클라우드 서비스 업체들이 사전에 제공하는 것이 바로 BaaS입니다. BaaS 덕분에 서비스 개발자들은 백엔드에 필요한 기능들을 클라우드에서 직접 호출하여 사용할 수 있게 되고, 백엔드 개발에 소요되는 시간과 에너지를 아낄 수 있게 됩니다. 구글의 Firebase가 대표적인 BaaS에 해당합니다. Firebase의 경우 안드로이드, iOS, 웹 등 그 플랫폼의 종류와 관계 없이 동일한 API(Application Programming Interface)를 통해 Firebase 백엔드를 사용할 수 있게 해줍니다. Firebase 덕분에 최초 한 번만 애플리케이션을 개발하면 다양한 플랫폼에 이를 활용할 수 있게 되는 것입니다.

FaaS(Function as a Service)

클라우드에서 이미 제공된 기능을 활용하기 보다는 직접 서버에서 수행되는 기능들을 개발자가 작성하고 이를 클라우드에 업로드하여 필요 시 마다 호출하여 사용하는 경우가 FaaS에 해당합니다. 애플리케이션 개발자는 클라우드 상의 서버를 할당 받거나 확장하고, 데이터베이스를 관리하는 등의 백엔드에서 필요한 작업을 신경 쓸 필요가 없게 되는 것입니다. ‘서버리스’라는 용어는 FaaS를 지칭하는 협의의 의미로 주로 사용됩니다.

‘경제성’, ‘확장성’, ‘편리함’ 이라는 서버리스 컴퓨팅의 장점들은 익히 잘 알려져 있습니다. 하지만 그 도입에 앞서 서버리스가 지니는 몇 가지 단점들을 눈여겨볼 필요가 있습니다. 일단 도입하게 되면 이를 다른 아키텍처로 이전하기 위하여 절약한 시간과 비용 이상을 지출하게 될 수 있기 때문입니다. 이후에서는 서버리스 도입에 앞서 고려해야 할 사항들에 대하여 알아보도록 하겠습니다.

1. 벤더 종속성(Vendor lock-in)

서버리스 컴퓨팅을 이용할 경우 비즈니스가 특정 클라우드 벤더사에 종속될 수 밖에 없다는 문제점이 있습니다. 서버리스 아키텍처에서는 하드웨어나 런타임, 그리고 업데이트 등을 직접 컨트롤 할 수 없기 때문입니다. 만약 애플리케이션을 단 하나의 서버리스 아키텍처에 구축한다면 추후 다른 벤더사로 아키텍처를 이전하는 것이 굉장히 복잡하고 어렵습니다. 게다가 이용중인 벤더사에서 가격이나 서비스 정책을 변경하거나 각종 옵션들이 제공을 중단할 위험성도 존재합니다.

2. 지속시간(Duration)의 제한

서버리스 컴퓨팅은 ‘이메일 발송’, ‘결제 처리’ 등의 과 같이 짧은 지속 시간을 가진 프로세스에 적합한 모델입니다. 하지만 ‘DB백업’이나 ‘영상 인코딩’과 같이 단시간에 많은 컴퓨팅 용량이 필요한 경우 상당히 비효율적인 모델입니다. 서버리스 모델에서는 하나의 함수가 1회 호출될 때 사용할 수 있는 메모리 및 시간에 제한이 명확이 존재하기 때문입니다. AWS Lambda의 경우 최대 5분이라는 시간 제한이 존재하고, 해당 시간 내에 작업이 완료되지 않을 경우 새로이 함수를 호출해야 합니다. 지속시간이 긴 작업으로 인하여 특정 함수가 반복적으로 실행된다면, 일반적인 아키텍처 보다 더 많은 비용을 지출하게 될 수 있습니다.

3. 콜드 스타드(Cold Start)

서버리스 아키텍처에서 최초 함수를 호출하면 해당 함수가 준비되는 데 일정한 지연 시간(Cold Start)이 발생하게 됩니다. 또한 해당 함수가 약 5분 여 이상 호출되지 않는다면 이내 Cold상태로 바뀌게 되고 다시 호출 시 새로운 지연 시간(Cold Start)이 발생하게 됩니다.
더 나아가 개발 언어나 설정한 메모리 양에 따라 지연 시간(Cold Start)이 달라진다는 점도 고려되어야 합니다. 빠른 응답과 실시간 처리를 요구하는 작업이라면 서버리스 컴퓨팅이 아닌 다른 대안을 고려하는 것이 보다 바람직할 것입니다.

4. 복잡성(complexity)

서비스를 기본적인 단위로 하는 마이크로서비스 아키텍처와 달리 서버리스 아키텍처는 개발자가 작성한 각각의 함수 단위로 작동합니다. 따라서 보다 작은 단위로 함수를 세분화하여 관리하여야 하고, 잘게 세분화된 함수를 관리하는 것은 더 많은 노력을 필요로 합니다. 물론 각각의 클라우드 서비스 업체들이 제공하는 프레임웍을 활용할 수 있지만, 전통적인 단일 아키텍처를 업데이트 하는 것보다 복수의 함수를 관리하고, 업데이트하는 것은 훨씬 더 복잡할 수 밖에 없습니다.

5. 기술의 성숙도(Maturity)

서버리스 컴퓨팅은 비교적 새로운 기술에 해당합니다. 본격적으로 기업들이 해당 서비스를 이용하기 시작한 것은 불과 5년이 채 되지 않았습니다. 따라서 관련된 국내 레퍼런스나 대표적인 유스 케이스를 찾아보기가 어렵습니다. 더 나아가 디버깅이나 모니터링의 경우 벤더사가 제공하는 도구에 종속될 수 밖에 없습니다. 기존의 보안 테스트로 확인할 수 없는 취약점이 존재할 위험성 또한 기술의 성숙도 측면에서 고려되어야 합니다.

서버리스 컴퓨팅은 많은 가능성을 내포하고 있지만, 아직 충분한 검증이 이루어지지 않은 것이 사실입니다. 특정 서비스나 기능을 구현하기에는 서버리스가 최적의 선택이 될 수 있습니다. 하지만 제대로 구축되지 않은 아키텍처로 인하여 애플리케이션의 성능이 저하될 수 있고, 그로 인해 고객들을 잃게 될 수도 있습니다. 따라서 도입에 앞서 위의 사항들을 충분히 고려하여 적합한 서비스에 서버리스 컴퓨팅 기술을 활용하여야 합니다.