쿠버네티스 모니터링

컨테이너 가상화 기술은 도커가 등장하면서 크게 대중화되었습니다. 도커의 사용자들은 컨테이너를 잘 관리하기 위한 방법을 연구했는데, 그렇게 등장한 많은 오케스트레이션 기술 중에서 쿠버네티스야말로 대세로 인정받는 도구라고 할 수 있습니다.

쿠버네티스에는 마이크로서비스를 효율적으로 운영할 수 있는 다양한 기능이 포함되어 있습니다. 컴퓨팅 리소스를 효율적으로 사용하기 위한 스케줄링 기능과 애플리케이션 업데이트를 위한 배포 기능, 컨테이너 실행에 필요한 스토리지와 네트워크 관리 등 서비스 운영에 필요한 모든 기능을 제공합니다.

모니터링 서비스는 사용자가 쿠버네티스를 운영하는 모든 과정에 도움을 주고자 합니다. 실시간으로 문제 상황을 감시하여 장애 상황을 알리고 문제를 해결에 도움을 주는 모니터링의 기본적인 기능 뿐만 아니라, 자원을 분배하고 인프라 비용을 절약하고자 하는 운영 업무 시, 또는 쿠버네티스로 통합된 여러 마이크로서비스와 이와 관련된 업무 부서 간 협업 도구로서 모니터링 서비스를 활용할 수 있습니다.

쿠버네티스의 활용성이 다양한만큼 운영 환경과 비지니스 상황에 따라 사용자의 모니터링 니즈도 다양합니다. 이를 위해 모니터링 서비스는 애플리케이션 트랜잭션과 리소스 사용량, 로그와 이벤트 등 쿠버네티스가 관리하거나 생산하는 모든 정보를 수집하고 통합적으로 관제할 수 있는 기능을 제공합니다.

컨테이너맵

컨테이너맵은 와탭 쿠버네티스 모니터링 서비스의 시작입니다. 쿠버네티스의 생태계와 내부적인 동작 원리를 재현함으로써 사용자에게 보다 완전한 가시성을 제공하고자 만든 화면입니다.

컨테이너맵 - 컨테이너 프로젝트 클릭 시 첫번째 메뉴로 컨테이너맵 화면이 열립니다.

컨테이너와 파드

개발자의 애플리케이션이 쿠버네티스 내에서 실행되기 위해선, 우선 ‘컨테이너’를 통해 패키징되어야 합니다. 쿠버네티스는 컨테이너의 실행 규칙과 쿠버네티스 설정에 따라 ‘파드’라고 하는 개념적인 단위에 컨테이너를 할당하고, 이를 관리하기 시작합니다. 쿠버네티스를 제대로 모니터링하기 위해서는 기본적으로 컨테이너와 파드를 중심으로 문제 현상에 접근할 수 있어야 합니다. 와탭 쿠버네티스 모니터링 컨테이너맵에서는 이를 위해 Container와 Pod 카테고리 선택 옵션을 제공하고 있습니다.

사용자 쿠버네티스 환경의 상태를 모니터링 UI로 표현해 문제 상황을 가시화 합니다.

클러스터링

사용자 쿠버네티스 클러스터 환경 내부에는 네임스페이스, 디플로이먼트, 레플리카셋, 파드 등의 다양한 구성 요소가 존재합니다. 이러한 쿠버네티스 구성 요소들은 계층 구조를 비롯하여 다양한 관계를 갖는다는 특징이 있습니다. 예를 들어 애플리케이션을 담고 있는 파드는 물리적으로 워커 노드에서 실행되며, 논리적으로는 네임스페이스에 속합니다.

쿠버네티스 기반 비즈니스가 증가하면 이러한 구성 요소 상태나 연간 관계를 파악하기 어려워지는데, 컨테이너맵의 그룹화 기능을 사용하면 클러스터의 구성 요소들 간의 계층 관계를 한층 수월하게 파악할 수 있습니다.

예를 들어, 특정 컨테이너 또는 컨테이너 그룹에서 문제가 발생할 때 쿠버네티스 구성 요소 단위로 그룹화 조건을 변경해간다면 빠르게 문제의 원인을 추적하고 영향 범위를 판단할 수 있습니다.

그룹화 하기

아래 예시는 MemByLimt (Container Memory by Limit, 컨테이너 Limit 기준 메모리 사용률) 필드를 기준으로 메모리 사용률이 높은 컨테이너를 식별한 뒤, 네임스페이스 단위로 그룹화 옵션을 적용하여 문제 해결이 필요한 대상(첫번째 카드)을 찾는 과정입니다.

네임스페이스(필드 이름: Namespace) 단위로 그룹화 하여 특정 네임스페이스에서 문제 상황이 두드러지는 것을 확인하였습니다.

쿠버네티스 모니터링 지표 선택하기

상태 정보, 자원 사용량 등 각 사용자마다 관심 있는 지표의 필드를 선택할 수 있으며 임계치도 직접 조정 가능합니다. 앞서 소개한 그룹화 기능과 함께 사용한다면 문제 상황의 특징을 구분하고 빠르게 원인을 파악하는데 큰 도움이 됩니다.

컨테이너 Limit 기준 메모리 사용률 (필드 이름:MemByLimit) 필드 변경 후

컨테이너 카테고리의 기본 설정 필드는 컨테이너 상태를 나타내는 ConState입니다. ConState 필드는 RUNNING, WAITING, DEAD 등 컨테이너의 현재 상태 값을 표시합니다. ConState가 컨테이너의 상태를 나타내는 가장 대표적인 지표라 할 수 있지만, 경우에 따라 실제 문제 상황을 잘 표현하지 못할 수 있습니다. 이 때 CPU, 메모리, 네트워크 사용량 등의 다른 필드로 변경해보면서 감춰진 문제 상황이 드러나기도 합니다.

컨테이너 Limit 기준 메모리 사용률 (필드 이름: MemByLimit) 필드 변경 후

상세 분석

문제가 있는 컨테이너 또는 파드를 식별하였다면 상세 분석 단계로 넘어가 해결을 위한 단서를 찾을 수 있습니다. 컨테이너맵 요약 및 상세 화면은 옵저버빌리티 구성 요소를 반영하여 연관 분석 기능을 제공합니다.

Metrics

쿠버네티스는 컨테이너 리소스 사용량을 통제하고 지속적으로 모니터링 하면서 최적의 상태를 유지합니다. 따라서 리소스 사용량을 확인하고, 해당 데이터를 바탕으로 컨테이너 리소스 사용량이 적절히 설정되었는지 확인하는 과정은 쿠버네티스 모니터링의 기본적인 패턴입니다. 컨테이너별 리소스 사용량 설정은 CPU Request/Limit, Memory Request/Limit이 대표적입니다.

컨테이너맵의 Metrics는 모니터링에 유용한 지표를 선별하여 대시보드로 제공합니다.

컨테이너맵 상세 정보 - Metrics

Trace

장애의 원인을 추적하다 보면 결국 특정 트랜잭션의 SQL 처리 지연, 비즈니스 로직 오류 등 애플리케이션 문제인 경우가 많습니다. 이러한 문제는 리소스 모니터링만으로 밝혀내기 어렵습니다. 와탭은 쿠버네티스 클러스터의 리소스와 쿠버네티스 상에서 실행되는 애플리케이션을 함께 모니터링하기 때문에 현상의 원인을 빠르고 정확하게 찾아낼 수 있습니다.

컨테이너맵의 Trace는 컨테이너 상에서 실행 중인 애플리케이션의 트랜잭션 정보를 제공합니다. 액티브 트랜잭션, TPS, 동시 사용자, 응답 시간, HTTP Call 및 SQL 건수 등이 대표적인 정보입니다. 애플리케이션 런타임 환경에 따라 힙 사용량, GC 횟수도 알 수 있습니다.

컨테이너맵 상세 정보 - Traces

Log & Event

쿠버네티스 로그는 ① 각 컨테이너 내부의 소프트웨어와 애플리케이션이 저장한 로그 ② 쿠버네티스가 관리하는 컨테이너의 표준 출력 로그로 구분됩니다. 이러한 로그는 컨테이너의 상태나 메트릭 정보로 확인하기 힘든 모니터링의 사각지대를 보완하는 역할을 합니다.

컨테이너에서 생성된 로그는 기본적으로 컨테이너 내부에 저장됩니다. 따라서 컨테이너를 종료하면 이 로그는 모두 사라지게 됩니다. 쿠버네티스가 제공하는 컨테이너 표준 출력 로그도 휘발성 정보입니다. 일정 기간 또는 일정 용량만 보관되기 때문입니다.

따라서 로그 데이터를 안정적이고 지속적으로 관리하기 위한 별도의 관리 방안이 필수적입니다. 특히 마이크로서비스 아키텍처 도입이 확산되면서 비즈니스를 구성하는 컨테이너 수량이 증가함에 따라 로그의 확인, 관리 방안은 더욱 복잡해지고 있습니다.

이벤트 역시 마찬가지입니다. 쿠버네티스는 자체적으로 이벤트 정보를 제공하는데, 쿠버네티스 클러스터 내에 리소스가 많아지면 이벤트 수도 증가하게 되고 많은 데이터 속에서 의미있는 정보를 식별하기 어려워집니다. 쿠버네티스 이벤트 정보 역시 매우 짧은 기간만 보관된다는 점을 염두해야 합니다.

와탭은 사용자 쿠버네티스 환경으로부터 컨테이너 로그와 쿠버네티스 이벤트 정보를 안정적으로 수집, 관리하고 특정 대상 별 정보를 제공하거나 상호 연계 분석에 활용할 수 있는 다양한 기능을 제공하고 있습니다.

컨테이너맵 상세 정보 - 컨테이너 로그

로그 검색기 - 쿠버네티스 이벤트