[책 리뷰] 스프링으로 하는 마이크로서비스 구축 1장

뿌이·2022년 2월 8일

스프링 클라우드

목록 보기

6/32

독립 소프트웨어 컴포넌트의 문제

원래는 일체형 플랫폼을 사용하는 모놀리스 방식에서
플랫폼을 개별적으로 독립시켜서 서비스별로 분리하는 MSA 방식은
모놀리스 방식과는 다른 새로운 문제가 발생한다

컴포넌트에 새 인스턴스를 추가하려면 수동으로 로드밸런서를 구성, 새 노드를 수동으로 설정해야 한다.
이 작업은 시간이 오래걸리고 오류가 발생하기 쉬움
플랫폼 내부 통신은 대부분 동기식이기때문에 한 컴포넌트의 중단은 연속적인 오류를 유발한다.
즉 중단된 컴포넌트의 클라이언트도 곧 중단된다 이것을 연쇄장애라고 한다.
(통신하는 다른 시스템에서 오류가 발생시 플랫폼으로 전이된다는 근본적 문제)
모든 컴포넌트 인스턴스의 구성을 일관성있게 최신 상태로 유지하는 작업에 많은 문제점이 있어
반복적인 수작업이 자주 발생 -> 이에 따른 품질문제 발생
지연시간 문제 및 하드웨어 사용량 측면에서 플랫폼 상태를 모니터링 하는 작업은
일체형 애플리케이션의 인스턴스 하나를 모니터링 하는것과 비교하면 훨씬 더 복잡
분산된 여러 컴포넌트에서 로그파일을 수집하고
관련된 컴포넌트 로그 이벤트를 상호연관 시키는 것은 어려운 작업
: 컴포넌트 수를 미리 알고있다면 실현 가능

위에서 언급한 대부분의 문제점은 자체개발 도구와 수동 처리를 위한 문서화된 지침으로 해결 가능
MSA가 꼭 좋은것만은 아니라는 설명 유튜브

마이크로 서비스 입문

🎇서비스 메시란?

서비스 메쉬가 서비스 간 커뮤니케이션의 모든 부분을 성능 메트릭으로 캡처하기 때문에
복잡한 마이크로 서비스 아키텍처 내에서 문제가 발생한 지점을 찾아냅니다.
서비스에 장애가 발생한 경우 서비스 메쉬는 재시도가 성공하기 까지 소요한 시간에 대한 데이터를 수집할 수 있습니다.

작동방식

서비스 메쉬는 네트워크 프록시의 배열로서 애플리케이션에 구축됩니다.

1. 이 페이지에 대한 사용자의 요청이 발송되면 사용자의 회사 웹 프록시가 먼저 이를 수신합니다.
2. 요청이 프록시 보안 조치를 통과하면 이 페이지를 호스팅하는 서버로 전송됩니다.
3. 다음으로 이 페이지가 프록시로 돌아가서 다시 보안 조치를 수행합니다.
4. 그 후 최종적으로 프록시에서 사용자에게 전송됩니다.

서비스 메쉬에서는 요청이 자체 인프라 계층의 프록시를 통해 마이크로서비스 간에 라우팅됩니다.
이러한 이유로 서비스 메쉬를 구성하는 개별 프록시는 서비스 내부가 아니라 각 서비스와 함께 실행되므로 'sidecar'라고도 합니다.
각 서비스에서 분리된 이러한 sidecar 프록시들이 모여 메쉬 네트워크를 형성합니다.