[MSA] MSA 구조란 무엇이고, 왜 다들 열광하는가?

현재 재직중인 회사에서 일부 서비스가 MSA 구조의 아키텍처를 가지고 있다.

이전에는 크게 생각하지 않았는데, 어느순간 MSA란 무엇인가? 과연 MSA 구조를 잘 지키고 있는가? 생각이 들었다.

 

그래서 오늘은 MSA란 무엇이고, 기존 모놀로식 구조와의 차이점이 뭐가 있는지 알아보려고 한다.

---

MSA가 뭐야?

MSA가 뭐냐고 물어본다면 `여러개의 작은 어플리케이션으로 분리해서 사용하는것`이라고 정의하고 싶다.

조금 더 전문적인 단어로 표현한다면 어플리케이션을 서비스 모음으로 느슨하게 구조화하여 서비스 지향 아키텍처의 개발 기법이다.

 

개발이라고 말한것처럼 정답은 없다. 시기와 서비스 규모에 따라서 선택하는 기법이 다를뿐이다.

흔히들 MSA 구조로 어플리케이션을 만든다고 하면, 조금 더 진보된 개발방법이라고 말하는 사람이 많다.

하지만 이는 MSA 구조를 사용하기 위해 개발하는 사람이고, 좋은것이라고는 생각하지 않는다.

 

잊으면 안되는것이 MSA 개발 기법을 위해 개발을 하는것이 아니라, 개발의 한 방향으로 MSA를 채택하는것이다.

더 좋은 기법이 있고, 더 적절한 방법이 있다면 적용하면 되는것이다. 목적을 잃어서는 안된다.

모놀로식이 더 좋다. MSA 구조가 더 좋다. 정답은 없고, 다를뿐이다.

 

내가 생각하는 모놀로식와 MSA는 트렌드와 서비스 크기에 결정된다고 생각한다.

트렌드에 따른 설계 차이

과거에는 모놀로식 구조가 트렌드였다. 하지만 최근에는 MSA 구조가 트렌드이다.

• 과거에는 Cloud가 없었기에 서비스를 배포할 노드(베어메탈)을 구성하는것이 어려웠다.
• 그렇기 때문에 MSA가 각광받지 못했다. 하지만 요즘은 대다수의 서비스가 Cloud 환경이다.
• 그리고 K8s가 일반화 됨에 따라서 작은 서비스를 배포하는것에 대한 허들이 낮아졌다.

Cloud라는 새로운 기술이 보편화되었기에 MSA가 각광받았다고 생각한다.

서비스 규모에 따른 설계 차이

서비스가 작은 경우에는 모놀로식 구조가 더 용이하고, 서비스가 큰 경우에는 MSA가 용이하다.

서비스가 크지 않은데 굳이 서비스를 분리하는것은 오히려 운영 코스트만 불필요하게 늘릴뿐이다.

모놀로식 구조에서 서비스가 클 경우에는 아래의 문제점이 야기 될 수 있고, 그래서 MSA를 선호한다.

• 서비스 부분 장애가 전체 장애로 확대될 수 있다.
• 전체 서비스 구조 파악이 힘들고, 서비스 변경시에 영향도 파악도 힘들다.
• 작은 서비스 변경에도 전체 이미지를 빌드/배포해야 되기에 배포 시간이 늘어난다.
• 특정 서비스 부분에 대해서만 부분적인 Scale-out이 불가능하다.

 

결과적으로 모놀로식과 MSA는 아래의 그림처럼 볼 수 있을것 같다.

MSA는 작은 서비스(개별 컨테이너)를 쌓고 쌓아서 하나의 서비스를 만든다.

MSA 구조는 뭐가 다른거야?

MSA 구조도 결국에는 모놀로식 서비스의 합이다. 이렇게 말하면 약간 혼란이 있을 수 있으나, 아래 그림을 보면 이해가 된다.

MSA 구조도 결국에는 비즈니스 로직이 있고, 데이터베이스를 따로 관리한다. 다만, 각 기능별로 분리했을뿐이다.

 

좀 더 다른말로 말하면, MSA는 API를 통해서만 상호작용하며, API 형태로 외부에 노출하고 그 외 나머지는 추상화한다.

• 예를들어) A 서비스에서 B 서비스 API를 호출하지만, A 서비스 입장에서는 B 서비스 동작원리를 알 필요가 없다.

내 생각에는 잘 설계된 MSA는 하나의 비즈니스 범위에 맞춰 만들어서 하나의 기능만 수행한다고 생각한다.

그리고 핵심은 DB를 나눠 단일 실패 지점 그리고 Bottleneck이 발생하는것을 지양하는것이다.

 

그렇기에 모놀로식보다 많은 리소스를 필요로 하게 된다.

• 하지만 이게 반드시 비용적으로 비효율적이라고 생각하지는 않는다.
  • 기존에는 특정 서비스에 문제가 되는 경우 부분적인 scale-out이 되지 않기 때문에 전체 서비스에 대한 리소스를 증설해야 한다.
  • 하지만, MSA가 되면 해당 서비스 리소스만 늘리면 되기 때문에 오히려 비용 효율적이다.

그리고 Vault, Istio sidecar와 같은 경우에는 아주 작은 MSA 서비스라 할지라도, 컨테이너가 필연적으로 늘어나게 된다.

 

MSA 구조에서 가장 어려운건 어떤 기능을 묶오, 어떻게 분리할것인가에 대한 정책을 세우는것이다.

그리고 찾아보면 이것은 정답은 없다ㅋㅋㅋㅋ 어떻게 팀원들과 합의하기 나름이고 나름의 정책을 세우기 나름이다.

 

MSA vs 모놀로식 뭐가 다른거야?

그렇다면 MSA 구조의 장/단점이 뭘까? 어찌되었든 단점보다 장점이 더 많으니깐 많은 사람들이 MSA를 채택한다.

MSA 구조 장점

• 개별 서비스 배포가 가능하고, 배포 시 전체 서비스에 대한 중단이 발생하지 않는다.
• 신규 서비스에 대한 기능 추가가 수월하다.
  • 서비스별 역할이 명확하고, 서비스 자체가 크지 않기 때문에 요구사항 반영이 빠르다.
• 특정 서비스에 대한 Scale-out이 가능하다.
• 일부 서비스의 장애가 전체 서비스 장애로 확대될 가능성이 적으며, 부분 장애에 대한 조치가 수월하다.
• 각 서비스별 언어와 기술스택에 대한 자율성이 높다.( = Polyglot 하다.)
  
  • A 서비스는 Java + Oracle로 만들고 / B 서비스는 Go + MYSQL로 개발
    
    

MSA 구조 단점

• 서비스가 분리되어 있기 때문에 내부 시스템 통신을 어떻게 설계할지 설계 어려움이 있다.
• 서비스 호출이 모두 API 기반이기 때문에 Network Latency가 늘어난다.
  • 또한, 만약 CrossAZ Data Transfer이 많은 경우에는 비용이 기하급수적으로 늘어날 수 있다.
• 서비스가 분리되어 있기 때문에 테스트와 트랜잭션 복잡도가 증가한다.
• 데이터베이스가 분리되어 있기 때문에 DB Join 등과 같은 데이터 관리의 중요성이 커지며 운영 코스트가 증가한다.

장점만 있는 것은 없다. 장점이 있으면 단점도 있는 법이다.

하지만 그 단점을 모두 상쇄할 장점이 있기에 MSA 구조를 채택하는 것이고, 배포 용이성 + Scale-out이 가장 큰 장점이지 않을까한다.

 

최근 개발자분들과 이야기를 해보면, 가장 걱정하는 것이 배포 용이성과 Scale-out이다.

내가 반영한 코드가 얼마나 빠르게 제품에 반영할 수 있을지? 얼마나 빠르게 확장이 가능한지가 초미의 관심이다ㅋㅋㅋㅋ

글로벌 기업의 MSA 구조

MSA에 대해서 이야기할 때, 가장 많이 나오는 그림이다.

아마존, 넷플릭스 기업의 MSA 네트워크를 가시화한것이다. 보기만해도 어지럽다. 얻는게 있으면 잃는것도 있는 법이다.

 

적절한 수준으로 적절하게 구조화하는것이 가장 어려운거 같다.

이번에 MSA 구조에 대해서 알아봤는데, 아직 MSA 구조에 대해 모르는점이 많고 배울것이 많다. 많아

 

이전에는 하나도 몰랐다면, 이제는 조금은 알것 같은 느낌적인 느낌이고 이걸 왜 사용하는지 조금은 알것 같다.

회사에서 일부 서비스가 MSA 구조로 되어 있는데, 운영하는 내가 MSA를 왜 써야 하는지 모른다면 말이 되는가!!

 

오늘도 이렇게 하나 배웠습니다.

끄읏!