Kubernetes를 사용하여 인프라 복원력 구현

인프라 기반 복원력을 구현하려면 서비스 메시를 사용할 수 있습니다. 서비스 메시는 코드를 변경하지 않고 복원력 외에도 트래픽 관리, 정책, 보안, 강력한 ID 및 관찰 가능성을 제공합니다. 앱은 인프라 계층으로 이동되는 이러한 운영 기능에서 분리됩니다. 아키텍처상 서비스 메시는 컨트롤 플레인과 데이터 평면의 두 가지 구성 요소로 구성됩니다.

컨트롤 플레인 구성 요소에는 서비스 메시 관리를 지원하는 많은 구성 요소가 있습니다. 구성 요소 인벤토리에는 일반적으로 다음이 포함됩니다.

• UI 또는 API일 수 있는 관리 인터페이스입니다.
• 서비스 메시가 특정 기능을 구현하는 방법을 정의하는 규칙 및 정책 정의입니다.
• mTLS에 대한 강력한 ID 및 인증서와 같은 항목에 대한 보안 관리.
• 앱에서 메트릭 및 원격 분석을 수집하고 집계하기 위한 메트릭 또는 관찰성을 제공합니다.

데이터 평면 구성 요소는 사이드카 패턴이라고 하는 각 서비스와 함께 투명하게 삽입되는 프록시로 구성됩니다. 각 프록시는 서비스를 포함하는 Pod 내/외부의 네트워크 트래픽을 제어하도록 구성됩니다. 이 구성을 사용하면 각 프록시를 다음으로 구성할 수 있습니다.

• mTLS를 통해 트래픽을 보호합니다.
• 트래픽을 동적으로 라우팅합니다.
• 트래픽에 정책을 적용합니다.
• 메트릭 및 추적 정보를 수집합니다.

Kubernetes 클러스터에 대한 몇 가지 인기 있는 서비스 메시 옵션으로는 링커드, Istio 및 Consul이 있습니다. 이 모듈에서는 링커드에 중점을 둡니다. 다음 다이어그램은 데이터 및 컨트롤 플레인 내의 구성 요소 간의 상호 작용을 보여 줍니다.

코드 기반 접근 방식과 비교

Linkerd의 주요 오류 처리 전략은 재시도 및 시간 제한으로 구성됩니다. Linkerd는 전체 클러스터를 체계적으로 볼 수 있으므로 새로운 방식으로 복원력 전략을 사용할 수 있습니다. 예를 들어 대상 서비스에 최대 20%의 추가 부하를 추가하는 방식으로 다시 시도하는 것이 있습니다. 링커드의 메트릭 기반 뷰를 사용하면 클러스터 조건에 실시간으로 동적으로 적응할 수 있습니다. 이 방법은 클러스터 관리에 다른 차원을 추가하지만 코드를 추가하지는 않습니다.

Polly와 같은 코드 기반 접근 방식을 사용하면 다음을 수행할 수 있습니다.

• 적절한 재시도 및 시간 제한 매개 변수를 추측하는 데 필요합니다.
• 특정 HTTP 요청에 집중합니다.

앱 코드에서 인프라 오류에 응답하는 합리적인 방법은 없습니다. 동시에 처리되는 수백 또는 수천 개의 요청을 고려합니다. 지수적 백오프(요청 횟수만큼)로 재시도해도 서비스가 과부하될 수 있습니다.

반면 Linkerd와 같은 인프라 기반 접근 방식은 앱 내부를 인식하지 못합니다. 예를 들어 복잡한 데이터베이스 트랜잭션은 Linkerd에 표시되지 않습니다. 이러한 트랜잭션은 Polly를 사용하여 오류로부터 보호할 수 있습니다.

앞으로 다가올 수업에서 Polly와 Linkerd를 사용하여 쿠폰 서비스의 복원력을 구현합니다.