컨테이너와 MSA의 확산을 시작으로 클라우드 비용을 낮추고 별도 서버 관리 필요성이 없다는 점으로 인해 서버리스 컴퓨팅 시장은 점차 활개를 띨 것으로 예상된다. 시장조사기관 마켓앤마켓(Markets and Markets)은 서버리스 아카텍처 시장 규모가 지난 2018년에 총 42.5억 달러를 형성했으며, 연평균 29%씩 성장해 2023년에는 149.3억 달러에 이를 것이라는 전망을 내놨다.

이미 AWS 람다(Lambda)를 시작으로 애저 펑션, 구글 클라우드 펑션 등 퍼블릭 클라우드 사업자들이 서버리스 서비스들을 속속 출시했으며, 국내외에서 점차 커지는 서버리스 컴퓨팅 시장에 대응하기 위한 노력을 지속하고 있다.

삼성SDS는 이스라엘의 서버리스 컴퓨팅 분야 선도 기업 이과지오(Iguazio)에 투자를 단행했다. 삼성SDS는 이과지오의 서버리스 플랫폼을 자사 PaaS에 탑재해 서비스로 제공하고, 관련 기술 협력을 강화하기 위해 투자를 추진했다고 설명했다. 이처럼 삼성SDS는 차별화된 미래 핵심 기술을 적기에 확보하고, 투자를 통한 비유기적(Inorganic) 성장 확대를 도모하고 있다.

네이버 비즈니스 플랫폼(NBP)은 자사 클라우드 서비스인 ‘네이버 클라우드 플랫폼’에 서버리스 컴퓨팅 상품 ‘클라우드 펑션(Cloud Functions)’을 추가했다. 이를 통해 고객들이 서버 없는 백엔드를 구축해 웹, 모바일, IoT 등 다양한 API 요청을 처리할 수 있도록 했으며, 향후에는 네이버의 인공지능(AI) 기술인 클로바 API와도 연동해 사용자 편의성을 더욱 확대한다는 방침이다.

효성인포메이션시스템이 국내에 공급하는 히타치 밴타라의 HSPC(Hitachi Storage Plug-in for Containers)는 플래시 클라우드 솔루션인 히타치 VSP(Hitachi Virtual Storage Platform) F/G 시리즈에 탑재돼 컨테이너 환경에 영구 스토리지(persistent storage)를 제공하고, 동적 볼륨 할당뿐 아니라 고급 스토리지 관리를 지원하는 플러그인 소프트웨어다.

도커 스웜(Docker Swarm) 및 쿠버네티스 기반의 컨테이너 오케스트레이션 자동화 플랫폼에 연동돼 컨테이너용 볼륨을 동적으로 최소 1만6000개에서 최대 6만4000개까지 생성할 수 있어 서버리스 컴퓨팅의 기반이 되는 컨테이너의 확장성을 보장한다.

또한 HSPC는 컨테이너를 최대 6만 개 이상 17PB까지 생성하고, 100만 개 스냅샷을 지원하는 VSP 기반 클라우드 환경에서 성능 모니터링, 원격 장애 처리 지원 등 검증된 고급 스토리지 관리 기능을 제공한다. 이에 컨테이너 환경의 100% 데이터 가용성을 보장하고, 클라우드 및 서버리스 컴퓨팅 환경을 구현하는데 있어 리스크를 최소화하도록 돕는다.

피보탈은 지난해 클라우드 네이티브 플랫폼 중 하나인 피보탈 클라우드 파운드리(PCF: Pivotal Cloud Foundry) 2.0에 서버리스 컴퓨팅 제품인 ‘피보탈 펑션 서비스(PFS: Pivotal Functions Service)’를 추가했으며, 레드햇은 지난해 구글 주도로 새롭게 시작된 오픈소스 프로젝트 ‘K네이티브(Knative)’에 참여하면서 쿠버네티스 위에서 동작하는 서버리스 솔루션 확보에 나섰다.

클라우드 종속 없어…온프레미스도 지원
컨테이터 워크로드 관리는 쿠버네티스가 사실상 표준으로 자리 잡았지만 여전히 쿠버네티스의 자원 설정 등은 개발자가 해줘야 한다는 문제가 존재한다. 이는 컨테이너가 추구하는 셀프 서비스와는 더욱 거리가 멀다. 대안으로 서버리스를 활용하는 방법이 있지만, 서버리스는 특정 클라우드 플랫폼에 의존성을 갖고 있다.

CNCF(Cloud Native Computing Foundation)의 후원으로 진행되는 K네이티브는 이러한 문제들을 해결하기 위해 등장한 오픈소스 서버리스 솔루션 프로젝트로, 쿠버네티스가 소스 중심 컨테이너 기반 최신 애플리케이션을 구축하는데 필수적인 일련의 미들웨어 구성 요소를 제공한다. 클라우드 데이터센터 외에도 온프레미스에 설치해 활용이 가능한 것이 특징이다.

프로젝트에 속한 각 구성 요소는 일반적인 패턴을 식별하고, 실제 쿠버네티스 기반의 성공적인 프레임워크 및 응용프로그램과 공유되는 모범 사례를 체계화하는데 목적이 있다. 특히 컨테이너 배포, 워크로드 크기에 따른 자동 확장 등 반드시 필요하면서도 어려운 작업의 문제를 해결하는데 초점이 맞춰져있다.

K네이티브는 크게 빌드(Build), 이벤팅(Eventing), 서빙(Serving)의 3가지 컴포넌트로 구성된다. 빌드는 소스코드로부터 서버리스 애플리케이션을 만들어내는 역할을 하며, 이벤팅은 요구사항이 발생했을 때 이를 관리하고 전달한다. 서빙은 서버리스 애플리케이션을 동작시키고, 작업이 끝났을 시 이를 다시 내려주는 역할에 부하가 더 들어왔을 경우 오토스케일링(Auto Scaling)까지 처리하는 사실상의 메인 기능을 맡는다.

서비스 메시(Service Mesh) 기능도 쿠버네티스와 함께 컨테이너 관리에 반드시 필요한 기능이다. 엔터프라이즈 서비스 버스(ESB: Enterprise Service Bus) 구조를 MSA로 만들 경우 하나의 덩어리였던 기능들이 잘게 쪼개지는 만큼 가시성이 떨어지는 문제가 발생할 수 있는데, 서비스 간 호출이 원활히 이뤄지는지의 여부를 확인하는 것이 어렵다.

이럴 경우에 대비해 가시성을 높여주는 기능으로 서비스 메시가 활용되며, 매 순간 서비스를 찾고 연결하는 과정을 자동으로 진행해주기 때문에 개발자 혹은 관리자의 부담을 줄여준다. 그뿐만 아니라 트래픽 분산, 사용자 리포팅 등 다양한 기능도 제공하기에 컨테이너 기반 환경 운영을 위한 필수품으로 자리를 잡아가고 있다.

인건비 절감에 일조
MSA는 블록을 조립하듯이 기능별 조합을 통해 새로운 서비스를 빠르게 만들 수 있으며, 각 기능별 최적의 개발 언어나 프레임워크를 선택해 활용하는 폴리그랏(Polyglot)도 가능하다는 장점이 있다.

이 같은 환경을 구현하려면 뒷받침되는 인프라가 필요하다. 그러나 아무리 개발과 운영을 결합한 데브옵스(DevOps) 개념이 확대되고 있더라도 소프트웨어 개발자가 서버 등 인프라 환경을 구성하는 것은 결코 쉬운 일이 아니다. 가령 이 모든 것을 할 수 있는 이른바 ‘풀스택(Full Stack)’ 개발자가 있다 하지만, 이들의 몸값은 일반적인 소프트웨어 개발업체에서 감당하기 어려운 수준이다.

국내 3D 공간데이터 플랫폼 기반 스타트업 어반베이스(Urbanbase)는 MSA 구현을 위해 서버리스 컴퓨팅 서비스인 AWS 람다를 선택했다. 별도의 인프라 프로비저닝이 필요 없고 오토스케일링을 지원하기 때문에 인프라 구성에 대한 고민을 할 필요가 없다는 것이 장점이었다. 서비스 개발을 위해 필요한 테스트와 개발 완료 이후 배포 역시 편의성이 좋아졌다.

다만 서버리스에서도 단점은 존재한다. 대표적인 것이 콜드 스타트로, 기능을 구현하기 위한 서비스가 서버에서 내려가 있다가 다시 호출이 들어오면 기동되기까지 시간 지연이 발생하는 현상이다. 비록 서비스 이용에 문제가 되는 것은 아니지만, 해당 시간 동안 사용자는 서비스가 느리다는 경험을 하게 된다. 어반베이스는 이를 극복하고자 1분마다 헬스 체크를 진행, 지속적으로 서비스 API가 구동 상태를 유지할 수 있도록 했다.

회사 측은 소프트웨어 개발자들이 인프라 구성에 대한 고민 없이 본연의 업무에만 집중할 수 있는 환경을 구성하는데 주력했으며, 향후에는 모든 개발이 100% 서버리스 환경에서 이뤄질 수 있도록 하겠다는 계획을 전했다.

“서버리스 아키텍처로 IT 인프라 전환, 비즈니스 가치 높여” 롯데정보통신은 롯데인터넷백화점, 롯데닷컴, 인터넷면세점, 롯데마트, 롯데홈쇼핑 등 롯데그룹이 보유하고 있는 이커머스 사업 경쟁력을 확보하고, 서비스 간 시너지를 위해 기존 7개 이커머스 사이트를 통합하는 프로젝트를 진행했으며, 그 결과 한 번의 로그인으로 7개 사이트를 넘나들며 이용 가능한 롯데On 서비스를 론칭했다. 기존에 운영되던 서비스들은 모놀리식 아키텍처였기에 과거 비즈니스 환경에서는 문제가 없었지만, 최근 IT 환경 변화와 새로운 마케팅 기법이 등장하면서 이를 제대로 수용하기 어렵다는 문제가 있었다. 이에 모든 서비스를 클라우드에서 제공하겠다는 방침 아래 빅뱅(Big bang) 방식으로 서비스 이전에 나섰고, 그 과정에서 서버리스 아키텍처를 도입했다. 이는 고객들에게 더 나은 비즈니스 가치를 제공하기 위함이었다. 모놀리식 앱의 한계를 극복하기 위해 20여 개의 MSA로 분리했으며, 그 과정에서 250여 개의 람다 함수와 다이나모 DB를 활용해 주문 시스템을 서버에서 자동으로 설계할 수 있도록 구성했다. 이를 기반으로 탄력적인 인프라 환경과 비즈니스 민첩성을 확보할 수 있었으며, 서버리스를 통해 핵심 역량에만 집중할 수 있는 효과를 거뒀다. 또한 장애가 발생하더라도 서비스 중단 없이 해결이 가능해졌으며, 단 며칠 사이에 몇십억 건의 콜이 들어와도 소화가 가능할 정도가 됨으로써 고객에게 더 큰 가치를 제공할 수 있게 됐다. 특히 서버리스는 시스템 운영 관점에서도 유휴 시간에 과금되지 않기 때문에 비용을 절감할 수 있는 효과까지 거둘 수 있게 됐다. 흔히 클라우드를 이용하면 비용 절감이 가능하다고 하지만, 실제로는 아무 것도 하지 않는 것이 가장 아끼는 방법이다. 실제 클라우드로 마이그레이션을 하게 될 경우 어떤 비즈니스 가치를 높일 지에 중점을 두고 접근해야 프로젝트의 성공을 높일 수 있다.

애플리케이션 운영 방식 고려해야
서버리스는 서비스 개발·배포 시간을 단축시키고, 이용한 만큼만 비용을 지불하면 되기 때문에 기업과 개발자 모두에게 매력적인 옵션임은 분명하다. 그러나 모든 방식을 서버리스로 구현해야 할 필요는 없다. 서버리스 애플리케이션은 모놀리식 아키텍처 대비 완전히 새롭게 개발해야 하는 것과 마찬가지며, 반 강제적으로 MSA를 구현해야 하기 때문이다.

또한 지연시간(Latency)에 민감한 애플리케이션의 경우에도 서버리스 적용에 신중할 필요가 없다. 물론 WAS의 지연시간에 비할 바는 아니지만, 함수 호출을 통해 컨테이너 서비스가 기동되는 시간은 필요로 하는 만큼 해당 사안에 대한 고려는 반드시 필요한 부분이다.

또한 함수 동시 처리 개수에 제한이 따른다는 점도 서버리스 구현의 제약으로 작용한다. 이는 반복을 유발할 수 있는 프로그래밍 오류로 인해 비용이 과다 청구되는 것을 방지하기 위한 부분으로, 동시접속자가 많은 서비스나 지속적으로 컴퓨팅 자원을 점유하면서 사용하는 서비스 등에도 적합하지 않다.

보안에 대한 부분도 빼놓아서는 안 된다. MSA 기반의 API 활용이 늘어난다는 것은 그만큼 엔드포인트와의 접점이 늘어나는 것을 의미한다. 비록 중간에 API 게이트웨이가 위치하고 있다 하더라도 기업 내부 시스템이 외부에 노출될 수 있는 여지는 있는 만큼 클라우드 보안에도 각별한 신경을 써야 한다.