MSA, Microservice Architecture 장단점

Microservice Architecture pattern

 

하나의 프로젝트가 너무 커지면 (monolith)

1. 내부 복잡도가 증가하여 유지보수 생산성이 떨어지고
2. 상호 종속성이 높기 때문에 테스팅을 해야하는 양이 증가하거나 버그가 증가하고 따라서 continuous deployment가 거의 불가능에 가깝다
3. 한 곳의 버그나 메모리 누수가 서비스 전체에 영향을 미칠 가능성이 있다.
4. 애자일 개발 방법론에 적용되지 않는다.

 

Microservice Architecture로 하게 되면

1. 복잡도의 문제를 해결할 수 있다.
2. 각 팀이 좀 더 독립적으로 해당 기능에 집중해서 개발할 수 있다.
3. 모듈 단위로 배포가 가능하다. A/B testing이 가능하고 UI 변화에 빠르게 대응할 수 있다. CI/CD가 가능해진다.
4. 여러 개의 인스턴스를 상황에 맞게 설정 가능하다. Computing 중심인 인스턴스와 database 중심인 인스턴스를 구별해서 개설하고 활용이 가능하다. Polyglot 환경도 만들 수 있고, 최신 버전의 언어, 프레임워크, 라이브러리를 적용하는 점에 있어서도 수월하다.

*인스턴스마다 독립적인 DB를 물리는 것이 효과적이다. 데이터의 중복이 생길 수도 있지만, 그래야 loose coupling되어 microservice의 장점이 드러날 수 있게 된다.

하나의 서비스에 1000개의 테이블이 있다면, 실질적으로 히팅 수가 높은 테이블은 몇 되지 않는다. 단순히 DB Index 만으로는 어려움에 부딪히는 상황이 많이 발생할텐데, MainDB의 데이터를 동기화하거나 Sharding하는 등 조회용으로 만들어 놓은 DB로 성능을 향상시킬 수 있다.

 

 

# Microservice Architecture 단점

1. 업무상 종속성이 높고 다소 복잡도가 높은 로직의 경우에는 ‘마이크로’하게 접근하기 어려운 점이 있다.
2. 여러 인스턴스 간의 소통에 대한 작업을 해야하고, 각각의 마이크로 서비스들의 장애가 발생할 때의 대응도 충분히 해줘야 한다.
3. 다른 곳에서 api를 호출하는 api 와 같은 경우에, 테스팅 하기 위해 좀 더 수고로운 케이스가 생기기도 한다.
4. 여러 Microservice가 하나의 트랜잭션으로 묶일 때는 개발이나 테스트가 어렵다. 어렵다고 못할 것은 아니지만..