ServiceMesh

  • Mesh, 서비스들이 서로 그물처럼 엮여 있다는 의미다.
  • MSA를 적용한 시스템의 내부 통신이 Mesh Network의 형태를 띠는 것에 빗대어 명명됐다.
  • Istio처럼 애플리케이션의 다양한 부분들이 서로 데이터를 공유하는 방식을 제어하는 방법
  • Istio가 서비스 메시를 구현할 수 있는 대표적 오픈소스 솔루션이다.

  • 데이터와 일관성을 공유하며 서로 통신할 수 있도록 지원하는 사전 구성된 애플리케이션 서비스
  • 애플리케이션에 구축된 전용 인프라 계층이다.
  • 쉽게 설정하고 배포할 수 있도록 설계된 서비스 메시는 MicroService에서 새로운 서비스를 쉽게 발견하고 관리할 수 있게 되어 있다.

  • k8s에선 서비스 메시는 sideCar를 이용한 확장 가능한 네트워크 프록시 모듈로 구현된다.

mesh.png 출처

  • MSA에서는 시간이 지나고 크기가 커지면 서비스 간 통신 복잡성이 급격하게 증가한다.
  • 마이크로서비스의 설정, 관리, 통신 방식에 대한 제어가 필요하며, 마이크로서비스마다 추가되어야 할 공통 기능이 증가한다.
  • 이러한 관리 포인트 증가에 대한 문제를 해결하기 위한 방법 중 하나가 ServiceMesh

사이드카 패턴

sideCar.png

  • pod 내 애플리케이션 컨테이너와 독립적으로 동작하는 컨테이너
  • 애플리케이션을 도와주는 역할을 한다.
  • 사이드카 프록시를 모아서 메시 네트워크를 형성한다.

주요 기능

  1. ServiceDiscovery
    • 검색 계층을 통한 서비스 검색
    • 서비스 이름만으로 다른 서비스가 참조 가능(DNS를 통해서)
  2. LoadBalancing
    • Replication 설정에서 복제본으로 부하 분산
    • RR(RoundRobin), WRR(Weighted Round Robin), LRR(Least Round Robin) 등과 같은 세밀한 부하 분산 기능 제공
  3. RequestRouting
    • 정교한 라우팅 지원
    • A/B, Canary 등 구현할 때 정교한 라우팅 활용 가능
  4. HealthCheck/RetryPolicy
    • 일시적 과부화, 네트워크 일시 단절 등으로 장애가 전파되는 것 방지
    • 주기적인 HealthCheck로 서비스 가용성 및 애플리케이션 성능 향상
  5. CircuitBreaker
    • 복잡한 통신 시나리오에 대한 내결함성 시나리오 처리 기능
    • 서비스 간 호출 시 단계적 호출 시나리오에서 발생 가능한 오류에 대해서 차단할 수 있는 기능 제공
  6. TLS
    • 암호화를 한 번에 관리해서 서비스 복잡도를 낮출 수 있다.
  7. Observability
    • 서비스 개수가 늘어남에 따라 각 서비스에서 발생하는 각종 지표들을 수집하고 분석할 수 있음

장점

  • 비즈니스, 내부 네트워크 컴포넌트를 분리해서 애플리케이션이 본연의 역할에 집중할 수 있도록 할 수 있다.
  • 애플리케이션 외부에 구현하여 재사용 가능
  • 마이크로 서비스의 런타임에 대한 복잡성 이슈를 해결할 수 있다.
  • 애플리케이션 개발 시 미들웨어 종속성 제거
  • 분산된 기능 관리를 중앙 집중화할 수 있다.
  • Proxy를 이용해서 인프라 복잡성 감소

    단점

  • 사이드카를 달아야 해서 인스턴스 수의 증가
  • 서비스 통신 간 네트워크 홉이 증가해서 지연 시간이 생김
  • Proxy에 대한 디버깅 및 관리 이슈가 증가

vs.Gateway

  • 적용되는 위치가 다르다.
    • API Gateway는 중앙 집중식 제어 영역으로 외부에서 들어오는 트래픽 제어를 담당한다.
    • Service Mesh는 애플리케이션 기능을 인프라 계층에 의해서 관리되는 MicroService로 분리하는 방법이다.
  • 아키텍쳐가 다르다.
    • API Gateway는 SPOF(Single Point of Failure)를 생성한다.
    • Service Mesh는 SPOF를 생성하지 않는다.
  • 패턴이 다르다.
    • API Gateway는 일반적으로 Gateway proxy pattern`을 사용
    • 호출자는 구현 내용을 알 필요 없이 Gateway에 집중한다.
    • Service Mesh는 Sidecar proxy pattern을 사용
    • 호출자 코드는 Provider의 주소를 찾는 방법, failover와 관련된 코드 등에 대한 내용이 들어간다.
주요 항목 Service Mesh API Gateway
목적 MSA로 이식성을 개선하도록 설계 내/외부 액세스를 위한 API 호출까지도 라우팅 할 수 있도록 설계
복잡성 서비스 확장에 따른 복잡성 가중 하나의 엔드포인트로 API를 확장하여 서비스들을 관리
기술 성숙도 비교적 신기술 비교적 성숙