MSA(Microservice Architecture)

MSA란?

Microservice Architecture의 약자로

"하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하게 만든 아키텍쳐"라고 할 수 있다.

서비스간 느슨한 결합(Loose Coupling)과 높은 응집성(High Cohesion)을 지향

애플리케이션 기능을 분해하고 분리해서 완전히 상호 독립적이여야 한다.

MSA를 왜 사용하는가?

기존에 많은 애플리케이션들은 Monolithic Architecture로 구현되어 있는데, 프로젝트 규모가 커지고 복잡도가 늘어날 수록 관리와 서비스 파악이 어렵고 단일 코드로 구축하기 때문에 배포도 모든 팀이 같이 해야한다.

이러한 단점을 개선하기 위해 Microservice Architecture를 사용한다.

Microservice Architecture는 각 팀이 서비스 코드와 서비스 인프라스트럭처를 완전히 소유하고 있기 때문에 독립적으로 빌드와 테스트, 배포를 할 수 있고, 다양한 언어와 기술로 개발 할 수 있다.

Monolithic Architecture의 한계점

• 서비스/프로젝트가 커지면 커질수록, 영향도 파악 및 전체 시스템 구조의 파악에 어려움이 있다.
• 빌드 시간 및 테스트시간, 그리고 배포시간이 기하급수적으로 늘어나게 된다.
• 서비스를 부분적으로 scale-out하기가 힘들다.
• 부분의 장애가 전체 서비스의 장애로 이어지는 경우가 발생한다.

장점과 단점

MSA의 장점

• 서비스 별로 배포가 가능(배포 시 전체 서비스 중단없음)
• 서비스 확장이 용의(클라우드 사용에 적합)
• 어떠한 한 서비스에서 장애 발생 시 전체 서비스에 영향이 적음
• 신기술 적용에 용의, 각자 다른 언어로 개발 가능

MSA의 단점

• MSA는 복잡한 아키텍쳐로 복잡도가 기하급수적으로 늘어날 수 있고,서비스간 통신으로 통신비용이나 레이턴시가 늘어날 수 있다.
• 서비스가 분리되어 있기 때문에 테스트와 트랜젝션 복잡도가 증가
• 데이터를 한번에 조회하기 어렵고 데이테의 정확도를 관리하기 어렵다.

참고 블로그

Microservice Architecture

MSA로 견고한 서비스를 구축하기 위해 생각할 점

• 적정 크기 마이크로서비스가 과도한 책임을 맡지 않도록 어떻게 적절한 크기로 만들 수 있을까?
• 위치 투명성 다수의 인스턴스가 재빨리 시작하고 종료될 때 서비스 호출에 대한 물리적 상세 정보를 관리할 수 있는 방법은?
• 회복성 어떻게 빠르게 장애가 발생한 서비스를 우회하고, 어떻게 전반적 무결성을 유지할 것 인가?
• 반복성 새로운 인스턴스가 시작할 때 운영 환경의 다른 서비스 인스턴스 구성과 코드 베이스를 동일하게 만드는 방법은?
• 확장성 비동기 프로세싱과 이벤트를 사용해 서비스 간 의존성을 최소화 하고 마이크로서비스를 원만하게 확장할 수 있는 방법은?