출처 [OKKY 5월 세미나] 실전 MSA 경험 공유 by. 주길재 팀장(GS리테일 뉴테크본부/플랫폼Product부문)
해당 영상을 보고 개인적으로 정리한 글입니다.
📗 왜 MSA인가?
✍ 강력한 모듈화
예를들어 쇼핑몰이 있다고 가정해보자. 쇼핑몰에서 신발과 가방을 판매하고 있는데 신발의 판매가 폭발적으로 증가하였다.
📄 Monolithic
이 경우 기존 모놀리식의 서비스의 경우 사용자들의 트래픽을 감당하기 위해 서비스 전체의 스케일 업, 아웃을 진행하게 된다. 가방은 판매가 되지 않더라도 신발을 구매하고자 하는 사용자들의 트래픽에 맞춰서 전체적으로 서버를 확장시켜야하는 것이다.
📄 MSA
하지만 MSA의 경우 신발과 가방을 각각의 서비스로 구분해서 진행해두었다 가정하면 신발의 서비스만 서버를 확장시키면 된다.
이처럼 MSA를 사용하면 모놀로식보다 강력한 모듈화를 보장한다. 의존성을 최소화하고 독립적으로 확장이 가능하다.
✍ 대체성
쉬운 교체 가능성이다. 쉬운 교체란 쇼핑몰의 PG사가 네이버페이를 사용하고 있었는데 특별한 이유로 카카오페이를 PG사로 교체해야할 일이 생겼다.
📄 Monolithic
이 경우 모놀로식은 서버 소스를 수정한 뒤 서버를 모두 다시 재 실행해야한다.
📄 MSA
MSA의 경우 카카오 PG와 통신하기 위한 새로운 서비스를 만들고 네이버 PG 서비스를 종료한 뒤 카카오 PG 서비스를 실행시키면 끝난다.
✍ 레거시 프로젝트와의 호환성
기존의 레거시 프로젝트의 경우 새로운 기술과 새로운 기능을 도입하기 위해서는 제한되는 부분이 있거나 프로젝트를 전반적으로 수정해야했었는데. MSA의 경우 서비스 단위로 구성한 후 기존의 레거시 프로젝트는 고도화작업과 함께 사용할수 있다.
✍ 서비스 런칭
모놀로식으로 구현한 어플리케이션의 경우 기존의 프로젝트에서 개선해나가는 작업이 추가로 들어가기 때문에 MSA 프로젝트에 비해 초반에 자원이 많이 들어간다. 또한 서비스가 성공했을 경우에 서비스를 더 키우기 위한 자원도 생각해야한다. 하지만 MSA는 작은 기능들로 먼저 서비스를 런칭해보고 서비스가 성공한다면 그에 따라 서비스의 크기도 키우기 편하다.
✍ 자유로운 기술의 선택
이게 가장 큰 장점 중 하나라고 나는 생각한다.
📄 Monolithic
하나의 서비스를 만들기 위해서는 선택된 기술로만 진행된다.
📄 MSA
각 서비스마다 제약없이 기술을 선택하고 사용할 수 있다.
✍ CI/CD
모놀로식은 전체적인 서비스의 버전을 관리해야하지만 MSA는 각 서비스별로 버전을 관리할 수 있어서 좀 더 가볍고 팀별로 관리할 수 있는게 장점이다.
👏 MSA와 Monolithic
🙋♂️그래서 MSA가 더 좋다구요?
MSA와 Monolithic을 비교하면서 얘기하고 있지만 특정 아키텍처가 무조건 더 좋고 무조건 그 아키텍처로 프로젝트를 전환하거나 신규 프로젝트를 진행해야한다! 이건 아니다. 그 이유는 각 아키텍처의 특징이 있고 상황에 따라 알맞은 아키텍처를 도입하는 것이 더 중요하기 때문이다.
✍ Monolithic를 고려해야할 경우
- 이미 프로젝트가 성공적으로 오랜기간 서비스 되고 있었고 있을 때
- 팀이 작거나 각 개발자가 특정 기능에 대한 전문화되지 않고 전체적으로 유지보수해야할 경우
- 프로젝트 자체가 트래픽이 높은 프로젝트가 아니고 빠르게 개발하며 비용 절약이 우선일 경우
한마디로 적은 인원으로 빠르게 쉽게 비용을 절약하며 일단 서비스를 런칭하는게 목표라면 Monolithic은 나쁜 선택이 아니다.
✍ MSA를 고려해야할 경우
- 확장성이 중요한 서비스이고 다양한 비즈니스가 추가하려는 서비스
- 다양한 기술 스택과 전문성이 다른 개발자들을 한팀으로 프로젝트를 진행할 경우
- 새로운 기술을 지속적으로 도입해야하는 서비스
- MSA의 지식이 있는 개발자 자원을 보유했을 경우
- 단기적보다 장기적으로 확장성을 고려할 경우
✍ Monolithic을 선택한 기업
Facebook(=meta)
각 서비스들간의 통신에서 잠재적인 보안적인 문제의 위험을 안고 가는 것보다 안정성이 높고 현재까지 진행해와 인증된 방법의 인프라를 유지하는 것으로 선택
📄 Segment
빅데이터 솔루션 회사로 초기에는 MSA로 서비스를 진행했지만 각 서비스간의 통신에서의 오버헤드가 너무 컸고 성능의 저하가 초래됨. 이러한 문제보다는 제공되는 서비스들의 안정성이 우선시되어 Monolithic으로 전환
원래의 인프라를 그대로 유지하되 새롭게 추가되는 기능들에 대해서는 MSA를 적용하여 진행하고 있음
✍ MSA를 선택한 기업
📄 Uber
초기에는 운전자 검색, 게시판, 주문 처리 및 결제 서비스를 제공하다 MSA로 전환하여 소비자들이 원하는 더 많은 기능들을 신속히 추가하여 진행함.
📄 eBay
엄청난 트래픽을 감당해야하는 기업으로 각 기능들을 MSA로 전환하여 분리하여 서비스를 제공하고 있음
위 내용을 토대로 봤을 땐 특정 아키텍처가 무조건 좋다고 할순 없고 현재 프로젝트가 어떤 상황이고 어떤 아키텍처가 더 적절한지 판단하여 적용하는 것이 중요하다.
✍ MSA와 Monolithic의 장점과 단점 정리
📄 MSA 장점
- 독립형 서비스
- 각 서비스 별 독립적으로 디버깅, 배포/관리가 가능
- 기능 변경이 다른 서비스에 영향을 미치지 않음 - 손쉬운 확장
- 특정 서비스의 수평 확장이 가능
- 수직 확장 대비 비용이 절약 - 유연성 향상
- 기술 도입이 쉬움
- 서비스의 변경이 쉬움
📄 MSA 단점
- 복잡도 증가
- 하나의 서비스는 단순하지만 여러 서비스가 모이면 복잡도가 매우 증가함 - 전문 기술 필요
- MSA에 대한 이해와 그 외 많은 기술에 이해가 필요함 - 분산 보안
- 각 서비스별 보안 취약성 대비 필요 - 테스트
- 각 서비스별로 테스트 해야함 - 추가 비용
- 각 서비스별 종속성 관리하기 위한 추가 리소스가 필요함
📄 Monolithic 장점
- 간단한 개발 및 배포
- 단일 개발자/소규모 팀의 경우 빠르게 개발/테스트가 용이함 - 테스트 용이성
- 하나의 프로젝트에서 모든 소스를 테스트하고 디버깅하는데 용이함 - MSA에 비해 적은 교육비용
- 대부분의 개발자는 Monolithic 어플리케이션을 개발할 수 있음
- 추가적인 교육이 필요 없음 - 보안
- 하나의 프로젝트의 보안 취약성만 대비하면 됨
📄 Monolithic 단점
- 점점 복잡도 증가
- 서비스가 성장하고 기능이 추가됨에 따라 점점 복잡도가 증가함 - 확장하기 어려움
- 특정한 기능만을 확장하는데 어려움이 있음
- 몇개의 주요 기능을 위해 모든 서비스가 확장되어야함
- 스케일 아웃보단 스케일업을 대부분 사용하여 확장함 - 에러
- 하나의 에러가 전체 어플리케이션에 장애를 유발시킬 수 있음
😂 그래서 언제 MSA를 써?
출처 https://twitter.com/der_rehan/status/1450044694013022209/photo/1
한 개발자가 MSA와 Monolithic을 고민한다면 고려해볼만한 사항들을 정의해본 그림이다. 꼭 여기에 맞출 필요는 없지만 참고하면 좋지 않을까?
강의에 나온 한글 번역본이다.
