MSA인지 아닌지를 판단하는 ‘명확한’ 기준이라는 게 없다. 왜냐하면 MSA라는 개념이 어떤 개인이나 단체가 정의한 개념이 아니다. 그냥 서로 입소문으로 퍼진 개념 중 하나이다. 한 마디로 ‘특정 기준을 만족시켜야 MSA다’라는 명확한 기준이 없다는 뜻이다. 그래서 개개인마다, 기업마다 얘기하는 MSA의 기준이 다를 수 밖에 없다.
하지만 MSA라는 개념이 개발자들 사이에서 유명해지면서, MSA를 판단하는 기준이 얼추 생기긴 했다. 그 기준을 알려주겠다.
MSA인지 아닌지를 판단할 때 핵심 개념은 ‘독립성’이다.
많은 기업들이 MSA로 전환하는 이유는 독립성으로 인해 생기는 장점들 때문이다. 따라서 독립성을 적용시켰냐 여부가 MSA를 판단하는 데 중요한 기준점이 된다.
‘독립성’이라는 키워드가 추상적이니 조금 더 구체적으로 얘기해보자.
✅ MSA에서 얘기하는 ‘독립성’
각 서비스를 독립적으로 개발 및 배포가 가능해야 한다.
각 서비스를 독립적으로 개발 및 배포가 가능해야만, MSA의 핵심적인 장점(’배포 사이클이 빠르다’)을 취할 수 있게 된다.
서비스끼리는 API로만 통신해야 한다.
예를 들어, 다른 서비스의 DB에 직접적으로 접근해서 데이터를 가져오면 안 된다. 그래야 API를 제외한 다른 부분에서 의존성이 안 생겨서 독립적인 개발과 배포가 원활하게 가능해진다. 그리고 DB를 별도로 분리해서 써야 DB 장애로 인한 장애 전파를 예방할 수 있다.
✅ MSA와는 상관없는 구분 기준
카프카, 쿠버네티스, API 게이트웨이, 서비스 디스커버리, 프로메테우스, 그라파나, Jenkins와 같은 기술 스택을 썼는 지 여부는 MSA를 잘 적용시켰는 지 판단하는 데 전혀 상관없는 요소이다.
서킷 브레이커 패턴, 사가 패턴, CQRS, 이벤트 소싱, DDD, EDA, BFF, 클린 아키텍처, 헥사고날 아키텍처와 같은 패턴을 썼는 지 여부는 MSA를 잘 적용시켰는 지 판단하는 데 전혀 상관없는 요소이다.
Spring Cloud Bus, Eureka, Spirng Cloud Gateway, Spirng Cloud Gateway, Spring Cloud Sleuth와 같은 다양한 라이브러리를 썼는 지 여부는 MSA를 잘 적용시켰는 지 판단하는 데 전혀 상관없는 요소이다.
서비스를 몇 개로 나눴는 지는 MSA를 잘 적용시켰는 지 판단하는 데 전혀 상관없는 요소이다. 독립성을 지키면서 2개의 서비스로 나눈 것도 MSA라고 부른다.
👨🏻🏫
MSA에 대한 잘못된 개념을 바로 잡지 않으면 MSA를 학습하는 데 방해가 될 수 있어서, MSA에 대해 오해할만한 부분을 정리해봤다.
