마이크로서비스 신화의 몰락...아마존도 모놀리스로 회귀

아마존 프라임 비디오, 마이크로서비스 포기하고 모놀리스 전환으로 비용 90% 절감

[한국정보기술신문] 클라우드 네이티브 아키텍처의 대명사로 여겨지던 마이크로서비스가 업계 재평가를 받고 있다. 마이크로서비스 인프라를 판매하며 연간 수십억 달러를 벌어들이는 아마존웹서비스 자체가 자사 프라임 비디오 서비스에서 마이크로서비스를 포기하고 전통적인 모놀리스 아키텍처로 돌아가 비용을 90% 절감한 사실이 알려지면서 업계에 충격을 주고 있다.

2023년 5월 아마존 엔지니어들은 프라임 비디오 품질 분석 팀이 마이크로서비스 아키텍처를 포기했다는 사실을 공개했다. 이들은 AWS Step Functions와 Lambda를 활용해 수천 개의 비디오 스트림을 모니터링하는 독립적이고 확장 가능한 컴포넌트들로 구성된 교과서적인 분산 시스템을 구축했다. 서버리스의 완벽한 구현처럼 보였지만 실제로는 재앙이었다.

프라임 비디오 엔지니어링 블로그에서 마르신 콜니는 분산 접근 방식이 이들의 특정 사용 사례에서 많은 이점을 가져다주지 않았다고 인정했다. 무한히 확장 가능할 것으로 기대했던 시스템은 오케스트레이션 오버헤드로 인해 예상 부하의 5%에 불과한 수준에서 무너졌다. 해결책은 당혹스러울 정도로 단순했다. 모든 것을 단일 프로세스로 통합한 것이다. 그 결과 비용이 90% 감소했고 성능도 더 빨라졌다.

트윌리오 세그먼트의 교훈

고객 데이터 플랫폼 기업인 트윌리오 세그먼트도 2018년 유사한 경험을 솔직하게 공개했다. 이들의 시스템은 140개 이상의 서비스로 확장되면서 운영 혼란을 초래했다. 한때 3명의 정규직 엔지니어가 대부분의 시간을 신규 개발이 아닌 문제 해결에 소비했다. 그들은 이 아키텍처가 빠르게 움직일 수 있게 해주는 대신 소규모 팀을 폭발적인 복잡성에 빠뜨렸다고 고백했다. 이 아키텍처의 필수적인 이점들이 부담으로 변했고 속도가 급락하면서 결함률이 폭발했다.

이들의 해결책은 급진적이었지만 효과적이었다. 140개 이상의 서비스를 단일 모놀리스로 통합한 것이다. 영향은 즉각적이었다. 한때 한 시간이 걸리던 테스트 스위트가 이제 밀리초 단위로 완료됐다. 개발자 생산성이 급증했다. 공유 라이브러리에 대한 개선 사항을 마이크로서비스 시대의 32건에서 연간 46건으로 늘렸다.

쇼피파이는 세계 최대 규모의 루비 온 레일즈 코드베이스 중 하나를 운영하고 있다. 280만 줄 이상의 코드를 보유하고 있지만 마이크로서비스를 추구하는 대신 의도적으로 모듈형 모놀리스를 선택했다. 명확한 컴포넌트 경계를 가진 단일 코드베이스 방식이다. 쇼피파이 엔지니어들은 마이크로서비스가 자체적인 도전 과제들을 가져올 것이라고 결론지었고 운영 오버헤드 없이 모듈성을 선택했다.

업계 전문가들의 경고

루비 온 레일즈의 창시자인 데이비드 하이네마이어 한슨은 오랫동안 아키텍처 트렌드보다 단순성을 옹호해왔다. 그는 아마존 프라임 비디오 사례를 분석하며 이렇게 말했다. 마이크로서비스는 아마도 시스템을 불필요하게 복잡하게 만드는 가장 큰 사이렌의 노래일 것이라는 것이다.

깃허브의 전 최고기술책임자인 제이슨 워너는 더욱 직설적이다. 그는 지난 10년간 가장 큰 아키텍처 실수 중 하나가 완전한 마이크로서비스로 전환한 것이라고 확신한다고 말했다. 워너는 깃허브를 인터넷 규모로 운영한 경험이 있으며 헤로쿠와 캐노니컬에서도 엔지니어링을 이끌었다. 그의 비판은 이론적 조언을 넘어선 실제 경험에서 나온다. 그는 세계 기업의 90%가 주 데이터베이스 클러스터와 데이터베이스 백업, 일부 캐시와 프록시를 실행하는 모놀리스만 있으면 충분할 것이라고 주장한다.

GraphQL의 공동 창시자인 닉 슈록도 분산 시스템을 응원할 이유가 있는 인물이지만 그마저도 마이크로서비스는 근본적이고 치명적으로 나쁜 아이디어여서 그들이 초래한 피해를 억제하는 것 외에는 아무것도 하지 않는 수십억 달러 규모의 기업들이 만들어질 것이라고 말한다. 그는 마이크로서비스를 조직적 도박으로 묘사하며 5년 전의 조직 구조와 제품 요구사항에 맞춰 영원히 유지해야 하는 서비스들로 끝나게 된다고 경고했다.

우버에서도 게르겔리 오로즈는 수천 개의 마이크로서비스를 테스트하고 유지하는 것이 어려울 뿐만 아니라 장기적으로 단기적으로 해결하는 것보다 더 많은 문제를 일으킬 수 있기 때문에 많은 마이크로서비스를 적절한 크기의 서비스로 이동하고 있다고 인정했다. 우버는 여전히 정당화되는 곳에서 마이크로서비스를 실행하지만 전투를 선택하고 있다.

쿠버네티스와 구글 클라우드 작업으로 유명한 켈시 하이타워는 마이크로서비스 과대 광고를 컴퓨터 과학 기초로 잘라냈다. 그는 모놀리스가 모든 마이크로서비스 아키텍처를 능가할 것이라고 확신한다며 각 서비스 간의 네트워크 지연시간과 각 요청의 직렬화 및 역직렬화 양을 계산해보라고 말했다.

마이크로서비스의 숨겨진 비용

마이크로서비스가 특별한 주의를 요구하는 이유는 팀들이 종종 과소평가하는 숨겨진 비용 때문이다. 모놀리스는 단순하다. 프로세스 내 함수 호출이다. 마이크로서비스는 이를 네트워크로 대체한다. 모든 요청은 이제 로드 밸런서, 서비스 메시, 인증 계층을 통해 머신을 가로질러 이동하며 더 많은 장애 지점과 인프라 요구사항을 만든다.

갑자기 서비스 디스커버리, 분산 추적, 중앙 집중식 로깅, 서비스 토폴로지를 이해하는 모니터링 시스템이 필요해진다. 이 각각은 필요하지만 함께 복잡하고 비쌉다. 중복된 데이터는 추가 스토리지가 필요하다. 지속적인 서비스 간 호출은 네트워크 송신 비용을 증가시킨다. 클라우드 비용은 호스팅하는 앱보다 빠르게 확장된다. 프라임 비디오의 워크플로는 실제 처리보다 서비스 간 S3 데이터 전송 오케스트레이션에 더 많은 비용을 지출했다.

더 현명한 대안

마이크로서비스를 기본값으로 선택하기 전에 더 단순하고 잘 구조화된 아키텍처가 분산 복잡성 세금 없이 비교 가능한 확장성을 제공할 수 있는 방법을 고려할 가치가 있다. 두 가지 주목할 만한 대안은 모듈형 모놀리스와 서비스 지향 아키텍처다.

전통적인 모놀리스와 달리 모듈형 모놀리스는 명확한 모듈 API와 규율 있는 분리를 통해 엄격한 내부 경계를 적용한다. 각 모듈은 잘 정의된 인터페이스를 노출하여 팀이 단일의 일관된 시스템을 배포하면서 독립적으로 작업할 수 있게 한다. 모듈은 여전히 마이크로서비스처럼 명시적 계약을 통해 통신하지만 네트워크 지연과 부분 실패에 취약한 HTTP 요청 대신 빠르고 신뢰할 수 있는 함수 호출을 사용한다.

서비스 지향 아키텍처는 모놀리스와 마이크로서비스 사이에 위치하며 수십 또는 수백 개의 작은 서비스 대신 더 크고 도메인 중심의 서비스를 선호한다. 이러한 서비스는 종종 엔터프라이즈 서비스 버스를 통해 통신하며 우려 사항의 분리를 유지하면서 오케스트레이션 오버헤드를 줄인다.

도커의 역할

도커는 마이크로서비스만을 위한 것이 아니다. 모놀리스, SOA, API, 이벤트 중심 시스템과 같은 모든 종류의 아키텍처에서 훌륭하게 작동한다. 실제 이점은 도커가 사용하는 아키텍처 접근 방식에 관계없이 일관된 성능, 더 쉬운 배포, 앱 확장 유연성을 제공한다는 것이다.

도커는 애플리케이션을 깔끔하게 패키징하고 노트북에서 프로덕션까지 환경을 일관되게 유지하며 종속성 관리를 단순화하고 호스트 시스템에서 애플리케이션을 격리한다. 도커화된 모놀리스는 마이크로서비스의 오케스트레이션 오버헤드를 제외하고 이러한 모든 이점을 제공한다.

마이크로서비스의 복잡성 없이도 도커는 깨끗한 배포, 쉬운 확장, 일관된 환경이라는 동일한 이점을 제공한다. 해결하려는 문제가 아키텍처를 정당화해야 한다. 대부분의 애플리케이션은 초대규모로 작동하지 않으며 근본적으로 다른 솔루션이 필요하다. 대부분의 시스템에서 잘 구조화된 모듈형 모놀리스나 SOA는 분산 복잡성 세금 없이 마이크로서비스와 비교 가능한 확장성과 복원력을 제공한다.

복잡성은 종종 해결하는 것보다 더 많은 문제를 만든다. 핵심은 마이크로서비스를 완전히 버리는 것이 아니라 클라우드 대기업이 추진하는 것이 아니라 실제 요구사항에 맞는 아키텍처를 선택하는 것이다. 대부분의 경우 모듈형 모놀리스나 잘 설계된 SOA가 비즈니스 요구사항을 더 잘 충족하고 팀을 더 생산적으로 만들 것이다.

한국정보기술신문 클라우드분과 이준호 기자 news@kitpa.org