글로벌 칼럼 | 비용 절감…클라우드 송환만이 답은 아니다

'이제 클라우드 서비스를 회수하고 회사 데이터센터를 다시 한 번 재구축해야 할 때'라는 생각이 퍼지고 있다. 이른바 송환(repatriation), 즉 클라우드로 보냈던 작업을 온프레미스 또는 자체 관리 하드웨어로 되가져오는 행위다. 송환의 주된 명분은, 특히 경기 침체기에는 단순 명료하다. AWS, 애저 또는 기타 클라우드 호스팅 서비스를 사용하지 않고 자체 인프라를 구축하고 관리해서 비용을 절감한다는 것이다.

ⓒ Getty Images Bank

송환이라는 개념은 몇 년 전 앤드리슨 호로위츠가 올린 글에서 처음 관심을 모은 이후 꾸준히 확산하는 중이다. 베이스캠프(Basecamp)와 헤이(Hey, 유료 웹메일 서비스)를 만든 기업인 37시그널스(37Signals)는 송환을 실행하면서 그 방법에 관한 글을 블로그에 주기적으로 게시한다. 최근 한 설문 보고서에 따르면, 자체 호스팅으로 복귀하려는 주된 이유는 돈이다. 응답자의 45%가 비용 때문이라고 답했다.

송환에 대한 관심 증가는 어떻게 보면 당연하다. 클라우드는 경제 호황기에 힘입어 성장했지만, 이제 기업이 지출을 줄일 방법을 모색하면서 처음으로 하향 압력을 받고 있다. 아마존, 구글, 마이크로소프트, 기타 클라우드 제공업체들은 그동안 고객들의 후한 씀씀이에 기대어 돈을 잘 벌었다. 그러나 지금은 예산 삭감으로 인해 고객들의 지갑이 닫히고 있다.

클라우드가 지나치게 비싸졌다는 느낌이 들 때 가장 자연스러운 반응은 무엇일까? 당연히 송환 선언이다. "모두 회사 내로 다시 가져오라!"

쿠버네티스는 비싸다

지나고 보니 클라우드는 비쌌다. 클라우드를 더 잘 활용하기 위해 우리가 구축한 기술이 그 원인일 수 있다. 수많은 애드온 서비스가 있지만, 문제는 가장 기본적인 수준에서 발생한다. 클라우드 컴퓨팅에만 초점을 맞춰보자.

호스팅되는 가상머신(클라우드 컴퓨팅의 원조)의 최초 가치 제안은 전체 운영체제를 패키징해서 다른 곳으로 보내 실행할 수 있다는 것이었다. 그러나 이 설정에서 운영 부분(데브옵스와 플랫폼 엔지니어링 팀에 떠맡겼던 부분)은 결코 유쾌하지 않았다. 유지보수는 다루기 힘든 괴물인데 관리 툴은 원시적이니 개발자들은 참여하지 않았고, 배포는 한없이 느렸다.

이후 도커 컨테이너가 등장했다. 컨테이너는 개별 서비스의 패키지와 배포 측면에서 VM보다 유리했다. 개발자들은 손쉽게 컨테이너를 빌드할 수 있었고 시작 시간도 분이 아난 초 단위였다. 또한 구글의 쿠버네티스라는 작은 프로젝트 덕분에 컨테이너 애플리케이션 관리의 오케스트레이션이 가능해졌다.

그러나 이 '멋진 신세계'를 구축하는 사이 사람들이 인지하지 못했던 것이 있었다. 비용이 발생하고 있다는 사실이었다. 더 구체적으로 말하자면, 안정성을 명분으로 비용을 경시했다. 쿠버네티스에서 선호되는 애플리케이션 배포 방법은 실행 중인 모든 애플리케이션의 복제본을 최소 3개 이상 실행하는 것이다. 이를 정당화할 정도의 인바운드 부하가 없는 경우에도 마찬가지다. 클러스터의 모든 서버는 365일 24시간, (최소한) 3중으로 실행되면서 전력과 리소스를 소비한다.

그 위에 무거운 사이드카와 보조 서비스까지 겹겹이 쌓아 올렸고, 이런 것들은 모두 더 많은 리소스를 소비했다. 3노드 '스타터' 쿠버네티스 클러스터가 어느 순간 7노드가 됐고 그 다음에는 12노드가 됐다. 최근 CNCF의 설문조사에 따르면, 쿠버네티스 클러스터 중 노드 수가 50개 이상인 비율이 50%에 이른다. 클러스터 비용은 까마득히 높아졌고, 우리 모두는 빠듯한 새 예산에 어떻게든 쿠버네티스 클러스터를 끼워 넣을 방안을 찾기 위해 '비용 관리' 툴을 설치하는 옹색한 입장에 놓였다.

최근 필자는 한 지인과 이런 상황에 대해 토론했는데, 그는 지금 시점에서 회사의 쿠버네티스 클러스터 운영은 도박과 같은 상황임을 인정했다. 필요한 리소스에 맞춰 프로비저닝하는 것이 아니라 언더프로비저닝을 하고는 그저 한꺼번에 너무 많은 것이 실패하지 않기를 바랄 뿐이다. 지인의 회사는 클러스터의 규모를 계속 줄였다. 모든 서버의 시작 요구사항이 상호 트리거되는 경우 전체 클러스터의 리소스가 소진되어 다시 시작할 수 없는 상황이 되기 직전까지 줄였다. 더 넓게 보면 이제 소소한 비용 절감을 위해 안정성과 마음의 평화를 포기하는 패턴이 나타나고 있다.

송환이라는 말에 귀가 솔깃한 것은 당연하다.

클라우드에서 문제를 해결할 수 있는가?

질문을 바꿔보자. 소비 중인 리소스의 양을 대폭 줄일 수 있는 아키텍처의 변화가 있다면? 허리띠를 졸라매고 아무 일도 없기를 바라는 것이 아니라, 비용 지속가능성이 더 높은 방식으로 서비스를 구축함으로써 쿠버네티스 클러스터를 한 자릿수 규모로 다시 줄일 수 있다면 어떨까?

기술과 프로그래밍 패턴은 이미 존재한다. 방법은 바로 서버리스 웹어셈블리(WebAssembly)다.

이 용어를 한 번에 하나씩 살펴보자.

서버리스 함수는 큰 인기를 끌고 있는 개발 패턴이다. 최대 클라우드 제공업체인 AWS가 매달 실행하는 서버리스 함수의 수는 10조 개에 달한다고 한다. 상상하기 어려울 정도의 방대한 규모다. 개발자들이 이 방식을 높이 평가하고 있고, 이들이 구축하는 것이 인기가 있음을 나타내는 수치다.

서버리스 함수를 이해하기 위한 최선의 방법은 이벤트 핸들러로 생각하는 것이다. 특정 이벤트(HTTP 요청, 대기열에 도착한 항목 등)가 특정 함수를 트리거한다. 함수가 시작되고 요청을 처리한 다음 즉시 종료된다. 즉, 함수는 밀리초, 몇 초 또는 몇 분 동안 실행되고 끝난다.

그렇다면 서버리스에서 '서버'는 무슨 말일까? 서버 하드웨어는 이제 과거의 산물이라는 무모한 주장이 아니다. '서버리스'는 소프트웨어 설계 패턴에 대한 설명이다. 장기간 실행되는 서버 프로세스는 없다. 우리는 함수, 즉 이벤트 핸들러 하나를 작성할 뿐이고 이벤트 핸들러의 호출 트리거는 이벤트 시스템에 맡긴다.

또한 이런 정의에 따라 서버리스 함수는 서비스, 심지어 기존 마이크로서비스보다도 훨씬 더 쉽게 작성할 수 있다. 서버리스 함수에 코드가 덜 필요하다는 단순한 사실은 곧 개발, 디버깅 패치 작업이 줄어든다는 것을 의미한다. 이는 그 자체로 중대한 결과를 가져올 수 있다. 데이비드 앤더슨은 저서 '밸류 플라이휠 효과(The Value Flywheel Effect)'에서 "리버티 뮤추얼(Liberty Mutual)의 웹 애플리케이션 하나를 서버리스 방식으로 다시 쓴 결과, 유지보수 비용이 연간 5만 달러에서 10달러로, 99.89% 절감됐다"라고 전했다(데이비드 앤더슨, 밸류 플라이휠 효과, 27p).

서버리스로 전환할 때 자연스럽게 얻는 또 다른 결과는 더 작은 덩어리의 코드를 더 짧은 기간 동안 실행하게 된다는 것이다. 클라우드 컴퓨팅 비용은 얼만큼의 시스템 리소스(CPU, 메모리)가 필요한지, 그리고 이런 리소스에 얼마나 오래 액세스해야 하는지의 조합에 따라 결정된다는 점을 감안하면 서버리스가 더 저렴하다는 것은 명확하다. 사용량이 더 적고 며칠이나 몇 주 또는 몇 달이 아닌 몇 밀리초, 몇 초 또는 몇 분 동안 실행되기 때문이다.

과거의 1세대 서버리스 아키텍처는 비용을 어느 정도 줄여줬지만 실제로 내부에는 대규모 런타임이 있었고, 시간이 갈수록 함수가 처리하는 요청이 점점 더 증가함에 따라 서버리스 함수의 비용도 상당히 증가했다.

바로 이 부분에서 웹어셈블리가 등장한다.

웹어셈블리는 더 나은 서버리스 런타임

고도의 보안성을 갖춘 격리된 런타임인 웹어셈블리는 서버리스 함수를 위한 좋은 가상화 전략이다. 웹어셈블리 함수의 콜드 스타트에 소요되는 시간은 1밀리초 미만이며 실행에 필요한 CPU와 메모리도 많지 않다. 즉, 시간과 시스템 리소스를 줄여 비용을 절감할 수 있게 해준다.

얼마나 절감될까? 비용은 클라우드와 요청의 수에 따라 달라지지만 컨테이너만 사용하는 쿠버네티스 클러스터와 웹어셈블리를 사용하는 클러스터를 비교해 볼 수는 있다. 쿠버네티스 노드 하나는 이론적으로 최대 250개 이상의 포드를 실행할 수 있다. 대부분의 경우 중간 용량의 가상 머신은 수십 개의 컨테이너만으로 메모리 및 처리 성능 한계에 도달한다. 컨테이너는 활동하는 기간 내내 리소스를 소비하기 때문이다.

퍼미온(Fermyon)은 중간 크기의 쿠버네티스 클러스터 노드에서도 수천 개의 서버리스 웹어셈블리 앱을 일상적으로 실행해 왔다. 최근에는 2워커 노드 클러스터에서 5,000개의 서버리스 앱을 부하 테스트하면서 10초 동안 150만 회 이상의 함수 호출을 달성했다. 퍼블릭 프로덕션 시스템인 퍼미온 클라우드(Fermyon Cloud)는 각 8코어 32기가바이트 가상머신에서 3,000개의 사용자 구축 애플리케이션을 실행한다. 이 시스템은 18개월 이상 프로덕션에서 운영되고 있다.

간단히 말해, 밀도와 속도를 통해 효율성을 달성했다. 효율성은 곧 비용 절감으로 이어진다.

송환보다 더 안전한 방법

송환은 비용 절감을 위한 한 가지 방법이다. 또 다른 방법은 개발 패턴을 장기 실행 서비스에서 웹어셈블리 기반 서버리스 함수로 전환하는 것이다. 이 두 가지는 상호 배타적이지는 않지만 둘 중 하나는 위험도가 높은 방법이다. 클라우드에서 온프레미스로의 전환은 비즈니스의 변화를 일으키는 방법인데, 더 나은 방향으로의 변화가 아닐 가능성도 있다.

송환은 클라우드 비용 지출을 통제하기 위한 최선의 방법은 모든 것(모든 쿠버네티스 클러스터와 프록시, 로드 밸런서 등)을 직접 관리하는 물리적 공간으로 다시 가져오는 것이라는 생각에 근거한다. 물론 이를 위해서는 공간, 하드웨어, 대역폭 등을 구매해야 한다. 또한 운영팀의 사고방식을 소프트웨어와 서비스에서 하드웨어 관리로 전환해야 한다. 서버 랙을 쌓고 고장 난 하드웨어 문제를 해결하고 그 과정에서 자정을 넘기는 시간까지 일했던 기억(좋은 기억은 아님)을 갖고 있는 필자로서는 송환이라는 말에서 결코 기분 좋은 기대감을 느낄 수 없다.

온프레미스로의 복귀는 큰 작업이고, 나중에 일이 틀어졌다고 해서 되돌리기도 어려운 결정이다. 또한 전환이 완료될 때까지는 비용 절감을 확인할 수 없다. (사실 전환 작업에 들어가는 자본 비용으로 인해 비용 절감 효과가 실현되기까지 오랜 시간이 걸릴 수 있다.)

반면 웹어셈블리 기반 서버리스 기능으로의 전환은 비용도, 위험 부담도 더 낮다 이러한 함수는 쿠버네티스 내부에서 실행이 가능하므로 몇 가지 대표적인 서비스를 잘라내서 다시 쓴 다음 결과를 분석하는 것만으로도 비용 절감 효과를 테스트할 수 있다.

마이크로서비스 스타일의 아키텍처에 이미 투자한 기업이라면 멀티서비스 애플리케이션의 일부분만 재구축할 수 있는 준비가 이미 돼 있는 것이다. 마찬가지로, 데이터 변환 파이프라인과 같은 이벤트 처리 체인에 투자한 기업도 시퀀스에서 실험용 테스트베드로 사용할 만한 한두 개의 단계를 쉽게 찾을 수 있을 것이다.

진입 장벽이 더 낮을 뿐만 아니라, 이 방식이 효과적이든 아니든 원한다면 언제든 송환을 선택할 수도 있고 이를 위해 뭔가를 다시 되돌리는 작업도 불필요하다. 웹어셈블리 서버리스 함수는 클라우드와 마찬가지로 온프레미스에서도(또는 엣지나 다른 어느 곳에서도) 잘 실행되기 때문이다.

무엇을 대가로 하는 비용 절감인가?

지금은 클라우드 비용을 관리하는 방법을 배워야 할 때다. 송환보다 훨씬 덜 극단적이고 덜 위험한 방법이 있다. 유행에 편승해 서버 랙을 가득 채우기 전에 더 값싸고 쉬운 솔루션을 먼저 살펴보는 편이 현명하다. 게다가 필자의 생각이 틀렸다 해도 오픈소스 서버리스 웹어셈블리 함수는 손쉽게 송환이 가능하다. 서버리스 웹어셈블리 함수는 과거를 주도했던 기술보다 더 가볍고, 빠르고, 저렴하고, 효율적이다.

클라우드 네이티브 웹어셈블리를 시작하는 한 가지 쉬운 방법은 오픈소스 스핀(Spin) 프레임워크다. 쿠버네티스가 대상 배포 환경이라면 오픈소스 스핀큐브(SpinKube)를 통해 클러스터 내 서버리스 웹어셈블리 환경을 설치하고 관리하면 된다. 몇 분만 사용해 보면 클라우드 리소스를 더 잘 활용하는 더 효율적인 애플리케이션을 구축하는 것이 비용 관리 측면에서 송환보다 더 나은 해결책이 될지 여부를 판단할 수 있을 것이다.

*Matt Butcher는 Fermyon의 CEO다.
editor@itworld.co.kr

Matt Butcher editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지