EP 8: ‘ShopStream’ 전설: 두 아키텍처의 이야기

Source: Dev.to

모놀리식 접근법

왜 성공했는가

• 속도 – 하나의 모듈에 있는 함수들이 다른 함수를 직접 호출할 수 있어 네트워크 지연이나 API 오버헤드가 없었다.
• 단순성 – 배포가 단일 실행 파일이었으며, 서버에 올려서 재시작만 하면 충분했다.
• 비용 – 월 $5 정도의 저렴한 가상 머신에서 실행되었다.

교훈

처음에는 모놀리식이 최고다. 스타트업이나 MVP 단계에서는 전달 속도가 아키텍처의 우아함보다 중요하다.

모놀리식의 성장통

병합 충돌 지옥

결제 팀이 결제 로직을 업데이트하면서 실수로 영상 팀의 코드를 덮어썼다.

깨지기 쉬운 유리 효과

주니어 개발자가 댓글 모듈에 오타를 넣어 메모리 누수가 발생했고, 이로 인해 전체 애플리케이션이 다운되어 사용자는 댓글을 달 수도 구매를 할 수도 없었다.

확장 문제

블랙 프라이데이에 영상 스트리밍은 서버 100대가 추가로 필요했지만 사용자 프로필 페이지는 한 대만 필요했다. 애플리케이션이 모놀리식이었기 때문에 전체 시스템을 100번 복제해야 했고, 자원이 낭비되었다.

교훈

모놀리식은 규모가 커질수록 어려움을 겪는다. 팀이 크고 트래픽 패턴이 고르지 않으면 단일 코드베이스가 병목이 되고 비효율적인 자원 사용을 초래한다.

마이크로서비스로의 전환

이별

아키텍트 Sasha는 6개월에 걸쳐 모놀리식을 해체했다:

• 결제 로직을 별도 서비스와 별도 데이터베이스로 추출했다.
• 영상 트랜스코더를 독립 서비스로 격리했다.
• 재고 시스템을 분리했다.

이제 모든 서비스는 네트워크 API를 통해 통신한다. 마치 마켓플레이스의 개별 상점들처럼.

왜 성공했는가

• 장애 격리 – 댓글 서비스가 다운돼도 영상이나 결제 서비스는 영향을 받지 않는다; 사용자는 로딩 스피너만 보지만 여전히 시청하고 구매할 수 있다.
• 독립적인 확장 – 블랙 프라이데이에 결제 서비스는 500 인스턴스로 자동 확장됐지만, 사용자 프로필은 두 인스턴스만 유지했다.
• 기술 자유 – 데이터 사이언스 팀은 추천 엔진을 파이썬으로 구축한 반면, 핵심 백엔드는 자바를 유지했다.

새로운 도전 과제

• 디버깅이 복잡해졌다; 요청을 추적하려면 이제 여러 서비스를 거쳐야 한다.
• 운영 오버헤드가 증가해 쿠버네티스, 도커 컨테이너, 분산 트레이싱을 관리할 전담 DevOps 팀이 필요해졌다.

교훈

마이크로서비스는 개발의 단순성을 운영 복잡성과 맞바꾼다. 실제로 규모가 필요할 때만 도입해야 한다.

올바른 아키텍처 선택하기

모놀리식을 유지해야 할 경우

• 스타트업이거나 소규모 팀(10~20명 이하)일 때.
• 새로운 제품(MVP)을 만들고 있을 때.
• 도메인이 단순할 때.
• 빠른 반복과 쉬운 디버깅이 필요할 때.

마이크로서비스로 전환해야 할 경우

• 대규모 기업(Netflix, Uber, Amazon 수준)일 때.
• 여러 팀이 서로 방해받지 않고 독립적으로 작업해야 할 때.
• 애플리케이션의 각 부분이 크게 다른 확장성을 요구할 때.
• 하나의 컴포넌트 장애가 전체 시스템을 다운시키지 않아야 할 때.

황금 규칙

처음엔 모놀리식으로 시작하라. 가능한 한 오래 모놀리식을 유지하라. 모놀리식을 관리하는 고통이 마이크로서비스를 관리하는 고통보다 클 때만 분리하라.