MSA 분해로 생긴 문제들

1. 모듈간 통신 → 서비스(프로세스) 간 통신 (개발자 입장)

 

Method(Function) Call을 해서 → Network(http, grpc, ... ) 통신을 한다는 과정이라고 했을때,

일반적인 상황에서는 모놀리식이든, MSA든 전혀 차이가 없다.

 

하지만! 항상 모든 이슈는 문제(장애) 상황에서 발생한다.

 

• 발생 가능한 문제들

1. 요청에 대한 처리량(throughput)이 급격히 하락↓
   → 필요한 컴퓨팅 자원의 최적화 어려움
   → 성능 하락 or 낭비 가능성
2. http,grpc 프로토콜 상의 이슈로 문제가 생기는 경우 디버깅이 어려움
   → Connection Pool 관리
   → 한정된 리소스로인한 JVM 최적화가 더 어려워짐으로써 의도치 않은 결과 발생 가능성 ↑
   → http, grpc 프로토콜에 디펜던시가 있는 지식 필요함 (Conn Timeout, tcp-3handshake 이해, grpc code, ...)

2. 모니터링 방식의 변경 (운영, 유지보수 담당자 입장)

 

모놀리식 환경

→ Node Exporter를 활용하여 Node(DB) 상태에 집중

 

MSA환경

→ Node 상태 뿐만이 아니라, 서비스 간 호출 상태 파악

→ Lantency 증감 확인, Call 증감 확인

→ 어떤 API 호출중인지 확인

→ Async 방식 등에 대해서도 모니터링 필요

     - kafka 큐잉

→ 다양한 비즈니스 메트릭에 대해서도 어려워짐

 

• 발생 가능한 문제들

1.  Network hop 이 늘어남에 따라, 어디서 어떤 요청에 대한 문제가 발생했는지 어려움
   → 서비스의 갯수가 늘어가면서, 어느 요청에서 문제가 발생했는지?
   
   
2. 로그 수집을 위한 별도의 인프라 필요 및 관리 필요성 (DevOps)
   →  굉장히 복잡하고, 처리해야할 많은 문제들 발생(e.g 누락)
   
   
3. 수십, 수백개의 서비스에 대해 JVM/하드웨어 얼마나 정상적인지 지속적인 확인 필요
   →  서비스 또는 서버에 문제가 생기더라도 적절하게 문제 감지 어려움
   
   
4.  어느 서비스에서 어느 서비스로 호출이 되어야 하는지, 이게 정상인지 확인 필요
   →  서비스 간 호출 상태가 옳은 상태인지, 엉뚱한 서비스를 후출하지 않는지 파악 어려움