Kubernetes를 사용하여 인프라 복원력 구현
인프라 기반 복원력을 구현하기 위해 ‘서비스 메시’를 사용할 수 있습니다. 서비스 메시는 코드 변경 없는 복원력 구현 외에도 트래픽 관리, 정책, 보안, 강력한 ID, 가시성을 제공합니다. 이러한 작업 기능은 앱에서 분리되어 인프라 계층으로 이동했습니다. 구조적으로 보면, 서비스 메시는 컨트롤 플레인과 데이터 평면이라는 두 가지 구성 요소로 구성됩니다.
컨트롤 플레인 구성 요소에는 서비스 메시 관리를 지원하는 많은 구성 요소가 있습니다. 구성 요소 인벤토리에는 일반적으로 다음이 포함됩니다.
- 관리 인터페이스(UI 또는 API일 수 있음)
- 서비스 메시가 특정 기능을 구현해야 하는 방법을 정의하는 규칙 및 정책 정의
- 강력한 ID 및 mTLS용 인증서와 같은 항목에 대한 보안 관리
- 앱에서 메트릭과 원격 분석을 수집하고 집계하는 메트릭 또는 가시성
데이터 평면 구성 요소는 각 서비스와 함께 투명하게 삽입되는 프록시로 구성됩니다. 이를 사이드카 패턴이라고 합니다. 각 프록시는 서비스를 포함하는 Pod 내/외부의 네트워크 트래픽을 제어하도록 구성됩니다. 이 구성을 통해 각 프록시를 다음과 같이 구성할 수 있습니다.
- mTLS를 통해 트래픽을 보호합니다.
- 동적으로 트래픽을 라우팅합니다.
- 트래픽에 정책을 적용합니다.
- 메트릭 및 추적 정보를 수집합니다.
Kubernetes 클러스터에 많이 사용되는 서비스 메시 옵션에는 Linkerd, Istio, Consul이 포함됩니다. 이 모듈에서는 Linkerd를 중점적으로 설명합니다. 다음 다이어그램에서는 데이터 평면과 컨트롤 플레인 내의 구성 요소 간 상호 작용을 보여 줍니다.
코드 기반 접근 방식과 비교
Linkerd의 주요 오류 처리 전략은 재시도 및 시간 제한으로 구성 됩니다. Linkerd는 전체 클러스터를 체계적으로 볼 수 있으므로 새로운 방식으로 복원력 전략을 사용할 수 있습니다. 예를 들어 대상 서비스에서 최대 20%의 추가 로드를 더하는 방법으로 다시 시도할 수 있습니다. Linkerd의 메트릭 기반 뷰를 통해 실시간으로 클러스터 조건에 동적으로 적용할 수 있습니다. 이 접근 방식은 클러스터를 관리하는 또 다른 차원을 추가하지만 코드를 추가하지는 않습니다.
Polly와 같은 코드 기반 접근 방식을 사용할 때는 다음과 같습니다.
- 적절한 재시도 매개 변수와 시간 제한 매개 변수를 추측해야 합니다.
- 특정 HTTP 요청에 집중합니다.
앱의 코드에서 인프라 오류에 대응할 적절한 방법은 없습니다. 동시에 수십만 개의 요청이 처리된다는 것을 고려할 때 지수 백오프(시간 요청 수)로 다시 시도해도 서비스 요청이 너무 많아질 수 있습니다.
반대로, Linkerd와 같은 인프라 기반 접근 방식은 앱 내부를 인식하지 못합니다. 예를 들어, 복잡한 데이터베이스 트랜잭션은 Linkerd에서 볼 수 없습니다. 이러한 트랜잭션은 Polly를 통해 오류로부터 보호될 수 있습니다.
다음 단원에서는 Polly 및 Linkerd를 사용하여 쿠폰 서비스의 복원력을 구현합니다.