2. Reactive Mircroservice의 Microservice #

Monolithic 아키텍쳐 #

• 모든 컴퍼넌트가 하나의 서버 내에 존재
• 단순성: 코드 저장소가 하나로 존재하는 경우가 많아서 관리 포인트가 줄어든다
• 일관성: 각각의 서비스는 하나의 기술 스택으로 제공되기 때문에 접근성이 높다
• 높은 효율: 서비스 사이에 네트워크 통신이 없기 때문에 네트워크 지연이나 데이터 직렬화에 의한 오버헤드가 없다

Monolithic 아키텍쳐의 단점 #

• 확장성의 한계: 모든 서비스가 하나의 서버로 구성되어 있기 때문에 특정 서비스가 부하를 받더라도 서버 전체를 늘려야 한다
• 장애의 전파: 서비스 중 한 곳에서 문제가 발생하면 시스템 전체에 영향을 줄 수 있다
• 배포의 단일화: 하나의 서비스를 변경하더라도 전체 시스템을 다시 배포해야 한다
• 기술의 정체: 모든 서비스가 하나의 코드베이스에 결합되어 있어서 새로운 기술을 도입하거나 아키텍쳐의 변경이 전체에 큰 영향을 줄 수 있다
• 유지보수의 어려움: 모든 구성요소가 직접 연결 되어 있기 때문에 작은 부분의 수정이 전체에 영향을 미칠 수 있다

Microservice 아키텍쳐 #

• 이러한 단점을 극복하기 위해 서비스와 저장 소, 데이터베이스 등을 분리
• 독립적인 배포: 각 서비스는 독립적으로 배포
• 유연한 확장: 각 서비스는 각각 탄력적으로 확장 가능. 트래픽이 몰리는 특정 서비스만 서버를 늘려서 유연하게 대응 가능
• 장애 격리: 서비스 하나에서 장애가 발생해도 전체 어플리케이션에 영향을 주지 않는다
• 기술의 유연성: 각 서비스는 다른 언어, 프레임워크, 기술 스택 사용 가능. 심지어 서버리스 또한 도입 가능

Microservice 아키텍쳐 단점 #

• 복잡성 증대: 각각의 서비스가 네트워크를 통해서 통신. 네트워크 지연, 실패, 데이터 일관성 등의 문제가 발생
• 데이터 일관성: 각각의 서비스가 별도의 데이터베이스를 유지하기 때문에 이를 일치하는 것이 어렵다
• 배포와 운영의 복잡성: 각 서비스가 독립적인 배포 프로세스를 갖추며, 모니터링, 알림 시스템이 필요
• 테스트의 어려움: 서비스가 분리되어 있고 데이터베이스도 각자 가지고 있기 때문에 테스트 준비에 더 많은 리소스 필요
• 높은 초기 비용: 올바르게 구축하기 위해서 상당한 시간과 노력이 필요

Microservice 구현 #

• 외부 서비스, 클라이언트에 대한 직접적인 노출
• 장애 격리 실패로 인한 시스템 전체의 붕괴
• 특정 메시지 큐를 직접 사용하여 불필요한 의존성 증대와 확장성 축소

Microservice와 Spring cloud #

• API Gateway를 이용해서 내부 시스템 은닉 및 안정성 제공
• Circuit breaker를 이용해서 장애를 격리하고 시스템 안정성 유지. 장애 복구 여유 확보
• 추상화된 발행/구독, 생산/소비 메시지 패턴을 제공하여 확장성을 높이고 의존성 축소