MSA는 무엇인가요?
msa(Micro Service Architecture)는 느슨하게 결합된 서비스 컴포넌트의 조합으로 구성된 아키텍처이다. 채용 공고를 보면 팀마다 사용하는 언어와 프레임워크가 다른 경우가 있는데. 이 경우 msa를 적용한 것으로 추측해볼 수 있다. 그렇다면 왜 msa 방식이 많이 쓰이기 된 걸까? 기존 아키텍처와 다른 점이 있을까?
MSA 이전 아키텍처?
MSA가 유행하기 이전에 일반적인 소프트웨어 아키텍처의 형태는 모놀리식이었다. 모놀리식 구조는 단일 컴퓨팅에 모든 코드가 담겨있다. 만약 서비스 규모가 커지기 시작하면 다음과 같이 3 가지 단점을 나타날 수 있습니다.
- 빌드 및 테스트 시간 늘어남 : 작은 수정에도 전체 빌드 시간이 늘어나 CI/CD에 어려움
- 선택적 확장 어려움 : 특정 기능 개발로 인해서 전체 확장 일어남
- 하나 서비스가 전체에 영향 줄 수 있음 : 일부 서비스에 트래픽 모이면 전체 서비스 다운
MSA의 장점
이러한 모놀리식 구조의 문제점을 해결하고자 MSA가 탄생하였다 . MSA에서 모듈 별로 독립적으로 배포 가능하기 때문에 새로운 기능과 비지니스 구조에 유연하게 대처할 수 있다. 비즈니스와 도메인에 특화된 언어 및 프레임워크를 선택할 수도 있다. 거대하고 복잡한 기존 방식에 비해 작고 독립적으로 분리할 수 있기 때문에 관리하기 편리하다. 따라서 MSA 는 다음 장점이 존재한다.
- 버그 수정, 기능 릴리즈 관리가 쉬움 : 작은 서비스 단위라서, 롤백도 쉬움,
- 기능적으로 한팀으로 모여서 민첩하게 움직임, : 구축, 테스트 배포가 빠름
- 종속성이 낮아져 새로운 기능 추가 쉬움
- 각 서비스에 맞는 기술을 쓸 수 있음
- 특정 부하가 몰리는 서비스를 확정하여 효율적으로 리소스 관리 가능
- 데이터 격리: 마이크로 서비스에만 디비 영향 받기 때문에 스키마 업데이트가 쉬움
MSA의 단점
MSA의 장점만 있는 것은 아니다. 단일 코드 베이스를 분리하여 얻는 장점도 있지만, 여러 모듈의 동시 다발적인 관리가 어렵다는 단점도 존재한다. 특히, 제대로 설계하지 않는다면, 무분별적인 모듈 생성으로 오히려 구조가 더 복잡해질 수 있다. 단점을 정리해보면 다음과 같다.
- 복잡성 : 각 서비스 단순, 전체 시스템은 복잡
- 개발 및 테스트: 한 서비스의 경계에 벗어난 리팩토링이 러ㅇ려워 서비스 종속성에 엮일 수도.
- 통제 어려움: 지나치게 언어와 프레임워크가 많아지면 유지 보수가 어려워짐
- 네트워크 정체 및 대기 시간 길어짐 : 서비스간 통신 리소스가 커짐 과도한 api 설계로 이어질 수도.
- 데이터 무결성을 해칠 수도 있음 : 각 서비스 별로 디비가 존재하기 때문이다.
MSA 구조
- 마이크로 서비스
- 독립적으로 배포할 수 있음.
- 각 서비스끼리 내부적으로 API 통신한다.
- 각자 다른 언어 및 프레임워크를 사용할 수 있다.
- 각각 개별적인 데이터베이스를 둔다. - AP 게이트 웨이
- 마이크로 서비스를 하나 엔드포인트로 모으는 기능을 한다.
- 인증, 부하 분산, 로깅 관리 등 다양한 기능을 수행한다. - 관리 / 오케스트레이션
- 각 마이크로 서비스에 노드를 두어 관리 용이하게 한다.
- 서비스 간 부하를 조정한다.
참고 사이트
- https://www.atlassian.com/ko/microservices/microservices-architecture/microservices-vs-monolith
- https://learn.microsoft.com/ko-kr/azure/architecture/guide/architecture-styles/microservices
- http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/
가능한 최선을 다하고 싶다