1. 복잡하여, 설계가 어렵다.
- 서비스가 자율적으로 되려면 전체적으로는 느슨하게 연결되고 개발적으로는 기능 요소들이 높은 응집도를 가지도록 설계해야 한다.
- 마이크로서비스의 범위를 정하고 식별하는 데는 대상 도메인에 대한 상당한 지식이 필요하다.
- 마이크로서비스는 분산 시스템이므로 시스템의 상태, 일관성, 네트워크 신뢰성에 대해 다른 가정을 전제해야 한다.
- 시스템 구성요소를 여러 네트워크에 분산하고 혼재된 기술의 수가 늘어나면 마이크로서비스에는 새로운 형태의 장애가 생긴다.
- 정상 상태에서는 무엇이 발생해야 하는지 이해하고 검증하는 것이 더욱더 어렵다.
- 시간이 지나면서 기존의 API를 사용하는 서비스와의 하위 호환성을 유지하면서 진화해야 한다.
2. 운영상의 도전과제
-
마이크로서비스 접근 방식은 본질적으로 시스템에 장애가 발생할 수 있는 지점을 증가시킨다.
-
개발할때는 마찰이 줄지만, 운영 중인 애플리케이션을 배포/검증/모니터링하는 방법이 더 복잡해진다.
-
아래와 같은 문제가 발생시 어떻게 처리해야할까?
-- 문제가 발생하면 어디에서 오류가 발생했는지 어떻게 알 것인가?
-- 서비스에 영향을 주지 않고 새로운 버전의 서비스를 어떻게 배포할 것인가?
-- 어떤 서비스가 호출돼야 했는지를 어떻게 알 것인가?
-- 어떤 동작이 여러 서비스에 걸쳐 올바르게 작동하는지 어떻게 테스트할 것인가?
-- 서비스를 사용할 수 없으면 무슨 일이 발생하는가? -
문제점 및 모니터링 대상
-- 네트워크/라우터 장애: 네트워크 문제가 사용자/서비스/의존성 사이에 요청 전달이 실패하는 문제를 일으킨다.
-- 과부하: 서비스 인스턴스가 요청을 너무 많이 받아 응답하지 못하거나 시간제한에 걸린다.
-- 하드웨어 장애: 데이터베이스 또는 서비스 인스턴스를 실행하는 하드웨어에 장애가 발생한다.
-- 하위 의존성 장애: 의존하는 서비스가 실패하거나 응답이 느려질 수 있다.
-- 제삼자 장애: 의존하는 제삼자로의 요청이 실패할 수 있다.
Fullstack developer