시대의 흐름에 따라 서비스의 고가용성을 제공하기 위해 배포 모델이 진화해 왔습니다. Kubernetes에 이르러서는 애플리케이션을 구성하는 컨테이너의 수평적 확장이 용이해지고 전체 시스템에 영향을 미치지 않으면서도 언제든 빠르게 새로운 기능을 제공하는 것이 가능해졌습니다.
하지만 여러 서버와 사설/공용 클라우드 환경을 연결해 복잡하게 구성하는 것이 가능해지고, 설정된 워크로드 정책을 기반으로 수요에 따라 컨테이너가 지속해서 파괴되고 가동되면서 애플리케이션이 어디에서 어떻게 실행되고 있는지 알기 어려워졌으며, 과거의 배포 환경보다 Entity의 수가 100배 이상 많아지는 경우가 생겼습니다.
따라서 문제가 시작되면 조사할 로그와 기타 데이터 및 구성 요소가 많아졌습니다. 기존 환경에서는 한두 가지의 로그 검색만 필요했지만, Kubernetes 환경에서는 조사 중인 타깃과 관련된 여러 마이크로 서비스들에 대한 상태 파악과 로그 분석이 필요할 수 있습니다.
Kubernetes 모니터링이 필요한 이유
자원 최적화
Kubernetes 클러스터에서 일어나는 일들의 파악하고 서비스(애플리케이션) 성능을 저하시키지 않는 선에서 컴퓨팅 자원 설정 최적화에 도움을 줍니다. 그리고 프로젝트, 팀, 서비스별 리소스 사용량을 파악해서 설정을 통해 자원 경쟁에 따른 문제점을 회피합니다.
안정적인 서비스
애플리케이션을 확장하고 안정적인 서비스를 제공하려면 애플리케이션이 어떻게 작동하는지에 대한 통찰력이 필요합니다. 컨테이너, 포드 및 애플리케이션의 전반적인 상태를 추적하고 리소스 사용량에 대한 정보 등을 종합해서 병목 현상을 감지하고 제거할 수 있습니다.
문제 해결
MSA(마이크로 서비스 아키텍처) 또는 클라우드 네이티브 형태로 개발된 애플리케이션의 서비스는 복잡해질 수 있습니다. 그래서 문제가 발생했을 때 문제의 원인을 정확히 파악하기 어려워졌습니다. Kubernetes 모니터링을 통해 문제가 발생했거나 발생하려고 하는 위치를 파악하고, 문제를 방지하거나 해결하기 위한 조치를 취하는 데 도움이 되는 정보에 접근이 용이해집니다.
비용
공용 클라우드 환경에서 Kubernetes를 이용해서 서비스를 하게 될 경우, 자원(노드의 개수 등)의 사용이 시간당 비용을 결정하기 때문에 추적하는 것이 중요합니다. 기업들은 간혹 발생하는 대규모 이벤트를 위해서 과거 환경에서 사용했던 방식처럼 넉넉하게 자원을 할당하여 운영함으로써 많은 비용을 지불하게 되는데 모니터링을 통해서 프로비저닝 최적화에 도움을 받을 수 있습니다.
모니터링 지표
Kubernetes를 모니터링할 때 살펴야 할 주요 지표들을 크게 클러스터 모니터링과 포드 모니터링으로 나누어 살펴보겠습니다.
Kubernetes 클러스터 모니터링
클러스터 모니터링의 목표는 Kubernetes 클러스터의 전체 상태를 모니터링하는 것입니다. 클러스터의 모든 노드가 제대로 작동하는지, 어떤 자원을 얼마나 사용해서 동작 중인지, 각 노드에서 얼마나 많은 애플리케이션이 실행되고 있는지, 클러스터의 전반적인 리소스 활용도를 파악하는 데 목적이 있습니다.
- 노드
: 사용 가능한 노드 수는 중요한 지표입니다. 이를 공용 클라우드 공급업체에 지불하는 비용을 파악하고 클러스터를 실행하는 데 필요한 클라우드 리소스를 결정할 수 있습니다. - 포드
: 실행 중인 포드 수를 측정하여 노드 장애 시 전체 워크로드를 처리할 수 있는 충분한 노드가 있는지 확인할 수 있습니다. - 리소스 활용도
: 리소스 관련된 많은 메트릭이 있습니다. 네트워크 대역폭, 디스크 사용률, CPU 및 메모리 그것입니다. 이러한 메트릭들을 사용하여 클러스터의 노드 수와 크기를 늘릴 것인지 줄일 것인지 알 수 있습니다.
Kubernetes 포드 모니터링
포드를 모니터링하는 작업은 크게 3가지입니다. 포드의 리소스 사용률, 애플리케이션 메트릭, 포드의 복제 또는 자동 크기 조정과 관련된 메트릭과 같이 개별 포드에 영향을 미치는 문제를 추적합니다.
- Kubernetes 메트릭
: 오케스트레이터가 특정 포드를 처리하는 방법을 모니터링할 수 있습니다. 예를 들어 실제 포드 인스턴스 수와 예상 배포 수의 비교 등의 경우입니다. - 컨테이너 메트릭
: 허용된 최댓값과 비교하여 CPU, 네트워크, 메모리 사용량과 같은 메트릭 등이 있습니다. - 애플리케이션별 메트릭
: 응용 프로그램 자체에 의해 개발되고 응용 프로그램이 처리하는 비즈니스 로직과 관련이 있습니다. 예를 들어 온라인 쇼핑 관련 프로그램은 하루 동안 접속한 사용자 수와 벌어들인 수입에 관해서 데이터를 제공할 수 있습니다.
클라우드 네이티브 아키텍처 통합관제 솔루션, CloudMOA
CloudMOA에서는 컨테이너화된 애플리케이션, Kubernetes 클러스터, Docker 컨테이너 및 기본 인프라 메트릭에 대한 심층적인 통찰로 애플리케이션 및 비즈니스 성능에 대한 가시성을 사용자에게 제공합니다.
그리고 이전 칼럼에서 언급했었던 적절한 리소스 요청 및 한계 설정 관련하여 설정 여부와 설정 내역 및 사용 흐름을 차트를 통해 확인할 수 있고, 로그 백업 기능을 통해 지속적인 상태 이력 제공 및 로그 수집 설정 화면에서 간단한 설정으로 로그 수집을 지원합니다.
이외에도 높은 수준의 서비스 제공에 도움을 줄 수 있는 알람 기능과 개별 구성요소를 검사 및 분석을 할 수 있는 다양한 모니터링 시스템을 제공합니다.
쉽고 편한 쿠버네티스 모니터링을 원하신다면, 👉이곳👈을 방문해주세요!
[NOW엑셈 166회] 다른 이야기도 궁금하시다면? | |
🤝 엑셈 뉴스룸 | EXpert EMpire, EXEM ❗️ 엑셈 인사이트 | 전구간 모니터링과 크로스셀링의 근간, 인터맥스 💡 혁신스토리 | 파괴적 혁신의 키워드 'SOUL' 👨🏫 월간기술동향 | 2022 ICT 10대 이슈 ☁️ 클라우드 A to Z | Kubernetes 모니터링이 필요한 이유 🧍 PHILINNOVATOR | 호모 사피엔스, 그 성공의 비밀 🔔 이벤트 | 도전! 엑셈 퀴즈 |
'엑셈 경쟁력 > 전문가 기술기고' 카테고리의 다른 글
클라우드 A to Z | Kubernetes 보안 위험 (0) | 2021.12.22 |
---|---|
클라우드 A to Z | 쿠버네티스에서 리소스 관리하기 (0) | 2021.10.27 |
클라우드 A to Z | Kubernetes 디자인 패턴 (0) | 2021.09.29 |
클라우드 A to Z | 컨테이너 오케스트레이션 (0) | 2021.08.25 |
클라우드 A to Z | 가상화 그리고 SDDC vs Cloud (0) | 2021.07.21 |
댓글