2.2. 서비스 메시 이해

주의

더 이상 지원되지 않는 Red Hat OpenShift Service Mesh 릴리스에 대한 문서를 보고 있습니다.

서비스 메시 버전 1.0 및 1.1 컨트롤 플레인은 더 이상 지원되지 않습니다. 서비스 메시 컨트롤 플레인 업그레이드에 대한 자세한 내용은 서비스 메시 업그레이드를 참조하십시오.

특정 Red Hat OpenShift Service Mesh 릴리스의 지원 상태에 대한 자세한 내용은 제품 라이프사이클 페이지를 참조하십시오.

Red Hat OpenShift Service Mesh는 서비스 메시에서 네트워크로 연결된 마이크로 서비스에 대해 동작 정보 및 운영 제어용 플랫폼을 제공합니다. Red Hat OpenShift Service Mesh를 사용하면 OpenShift Container Platform 환경에서 마이크로 서비스를 연결, 보호 및 모니터링할 수 있습니다.

2.2.1. 서비스 메시 이해

서비스 메시는 분산 마이크로 서비스 아키텍처에서 애플리케이션을 구성하는 마이크로 서비스 네트워크와 이러한 마이크로 서비스 간의 상호 작용입니다. 서비스 메시의 크기와 복잡성이 증가함에 따라 이를 이해하고 관리하는 것이 어려워질 수 있습니다.

오픈 소스 Istio 프로젝트를 기반으로 하는 Red Hat OpenShift Service Mesh는 서비스 코드를 변경할 필요 없이 기존 분산 애플리케이션에 투명 계층을 추가합니다. 마이크로 서비스 간의 모든 네트워크 통신을 차단하는 메시의 관련 서비스에 특수 사이드카 프록시를 배포하여 Red Hat OpenShift Service Mesh 지원을 서비스에 추가합니다. 서비스 메시 컨트롤 플레인 기능을 사용하여 서비스 메시를 구성하고 관리합니다.

Red Hat OpenShift Service Mesh를 사용하면, 다음과 같은 기능을 제공하는 배포된 서비스 네트워크를 쉽게 생성할 수 있습니다.

  • 검색
  • 로드 밸런싱
  • 서비스 간 인증
  • 장애 복구
  • 지표
  • 모니터링

Red Hat OpenShift Service Mesh는 다음과 같은 보다 복잡한 운영 기능을 제공합니다:

  • A/B 테스트
  • Canary 릴리스
  • 액세스 제어
  • 엔드 투 엔드 인증

2.2.2. Red Hat OpenShift Service Mesh 아키텍처

Red Hat OpenShift Service Mesh는 논리적으로 데이터 플레인과 컨트롤 플레인으로 분할됩니다.

데이터 플레인은 사이드카로 배포된 지능적 프록시 세트입니다. 이러한 프록시는 서비스 메시에서 마이크로 서비스 간의 모든 인바운드 및 아웃바운드 네트워크 통신을 가로채기하고 제어합니다. 또한 사이드카 프록시는 범용 정책 및 Telemetry 허브인 Mixer와 통신합니다.

  • Envoy proxy는 서비스 메시의 모든 서비스에 대한 인바운드 및 아웃바운드 트래픽을 가로채기합니다. Envoy는 동일한 pod에서 관련 서비스에 사이드카로 배포됩니다.

컨트롤 플레인은 트래픽을 라우팅하기 위해 프록시를 관리 및 구성하며, 정책을 적용하고 Telemetry를 수집하도록 Mixers를 구성합니다.

  • Mixer는 액세스 제어 및 사용 정책(예: 권한 부여, 속도 제한, 할당량, 인증 및 요청 추적)을 시행하고 Envoy 프록시 및 기타 서비스에서 Telemetry 데이터를 수집합니다.
  • Pilot은 런타임 시 프록시를 구성합니다. Pilot은 Envoy 사이드카에 대한 서비스 검색, 지능형 라우팅을 위한 트래픽 관리 기능(예: A/B 테스트 또는 카나리아 배포) 및 복구 기능(시간 초과, 재시도 및 회로 차단기)을 제공합니다.
  • Citadel은 인증서를 발행 및 교체합니다. Citadel은 내장 ID 및 자격 증명 관리를 통해 강력한 서비스 간 인증과 최종 사용자 인증을 제공합니다. Citadel을 사용하여 서비스 메시에서 암호화되지 않은 트래픽을 업그레이드할 수 있습니다. Operator는 Citadel을 사용하여 네트워크 제어가 아닌 서비스 ID를 기반으로 정책을 시행할 수 있습니다.
  • Galley는 서비스 메시 구성을 수집한 다음, 구성의 유효성을 검증, 처리 및 배포합니다. Galley는 다른 서비스 메시 구성 요소가 OpenShift Container Platform에서 사용자 구성 세부 정보를 얻지 못하도록 보호합니다.

또한 Red Hat OpenShift Service Mesh는 istio-operator를 사용하여 컨트롤 플레인 설치를 관리합니다. Operator는 OpenShift Container Platform 클러스터에서 공통 활동을 구현하고 자동화할 수 있는 소프트웨어입니다. 컨트롤러 역할을 하여 클러스터에서 원하는 오브젝트 상태를 설정하거나 변경할 수 있습니다.

2.2.3. Kiali 이해

Kiali는 서비스 메시의 마이크로 서비스와 해당 연결 방법을 표시하여 서비스 메시를 시각화할 수 있습니다.

2.2.3.1. Kiali 개요

Kiali는 OpenShift Container Platform에서 실행 중인 서비스 메시에 대한 관찰 기능을 제공합니다. Kiali는 Istio 서비스 메시를 정의하고 검증하며 관찰하는 데 도움이 됩니다. 이를 통해 토폴로지를 유추하여 서비스 메시의 구조를 이해하고 서비스 메시의 상태에 대한 정보를 제공할 수 있습니다.

Kiali는 회로 차단기, 요청 속도, 대기 시간, 트래픽 흐름 그래프와 같은 기능에 대한 가시성을 제공하는 네임스페이스의 대화형 그래프 보기를 실시간으로 제공합니다. Kiali는 애플리케이션에서 서비스 및 워크로드에 이르기까지 다양한 수준의 구성 요소에 대한 통찰력을 제공하며, 선택한 그래프 노드 또는 에지에서 상황별 정보에 대한 상호 작용과 차트를 표시할 수 있습니다. Kiali는 게이트웨이, 대상 규칙, 가상 서비스, 메시 정책 등과 같은 Istio 구성의 유효성을 확인하는 기능도 제공합니다. Kiali는 자세한 지표를 제공하며 고급 쿼리에 기본 Grafana 통합이 가능합니다. Jaeger를 Kiali 콘솔에 통합하면 분산 추적이 제공됩니다.

Kiali는 기본적으로 Red Hat OpenShift Service Mesh의 일부로 설치됩니다.

2.2.3.2. Kiali 아키텍처

Kiali는 오픈 소스 Kiali 프로젝트를 기반으로 합니다. Kiali는 Kiali 애플리케이션과 Kiali 콘솔이라는 두 가지 구성 요소로 구성됩니다.

  • Kiali 애플리케이션(백엔드) - 이 구성 요소는 컨테이너 애플리케이션 플랫폼에서 실행되고 서비스 메시 구성 요소와 통신하며, 데이터를 검색 및 처리하고, 이 데이터를 콘솔에 노출합니다. Kiali 애플리케이션에는 스토리지가 필요하지 않습니다. 클러스터에 애플리케이션을 배포할 때 구성은 ConfigMaps 및 시크릿에 설정됩니다.
  • Kiali 콘솔(프론트엔드) - Kiali 콘솔은 웹 애플리케이션입니다. Kiali 애플리케이션은 Kiali 콘솔을 제공하며 이를 사용자에게 표시하기 위해 데이터의 백엔드를 쿼리합니다.

또한 Kiali는 컨테이너 애플리케이션 플랫폼과 Istio에서 제공하는 외부 서비스 및 구성 요소에 따라 달라집니다.

  • Red Hat Service Mesh(Istio) - Istio는 Kiali 요구 사항입니다. Istio는 서비스 메시를 제공하고 제어하는 구성 요소입니다. Kiali와 Istio를 별도로 설치할 수 있지만 Kiali는 Istio에 따라 달라지며 Istio가 존재하지 않는 경우 작동하지 않습니다. Kiali는 Prometheus 및 클러스터 API를 통해 노출되는 Istio 데이터와 구성을 검색해야 합니다.
  • Prometheus - 전용 Prometheus 인스턴스는 Red Hat OpenShift Service Mesh 설치의 일부로 포함되어 있습니다. Istio Telemetry가 활성화되면 지표 데이터가 Prometheus에 저장됩니다. Kiali는 이 Prometheus 데이터를 사용하여 메시 토폴로지 확인, 지표 표시, 상태 계산, 가능한 문제 표시 등의 작업을 수행합니다. Kiali는 Prometheus와 직접 통신하고 Istio Telemetry에서 사용하는 데이터 스키마를 가정합니다. Prometheus는 Istio 종속성 및 Kiali에 대한 하드 종속성이며, 대부분의 Kiali 기능은 Prometheus없이 작동하지 않습니다.
  • 클러스터 API - Kiali는 서비스 메시 구성을 가져와 해결하기 위해 OpenShift Container Platform(클러스터 API)의 API를 사용합니다. Kiali는 클러스터 API를 쿼리하여 네임스페이스, 서비스, 배포, pod 및 기타 엔터티에 대한 정의를 검색합니다. 또한 Kiali는 다른 클러스터 엔티티 간의 관계를 해결하기 위해 쿼리를 만듭니다. 클러스터 API는 가상 서비스, 대상 규칙, 경로 규칙, 게이트웨이, 할당량 등과 같은 Istio 구성을 검색하도록 쿼리합니다.
  • Jaeger - Jaeger는 선택 사항이지만 Red Hat OpenShift Service Mesh의 일부로 설치됩니다. 기본 Red Hat OpenShift Service Mesh 설치의 일부로 분산 추적 플랫폼을 설치하면 Kiali 콘솔에 분산 추적 데이터를 표시하는 탭이 포함됩니다. Istio의 분산 추적 기능을 비활성화하면 추적 데이터를 사용할 수 없습니다. 또한 사용자가 추적 데이터를 보기 위해 Service Mesh Control Plane이 설치된 네임스페이스에 대한 액세스 권한이 있어야 합니다.
  • Grafana - Grafana는 선택 사항이지만 Red Hat OpenShift Service Mesh의 일부로 설치됩니다. 사용 가능한 경우, Kiali의 지표 페이지에 사용자를 Grafana의 동일한 지표로 안내하는 링크가 표시됩니다. 사용자가 Grafana 대시보드에 대한 링크를 보고 Grafana 데이터를 보려면 Service Mesh Control Plane이 설치된 네임스페이스에 대한 액세스 권한이 있어야 합니다.

2.2.3.3. Kiali 기능

Kiali 콘솔은 Red Hat Service Mesh와 통합되어 다음 기능을 제공합니다.

  • 상태 - 애플리케이션, 서비스 또는 워크로드에 대한 문제를 빠르게 식별합니다.
  • 토폴로지 - 애플리케이션, 서비스 또는 워크로드가 Kiali 그래프를 통해 통신하는 방식을 시각화합니다.
  • 지표 - 사전 정의된 지표 대시 보드를 통해 Go, Node.js. Quarkus, Spring Boot, Thorntail, Vert.x에 대한 서비스 메시 및 애플리케이션 성능을 차트로 작성할 수 있습니다. 또한 사용자 정의 대시보드를 생성할 수도 있습니다.
  • 추적 - Jaeger와의 통합을 통해 애플리케이션을 구성하는 다양한 마이크로 서비스를 통해 요청 경로를 따를 수 있습니다.
  • 검증 - 가장 일반적인 Istio 오브젝트에 대한 고급 검증(대상 규칙, 서비스 항목, 가상 서비스 등)을 수행합니다.
  • 구성 - 마법사를 사용하거나 Kiali 콘솔의 YAML 편집기에서 직접 Istio 라우팅 구성을 생성, 업데이트 및 삭제할 수 있는 옵션입니다.

2.2.4. Jaeger 이해

사용자가 애플리케이션에서 작업을 수행할 때마다 응답을 생성하기 위해 참여하도록 다양한 서비스를 필요로 할 수 있는 아키텍처에 의해 요청이 실행됩니다. 이 요청의 경로는 분산 트랜잭션입니다. Jaeger를 사용하면 애플리케이션을 구성하는 다양한 마이크로 서비스를 통해 요청의 경로를 따르는 분산 추적을 수행할 수 있습니다.

분산 추적은 분산 트랜잭션에 있는 전체 이벤트 체인을 이해하기 위해 일반적으로 다양한 프로세스 또는 호스트에서 실행되는 다양한 작업 단위에 대한 정보를 결합하는 데 사용되는 기술입니다. 분산 추적을 통해 개발자는 대규모 서비스 지향 아키텍처에서 호출 흐름을 시각화할 수 있습니다. 직렬화, 병렬 처리 및 대기 시간 소스를 이해하는 데 유용할 수 있습니다.

Jaeger는 마이크로 서비스의 전체 스택에서 개별 요청 실행을 기록하고 이를 추적으로 제공합니다. 추적은 시스템을 통한 데이터/실행 경로입니다. 엔드 투 엔드 추적은 하나 이상의 기간으로 구성됩니다.

기간은 작업 이름, 작업의 시작 시간 및 기간이 있는 Jaeger의 논리적 작업 단위를 나타냅니다. 기간은 중첩되어 인과 관계를 모델링하도록 주문될 수 있습니다.

2.2.4.1. 분산 추적 개요

서비스 소유자는 분산 추적을 사용하여 서비스 아키텍처에 대한 통찰력을 수집하기 위해 서비스를 계측할 수 있습니다. 분산 추적을 사용하여 최신 클라우드 네이티브, 마이크로서비스 기반 애플리케이션의 구성 요소 간 상호 작용을 모니터링, 네트워크 프로파일링 및 문제 해결할 수 있습니다.

분산 추적을 사용하면 다음 기능을 수행할 수 있습니다.

  • 분산 트랜잭션 모니터링
  • 성능 및 대기 시간 최적화
  • 근본 원인 분석 수행

Red Hat OpenShift distributed tracing은 다음 두 가지 주요 구성 요소로 구성됩니다.

이러한 두 구성 요소는 모두 벤더 중립 OpenTracing API 및 계측을 기반으로 합니다.

2.2.4.2. 분산 추적 아키텍처

분산 추적 플랫폼은 오픈 소스 Jaeger 프로젝트를 기반으로 합니다. 분산 추적 플랫폼은 추적 데이터를 수집, 저장 및 표시하기 위해 함께 작동하는 여러 구성 요소로 구성됩니다.

  • Jaeger Client(Tracer, Reporter, 조정된 애플리케이션, 클라이언트 라이브러리)- Jaeger 클라이언트는 OpenTracing API의 언어 특정 구현입니다. 수동으로 또는 이미 OpenTracing과 통합된 Camel(Fuse), Spring Boot(RHOAR), MicroProfile(RHOAR/T©tail), Wildfly(EAP) 등의 다양한 기존 오픈 소스 프레임워크를 사용하여 분산 추적에 대해 애플리케이션을 조정하는 데 사용할 수 있습니다.
  • Jaeger 에이전트(Server Queue, Processor Workers) - Jaeger 에이전트는 UDP(User Datagram Protocol)를 통해 전송되는 기간을 수신 대기하는 네트워크 데몬으로, 수집기에 배치 및 전송합니다. 에이전트는 조정된 애플리케이션과 동일한 호스트에 배치되어야 합니다. 일반적으로 Kubernetes와 같은 컨테이너 환경에서 사이드카를 보유하여 수행됩니다.
  • Jaeger 수집기(Queue, Workers) - 에이전트와 유사하게 수집기는 기간을 수신하여 처리를 위한 내부 큐에 배치할 수 있습니다. 그러면 수집기는 기간이 스토리지로 이동할 때까지 대기하지 않고 클라이언트/에이전트로 즉시 돌아갈 수 있습니다.
  • 스토리지(데이터 저장소) - 수집기에는 영구 스토리지 백엔드가 필요합니다. Jaeger에는 기간 스토리지를 위한 플러그인 메커니즘이 있습니다. 이 릴리스에서 지원되는 유일한 스토리지는 Elasticsearch입니다.
  • 쿼리(쿼리 서비스) - 쿼리는 스토리지에서 추적을 검색하는 서비스입니다.
  • Ingester(Ingester 서비스) - Jaeger는 수집기와 실제 백업 스토리(Elasticsearch) 간의 버퍼로 Apache Kafka를 사용할 수 있습니다. Ingester는 Kafka에서 데이터를 읽고 다른 스토리지 백엔드(Elasticsearch)에 쓰는 서비스입니다.
  • Jaeger 콘솔 - Jaeger는 분산 추적 데이터를 시각화할 수 있는 사용자 인터페이스를 제공합니다. 검색 페이지에서 추적을 찾고 개별 추적을 구성하는 기간의 세부 사항을 확인할 수 있습니다.

2.2.4.3. Red Hat OpenShift distributed tracing 기능

Red Hat OpenShift distributed tracing은 다음과 같은 기능을 제공합니다.

  • Kiali와의 통합 - 올바르게 구성된 경우 Kiali 콘솔에서 분산 추적 데이터를 볼 수 있습니다.
  • 높은 확장성 - 분산 추적 백엔드는 단일 장애 지점이 없고 비즈니스 요구에 맞게 확장할 수 있도록 설계되었습니다.
  • 분산 컨텍스트 전파 - 다양한 구성 요소의 데이터를 함께 연결하여 완전한 엔드 투 엔드 추적을 만들 수 있습니다.
  • Zipkin과의 역호환성 - Red Hat OpenShift distributed tracing에는 Zipkin을 대체하는 데 사용할 수 있는 API가 있지만 Red Hat은 이 릴리스에서 Zipkin 호환성을 지원하지 않습니다.

2.2.5. 다음 단계