이번 글에서는 서버리스와 컨테이너에 대해서 설명하고자 한다.

일을 하다보니, VM을 이용할 경우 유후 시간이 많을 때 비용이 최적화되지 못하다는 느낌이 많이 들었다.

서버리스는 서버 프로비저닝 및 유지 관리를 추상화하는 클라우드 아키텍처 모델이다.

FaaS(Function-as-a-Service)라 불리며, 필요에 따라 코드를 실행하는 개념이고 실행 후 종료된다.

일반적으로 FaaS와 Container를 많이 비교하곤 한다. FaaS와 Container는 몇 가지 공통점이 존재한다. 분산 시스템 및 대규모 애플리케이션 개발에 특화 되어 있고 관리상의 번거로움을 제거하고 애플리케이션과 비즈니스의 가치에 집중하고자 하는 목적이 있다.

Container

애플리케이션을 박스에 담아 어디서든 실행 할 수 있다면 좋지 않을까? 호스트 시스템이 무엇이든, 어디에 위치하든 상관없이…

이것이 컨테이너화의 아이디어이다. 필요한 모든 종속성이 사전에 설치되어 있는 컨테이너를 만들고 안에 애플리케이션을 넣고 컨테이너 런타임이 설치된 모든 곳에서 실행되게 한다.

이런 장점으로 인해 많은 기업이 컨테이너를 채택했고, 표준으로 정의되었다. 오늘날 대부분의 클라우드 제공사는 컨테이너화된 애플리케이션을 호스팅하는 방법을 제공하고 있다.

컨테이너의 장점

• 제어 및 유연성
• 공급 업체에 Lock-In 되지 않음
• 쉬운 마이그레이션
• 휴대성

컨테이너의 단점

• 관리 작업 (e.g. 패치 적용)
• 확장 속도가 느림
• 유지비용
• 처음 시작시 Learning Curve가 존재
• 수동 개입이 필요

Serverless (FaaS)

서버리스의 기본 전제는 애플리케이션(모든 비즈니스 로직)이 기능과 이벤트로 구현된다는 점이다.

클라우드 제공사가 어떤 일이 있어도 기능을 사용할 수 있도록 보장한다.

2014년도에 서버리스 컴퓨팅이 처음 도입되었을 때, 워크로드가 상당히 제한된 상태였고 이미지 혹은 데이터 처리와 같은 소규모 작업에만 사용되었었다. 하지만 AWS가 Lambda의 이벤트 소스로 API Gateway를 도입한 후 모든 것이 바뀌게 되었다. 서버리스 컴퓨팅으로 구동되는 전체 API를 만드는 것이 가능하게 되었다. 점점 더 많은 서비스가 Lambda 제품과 통합되어 복잡한 상황의 애플리케이션을 구축할 수 있게 되었다.

서버리스의 장점

• 관리 필요 없음
• 사용시에만 비용 지불
• 유휴 시간 비용 없음
• 자동 확장
• 시장 출시 시간 단축
• 마이크로 서비스 특성 → 명확한 코드 분리
• 관리 부담 대폭 감소

서버리스의 단점

• 블랙 박스 환경
• 공급 업체 종속
• 콜드 스타트
• 아주 복잡한 앱을 구축하기 어려울 수 있음

서버리스는 서버 또는 가상머신을 프로비저닝하고 관리할 필요가 없다.

AWS를 예를 들면, EC2서버를 프로비저닝 할 필요 없이 프로그래밍 언어로 작성된 코드를 실행할 수 있다. 내부적으로는 Lambda가 임시 마이크로 컨테이너를 생성하고 코드를 실행하고 결과를 반환하는 역할을 수행한다. 따라서 인프라를 관리할 필요가 없어지게 된다. 개발자는 코드를 배포하고 실행하기만 하면 된다.

흔히, 이런 코드들도 서버에서 실행되기 때문에 서버리스라는 용어가 잘못된 것이라고 주장하는 이들도 있지만, 개발자의 관점에서 서버 처리가 필요하지 않다는 점이 중요하다.

서버 기반 시스템은 주어진 기간 동안 사용한 리소스에 대해 요금을 청구한다. (e.g. EC2는 시간단위로 청구됨)

반면 서버리스는 실제 사용량을 청구한다. 사용하지 않을때는 비용이 청구되지 않는다.

AWS의 Lambda의 경우, 함수 코드 1백만건에 대해 0.2USD, 요청당 0.0000002USD만 청구하고 해당 기능이 동작하기 위해 필요한 메모리의 양에 따라 추가 요금이 부과된다.

이 가격 모델은 고정 비용을 가변 비용으로 전환하기에 스타트업 및 중소형 애플리케이션에 유리하다.

대규모 애플리케이션에서도 유리할 수 도 있다. 피크 타임때 기존 인프라에서는 프로비저닝을 미리 해야하기에 유휴 리소스에 대한 추가 비용이 생기기 때문이다.

예를 들어서, 미국내 뉴스 및 엔터테인먼트 서비스인 Bustle은 IT지출이 약 84% 감소했다. 유지 보수 직원이 자체 서버를 관리하는 비용 대비 저렴하기 때문이다.

서버리스 비용 계산은 여기를 참고하길 바란다.

“우리가 프로젝트를 진행할 때 어떤 기술을 선택해야 할까? 아마도 상황에 따라 다를 것이다.”

컨테이너를 선택해야 하는 경우

컨테이너를 사용하면 기본 운영 체제를 선택하고 설치된 프로그래밍 언어 및 런타임 버전을 완전히 제어할 수 있다. 따라서 특정 버전에 대한 요구사항이 있는 소프트웨어를 활용할 경우 유용하다.

대규모 컨테이너에서 서로 다른 소프트웨어 스택을 사용하여 컨테이너를 운영할 수 있다. 특히 오래된 레거시 시스템을 컨테이너 환경으로 마이그레이션을 해야 하는 경우 매우 유용하다.

하지만 이러한 유연성에는 운영 비용이 함께 제공된다. 컨테이너는 여전히 많은 유지 관리 및 설정이 필요하다.

최대한 이점을 취하려면 Monolithic 애플리케이션을 마이크로 서비스로 분리해야 하며, 이를 개별 컨테이너 그룹으로 이용해야 한다. 또한 정기적으로 업데이트를 통해 운영 체제를 최신 상태로 유지해야 하는 번거로운 작업을 수행해야 한다.

트래픽이 없는 경우, 완전한 종료가 불가능하다. 따라서 항상 런타임 비용이 지불해야 한다는 점을 고려해야 한다.

서버리스를 선택해야 하는 경우

서버리스는 트래픽을 자동으로 감지하고 즉시 처리해야 하는 경우 유용하다. 트래픽이 전혀 없으면 애플리케이션이 완전히 종료된다. 사용한 리소스에 대해서만 비용을 지불하게 된다.

서버리스로 개발하게되면 기본 인프라 관리에 대해 신경 쓸 필요가 없다. 최종 사용자에 대한 코드와 비즈니스 가치에만 집중하면 된다. 설정이나 프로비저닝 없이 코드를 더 빠르게 전달 할 수 있기에, 개발시간이 빨라질 수 있다.

그러나 현재 몇가지 제약이 존재한다. 프로그래밍 언어 및 런타임은 공급자가 지원하는 범위내에서 사용 가능하다.

또한, 인프라와 코드가 너무 분리되어 있으면 애플리케이션 스택의 모든 부분에 대해 추론하기가 어려워진다.

결론

유연성이 필요하거나 레거시 서비스를 마이그레이션 해야 하는 경우에는 컨테이너를 선택하고 개발 속도, 자동 확장 및 현저히 낮은 런타임 비용을 지불하고 싶으면 서버리스를 선택하는 것을 고려했으면 한다.