마이크로서비스 핵심만 빠르게 이해하기

마이크로서비스(이하 mSVC라고도 함)에 대해서 제가 이해하는 수준에서 최대한 쉽게 정리해 봤습니다.

마이크로서비스란 ? 

마이크로서비스는 큰 서비스를 고유의 Database를 갖고 있는 작은 단위로 나눈 서비스입니다.

이런 마이크로서비스를 설계,개발,배포,운영하는 아키텍처 패턴(반복 사용될 수 있는 방법)을 마이크로서비스아키텍처(MSA-Micro Service Architcture)라고 합니다.

각 마이크로서비스가 고유의 DB가 있어야 하는 이유는 다른 서비스의 일시적 장애에도 자기 자신의 서비스는 그 자체로 동작하도록 하기 위해서입니다. 즉, 서비스 간 Loosely Coupling 하기 위해서 입니다. 

이론적으로는 그렇지만 각 서비스가 고유의 DB를 갖기 위해서는 추가적인 비용이 들어갑니다. 

대표적으로 DB간 데이터 동기화를 위한 추가적인 개발이 필요하며, 분산된 DB를 운영하기 위한 추가적인 노력이 필요합니다. 

그래서 서비스는 나누지만 DB는 공유하는 Shared Database패턴을 사용하기도 합니다.  

아래는 마이크로서비스의 핵심을 한 장으로 요약한 장표 입니다. 

 

마이크로서비스의 장점과 기대효과 : SSS

Speedy -> Time to maket

작은 단위의 서비스는 비즈니스 요구사항을 수용하기 더 쉽고 빠릅니다.

또한, 다른 서비스와 느슨하게 결합되어 있기 때문에 배포도 더 자주 더 빠르게 할 수 있습니다.

 

Service Always -> Earning More

서비스가 비동기로 느슨하게 결합되어 있고 고유의 DB를 갖고 있기 때문에 특정 서비스의 장애로 인해 전체 서비스가 중단되지 않습니다.

예를 들어 주문 마이크로서비스는 결제서비스만 살아 있다면 음식점서비스, 배달서비스가 정지되었어도 주문을 계속 받을 수 있습니다.

일단 주문 접수와 결제까지만 처리하고 Queue에 음식점티켓과 배달요청 메시지를 생성만 합니다. 음식점서비스와 배달서비스는 재시작 후 이 Queue의 요청을 읽어 정상 처리를 합니다.

서비스를 컨테이너화하면 장애 시 컨테이너를 재 생성하여 스스로 장애를 해결할 수도 있습니다.

Save Cost -> Cost Effective

1) 수평 Scaling

서비스가 분할되어 있으므로, 사용량이 많은 서비스는 자원(CPU, Mem, Disk)을 늘리고, 사용량이 적은 서비스는 자원을 줄이는게 가능합니다. 따라서 전체적인 비용을 절감할 수 있습니다. 

또한 사용량이 급증하는 서비스의 자원을 자동으로 늘림으로써 서비스 장애도 방지할 수 있습니다.

2) 수직 Scaling
서비스를 컨테이너화 한다면 각 서비스에 기본 자원을 배정하고 사용량에 따라 자원을 늘이고 줄일 수 있습니다. 이는 기존에 사용량 최대치를 추정하여 초기 할당량을 배정함으로써 생기는 불필요한 자원 낭비를 줄일 수 있습니다. 

 

 

마이크로서비스의 이슈: CCOP   

Complex

큰 서비스를 이루는 마이크로서비스들은 계속 생성, 수정(버전 up/down), 삭제된다. 마이크로서비스가 많아지면 많아질 수록 서로를 연결하고 네트워킹을 통제하기가 점점 힘들어집니다. 

==> Service Mesh(istio, spring cloud)툴

 

Consistency

각 마이크로서비스가 갖고 있는 DB간에 정합성을 보장하기 힘듭니다. 주문, 결제, 배달서비스가 분리되어 있을 때 결제 실패한 주문이 배달될 수도 있습니다. 

==> Saga패턴과 비동기메시징을 통해 완화

Operational Overhead

각 마이크로서비스는 개발기술과 조직이 다를 수 있습니다. 따라서 테스트, 배포, 버전관리, 장애관리 등이 기존보다 더 복잡하고 힘듭니다. 

==> DevOps문화, CI/CD Pipeline, Test 자동화, 통합 로깅 및 모니터링

Performance

각 마이크로서비스는 물리적으로 다른 HOST 또는 VM에 있기 때문에 기존에 한 HOST/VM에 있을때보다 네트워크 트래픽이 훨씬 많이 증가합니다. 네트워크 장애 또는 지연으로 인해 성능이 감소할 수 있습니다. 

=> BFF(Backend for Frontend)계층분리, 캐시

Monolithic 단점

 

mSVC의 장점인 SSS(Speedy, Scalability, Service Always)의 반대가 Monolithic의 단점이라고 할 수 있습니다. 

즉, 큰 단위의 서비스로 되어 있기 때문에 비즈니스 요구사항 수용이 어렵고, 불필요하게 자원을 사용할 수도 있으며 서비스 장애 가능성이 높아집니다. 

 

참고) Monolithic앱 배포 시 WAS 재기동 문제 해결

이론서에는 모놀리식은 배포할 때 전체 서버를 재기동해야하는 단점이 있다고 하지만,

Java는 Custom classloader의 hot deploy기능을 이용하여 WAS 재기동 없이 특정 어플리케이션만 배포할 수 있습니다. 

https://chaeyoungdo.tistory.com/32

https://tinyurl.com/y3yod45u

특히 한국 기업에서 사용하는 개발프레임워크는 이 기능이 매우 잘 되어 있습니다.

 

마이크로서비스 설계

마이크로서비스의 설계는 DDD가 가장 적합합니다.

happycloud-lee.tistory.com/94?category=902418

DDD 개요

 

마이크로서비스 패턴 적용

아래 글들을 참조하십시오.

마이크로서비스 패턴: 핵심패턴만 빠르게 이해하기