아마존 프라임 비디오의 '서버리스 vs. 모놀리스' 논란에서 얻는 6가지 교훈
ITWorld Korea
모놀리스는 부끄러운 아키텍처인가?
아마존 프라임 비디오는 서버리스 아키텍처를 버리고 모놀리스를 선택했다. 그리고 클라우드 인프라 비용을 90% 절감했다.
언젠가부터 MSA, 서버리스 안하면 쿨하지 못한게 되었다. 이 흐름탓인지 부트캠프에서 몇 주간 진행하는 프로젝트에도 MSA로 서버를 구성한다. 정말 말리고 싶었지만 아무리 말해도 자기가 고생해봐야 이게 아닌걸 알지 않나.
각 팀과 회사가 가진 자원은 모두 다르다! 그러니 너무 부끄러워 마시라!
더 많은 콘텐츠를 보고 싶다면?
이미 회원이신가요?
2023년 6월 3일 오전 2:27
댓글 10
아주 좋은 생각입니다. MSA에 너무 큰 환상을 갖지 말고 플젝별로 뭐가 더 좋은지를 판단하는게 중요해보입니다
이건 아키텍쳐 선택은 물론 프로그래밍 언어를 선택할때도, 리펙토링기법을 선택할때도 뽕에 차서 고르면 안됨. 절대 반지 같은건 없는 세상이라서요..
삭제된 사용자
2023년 06월 04일
경영진이 MSA를 해야 쿨하다는 강박에 사로 잡히면 여러 프로젝트가 매우 힘들어 지는걸 경험했습니다.
한국에서 MSA 가 필요한 큰 규모의 비즈니스는 극히 드뭅니다. 내 돈이 나가는 사업이라고 생각하면 대부분의 환경에선 모놀리스가 필요 충분 조건을 만족한다고 생각합니다. 심하게 말하는 분들 중에는 MSA를 이력서 주도 개발이라고까지 하니까요.. ㅎㅎ
@김도열 작은 서비스라도 클라우드 쿠버네티스등을 이용해서 서비스를 구축하면 그 규모에 맞는 인프라 비용을 선택할 수 있기때문에 경제적이나 구축적인 측면에서 더 나은점도 있지않나요? 커야만 msa를 구축하는게 효과적이라 라는 의견에 저는 굳이 모놀리식에서 마이크로서비스 아키텍쳐로 옮기는 것만 아니라면 초기구축에는 msa가 더 낫지 않을까 라는 위 의견을 갖고있어서요
@이펴 인프라 비용도 중요하지만 인적 비용과 시간 비용이 저는 더 큰 허들인 것 같습니다. 더 많은 사람과 잘 설계된 조직도 마련되어야 하니까요. 이 추가 비용을 감당할 수 있는 환경이 맞는지.. 예를들면 경영진의 이해와 공감, 동의가 충분한지 라던가, 현재 수익이 없는 스타트업이라면 남은 런웨이가 충분히 긴가 등등의 현실적 환경도 고려해야 할 겁니다. 저는 합리적인 수준에서 낮은 결합도와 높은 응집도, 다른 서비스에 영향을 주지 않거나 덜 주는 수준에서의 배포 시스템은 필수라고 생각하지만, 그것이 꼭 전통적인 MSA의 형태라야 해결할 수 있는 문제인지는 뒤돌아 볼 필요가 있다고 생각합니다.
@김도열 넵 좋은 의견 감사합니다!
기사 본문 중 => 특정 규모에 도달하면 그 외의 다른 합리적인 조율 방안이 없다. 이 방법이 아니라면 모두가 서로의 발등을 밟게 되고 끝없는 병합 충돌을 처리해야 할 것. 사실 이 부분이 MSA를 도입하는 가장 큰 이유라고 볼 수 있을 것 같습니다. '한국에서 이 정도 규모의 비즈니스가 드물다는' 의견은 확실히 맞는 듯 합니다. 이와 비슷한 논조로 위대한 모놀리식 이라는 게시글이 유명합니다. https://m.signalvnoise.com/the-majestic-monolith/ 결국 그런 규모의 비즈니스가 아니라면, 본문에 있는 아래 내용을 마음에 숙지하는 것이 좋아 보입니다. => 기술이 아니라 목표부터 시작하라”라면서 “달성하고자 하는 것부터 시작하고 거기서 제시되는 요구사항에 따라 시스템을 구축해 나가야 한다" 결국 스타트업이나, 소규모 기업이 '생존'하기 위해선 아이디어에 대한 속도감 있는 구현이 우선이고, MSA와 같은 구조적 설계로 리팩토링 하는 것은 필요에 따른 차선일지도 모르겠습니다. 이와 별개로 MSA의 핵심은 '무조건 나누어라'가 아니라는 점도 배울 수 있을듯 합니다. 마이크로서비스를 구성할 때 모놀리식에서 어느 정도 까지를 나눌 것이냐의 문제는 결국 하나의 독립적인 영역을 찾는 것이 큰 임무인듯 합니다. "서비스 자체의 응집도가 높으며, 서비스간 결합도가 낮은" 영역을 찾는 게 핵심이죠. 개인적으론 본문에 있는 아래 지적이 일리가 있다고 느껴집니다. => "프라임 비디오 팀은 서버리스 우선(Serverless First) 방식을 따랐다. 이 방식에서는 뭔가를 구축하기 위한 첫 시도를 스텝 함수와 람다 호출로 조합한다. 뭔가를 구축할 방법을 알아볼 때 며칠이나 몇 주에 걸쳐 프로토타입을 만드는 것은 좋은 접근 방법이다. 이들은 그런 다음 높은 트래픽에 대응하기 위해 확장을 시도했는데, 스텝 함수의 상태 전환 일부가 너무 빈번하게 일어나고 AWS 람다 함수와 S3 사이의 호출이 과도하다는 사실을 발견했다. 이들은 코드 대부분을 재사용해서 ECS를 통해 수평 확장되고 람다 함수를 통해 호출되는 하나의 장기 실행 마이크로서비스로 결합할 수 있었다. 문제는 이 리팩터링을 두고 마이크로서비스에서 모놀리스로 전환했다고 표현했다는 점이다. 이것은 명확히 마이크로서비스 리팩터링 단계이며, 내가 권장하는 방식"
Less is more 이라는 표현도 어울릴 듯 하네요
뭐든 기술이 먼저가 아닌 우리 사업에 적합한 모델이 답이겠지요. 모놀리스는 부끄러운게 아닌 필요에 따라 맞는 곳도 상당히 많이 있습니다.
