오늘은 https://github.com/skarbgud/SpringInAction5/issues/4에서 스터디 주제로 나온 MSA에 대해 알아보고자 합니다.
2022/1/15 스터디 주제 · Issue #4 · skarbgud/SpringInAction5
MSA(마이크로 서비스 아키텍처)란? MSA에서 통신 방법?
github.com
MSA 정말 많이 들어봤었습니다. 채용공고에도 정말 정말 많이 나오는 그이름 MSA...
MSA가 Micro Service Architecture의 약자라는 것은 쉽게 알 수 있습니다.
말로써는 마이크로 서비스 아키텍쳐로 작은 서비스의 단위로 나누어 구성하는 아키텍쳐의 방식입니다.
우선 MSA를 논하기 전에 모놀리식 아키텍처에 대한 이해를 할 필요가 있습니다.
보통 MSA로 전환 또는 마이크로 서비스로 전환이라는 표현을 많이 합니다.
이외에도 카카오, 배달의 민족 (우아한 형제들)등 흔히 MSA 아키텍쳐를 도입하는데 있어서 마이크로 서비스로 전환을 했다는 표현을 많이 합니다.
그럼
무엇 -> MSA로 전환을 했을까?
여기서의 무엇이 위에서 말했던 모놀리식 아키텍처(Monolithic Architecture) 을 말합니다.
그럼 모놀리식 아키텍쳐란 무엇일까?
흔히 전통적인 하나의 애플리케이션이 하나의 단일 시스템에 모든 기능과 시스템 컴포넌트들(UI, SERVER, DB)를 통째로 담아두고 운영되는 구조입니다.
그럼 이런 모놀리식 아키텍처(Monolithic Architecture)에서 MSA(Micro Service Architecture)로 왜 전환을 하는 걸까?
일단 모놀리식 아키텍처(Monolithic Architecture) 에서는 어떤 기능이나 서비스든 개발되어 있는 환경이 같아서 복잡하지 않고 End-to-End 테스트가 용이하고 쉽게 고가용성 서버 환경을 구축할 수 있어 단순한 아키텍처 구조와 개발에서는 용이합니다.
하지만, 애플리케이션의 규모가 커지고 그에 따른 빌드, 배포 시간이 길어지고 특정 부분에서 오류가 나면 전체 서비스가 장애가 생겨 서버가 다운이 될 수가 있습니다.
그럼 MSA는?
하나의 애플리케이션을 여러개의 작은 단위로 서비스(microservice)로 나누어 운영이 되는 구조입니다.
쪼개어진 각각의 서비스는 하나의 프로세스로 동작하며 그 자체는 Monolithic한 서비스와 구조적으로 유사합니다.
MSA는 이렇게 나뉘어져서 독립된 각각의 모듈들을 조립하여 만들어 하나의 서비스를 구성하는 아키텍쳐입니다.
MSA는 단일 책임 원칙(Single Responsibility Principle; SRP)를 중시합니다.
즉, 큰 문제를 작은 문제로 분해해 해결하며, 작게 나눠진 서비스가 서로에게 영향을 미치지 않고 독립적으로 역할을 수행하게 만드는 것입니다.
이렇게 되면
- 작고 독립적인 서비스로 쪼개져있어 팀 별로 독립적으로 개발 및 배포를 할 수 있다.
- 상호의존적이지 않으며 다른 언어, 다른 서버를 사용할 수 있다.
- 하나의 서비스가 장애를 일으켜도 다른 서비스를 사용할 수 있다.
- 수평적 확장이 가능하며 관리하기 쉽고 클라우드 사용이 용이하다.
- 특정 서비스에 유저가 몰린다면 그 서비스의 서버만 확장할 수 있다.
그렇다면 좋은 점만 있는가? 라고 한다면
- 공유 자원 접근이 어려움.
- 배포와 실행이 복잡 ( 배포 자동화 과정 필요 )
- 분산 시스템을 구현하기 어려움 : 독립적인 프로세스들을 유기적으로 동작할 수 있게 분산 네트워크 시스템이 필요함. 네트워크 레벨에서 다양한 상황별로 처리해야하는 어려움
그럼에도 불구하고 기능 단위로 서비스의 개발이 분리됨에 따라 각각의 모듈이 서로 약결합(loosely coupled)형태로 연결이 되어 종속성을 최소화할 수 있고, 기능별 개발팀이 서로의 간섭을 최소화하고 빠르게 개발하고 효율적으로 유지보수할 수 있다는 측면에서 많은 기업들이 도입하고 있는 아키텍쳐임에는 틀림없어 보인다.
Reference
https://tech.kakao.com/2021/09/14/msa/
https://dahye-jeong.gitbook.io/til/devops/2020-04-24-architecture
