요약
- 마이크로서비스 운영과 관리를 위한 플랫폼 패턴의 나머지 부분에 대해 이해함.
- 장애 및 실패 처리를 위한 서킷 브레이커 패턴
- 모니터링과 추적 패턴
- 중앙화된 로그 집계 패턴
- MSA 기술 변화 흐름
- 서비스 메시 패턴
메모
장애 및 실패 처리를 위한 서킷 브레이커 패턴
- 여러 서비스로 구성된 시스템에서 한 서비스에 장애가 발생했을 때 다른 서비스가 영향을 받을 수 있음.
- 이때 장애가 발생한 서비스를 격리해서 유연하게 처리할 수 있는 방법이 필요함.
- 이를 위한 한 가지 방법은
서킷 브레이커 패턴임.
- 시스템 과부하나 특정 서비스에 문제가 생겼을 때 자연스럽게 다른 정상적인 서비스로 요청 흐름이 변겨오디게 해야 함.
- 그러자면 서비스 상태를 항상 실시간으로 관리해서 시각화하고 모니터링할 수 있어야 함.
- 특정 서비스에서 장애가 감지되면 장애가 다른 서비스로 전이되지 않게 하는 방법이 반드시 필요함.
- 이를 전기회로 차단기와 비슷하다고 해서 서킷 브레이커 패턴이라고 함.
- 연속 실패 횟수가 임곗값을 초과하면 회로 차단기가 작동해서 이후에 서비스를 호출하려는 모든 시도를 즉시 실패하게 만듦.
- 폴백(fallback) 메서드를 지정해 두면 장애가 발생했을 때 폴백 메서드가 자연스럽게 처리르 진행하게 됨.
- 사용자는 특정 서비스에 장애가 발생했는지 눈치채지 못하고 시간이 흘러 장애가 복구됐을 때 다시 호출을 정상화하면 됨.
모니터링과 추적 패턴
- 서킷 브레이커 패턴을 가능하게 하려면 각 마이크로서비스의 장애를 실시간으로 감지해야 함.
- 그리고 서비스 간의 호출이 어떤지 알아야 함.
- 즉, 모니터링하고 추적하는 패턴이 필요함.
- 스프링 클라우드에서는 히스트릭스라는 라이브러리를 제공함.
- 히스트릭스 라이브러리가 배포된 서비스를 모니터링할 수 있는 히스트릭스 대시보드를 제공함으로써 마이크로서비스의 요청을 실시간으로 모니터링 할 수 있음.
- 분산 트레이싱 서비스의 경우 모니터링과 함께 각 서비스 트랜잭션의 호출을 추적함.
- 마이크로서비스 운영에 매우 유용함.
- 트위터에서 공개한 집킨(Zipkin) 오픈소스 프로젝트의 대시보드는 분산된 서비스 간의 호출이나 지연 구간별 장애 포인트를 확인할 수 있음.
- 호출 빈도가 너무 많은 API나 반응 시간이 높은 API가 있다면 이를 개선해볼 수 있음.
중앙화된 로그 집계 패턴
- 마이크로서비스의 로그는 어떻게 관리하는 가?
- 마이크로서비스가 사용량에 따라 탄력적으로 변화하면서 언제든지 인스턴스가 생성/삭제 되는 과정에서 로컬 로그가 초기화될 수 있음.
- Twelve-Factor 에서는 로그를 이벤트 스트림(event streams)으로 처리하라고 함.
- 로그는 시작과 끝이 고정된 것이 아니라 서비스가 실행되는 동안 계속 흐르는 흐름임.
- 서비스는 스트림의 전달이나 저장에 절대 관여하지 않아야 한다고 말함.
- 로그를 전달 및 저장하는 메커니즘 자체가 특정 기술이나 인프라에 의존할 수밖에 없고 이러한 메커니즘을 직접 마이크로서비스에서 구현한다면 유연성이 떨어지기 때문
- 따라서,
중앙화된 로그 집계 패턴이 필요함.
- 서비스에서 발생한 이벤트 스트림 형태의 로그를 수집하고 살펴볼 도구가 필요함.
- 대적으로 많이 쓰이는 기술이 ELK 스택임
- ELK 스택는 엘라스틱서치, 로그스태시, 키바나라는 세 가지 오픈소스 프로젝트를 기반으로 데이터 분석 환경을 구성한 것임.
- 엘라스틱서치(Elasticsearch)
- 로그스태시(Logstash)
- 키바나(Kibana)
- ELK 스택을 사용하면 각 서비스의 인스턴스 로그를 집계해서 중앙에서 집중 관리할 수 있음.
- 특정 메시지가 로그에 나타나거나 특정 예외가 발생할 때 운영자나 개발자에게 직접 통보도 가능함.
- 위 그림은 로그 집계 아키텍처임.
- 각 서비스에 로그스태시가 설치되어 각 로그를 수집해서 레디스 저장소에 보냄.
- 또, 엘라스틱서치와 키바나로 로그 중앙 관리 저장소와 대시보드 서비스를 각각 구축함.
- 마이크로서비스에서 보낸 로그가 중앙 레디스에 쌓이면 레디스에서 중앙 관리 저장소에 로그를 보내고, 이 로그 저장소에 엘라스틱서치 엔진이 로그를 인덱싱하고 해당 로그 정보가 키바나 대시보드를 통해 보여짐.
- 중간에 레디스 데이터베이스를 둔 까닭은
- 마이크로서비스의 로그스태시가 바로 로그 저장소에 로그를 보낼 수는 있지만 로그 스트림이 너무 몰리면 로그 저장소 서비스에도 성능 문제가 생기기 때문에 중간에 임시 저장소를 추가한 것임.
MSA 기술 변화 흐름(3)
- 초기 MSA 생태계에서는 넷플릭스 OSS 나 스프링 클라우드를 이용해 각각의 서비스를 별도로 만들어서 해결하거나 유연성처럼 수평 확장이 필요한 요소는 AWS IaaS 서비스를 이용해 해결함.
- 문제마다 상이한 기술로 해결할 수밖에 없었음.
- 이후, 여러 문제의 해결책을 한꺼번에 제공하는 솔루션들이 등장함.
- 쿠버네티스나 오픈시프트 같은 제품임.
- 기존의 넷플릭스 OSS 기반의 여러 서비스로 처리했던 문제들을 묶어서 하나의 쿠버네티스, 또는 오픈시프트로 해결할 수 있게 됨.
- 특히, 인프라 유연성 보장을 위해 AWS IaaS의 인프라 차원에서 해결했던 역할을 쿠버네티스가 소프트웨어 차원, 즉 컨테이너 레플리카 기술로 탐색, 호출 문제와 함께 통합해서 지원하면서 쿠버네티스가 각광받고 있음.
- 최근 동향은 쿠버네티스에 덧붙여 이스티오 기술이 함꼐 사용되고 있음.
서비스 메시 패턴(3)
- API 게이트웨이, 서비스 레지스트리, 컨피그 서비스와 같이 운영 관리를 위한 여러 개의 기반 서비스를 별도로 각각 만들어야 한다는 번거로움이 있음.
- 위 그림은 서비스 메시의 개념도임.
- 왼쪽은 업무 처리 마이크로서비스에 스프링 클라우드 서비스를 사용하기 위한 라이브러리를 비즈니스 로직과 함께 탑재해야 함.
- 기능 구현에 집중해야 하는 마이크로서비스 입장에서 이러한 코드관리 까지 관리 및 운영하는 것은 번거로울 수밖에 없음.
- 스프링 클라우드는 자바 기반이므로 마이크로서비스가 자바 외의 다른 언어로 폴리글랏하게 구현된 경우, 스프링 클라우드 서비스를 아예 사용할 수조차 없음.
- 이 문제를 해결하기 위해 비즈니스 로직과 분리해서 네트워크 인프라 계층에서 수행하게 하는 서비스 메시(service mesh) 패턴이 선호되고 있음.
- 서비스 메시는 인프라 레이어로서 서비스 간의 통신을 처리하며 앞에서 언급한 여러 문제 해결 패턴을 포괄함.
- 이스티오는 애플리케이션이 배포되는 컨테이너에 완전히 격리되어 별도의 컨테이너로 배포되는
사이드카(Sidecar) 패턴 을 적용해서 서비스 디스커버리, 라우팅, 로드 밸런싱, 로깅, 모니터링, 보안, 트레이싱 등의 기능을 제공함.
- 이스티오는 쿠버네티스에 탑재되어 이러한 서비스 메시 기능을 지원함.
- 서비스 메시를 적용하는 경우, 위 오른쪽 그림처럼 마이크로서비스마다 함꼐 배포되는 사이드카 프록시에 운영 관리를 위한 기능이 별도로 담겨있기 때문에 마이크로서비스는 순수 비즈니스 로직에 집중할 수 있음.
- 위 그림은 서비스 메시의 통신을 보여줌.
- 컨트롤 플레인 기능에 의해 중앙에서 통제됨.
- 사이드끼리 통신해서 관련 운영 관리 기능을 제공하는 모습을 보여줌.
- 이를 통해 마이크로서비스의 비즈니스 로직과 완벽하게 독립적으로 운영됨.
- 쿠버네티스의 컨테이너 단위인 파드(pod)에 서비스 컨테이너와 사이드카 구현체인 엔보이(Envoy) 컨테이너가 함께 배포된 것을 볼 수 있음.
댓글