- MSA(마이크로서비스 아키텍처)
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. - James Lewis and Martin Fowler
(번역) 마이크로서비스는 서비스 디자인 스타일로서 작은 서비스의 결합을 통해 하나의 응용 프로그램을 개발하는 방법이다. 각각의 서비스는 독립적인 비지니스 로직으로 구성되며, 완전 자동화된 개발/배포 환경에 의해 각각 독립적으로 배포할 수 있다. 최소한의 중심적인 관리 체계가 있고, 각 시스템들은 다른 프로그래밍 언어, 다른 데이터 스토리지 기술로 작성하는 것이 가능하다.
vs 모놀리틱 아키텍처(Monolithic Architecture)
모놀리틱 아키텍처는 하나의 애플리케이션이 한 통으로 들어가는 일체식 구조로 마이크로 서비스 아키텍처의 반대 개념이다. 실제 많은 서비스가 이와 같은 구성으로 이루어져 있으며 단순한 구성으로 아래와 같은 장점들을 가진다.
- 하나의 애플리케이션만 개발하면 되기 때문에 배포 및 테스트가 편리하다.
- 컴포넌트 간 함수 호출을 사용하기 때문에 높은 성능을 보인다.
- 개발 repository, package의 운영 및 관리가 쉽다.
하지만 서비스가 지속해서 성장하고 규모가 커진 상황에서는 한계가 있다. 서비스의 구조 자체가 너무 복잡해져 있기 때문에 초창기부터 함께 개발을 진행한 개발자가 아니고서는 재활용 가능한 모듈을 알지 못하므로 중복된 코드를 생산하게 될 가능성이 높다. 그리고 코드가 서로 다양한 방식으로 연관되어 있어서 간단한 버그 수정이 오히려 큰 버그를 만들 수도 있다. 정리하자면 복잡해진 서비스 구조로 인해 아래와 같은 단점을 가진다.
- 빌드, 배포 시간, 서버 가동 시간 등이 오래 걸릴 수 있다.
- 개발자 개개인이 대략적인 전체 시스템을 이해해야 한다.
- 컴포넌트별로 다른 기술을 도입하기 어렵다.
- 컴포넌트의 문제가 다른 컴포넌트에 영향을 미친다. (= Tight Coupled)
API Gateway
마이크로 서비스 아키텍처 설계에 있어서 많이 언급되는 컴포넌트 중의 하나가 API gateway 라는 컴포넌트이다. API gateway는 마치 프록시 서버처럼 API들 앞에서 모든 API에 대한 end point를 통합하고, 몇 가지 추가적인 기능을 제공하는 미들웨어로, SOA의 ESB (Enterprise Service Bus)의 경량화 버전이다
MSA의 장점
Loosely coupled, More Flexibility
서비스가 개별적으로 독립적인 단위의 애플리케이션이라서 변경이 쉽고 그 변경이 다른 서비스에 미치는 영향이 적다. 덕분에 서비스를 독립적으로 개발/배포/운영할 수 있고 새로운 기술 도입 및 변경이 용이하다.
More Agility
소프트웨어의 구조가 조직 구조와 일치한다. 서비스가 독립적으로 분리되어 있기 때문에 수정 작업이 다른 서비스의 이해 당사자들과 독립적으로 진행될 수 있다. 덕분에 의사결정이 빠르고 독립적인 테스트를 진행할 수 있다. 이는 조직의 의사결정 프로세스에 많은 영향을 끼친다.
More Reusability
서비스의 재사용성이 높다.
More Scalability
독립적인 서비스별로 확장을 유연하게 할 수 있다. 서비스의 특성에 따라서 메모리 사용량이나 CPU 사용량이 많은 경우 이에 맞게 자원을 할당하여 스케일 아웃할 수 있기 때문에 효율적인 자원사용이 가능하다.
MSA 구현시 고려사항 (faet. MSA의 단점)
성능
모놀리틱에서는 컴포넌트 간에 간단한 함수호출을 사용한다. 하지만 MSA에서는 서비스 간의 호출이 통신을 통해 이루어지기 때문에 네트워크 전송 오버헤드가 발생한다.
Transaction 처리
모놀리틱에서는 트랜젝션에 문제가 있으면 DB에서 제공하는 롤백을 사용하면 됐었다. 하지만 MSA에서는 이 기능을 사용할 수 없기 때문에 메시지 전달이 실패하거나 서비스 처리 중 오류가 발생하면 핸들링해주는 별도의 비즈니스를 추가해야 한다.
End-to-end 테스팅의 복잡도 증가
MSA는 각 서비스가 분리되어 비동기로 동작하기 때문에 런타임 환경에서의 상호작용을 테스트하기가 매우 까다롭다. 그래서 각 서비스의 초기 단계에서 최대한 테스트 커버리지를 높여서 End-to-end 테스팅을 최소화하는 전략도 있다.(Testing Strategies in a Microservice Architecture 참고)
중복
다양한 언어와 기술을 사용하여 개발될 수 있기 때문에 다른 서비스와는 독립적으로 최적화된 언어 또는 기술을 사용하여 개발할 수 있다는 장점이 있지만, 같은 기능을 수행하는 코드를 서비스별로 중복으로 작성하게 될 수도 있다. 중복되는 기능을 API Gateway에서 작성할 수도 있지만, API Gateway는 최대한 가볍게 가져가야 한다는 설계 원칙을 잊어서는 안 된다. 마찬가지로 다양한 데이터 스토리지를 사용할 수도 있지만 이에 따른 데이터 중복이 발생할 수도 있다.
Reference
댓글