아마존 프라임 비디오의 ‘서버리스 vs. 모놀리스’ 논란에서 얻는 6가지 교훈

최근 한 기업의 소프트웨어 개발팀이 서버리스 아키텍처 프로젝트를 버리고 모놀리스를 도입해서 클라우드 인프라 비용을 90% 절감했다는 내용의 블로그 글을 올리며 뜨거운 논란을 불러일으켰다. 더구나 이 글은 다른 누구도 아닌 아마존 프라임 비디오의 선임 소프트웨어 개발 엔지니어 마신 콜니가 쓴 글이었다.
 

아마존은 클라우드 서비스 시장의 리더임은 말할 것도 없고 서버리스 컴퓨팅을 앞장서서 지지하는 대표적인 기업이다. 따라서 문제의 글을 본받을 만한 개방성을 보여주는 행동으로 평가하는 사람도 있고, 전형적으로 회사의 뒤통수를 때리는 행동이라고 평가하는 사람도 있다. 어느 쪽이든 이 블로그 글은 소셜 미디어 플랫폼에서 다음과 같은 주제로 열띤 논쟁을 촉발했다.
 

• 그동안의 서버리스/마이크로서비스/SOA(Service-Oriented Architecture)에 관한 온갖 호들갑은 결국 과대포장이었나?
• 소프트웨어 개발에 대한 전통적인 모놀리식 접근법이 과소평가되었는가?
• 일부 기업이 클라우드에서 데이터센터로 앱을 다시 옮기고 클라우드 우선 전략을 재고하는 등 현재 클라우드 전반에서 일어나고 있는 현상과 비슷한 시장 조정이 필요한 시점인가?

소동이 어느 정도 가라앉은 지금, 프라임 비디오 팀의 경험을 면밀히 살펴보면 기업에서 앞으로 적용할 수 있는 몇 가지 중요한 교훈을 얻을 수 있다. 그러나 이에 못지않게 중요한 점은 이들이 직면했던 문제는 조기에, 즉 애플리케이션 계획 프로세스를 시작할 때 네트워킹 전문가들의 의견을 반영해야 할 필요성도 잘 보여준다는 것이다.

무엇이 문제였는가?

가장 먼저 해야 할 질문부터 보자. 이 문제가 광범위하고 일반적인 의미를 갖는 사례일까? 아마존 팀은 실시간 비디오 스트림을 다루는 일을 하므로 엄밀히 말해 일반적인 엔터프라이즈 앱 사례는 아니다. 그러나 관련된 교훈은 데이터 집약적인 저지연 애플리케이션이 포함되는 모든 개발 프로세스에 보편적으로 적용된다.

프라임 비디오는 비디오 스트림에서 비디오 멈춤 또는 오디오와 비디오의 동기화 어긋남과 같은 품질 문제를 분석하기 위한 툴을 만들고 있었다. 여러 단계로 구성된 복잡한 프로세스로, 미디어 컨버터가 스트림을 비디오 프레임과 오디오 버퍼로 분할하면 이렇게 분할된 데이터가 결함 탐지기로 전달되는 구조다. 결함 탐지기는 알고리즘을 사용해서 결함을 식별해 실시간 알림을 보내는 소프트웨어이며, 자체 마이크로서비스로 실행 중이었다.

팀이 해당 애플리케이션의 규모를 확장하기 시작하자 2가지 문제가 발생했다. 아마존 S3 스토리지를 대상으로 한 고부하 호출이 너무 많고 프로세스의 오케스트레이션이 어렵다는 점이다.

아마존 프라임 비디오 팀은 “초기 솔루션은 서버리스 구성요소(가령 AWS 스텝 펑션 또는 AWS 람다)를 사용하는 분산 시스템으로 설계했고, 신속하게 서비스를 구축하기 위한 좋은 선택이었다. 이론적으로는 각 서비스 구성요소를 독립적으로 확장할 수 있는 설계였다”라고 말했다.

그러나 “일부 구성요소를 사용한 방식으로 인해 예상된 부하의 5% 정도에서 확장의 한계에 이르렀다. 또한 대규모로 해당 솔루션을 채택하기에는 모든 빌딩 블록의 전체적인 비용이 너무 높았다. 문제를 해결하기 위해 모든 구성요소를 하나의 프로세스로 옮겨 데이터 전송을 프로세스 메모리 내에 유지했고, 이를 통해 오케스트레이션 로직도 간소화했다”라고 설명했다.

전반적인 아키텍처는 그대로 유지됐으며, 원래의 코드를 재사용해서 새 아키텍처로 신속하게 마이그레이션해서 워크플로우를 하나의 아마존 ECS(Elastic Container Service) 작업으로 통합했다.

팀은 블로그에서 “서비스를 모놀리스로 이전한 결과 인프라 비용이 90% 이상 줄었고 확장 역량도 증대됐다. 현재 우리는 수천 개의 스트림을 처리할 수 있고 서비스를 지금보다 더 확장할 용량까지 갖추고 있다”라고 썼다.

엇갈린 반응

이 글은 소셜 미디어에서 논쟁을 불러일으켰다. SaaS 솔루션 제공업체 37시그널스(37signals)의 CTO 데이비드 하이네마이어 핸슨도 즉시 논쟁에 뛰어들었다. 최근 핸슨은 회사의 애플리케이션과 데이터를 아마존 퍼블릭 클라우드에서 빼내기로 하면서 논쟁을 촉발한 바 있다.

핸슨은 블로그에서 “마이크로서비스 우선 아키텍처가 합리적인 경우도 있다는 것을 부정하지는 않는다. 다만 극히 드물 뿐이다. 대다수 시스템은 ‘장엄한 모놀리스’로 시작해 유지하는 편이 훨씬 더 효과적”이라고 썼다.

핸슨은 마이크로서비스/SOA 접근 방법이 대규모 엔터프라이즈와 하이퍼스케일러에는 적합하지만, 그보다 작은 기업의 경우 효과를 장담할 수 없다면서 “아마존, 구글 또는 개발자가 수천 명이 있는 다른 소프트웨어 기업이라면 마이크로서비스/SOA는 개선의 기회를 병렬화하기 위한 좋은 방법이다. 각 서비스마다 자체 팀, 자체 타임라인, 담당자, 목표가 있다. 적어도 어느 정도는 전체 환경 내의 다른 부분에서 일어나는 일과는 독립적으로 발전할 수 있다. 특정 규모에 도달하면 그 외의 다른 합리적인 조율 방안이 없다. 이 방법이 아니라면 모두가 서로의 발등을 밟게 되고 끝없는 병합 충돌을 처리해야 할 것”이라고 말했다.

그러나 애플리케이션을 여러 조각으로 나누면 복잡성이 커질 수 있다. 핸슨은 “객체 간 협업에서 시스템 간의 협업으로 추출할 때마다 수많은 책임과 장애 상태가 있는 골칫덩어리를 받아들게 된다”라고 지적했다.

이어 오늘날의 기술 문화에서 전통적인 모놀리식 애플리케이션은 “조롱의 대상”이 됐지만 “자부심을 갖고 모놀리스를 포용하는” 문화가 필요하다며, “모놀리스는 불필요한 개념적 모델을 최대한 많이 축소하고 쓸데없는 추상화를 최대한 많이 제거한 통합 시스템이다. 정작 해야 할 일을 못하도록 하는 시스템 분산에 대한 강력한 ‘반대’의 상징”이라고 덧붙였다.

썬 마이크로시스템즈(Sun Microsystems)와 이베이, 넷플릭스, 배터리 벤처스(Battery Ventures), AWS를 거치며 일해온 베테랑인 아드리안 코크로프트의 생각은 달랐다. 코크로프트는 프라임 비디오 팀이 사실상 부정확한 용어를 사용했다고 주장했다. 모놀리스로 돌아간 것이 아니라 초기 구현을 리팩터링했을 뿐이며, 이는 베스트 프랙티스라는 것이다.

코크로프트는 “프라임 비디오 팀은 서버리스 우선(Serverless First) 방식을 따랐다. 이 방식에서는 뭔가를 구축하기 위한 첫 시도를 스텝 함수와 람다 호출로 조합한다. 뭔가를 구축할 방법을 알아볼 때 며칠이나 몇 주에 걸쳐 프로토타입을 만드는 것은 좋은 접근 방법이다. 이들은 그런 다음 높은 트래픽에 대응하기 위해 확장을 시도했는데, 스텝 함수의 상태 전환 일부가 너무 빈번하게 일어나고 AWS 람다 함수와 S3 사이의 호출이 과도하다는 사실을 발견했다. 이들은 코드 대부분을 재사용해서 ECS를 통해 수평 확장되고 람다 함수를 통해 호출되는 하나의 장기 실행 마이크로서비스로 결합할 수 있었다. 문제는 이 리팩터링을 두고 마이크로서비스에서 모놀리스로 전환했다고 표현했다는 점이다. 이것은 명확히 마이크로서비스 리팩터링 단계이며, 내가 권장하는 방식”이라고 말했다. 

코크로프트는 마이크로서비스가 과대포장된 면이 어느 정도 있고, 많은 기업이 “쿠버네티스의 복잡성에는 비용이 따르며 애초에 대규모 팀에서 대규모로 실행하지 않는 한 불필요한 요소”라는 사실을 인식하면서 역풍도 발생했다는 점을 인정했다.

이어 “서버리스만 사용하는 방식은 지지하지 않는다. 지속적인 높은 트래픽과 낮은 지연, 높은 효율성이 필요한 경우에 권장하는 방식은 더 큰 서버리스 이벤트 기반 아키텍처의 일부로 지속적으로 실행되는 자동 확장 컨테이너로 신속한 프로토타입을 다시 구현하는 것이다. 프라임 비디오 팀이 한 작업은 바로 그것”이라고 덧붙였다.

IT 전문가가 기억해야 할 6가지 교훈

기업의 IT 리더가 아마존 프라임 비디오 사례에서 배울 수 있는 중요한 교훈은 다음과 같다.

1. 핵심은 기술이 아니다

아카마이의 선임 제품 마케팅 관리자인 파벨 디스팟은 “기술이 아니라 목표부터 시작하라”라면서 “달성하고자 하는 것부터 시작하고 거기서 제시되는 요구사항에 따라 시스템을 구축해 나가야 한다”라고 말했다.

퍼널랩스(Funnel-Labs.io) CEO 비제이 나야르 역시 “문제가 무엇인지 듣기도 전에 마이크로서비스 또는 모놀리스 시스템을 정답 또는 오답으로 정하는 것은 총을 먼저 쏜 다음 질문하는 것과 같다. 무모하고 나쁜 의사 결정으로 이어진다”라고 지적했다.

2. 절충점을 분석하라

마이크로서비스는 유연성을 제공하고 개별 서비스의 독립적인 개발, 배포, 확장성을 실현한다. 하지만 서비스 검색 필요성, 서비스 간 통신, 분산된 시스템 관리 등의 복잡성도 따른다. 서버리스를 선택하는 경우 애플리케이션을 구축하는 기반 인프라를 서비스 제공업체가 수요에 따라 가동하므로 빠른 배포의 장점을 얻게 된다.

3. 첫 설계를 제대로 하라

애플리케이션이 실행되는 기반 인프라는 처음부터 제대로 돼야 한다. 그렇지 않은 경우 프로토타입에서 프로덕션으로 이동할 때 확장 문제에 직면하게 된다.

AWS 전문가이자 여행 앱 개발 업체 인에이블스(Enables)의 CTO 데이비트 개티는 “아키텍처를 잘못 설계할 경우 작동하지 않고 많은 비용이 소비되고 복잡해진다. 람다에서 람다로 데이터를 전달해 가면서 작업을 한다는 것은 좋은 생각이 아니다. 모든 처리 작업을 하나의 람다에서 해야 한다”면서, 아마존 프라임 비디오 팀을 향해 “필요한 워크로드를 기반으로 잘못된 의사 결정을 내렸지만 이제는 제대로 하고 있다. 이 사례가 모든 서버리스가 나쁘다는 것을 의미하지는 않는다”라고 말했다.

4. 언어와 종속성을 간소화하라

핸슨은 “마이크로서비스 광기의 나쁜 부작용 중 하나는 수없이 많은 프로그래밍 언어와 프레임워크와 생태계를 포용하는 경향”이라며, 언어는 2가지를 넘지 말아야 한다고 권장했다. 두 언어 중 하나는 생산성에 초점을 둔 언어로 대부분 시간 동안 사용되며, 다른 하나는 문제 영역을 처리하는 데 사용되는 고성능 언어다.

나야르는 “서비스를 100가지 작은 서비스로 분할했는데, 문제의 발생지가 어디인지 알 수 없고 서비스 간의 거미줄처럼 얽힌 종속성으로 인해 배포가 극단적으로 어려워진다면 각 서비스의 용도와 논리를 명확히 하기 위한 고민 없이 서비스를 분할했기 때문”이라고 지적했다.

5. 특정 사용례를 목표로 삼아라

코크로프트에 따르면, 간헐적이고 규모가 작은 기업의 워크로드는 아마존 스텝 펑션과 람다를 사용한 서버리스 접근 방법에 적합하다. 

핸슨은 “효과적인 마이크로서비스를 보면 시스템에서 좁은 범위의 격리된, 일반적으로 성능이 중요한 특정 부분을 대상으로 하는 경우가 많다”라고 덧붙였다. 

디스팟은 서버리스 접근 방법이 유연함을 제공하긴 하지만 마이크로서비스 간, 그리고 백엔드 데이터베이스와의 통신 요구사항으로 인해 지연이 발생할 수 있다고 지적했다. 

6. 비용을 고려하라

서버리스 컴퓨팅 제공업체는 코드가 실행되는 시간만큼 비용을 청구하므로 서버리스 환경에서 장기간 실행되는 프로세스가 있는 애플리케이션이라면 비용 효율성이 떨어질 수 있다.

주의하지 않으면 스토리지 비용에 얻어맞을 수 있다는 교훈은 아마존 프라임 팀의 사례에서도 얻을 수 있다. AWS 스토리지 비용은 티어 기반으로, 티어 1 고속 액세스가 다른 느린 티어에 비해 값도 더 비싸다. 또한 모든 데이터 요청과 데이터 전송에 대한 비용도 청구되므로 요청이 지나치게 많은 애플리케이션은 빠른 비용 증가를 유발할 수 있다.
editor@itworld.co.kr