컨테이너 오케스트레이션 환경이 상태 모니터링에 미치는 영향

가용성의 핵심은 모니터링입니다. 모든 로드 밸런서는 대상 리소스를 선택하기 전에 해당 리소스가 실제로 사용 가능한지 여부를 알아야 합니다. 그렇지 않으면 무슨 의미가 있겠어요?

리소스의 수명이 시간이나 일이 아닌 분 단위로 측정되는 환경에서는 요청을 보내기로 결정하기 전에 리소스의 상태를 아는 것이 더욱 중요해집니다.

상태 모니터링은 로드 밸런서와 프록시의 일부입니다. 이는 컨테이너화된 환경에서도 사실입니다(또는 사실이어야 합니다). 이러한 환경이 (급속하게) 계속해서 성숙해짐에 따라, 우리는 그러한 매우 불안정하고 분산된 시스템과 관련된 다소 독특한 과제를 해결하기 위해 새로운 모니터링 모델이 등장하는 것을 보고 있습니다.

기존의 건강 모니터링은 확실히 방정식의 일부이지만 컨테이너 환경 내의 일부 가용성 및 확장 모델은 해결해야 할 기존의 건강 모니터링에 부담을 줍니다. 예를 들어, 전방 프록시 모델에 배포된 프록시는 가능한 모든 서비스에서 정상(사용 가능한) 대상을 선택할 수 있어야 합니다. 역방향 프록시(전통적인 로드 밸런서라고 할 수 있는)는 단일 애플리케이션의 매우 구체적인 서비스 집합의 상태를 추적하는 데만 책임이 있는 반면, 순방향 프록시는 환경 내의 모든 애플리케이션의 모든 서비스 상태를 파악해야 합니다. 이미 서비스가 중단된 컨테이너에 요청을 보내는 건 좋지 않을 것 같죠?

전통적인 건강 모니터링

전통적으로 건강 모니터링은 프록시를 통해 두 가지 방법으로 수행됩니다.

• 활성 모니터링: 컨테이너에 프로브나 상태 점검 요청을 보내고 응답을 평가합니다.
• 수동 모니터링: 자연스러운 고객의 요청과 응답을 관찰합니다.

모든 서비스의 모든 전방 프록시가 적극적으로 모니터링을 수행하면 로컬 네트워크의 트래픽이 극적으로 증가하고 불필요하게 리소스가 소모될 것이라고 생각할 수 있습니다. 유용한 모니터링은 최소한 TCP 계층과 이상적으로는 HTTP 계층에서 수행됩니다. 결국 네트워크 연결은 서비스 상태나 가용성을 나타내는 지표가 아닙니다. TCP 연결을 사용하고 HTTP 처리를 요구하면 노드 수(따라서 전달 프록시)가 늘어나면서 컨테이너에 부담이 빠르게 가중됩니다. 모니터링으로 인해 컨테이너가 과부하되어 확장해야 하는 상황은 원치 않을 것입니다.

이 경우 수동 모니터링이 더 나은 옵션입니다. 모니터링하는 시스템에 부담을 주지 않지만 일부 컨테이너 환경에서는 한계가 있습니다. 많은 프록시가 오버레이 네트워킹 원칙을 기반으로 구축되어 있어 모든 프록시가 모든 서비스 응답을 보고 추적할 수 있도록 보장하기 어렵습니다. 불가능하지는 않지만 네트워크 계층에서는 어려운 일입니다.

두 모델 모두 프록시 자체에도 부담을 주어, 리소스를 자신들이 수행해야 할 작업인 서비스 확장보다는 환경을 모니터링하는 데만 전담해야 합니다.

컨테이너화된 건강 모니터링 

컨테이너 환경 역시 이러한 과제를 무시하지 않습니다. 이에 대응하여 가용성과 확장성을 위해 포워드 프록시를 사용하는 아키텍처에서 가용성을 보장하는 데 도움이 될 두 가지 새로운 모델이 등장하고 있습니다.

두 모델은 다음과 같습니다.

• 환경 모니터링: 프록시는 컨테이너 오케스트레이션 환경(COE)에서 제공하는 컨테이너 상태에 대한 정보 덕분에 상태/가용성을 인식할 수 있습니다.
• 공유 모니터링: 환경에는 많은 프록시가 있을 가능성이 높으므로 모니터링 작업을 프록시 간에 분할하고 결과를 공유할 수 있습니다.

환경 모니터링은 종종 서비스 레지스트리와 연관이 있는데, 서비스 레지스트리는 컨테이너가 시스템에 들어오고 나갈 때 이를 추적합니다. 즉, 이는 종종 시스템에서 컨테이너 가용성에 대한 가장 권위 있는 소스인 것을 의미합니다. 프록시는 컨테이너 생성 및 파괴로 인해 발생하는 이벤트를 구독하여 해당 리소스를 직접 추적할 수도 있습니다(실제로 레지스트리 역할을 함).

예를 들어, Marathon의 앱에 대한 상태 모니터링이 활성화된 경우 프록시는 'healthCheckResults' 필드를 활용할 수 있습니다. 쿠버네티스에서 프록시는 활성 여부 및/또는 준비 상태 검사를 사용할 수 있습니다. 환경 건강 검사를 통해 오케스트레이션 시스템이 건강하지 않은 엔드포인트를 다시 시작하기 전에 프록시가 더 건강한 엔드포인트를 선택할 수 있습니다.

공유 모니터링은 전방 프록시 모델을 사용하는 시스템, 특히 Istio 와 같은 서비스 메시 기반을 갖춘 시스템에서 매우 유용합니다. 노드에 연결된 프록시는 요청을 전달하는 컨테이너의 상태와 가용성을 확실히 모니터링할 수 있습니다(역방향 프록시 모델에서 서비스를 추적하는 것과 같은 방식). 하지만 그러한 시스템에서는 모든 프록시가 모든 엔드포인트를 적극적으로 조사하는 것을 원하지는 않을 것입니다. 따라서 다른 프록시(또는 더 나은 경우 환경)와 로컬 상태 정보를 공유함으로써 모든 프록시는 모든 서비스에 대한 과도한 상태 검사를 요구하지 않고도 시스템의 알려진 전체 상태를 얻을 수 있습니다.

로드 밸런싱과 같은 앱 서비스와 컨테이너화와 같은 새로운 모델의 요구 사항과 필요 사항을 충족하기 위해 상호 작용하는 방식과 관련하여 "네트워크"에서 많은 변화가 일어나고 있습니다. 이러한 요구 사항은 프록시에 적응하라는 압력을 지속적으로 가하고 있습니다. 그 이유는 프록시가 지난 20년 동안 개발된 가장 유연한 기술 중 하나이며 앱 서비스가 설계, 개발, 배포되는 중요한 기반이 되고 있기 때문입니다.