AEWS 4주차. EKS Observability

대부분의 IT 업무에서는 현재 상태를 점검하거나, 발생한 문제를 해결하기 위해 수많은 과거/현재 데이터를 확인합니다.

특히 시스템을 운영하다보면 평상시 모니터링이라 불리는 업무를 상시적으로 진행하게 됩니다.

이는 전반적인 시스템의 상태를 점검하고,문제 발생시 해당 문제를 해결하기 위한 여러가지 값들을 점검하는 업무입니다.

 

어떻게보면, 그동안의 경험을 바탕으로 현재 상태의 메트릭과 지나온 로그를 분석하여,

문제의 지점이나 원인을 빠르게 찾아내는 것이 IT 운영자의 숙명이자 필수적인 요구 능력이라고 볼 수 있습니다.

    - 메트릭(metrics) : CPU 사용량, 메모리 사용량, 네트워크 트래픽과 같은 시스템 성능과 관련된 정량적 정보

    - 로그(log) : 사용자 작업 및 오류를 포함하는 시스템 활동에 대한 기록

 

요즘 많이들 이야기하는 옵저버빌리티(Observability)는 과거의 모니터링보다 더 발전한 개념으로,

시스템의 동작을 깊이 이해하고 발생가능한 모든 문제의 근본 원인을 파악하기 위해 사용되는 용어 입니다.

주로 메트릭과 로그 외에 추적 데이터를 함께 사용하여, 여러 소스에서 수집한 데이터를 같이 분석함으로써,

쉽게 찾을 수 없는 패턴과의 상관관계를 발견하는데 도움을 줍니다.

최근에는 여기에 AI를 추가하여, 스스로 학습을 기반으로 장애나 이슈를 사전에 예측하기도 합니다.

    - 추적(Tracing) : 요청의 호출 순서 및 응답 시간과 같은 시스템 동작에 대한 정보

 

관리 또는 규제 등 다양한 상황에 따라 EKS에 대해 옵저빌리티가 필요한 경우가 발생할 수 있습니다.

기본적으로 EKS는 AWS의 관리형 k8s 서비스로, 컨트롤플레인의 로깅이 활성화되어 있지 않기 때문에,

컨트롤플레인에 대한 로깅을 활성화하여 사용자의 cloudwatch를 통해 확인할 수 있는 기능을 제공하고 있습니다.

 

이를 통해 총 5가지 형태의 로그를 cloudwatch의 "Log groups"를 통해 제공합니다.

    1. API 서버(Kubernetes API server componets log) : 클러스터에 대한 API 요청 및 서버의 동작과 관련된 로그
    2. 감사(Audit) : Kubernetes API를 통한 클러스터 액세스와 관련된 로그
    3. Authenticator : 클러스터에 대한 인증 요청과 관련된 로그
    4. 컨트롤러 관리자(Controller manager) :클러스터 컨트롤러 상태와 관련된 로그
    5. 스케줄러(Scheduler) : 예약 결정과 관련된 로그로 스케줄러의 정상 동작등을 확인

 

그외 컨트롤노드가 아닌 pod에 대한 로그는 kubectl을 통해 확인할 수도 있습니다.

무조건 확인이 아닌 할 수도인 이유는, 사전에 dockerfile 내에 중요 로그 확인을 위한 사전 구성이 필요하기 때문입니다.

 

기본적으로 pod내에서 생성된 log는 pod에 접근해야 확인이 가능합니다.

하지만, 사전에 중요 로그 파일에 대해서 stdout과 stderr로 심볼릭 링크를 걸어준다면,

별도의 pod 접근 없이 kubectl을 통해 편리하게 로그를 확인할 수 있습니다.

 

이러한 장점으로 컨테이너 환경의 로그는 표준 출력 stdout과 표준 에러 stderr로 보내는 것을 권고하고 있으며,

이에 따라 많은 공식 이미지들이 dockerfile 안에 해당 링크를 추가해 두고 있습니다.

nginx의 공식 nginx dockerfile

bitnami의 공식 ngingx dockerfile

ngingx의 dockerfile을 살펴보면

nginx 컨테이너 내부에 있는 access.log는 /dev/stdout으로 error.log는 /dev/stderr 경로를 통해 심볼릭링크가 걸려있습니다.

이러한 심볼릭 링크를 통해 컨테이너에 접속하지 않고도

애플리케이션 종류에 상관없이, 로그 파일에 위치에 상관없이 단일 명령어로  외부에서 확인할 수 있습니다.

 

그러나 해당 방법은 pod 내 파일에 대한 링크를 제공하는 것으로,

실제 pod가 종료된다면 pod 내부의 데이터도 삭제되어 종료 이후에는 로그를 확인할 수 없습니다.

또한, EKS에서 기본적 kubelet에서 정의된 용량이 10MiB로 설정되어 있어 초과하는 전체로그는 확인할 수 없습니다.

물론 이경우에는 필요시 kubelet-config.yaml의 사이즈 변경을 통해 더 큰 용량의 로그를 확인할 수 있습니다.

 

이와 같은 로그 관리에 대한 어려움을 방지하기 위애

장기간의 로그의 수집 및 분석을 제공하는 EKS 외부의 중앙 로그 수집 장치가 필요합니다.

기본적으로 EKS에서는 컨트롤플레인에 대한 로그는 설정을 통해 손쉽게 확인할 수 있지만,

pod에 대한 로깅은 사용자가 도구를 선택해서 로그 저장과 수집을 구성해야 합니다.

이를 위해 AWS에서는 CloudWatch Container Insight(CCI)라는 CloudWatch의 세부 기능을 제공합니다.

CCI는 컨테이너형 애플리케이션 및 마이크로 서비스에 대한 모니터링, 트러블 슈팅 및 알람을 위한

완전 관리형 관측 서비스로 CloudWatch 콘솔에서 자동화된 대시보드 형태로 제공됩니다.

 

  1. 컨테이너와 프로메테우스의 Metrics 및  애플리케이션 Log와 성능 Log 이벤트를 탐색, 분석 및 시각화하여 제공

  2. CPU, 메모리, 디스크 및 네트워크와 같은 인프라 metric을 자동으로 수집

  3. EKS 클러스터의 Crashloop backoffs와 같은 진단 정보를 제공하여 빠르게 문제를 격리하고 해결할 수 있도록 지원

  4. AWS EKS, ECS, ECS Fargate 및 EC2 위에 구성된 K8s 클러스터에서 사용 가능

CCI는 기본적으로 metric을 수집하는 CloudWatch Agent와 Log를 수집하는 Fluent Bit을 데몬셋으로 구성하여,

관련 데이터를 수집하여 보여줍니다.

Log를 수집하는 Fluent Bit의 경우 중요 3가지 종류의 로그를 수집하여 CloudWatch Logs로 전송하고 있습니다.

CloudWatch Logs에 저장된 데이터는 Log Insights를 통해 로그 대상을 분석하고, 대시보드로 시각화 합니다.

    1. /aws/containerinsights/Cluster_Name/application : 컨테이너/pod 로그

    2. /aws/containerinsights/Cluster_Name/host : Node(호스트) 로그 로그

    3. /aws/containerinsights/Cluster_Name/dataplane : k8s 데이터플레인 로그

 

이외에도 EKS의 데이터를 모니터링 할 수 있는 방법은 여러가지가 있습니다.

 

1) Metric Server

Metric Server는 kubelet으로부터 수집한 리소스 메트릭을 수집 집계하는 클러스터의 add-on 구성요소로

cAdvisor를 통해 kubelet에 포함된 컨테이너 메트릭을 수집하고 pod 데이터를 모아 함께 Metric server로 전달합니다.

해당 정보를 이용하여 kubectl top이라는 CLI를 통해 사용현황에 대한 통계를 확인할 수 있습니다.

 

2) kwatch

k8s에서 발생하는 클러스터의 이벤트나 로그를 실시간으로 확인해서

슬랙이나 디스코드 같은 협업도구로 전달하여 빠른 처리가 될 수 있도록 공유합니다.

 

3) botkube

kwatch보다 더 많은 기능을 가지고 있으며, 

알람외에도 slack 창을 통해서 명령어를 넘겨주거나, 관련 명령어에 대한 입력시 도움을 주기도 합니다.

 

 

일반적으로 가장 많이 사용하는 모니터링 방법은 오픈소스 기반의 프로메테우스와 그라파나를 이용하는 것입니다.

AWS에서도 관리형으로 제공하고 있으며, 얼마전 서울리전에도 서비스가 시작되었습니다.

 

프로메테우스는 오픈소스 기반의 모니터링 시스템으로 

대상 시스템으로부터 각종 모니터링 지표를 수집하고 저장하고 검색할 수 있습니다.

k8s 모니터링 뿐만 아니라 다양한 솔루션들의 모니터링을 위해 널리 사용되고 있어

다양한 시스템과의 연동 및 활용방안이 검증되어 있는 장점이 있으며, 관련 생태계가 계속 확장 중입니다.

그러나 이중화나 클러스터링이 기본적으로 제공되지는 않습니다.

 

프로메테우스는 대상을 지정할수도 있지만, 자동 발견 기능을 통해 대상을 자동으로 확인하고, 

key-value 타입의 시계열 데이터의 메트릭을 Retrieval라는 컴포넌트를 통해서 pull 방식으로 직접 가져옵니다.

이렇게 수집된 데이터를 시계열 데이터베이스인 TSDB에 저장합니다.

 

이와 반대로 그라파나는 오픈소스 시각화 솔루션으로 DB를 기준으로 대시보드 형태로 데이터를 보여줍니다.

그라파나는 기본적으로 다양한 메트릭을 기준으로 기본 대시보드를 제공해줄 뿐만 아니라,

사용자들이 직접 커스텀한 다양한 형태의 대시보드가 활발히 공유 되고 있습니다.

 

기본적으로 프로메테우스와 달리 데이터 자체를 저장하는 기능이 없으나, 

역시 다양한 소스들과 연동이 가능하며, 주로 프로메테우스와 함께 짝을 이루어 구성되고 있습니다.

 

 

 

관련 실습

-----------------------------------------------------------------------------------------------

이 내용은 AEWS(AWS EKS Workshop Study) 1기의 과제로써 작성되었습니다.

AEWS는 '가시다'님이 속한 CloudNet@에서 진행하는 AWS EKS workshop에 대한 스터디입니다.

매주 일요일마다 소중한 정보를 퍼주시는 '가시다'님께 무한 감사 드립니다.

https://gasidaseo.notion.site/23-AWS-EKS-Workshop-07165aec800042b9ac9357aee18fdf17