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

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

가용성의 핵심은 모니터링입니다. 모든 로드 밸런서는 대상 리소스를 선택하기 전에 해당 리소스를 실제로 사용할 수 있는지 확인해야 합니다. 그렇지 않다면 무슨 의미가 있을까요?

리소스의 수명이 몇 시간이나 며칠이 아니라 몇 분 단위로 측정될 수 있는 환경에서는 요청을 보낼지 결정하기 전에 리소스의 상태를 파악하는 것이 더욱 중요합니다.

상태 모니터링은 로드 밸런서와 프록시의 필수 요소입니다. 이는 컨테이너화된 환경에서도 마찬가지입니다(또는 그래야 합니다). 이러한 환경이 빠르게 성숙해 감에 따라, 변동성이 매우 크고 분산된 시스템 특유의 과제에 대응하기 위한 새로운 모니터링 모델이 등장하고 있습니다.

물론 기존의 상태 모니터링도 중요한 요소이지만, 컨테이너 환경 내 일부 가용성 및 확장성 모델은 기존의 상태 모니터링에 부담을 주므로 이에 대한 대응이 필요합니다. 예를 들어 포워드 프록시 모델로 배포된 프록시는 정상(사용 가능) 상태인 대상을 가능한 모든 서비스 중에서 선택할 수 있어야 합니다. 리버스 프록시(말하자면 기존의 로드 밸런서)는 단일 애플리케이션에 속한 매우 구체적인 서비스 집합의 상태만 추적하면 되지만, 포워드 프록시는 해당 환경에 있는 모든 애플리케이션의 모든 서비스 상태를 파악해야 합니다. 이미 서비스가 중단된 컨테이너에 요청을 보내면 안 되니까요, 아시겠죠?

기존 상태 모니터링

전통적으로 상태 모니터링은 프록시를 통해 두 가지 방식으로 수행됩니다:

• 능동 모니터링: 컨테이너에 프로브 또는 상태 확인 요청을 보내고 응답을 평가합니다.
• 수동 모니터링: 실제 클라이언트 요청과 그에 대한 응답을 관찰합니다.

모든 서비스의 각 포워드 프록시가 능동 모니터링을 수행하면 로컬 네트워크의 트래픽이 상당히 급증하고 리소스가 불필요하게 소모될 것임을 쉽게 예상할 수 있습니다. 유용한 모니터링은 최소한 TCP 계층에서, 이상적으로는 HTTP 계층에서 이루어져야 합니다. 결국 네트워크 연결 여부만으로는 서비스의 상태나 가용성을 판단할 수 없습니다. 노드 수가 늘어나고 그에 따라 포워드 프록시 수도 증가하면 TCP 연결을 사용하고 HTTP 처리를 요구하는 작업이 컨테이너에 빠르게 부담을 줄 수 있습니다. 모니터링으로 인해 컨테이너가 과부하되어 확장해야 하는 상황은 피해야 합니다.

이 경우에는 모니터링 대상 시스템에 부담을 주지 않는 수동 모니터링이 더 나은 선택이지만, 일부 컨테이너 환경에서는 한계가 있습니다. 많은 컨테이너 환경이 오버레이 네트워킹 원칙을 기반으로 구축되어 있어, 모든 프록시가 각 서비스의 응답을 확인하고 추적하도록 보장하기가 어렵습니다. 불가능한 것은 아니지만 네트워크 계층에서 구현하기가 까다롭습니다.

두 모델 모두 프록시 자체에도 부담을 주며, 프록시의 본래 역할인 서비스 확장보다 단순히 환경을 모니터링하는 데 리소스를 할당해야 합니다.

컨테이너화된 상태 모니터링

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

이 두 가지 모델은 다음과 같습니다:

• 환경 모니터링: 프록시는 컨테이너 오케스트레이션 환경(COE)에서 제공하는 컨테이너 상태 정보를 통해 상태 및 가용성을 파악합니다.
• 공유 모니터링: 환경에 프록시가 여러 개 있을 가능성이 높으므로 모니터링 작업을 프록시 간에 분담하고 결과를 공유할 수 있습니다.

환경 모니터링은 컨테이너가 시스템에 들어오고 나가는 것을 추적하는 서비스 레지스트리와 연계되는 경우가 많습니다. 따라서 서비스 레지스트리는 대개 시스템 내 컨테이너 가용성에 관한 가장 신뢰할 수 있는 정보 소스입니다. 프록시는 컨테이너 생성 및 삭제 시 트리거되는 이벤트를 구독하여 해당 리소스를 직접 추적할 수도 있습니다(사실상 프록시 자체가 레지스트리 역할을 하는 셈입니다).

예를 들어 Marathon에서 앱의 상태 모니터링이 활성화되어 있으면 프록시는 'healthCheckResults' 필드를 활용할 수 있습니다. Kubernetes에서는 프록시가 활성 상태 검사 및/또는 준비 상태 검사를 사용할 수 있습니다. 환경 상태 검사를 사용하면 오케스트레이션 시스템이 비정상 엔드포인트를 다시 시작하기 전에 프록시가 더 정상적인 엔드포인트를 선택하기 시작할 수 있습니다.

공유 모니터링은 순방향 프록시 모델을 사용하는 시스템, 특히 Istio와 같은 서비스 메시를 기반으로 하는 시스템에서 매우 유용합니다. 노드와 연결된 프록시는 자신이 요청을 전달하는 컨테이너의 상태와 가용성을 충분히 모니터링할 수 있습니다(역방향 프록시 모델에서 서비스를 추적하는 것과 매우 유사한 방식입니다). 하지만 이러한 시스템에서 모든 프록시가 모든 엔드포인트를 능동적으로 점검하도록 하는 것은 바람직하지 않습니다. 따라서 로컬 상태 정보를 다른 프록시와 공유하면(더 나아가 실행 환경과 공유하면 더욱 좋습니다) 모든 서비스에 과도한 상태 점검을 수행하지 않고도 모든 프록시가 시스템의 알려진 전체 상태를 파악할 수 있습니다.

로드 밸런싱과 같은 애플리케이션 서비스, 그리고 이러한 서비스가 컨테이너화 같은 새로운 모델의 필요와 요구 사항을 충족하기 위해 상호 작용하는 방식과 관련해 ‘네트워크’에는 많은 변화가 일어나고 있습니다. 이러한 요구 사항은 프록시가 끊임없이 적응하도록 압박합니다. 프록시는 지난 20년간 개발된 기술 중 가장 유연한 기술에 속하며, 애플리케이션 서비스를 설계하고 개발하고 배포하는 데 계속해서 중요한 기반이 되고 있기 때문입니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물