[MSA] MSA의 특징과 장단점

오늘은 저번 시간에 이어서 MSA의 특징과 장단점에 대해서 알아보도록 하겠습니다.

MSA의 특징

스프링 5.0 마이크로서비스 2/e에서는 아래와 같은 문구가 나옵니다.

마이크로서비스의 특징에 대해서는 구체적이면서 모두가 동의하는 단 하나의 정의는 없다. 하지만 성공적이었던 모든 마이크로서비스 구현체들 사이에는 공통적으로 발견되느 특징들이 몇 가지 있다.

이 책에 서술되어 있는 성공적인 마이크로서비스의 공통적인 특징에 대해서 알아보도록 하겠습니다.

서비스는 일급 시민

API를 통해서만 마이크로서비스와 서비스와 상호작용할 수 있습니다. 즉, 마이크로서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화합니다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려집니다.

• 따라서 SOA(Service Oriented Architecture)의 특징을 다수 공통으로 가집니다.

마이크로서비스는 가볍다

제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다. 그 결과 대부분의 마이크로서비스 구현체에서 볼 수 있는 공통적인 특징 중 하나는 마이크로서비스가 작은 공간만을 차지한다는 점이다. 따라서 마이크로서비스를 이루는 기술을 선택할 때에도 그 기술이 가벼운지 꼭 확인해야 한다.

다양한 언어로 구성할 수 있는 마이크로서비스

마이크로서비스는 자율적이고 모든 것을 추상화해 서비스 API 뒤에 숨기기 때문에 서로 다른 마이크로서비스에서 서로 다른 아키텍처를 적용할 수 있다.

ex_1) 서로 다른 서비스는 동일한 기술의 다른 버전을 사용할 수 있습니다. 어떤 마이크로 서비스는 자바 1.7, 다른 마이크로서비스는 자바 1.8로 적용할 수 있습니다.

ex_2) 서로 다른 서비스는 서로 다른 언어로 개발될 수 있다. 예를 들어 어떤 마이크로서비스는 자바로 개발되고, 다른 마이크로서비스는 스칼라로 개발될 수 있다.

ex_3) 서로 다른 마이크로서비스는 서로 다른 아키텍처를 적용할 수 있다. 예를 들어 어떤 마이크로서비스가 데이터의 신속한 서비스를 위해 Redis 캐시를 사용하는 반면에 다른 마이크로서비스는 데이터 스토어로 MySQL을 사용할 수도 있다.

마이크로서비스 환경에서의 자동화

마이크로서비스는 일체형 어플리케이션을 여러 개의 작은 서비스로 분리하므로, 대규모의 기업 시스템 안에는 상당히 많은 수의 마이크로서비스가 존재할 수 있다. 이렇게 많은 수의 마이크로서비스는 자동화하지 않는다면 관리 부담이 상당히 커질 수 있다.

ex_1) 개발 단계의 자동화를 위해 git같은 형상 관리 도구와 Jenkins, Travis CI등과 같은 지속적 통합도구(Continuous Integration)를 함께 사용한다. 이런 자동화 과정에는 코드 품질 검사와 단위 테스트 자동화를 포함할 수도 있다.

ex_2) 테스트 단계에서는 셀레늄, 큐컴버나 다른 A/B 테스트 전략을 사용해서 자동화를 적용할 수 있다. 마이크로서비스는 단위 비즈니스 영역에 맞춰 만들어지므로, 일체형 어플리케이션보다는 자동화해야 할 테스트 케이스 수가적다.

ex_3) 인프로스트럭처 프로비저닝도 도커와 같은 기술과 셰프 또는 퍼펫같은 릴리스 관리 도구, 앤서블(Ansible)과 같은 구성 관리 도구를 함께 사용해서 자동화할 수 있다.

마이크로서비스를 지원하는 생태계

대부분의 대규모 마이크로서비스 구성체는 적재적소에 필요한 생태계(ecosystem)를 갖고 있다. 데브옵스 프로세스, 중앙 집중식 로그 관리, 서비스 레지스트리, API 게이트웨이, 모니터링, 서비스 라우팅, 작업 흐름 통제 메커니즘 등이 마이크로서비스를 지원하는 생테계에 포함된다.

동적이고 분산돼 있는 마이크로서비스

마이크로서비스는 SOA에서 사용되는 집중화된 관리 체계를 사용하지 않는다. 마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점이다. REST 등 가벼운 통신 아키텍처, 또는 kafka 등을 이용한 message stream을 주로 사용한다.

붕괴 저항성, 빨리 실패하기, 자체 치유

빨리 실패하기란? 장애를 견딜 수 있고 회복력이 좋은 시스템을 구축하는 데 사용되는 개념이다. 이런 철학은 절대로 장애가 발생하지 않는 시스템을 구축하기보다는 장애를 예상하고 대응할 수 있는 시스템을 만드는 쪽에 무게를 둔다. 얼마나 빨리 실패하는지, 또 실패할 경우 얼마나 빨리 정상 상태로 복구할 수 있는지가 정말 중요한 포인트다.

자체 치유란 ? 마이크로서비스에서 널리 사용되는 개념으로 시스템이 장애로부터 학습을 하고 스스로를 장애에 적응시킨다는 개념이다. 이런 시스템은 미래의 장애를 어느 정도 예방할 수 있다.

MSA의 장점

복잡성의 문제를 해결한다

모놀로식과 비교하여 MSA의 기능의 수는 동일합니다. 하지만 각각의 서비스는 모듈화가 되어있으며 이러한 모듈끼리는 RPC 또는 message-driven API등을 이용하여 통신합니다.이러한 MSA는 각각 개별의 서비스 개발을 빠르게 하며, 유지보수도 쉽게 할 수 있도록 합니다.

서비스는 팀단위로 문제가 해결 될 수 있다

기술을 선택할 때 물론 회사의 정책 등을 고려해야겠지만, 팀단위로 기술 적절한 수준에서 스택을 다르게 가져갈 수 있게 되었습니다. 적절한 기술에 적절한 기술 스택을 선정할 수 있게 되었습니다. 예를 들어 블록체인은 solidity에 이어 백엔드의 기술스택은 node.js로 가져가는 것이 일반적입니다. (물론, web3j를 이용하여 java로 개발 할 수 있습니다.) 하지만 해당 회사가 java의 spring기반이라면 제약사항이 따를 수 밖에 없습니다. 하지만 MSA를 적용하면 node.js로 블록체인 개발 모듈을 가져감에 무리가 없습니다.

마이크로서비스의 개별 배포

마이크로서비스는 서비스별로 독립적 배포가 가능합니다. 따라서 지속적 배포 CD도 모놀로식에 비해서 가볍게 할 수 있습니다.

마이크로서비스의 개별 Scale-Out

마이크로서비스는 각각 서비스의 부하에 따라 개별적으로 scale-out이 가능합니다. 만약 물류시스템에 주문과 물류사 관련 서비스가 있을 때, 주문이 많이 밀렸을 경우 주문 서비스만 Scale-out하여 견딜 수 있습니다. 메모리, CPU적으로 상당부분 이득이 됩니다.

MSA의 단점

복잡성의 증가

MSA는 모놀리식에 비하여 상대적으로 많이 복잡합니다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할 지 정해야합니다. 또한 통신의 장애, 한 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할 지 결정하고 구현해야합니다.

데이터 transaction의 일관성

서비스는 항상 트랜잭션을 유지하는게 중요합니다. MSA는 서비스가 분산되어 있기 때문에 비즈니스 트랜젝션을 유지하는게 어렵습니다. 모놀리식에서는 단일 트랜젝션(DB)을 유지하면 됬지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵습니다.

통합 테스트의 어려움

개발환경과 실제 운영환경을 동일하게 가져가는게 쉽지않습니다.

배포의 어려움

실제 운영환경에 대해서 배포하는게 쉽지 않습니다. 모놀리식의 경우 서버 전체에 대해서 배포하기 때문에 서비스간의 연계에 대해서 생각해야하는 경우는 드뭅니다. 하지만 마이크로서비스의 경우 서비스 1개를 재배포 한다고 하면 다른 서비스들과의 연계가 정상적으로 이루어 지고 있는지도 확인해야합니다. 또한 그렇게 되도록 배포해야합니다.

참조

https://www.nginx.com/blog/introduction-to-microservices/

스프링 5.0 마이크로서비스 2/e