서비스 메시란 무엇입니까

마이크로서비스 아키텍처를 채택하고 마이크로서비스 패턴을 직접 구현할 때 팀은 비즈니스 로직과 관련 없는 부분에 많은 시간 투자를 하게 됩니다. 또한 서비스 간의 통신을 구현하기 위해 추가적인 학습이 필요합니다. 이러한 패턴은 조직의 Time To Value를 저하시키고 개발 복잡도를 증가시킵니다. 이러한 문제는 서비스 메시 패턴을 통해 해결할 수 있습니다.

서비스 메시는 일종의 통합 방식으로 마이크로서비스 네트워킹 문제를 해결하기 위한 분산 시스템이라 할 수 있습니다. 완전한 시스템은 쿠버네티스의 기능을 보완하며 쿠버네티스 클러스터에서 모든 서비스 상호작용을 제어한느 전용 계층을 기반으로 구축할 수 있습니다. 이 계층은 대개 서비스가 알지 못하는 사이에 서비스와 함께 배포된 경량 네트워크 프락시로 구성됩니다.

서비스 메시 구축 목표는 모든 서비스 트래픽을 능동적으로 모니터링할 수 있는 통합 플랫폼 확보에 있습니다. 이를 통해 내결함성, 서비스 보안, 애플리케이션 모니터링과 관련된 문제를 효율적으로 해결할 수 있습니다. 서비스 메시는 서비스 외부의 문제를 해결하기 때문에 서비스는 서비스 메시와 함께 동작하고 있음을 인식하지 못합니다. 따라서 개발자는 순수 비즈니스 로직 구현에 집중할 수 있으며 시스템 엔지니어는 인프라를 효율적으로 운영할 수 있습니다.

서비스 메시는 프로토콜에 구애받지 않으며 Session 계층에서 동작합니다. 따라서 폴리글랏 환경에 배포할 수 있습니다.

트래픽 제어

모노리딕 애플리케이션의 트래픽 흐름은 남북 방향으로 표현될 수 있습니다. 그러나 서비스 간의 통신이 빈번히 발생하는 마이크로서비스 애플리케이션의 서비스는 동서 트래픽이 빈번히 발생합니다. 따라서 서비스는 새로 배포된 서비스를 검색 (Discovery) 하고 해당 서비스로 통신을 라우팅 (Routing) 할 수 있어야 합니다.

쿠버네티스 클러스터에서 배포된 서비스는 DNS를 통해 확인할 수 있습니다. 또한 쿠버네티스는 로드 밸런서 역할을 하며 사용 가능한 모든 서비스 노드 간에 트래픽을 균등하게 보냅니다. 쿠버네티스의 이러한 기능은 롤링 업데이트 시 유용하지만 쿠버네티스는 다양한 방법을 사용해 트래픽을 세밀하게 라우팅할 수 있는 트래픽 제어 메커니즘을 제공하진 않습니다.

반면 서비스 메시를 사용하면 배포된 각 서비스 인스턴스에 관한 트래픽 흐름을 세밀하게 조정할 수 있습니다. 서비스 메시는 네트워크 계층7의 요청 헤더를 조회한 다음 요청을 특정 서비스 인스턴스로 라우팅합니다. Dark Lunch/Canary 배포 프로세스를 사용해 일부 사용자에 관한 서비스를 릴리스할 수 있습니다.

보안

쿠버네티스 클러스터에 배포된 애플리케이션은 동작하기 전에 SSL 기반 핸드 셰이크를 수행합니다. SSL 프로토콜은 서비스 ID의 유효성을 검사하고 그에 따라 권한을 부여합니다. 보안 문제는 쿠버네티스의 범위를 넘어선 인프라 차원에서 해결됩니다.
또한 애플리케이션 사용자 속성에 따른 세분화 정책을 적용할 수 있는데 서비스 메시는 L4 통신을 기반으로 하므로 서비스 프로토콜을 이해하지 않고도 모든 보안 정책을 적용할 수 있습니다. 또한 서비스 메시로 악성 서비스 사용자를 제한할 수 있도록 속도 제한을 설정할 수 있습니다.

분석

서비스 메시로 서비스 간의 통신을 체계적으로 추적하고 상호 연관시킬 수 있습니다. 그리고 이는 요청 타임라인 형태로 제공됩니다 (Trace).

서비스 메시의 마이크로서비스는 추적 컨텍스트 헤더를 전달해 이를 달성합니다. 그리고 이러한 분산 추적으로 서비스 간의 종속성을 시각화할 수 있습니다. 서비스 메시는 요청량 및 실패율에 관한 메트릭도 수집합니다.

마이크로서비스 아키텍처에선 특정 동작을 이해하기 위해 연관된 모든 서비스를 조회해야 합니다. 서비스 메시는 이러한 로깅을 위해 구축된 중앙 로깅 및 그래픽 대시보드를 제공합니다. 이를 통해 마이크로서비스 내에서 운영 가시성을 제공받을 수 있습니다.

요약하면 서비스 메시를 통해 애플리케이션 코드에서 인프라를 분리할 수 있습니다. 또한 네트워크가 물리적 연결만 제공하므로 기본 네트워크 토폴로지를 단순화합니다. 또한 서비스 메시를 사용하면 서비스 간 통신을 위한 방화벽, LB, 서브넷 등의 문제를 별도로 고민하지 않아도 됩니다.

사이드카 패턴

일반적으로 서비스 메시는 사이드카 패턴을 통해 구현됩니다. 각각의 마이크로서비스는 별도의 프로세스 (사이드카)와 함께 배포됩니다. 사이드카는 네트워킹, 모니터링, 추적, 로깅 등과 같은 기능을 제공합니다. 사이드카는 각 마이크로서비스에 따라 다르며 마이크로서비스와 동일한 생명 주기를 갖습니다. 이를 통해 다양한 기술 스택의 서비스들을 확장할 수 있습니다.

쿠버네티스 클러스터에서 사이드카는 클러스터에서 실행되는 모든 서비스와 함께 실행되며 사이드카는 다른 사이드카와 통신하며 서비스를 오가는 모든 트래픽을 프록시합니다.

그러나 사이드카 패턴은 네트워크 오버헤드가 발생할 수 있습니다. 사이드카는 부모와 동일한 수명 주기를 가지며 부모 애플리케이션과 함께 확장됩니다. 따라서 사이드카의 단독 확장은 어렵습니다.

서비스 메시에서 사이드카 프록시는 다음 작업을 수행합니다.

서비스 디스커버리

프록시가 사용 가능한 업스트림과 다운스트림 서비스 인스턴스 목록을 결정합니다.

헬스 체크

프록시가 서비스 디스커버리에서 반환된 업스트림 서비스 인스턴스가 정상인지, 네트웍 트래픽을 수락할 준비가 되었는지 확인합니다. 이런 검사에는 /health 와 같은 엔드포인트 조회를 통해 이루어집니다. 또한 5XX와 같은 실패율을 기반으로 검사할 수도 있습니다.

라우팅

서비스 메시의 서비스에서 /foo에 관한 REST 요청이 주어지면 프록시는 요청을 라우팅할 클러스터를 결정합니다.

로드 밸런싱

라우팅 중에 업스트림 서비스 클러스터가 선택되면 적절한 업스트림 서비스 인스턴스로 요청을 보냅니다.

인증과 권한 부여

mTLS 또는 기타 매커니즘을 사용해 서비스 상호작용을 검증합니다.

관찰성

각 요청에 대해 자세한 통계, 로깅, 분산 추적 데이터가 생성되므로 운영자는 문제가 발생하면 분산 트래픽 흐름을 이해하고 문제를 해결할 수 있습니다.

이외에도 사이드카는 서비스 인스턴스로부터 흐르는 모든 네트워크 패킷을 조건부 변환, 전달, 관찰할 수 있습니다. 사이드카는 서비스 메시 데이터 플레인이라고도 불립니다.

Envoy (사이드카 프로바이더)란 무엇입니까

Envoy는 C++로 작성된 고성능 L7 프록시 및 통신 버스입니다.

Envoy 아키텍처의 이점

• 저수준 언어로 작성한 고도로 최적화된 내부 서비스 프록시 제공
• L3/L4에서 수신된 TCP 메시지에 관한 다양한 작업 수행
• 요청 라우팅, 유입량 제한 등과 같은 작업을 수행하기 위해 HTTP L7에 삽입 가능
• 모든 애플리케이션에서 통곌를 수집하고 보고할 수 있는 다양한 애플리케이케이션 관찰 기능 제공
• MongoDB, DynamoDB, MySQL, Thrift 등과 같은 다양한 애플리케이션 지원

Envoy 아키텍처는 다음 요소로 구성됩니다.

Envoy 아키텍처의 구성 요소

• 포트 리스너
  리스너는 Envoy가 지정된 주소에서 네트워크 트래픽을 리스닝할 수 있도록 합니다. Envoy는 TCP 기반 리스너만 지원합니다. 일반적으로 하나의 Envoy 인스턴스에 여러 리스너를 구성하는 것이 권장됩니다.

• 필터
  필터를 통해 Envoy는 수신된 메시지에 관한 라우팅, 프로토콜 변환, 통계 생성 등과 같은 다양한 작업을 수 있습니다. 각 포트 리스너는 고유한 필터 세트를 구성하며 모든 필터는 TCP 메시지를 호출하는 필터 체인을 결합합니다. Envoy는 다음과 같은 필터 세트를 제공합니다.

• 리스너 필터
  리스너 필터는 연결 요청에서 핸드 셰이크의 일부로 호출됩니다. 이들은 TLS 검사 또는 서비스 원격 대상 등을 담당합니다.
  
  
• 네트워크 필터
  네트워크 필터에선 애플리케이션 권한 부여, 속도 제한, TLS 인증 등과 같은 작업이 수행됩니다. 통계 수집, 역할 기반 액세스 등을 수행하기 위해 호출되는 MySQL과 MongoDB와 같은 애플리케이션별 프로토콜에 관한 필터 또한 있습니다.
  
  
• HTTP 필터
  HTTP 필터는 gzip 압축, grpc에서 JSONㅇ으로의 변환 등과 같은 다양한 작업을 수행할 수 있습니다. 또한 Envoy 프록시가 수신한 HTTP 요청을 조작할 수 있습니다. HTTP 필터는 HTTP 네트워크 연결 관리자 네트워크 필터로 작성됩니다.

• 클러스터
  클러스터는 Envoy가 연결하는 논리적으로 유사한 호스트 그룹으로 정의됩니다. Envoy 클러스터는 정적 구성으로 정의되거나 내장된 서비스 디스커버리를 사용해 동적으로 생성될 수 있습니다.

Envoy의 동적 서비스 구성 요소

• 엔드포인트 디스커버리 서비스 (EDS, Endpoint Discovery Service)
  Envoy는 EDS를 사용해 클러스터에 서비를 추가/제거할 수 있습니다. EDS는 DNS의 대안을 제공하며 DNS 병목 현상을 해결하는 데 사용될 수 있습니다.

• 클러스터 디스커버리 서비스 (CDS, Cluster Discovery Service)
  CDS는 라우팅에 사용되는 애플리케이션 클러스터를 동적으로 검색하기 위해 사용됩니다. Envoy는 클러스터를 검색한 후 구성을 정상적으로 추가, 업데이트, 제거합니다.

• 라우터 디스커버리 서비스 (RDS, Route Discovery Service)
  RDS는 HTTP 연결 관리자 필터에 관한 필터 체인을 동적으로 만드는데 사용됩니다.

• 리스너 디스커버리 서비스 (LDS, Lister Discovery Service)
  LDS는 HTTP 연결 관리자 필터에 관한 리스너 체인을 동적으로 만드는데 사용됩니다.

• 시크릿 디스커버리 서비스 (SDS, Secret Discovery Service)
  SDS는 TLS 인증서, 개인 키 등과 같은 애플리케이션 시크릿을 검색하는데 사용됩니다. 또한 SDS는 클라이언트의 공개 인증서를 제공합니다.