Helm 이어서, 관측

현대 오토에버 클라우드 스쿨

Helm 이어서, 관측

Gom3rye 2025. 8. 12. 17:33

728x90

설정 가능한 파라미터 확인
- helm show values bitnami/wordpress
readme 확인
- helm show readme bitnami/wordpress
설치 및 삭제
- helm install sample-wordpress bitnami/wordpress --version 25.0.8 --set wordpressUsername=유저이름 --set wordpressPassword=비밀번호 --set wordpressBlogName="블로그이름" --set persistence.size=숫자Gi
설치: 파일에 파라미터를 미리 입력해두고 파일을 읽어서 파라미터를 설정할 수 있다.
- 파라미터를 저장할 yaml 파일 생성(values.yaml)
```
wordpressUsername: 유저이름
wordpressPassword: 비밀번호
wordpressBlogName: 블로그이름
persistence:
  size: 사이즈
```
- helm install sample-wordpress bitnami/wordpress --version 25.0.8 --values 파라미터파일경로
- 테스트: helm test sample-wordpress
- 삭제: helm uninstall sample-wordpress

Helm 아키텍쳐

헬름 클라이언트는 헬름 저장소에서 다운로드 한 차트와 values의 조합을 release로 관리하고 쿠버네티스의 시크릿으로 데이터를 저장하기 때문에 별도의 데이터베이스가 필요 없다.

확인
- kubectl get secret -l owner=helm
릴리스 확인
- helm list

커스텀 차트 생성

헬름은 차트라는 단위로 시스템을 패키징한다.
차트의 내용은 쿠버네티스의 매니페스트 템플릿과 변수가 메인이다.
커스텀 시스템을 패키징하려면 신규로 차트를 생성해야 한다.
차트 생성
- helm create 차트이름
  - 차트를 생성하면 하나의 디렉토리가 만들어지고 그 안에 Deployment/Service/Ingress/HPA/ServiceAccount 리소스 템플릿이 자동으로 생성된다.
  - 기본적으로 롤링 업데이트가 가능한 디플로이먼트를 사용해서 생성하는 것을 권장하지만 레플리카셋이나 파드로도 가능하다.
  - 차트를 직접 생성하는 것도 가능하지만 쿠버네티스 버전 업그레이드에 따라 이전에는 어노테이션 아래에 지정했던 것들이 spec 아래로 변경되는 등의 문법 변화가 생기기 때문에 기본적으로 helm create로 만드는 것을 권장한다.
  - 이미 생성한 매니페스트도 계속해서 쿠버네티스 버전에 맞춰야 하는데 헬름에는 자동으로 맞춰주는 기능이 없으므로 매니페스트 유지보수를 별도로 해주어야 한다.
파일 구성
- template/*yaml: 설치하는 매니페스트 템플릿
- template/tests/*.yaml: 설치한 차트가 정상적으로 동작하는지 테스트하는 매니페스트 템플릿
- values.yaml: 사용자가 나중에 덮어쓸 수 있는 기본값을 정의, 여기에 보통 리소스 제한이나 사용 이미지, 포트 번호 등을 제공한다.
- template/NOTES.txt: helm install 중에 출력되는 메시지
- template/_helpers.tpl: 릴리스 이름으로 변수를 정의하는 등의 헬퍼 변수 정의
- requirements.yaml: 의존하는 차트와 해당 버전 기록
- Chart.yaml: 차트 메타 데이터
생성한 차트 설치
- helm install 이름 차트이름
차트 패키지 화
- tgz 파일로 생성
  - helm package --dependency-update 경로
  - helm package --dependency-update sample-charts/
공개
- 웹 서버 디렉토리를 만들어서 tgz 파일을 업로드
- helm repo add 명령으로 URL을 등록

관측과 모니터링

관측 가능성의 개념과 방향성

관측 가능성의 3가지 요소

모니터링과의 차이점
- 관측 가능성
  - 시스템에서 외부로 출력되는 값만을 사용해서 시스템 내부 상태를 이해하고 예측하는 것
- 모니터링은 블랙박스와 화이트박스 영역을 포함하지만 관측 가능성은 화이트 박스와 예측으로 구성
- 관측 가능성이 지향하는 목표는 내부 시스템에 대한 자세한 이해를 바탕으로 미래에 발생할 이벤트를 예측하는 것이고 이러한 예측을 바탕으로 IT 운영을 자동화하는 것(장애가 발생할 위험이 있으면 미리 예측하고 운영자에게 통지하거나 서비스에 필요한 리소스의 증감을 미리 예측하는 것)
- 관측 가능성은 학술적 용어일 뿐 이전에도 수행하고 있는 작업
- 제어 이론을 설명할 때 기계공학이나 수학에서 사용
- ElasticSearch를 사용해서 로그 관리를 하거나 다이나트레이스 APM(성능 관리)을 사용해서 처리 시간과 지연 시간을 모니터링 하고 InfluxDB와 Telegraph, 다양한 에이전트를 통해서 메트릭을 수집하고 측정하는 것이 일종의 관측 가능성 작업
- 용어의 차이
  - 모니터링에서는 Application Performance Management(성능 관리) 대신에 Tracing(추적)이라고 부르며 Instrumentation(계측) 이나 Telemetry 라는 용어를 자주 사용한다.
- 관측 가능성에서는 블랙 박스 모니터링 정보를 사용하지 않는다.
- 관측 가능성은 애플리케이션 내부의 상태를 모니터링 할 수 있는 정보를 제공하기 때문에 장애가 발생했을 경우 신속하고 수월하게 대응할 수 있다.
- 관측 가능성은 제공된 결과를 보고 이해하는 수준에 그치지 않고 원하는 계측을 추가할 수 있고 이를 통해 보다 자세하게 이해할 수 있을 뿐 아니라 향후 발생할 가능성이 높은 장애에 대한 예측이 가능하다.
관측 가능성의 구성 요소
- Metric
  - 일정 시간 동안 측정된 데이터를 집계하고 수치화
  - 큐의 대기 메시지 개수, 사용 중인 CPU와 메모리 크기, 서비스에서 초당 처리하는 개수 등
  - 메트릭은 전체적인 시스템의 상태를 보고하는데 유용하며 일반적으로 히스토그램 또는 게이지 등 차트를 사용해 시각적으로 표현한다.
  - 애플리케이션에서 기본적으로 제공하는 메트릭 이외에 커스텀 매트릭이 필요한 경우가 있는데 이 경우 계측 API와 SDK를 사용해서 커스텀 메트릭을 개발해도 되지만 다른 패키지 애플리케이션이나 로드밸런서 등은 커스텀 매트릭 개발을 어렵게 하고 일부는 솔루션을 구입한 벤더를 통해서만 가능하다.
- Log
  - 애플리케이션 실행 시 생성되는 텍스트 라인으로 구조적인 JSON이나 비구조적인 텍스트로 출력
  - 애플리케이션 에러와 경고를 확인하고 문제점에 대한 정확한 원인을 이해하기 위해서 필요하다.
  - 레거시 애플리케이션이나 패키지 애플리케이션일 수록 매트릭보다는 로그를 이용해서 시스템 내부를 이해하고 문제 해결을 하는 것이 일반적이다.
- 추적
  - 마이크로 서비스가 시스템을 경유하며 트랜잭션을 처리하는 과정에서 발생하는 세부적인 정보를 조회
  - 트랜잭션이 이동하는 경로, 트랜잭션을 처리하는 과정에서 발생하는 대기 시간 및 지연 시간 그리고 병목 현상이나 에러를 일으키는 원인을 context와 로그 태그 등의 메타데이터에 출력
  - 분산 마이크로 서비스 간에 복잡한 상호작용이 발생하는 클라우드 네이티브 운영 환경에서 생기는 문제

Metric

가용성

가용성은 시스템의 전반적인 상태와 정상 작동 여부를 거시적 관점에서 측정
SLI(Service Level Indicator, 서비스 수준 지표)로 정량화
SLO(Service Level Objective, 서비스 수준 목표)는 사업적으로 합의한 수준 또는 SLA(Service Level Agreement, 서비스 수준 협약)에 명시된 제공 수준보다 제한적이거나 보수적인 수치
SLI는 SLO라는 임계 기준을 달성해야 한다.

구글의 골든 시그널: 네트워크에서 발생하는 이벤트와 많은 연관

지연
- 지연은 에러가 아니다.
- 지연을 확인할 수 있는 차트로는 시계열, 히트맵, 히스토그램 차트를 많이 이용한다.
- 그라파나로 시각화할 때 히스토그램을 많이 사용한다.
- 지연은 잠재적인 장애를 예측할 수 있는 유용한 신호로 서비스 요청 후 완료까지 걸리는 시간을 측정
- 에러는 지연 없이 빠르게 처리되는 경향이 있고 정상 응답은 지연을 포함하는 경우가 많다.
- 1초의 지연을 포함하는 정상 응답과 60초의 지연을 포함하는 정상 응답을 동일하다고 판단할 수는 없다.
- 일정 시간 이상의 지연은 에러로 판단하거나 타임아웃으로 처리를 하는 것이 현명하다.
- 이런 일정 시간을 SLI로 정의한다.
에러
- 에러의 기준을 명확히 하는 것이 중요
- 일반적으로 이상치와 에러를 별도로 포함한 대시보드 형태로 구성해서 시각화
트래픽
- 트래픽은 발생하는 요청의 양
- 관찰되는 시스템의 유형, 초당 요청의 수, 네트워크 입출력 등에 따라 다양하다.
- 트래픽은 양이 급격하게 많아지거나 임계치를 초과하거나 포화 상태가 되면 지연과 에러가 발생하고 최종적으로 장애에 이른다.
- 트래픽은 다른 신호와 연관성이 많은데 지연과 에러가 발생하더라도 중단 없이 적정 수준의 트래픽을 처리할 수 있는 시스템을 구축하는 것이 클라우드 네이티브의 사상이다.
- 골든 시그널의 원칙은 트래픽의 증가에 따른 지연과 에러를 최소화하고 최종적으로 장애에 이르지 않도록 설계하는 것
포화 (saturation)
- 리소스가 얼마나 사용 중인지 또는 얼마나 여분이 있는지를 나타내는 것
- 전체 총 대역폭과 처리 가능한 트래픽에 대비해서 현재 트래픽 혹은 대역폭이 어느 정도인지 이해할 수 있는 지표
- 포화를 통해 향후 트래픽이 증가했을 때 이용 가능한 자원의 총 사용율을 예측할 수 있다.
- CPU, Memory, Network와 같이 제약이 큰 리소스에 주로 적용한다.
- 지연 증가는 종종 포화의 선행 지표가 된다.
- 오류와 재시도 메시지가 트래픽에 더해지면 상황은 더욱 악화된다.
메트릭 유형
- Counter
  - 모니터링하는 이벤트의 누적 개수 혹은 크기를 표현한다.
  - rate 함수와 함께 이벤트를 추적하는데 많이 사용
  - 대표적인 카운터
    - 초당 요청 개수
    - 초당 처리 개수
  - 카운터는 증감을 하지 않는다.
- Gauge
  - 증가하거나 감소하는 임의의 값을 나타내는 메트릭
  - 현재 상태를 나타내는 메트릭
  - 대표적인 게이지
    - 데이터베이스에 연결된 커넥터 개수
    - 현재 동작하는 스레드 개수
    - 사용률
- Summary
  - 요약은 응답의 크기와 대기 시간을 추적하는데도 사용하는데 측정한 이벤트의 합계와 카운트를 모두 제공한다.
  - 집계가 필요하거나 범위와 분포에 대해서 측정하는 경우는 히스토그램을 권장하고 범위와 분포에 상관없이 정확한 백분위 수가 필요하다면 요약을 사용한다.
- 히스토그램
  - 시간 경과에 따른 추세와 데이터가 단일 범주에서 어떻게 분포되어 있는지를 나타낸다.
  - 분포를 이해하고자 하는 경우 분위수 외에도 표준편차와 그래프를 이용하는데 히스토그램은 분위수를 주로 사용한다.
- 시계열 데이터
  - 관측 가능성에서는 시계열 데이터를 주로 다룬다.
  - 정해진 시간 내의 분포와 변화를 출력하기 위해서는 히스토그램을 많이 사용한다.
  - 그라파나 히스토그램은 각 범위 내에 데이터 포인트의 수를 표시하여 숫자 데이터를 시각적으로 표현한다.
  - 상관 관계에 따라 타 관측 가능성으로 이동하거나 화면 전환이 가능하다.
  - Loki는 히스토그램과 유사한 차트를 사용하며 이를 통해서 특정 시간 동안의 분포를 이해할 수 있고 추적의 Gantt화면으로 전환할 수 있다.
  - 프로메테우스 이그젬플러는 추적에 대한 근사치를 시계열로 표현한다.
메트릭 관리 방안
- 한 번에 너무 많은 정보가 전달돼 추론하기 어렵지 않도록 데이터를 대시보드에 나타내고 점진적으로 정보를 설정한다.
- 서비스 별로 여러 개의 대시보드를 상세 보기와 함께 만들 수 있지만 가장 중요한 정보를 표시하는 상위 수준의 대시보드는 1개만 유지한다.
- 메트릭을 표시할 때 응답 시간, 에러, 트래픽 같은 가장 중요한 것에 집중한다.
- 가능하면 태그를 사용해서 메트릭의 상황 정보를 포함시키는 것을 권장한다.
- 메트릭의 이름을 정할 때 정의된 표준을 따르기를 권장한다.

로그

로그 관리

로그 관리의 목적은 시스템에 분산된 로그를 한 곳에 저장해서 다루기 쉽게 하는 것이다.
일단 로그를 중앙집중적으로 수집하고 관리할 수 있는 인프라와 로그 관리 시스템을 구축한 상태라면 다양한 로그 유형을 표준화하는 작업이 필요하다.
- 로그 유형이 제각각이면 로그 내용을 쉽게 검색하는 것이 어렵고 후속 처리를 위한 가공과 집계에 많은 시간이 걸린다.
로그를 수집할 때 고려할 점
- 서비스가 재시작되거나 예상치 못한 장애가 발생할 수 있는데 이러한 상황을 극복하고 지속적으로 로그를 수집, 관리해야 한다.
- 급격하게 증가하는 로그 데이터를 처리하기 위해 로그 관리 시스템을 동적이고 수평적인 확장을 지원하기 위해서 가상 머신, 도커 컨테이너, 쿠버네티스 파드 등 다양한 런타임 환경에서 동일한 방식으로 로그 데이터를 수집할 수 있어야 한다.
- 클라우드 네이티브는 멀티 테넌트를 지원해야 한다.
- 단일한 로그 시스템을 사용해서 다양한 조직과 서비스에서 생성하는 로그 데이터를 수집하고 중앙 집중적으로 관리해야 한다.
- 수집된 로그 데이터를 활용해서 검색과 후속 처리를 할 수 있어야 한다.
표준화되고 구조적인 로그 생성
- 저장하고 사용할 수 있는 데이터
  - 프론트엔드, 백엔드 애플리케이션에서 수집한 성능 데이터
  - 프록시, 로드밸런서 등에서 수집한 네트워크 트래픽 로그
  - 웹 서버, 서버 프레임워크, 언어별 로깅 라이브러리에서 수집한 로그
  - SAP등 벤더 솔루션 패키지와 레거시 시스템에서 수집한 비구조적인 데이터
- 벤더 솔루션 패키지와 레거시 시스템(기존에 운영 중인 시스템)의 경우는 자체 고유한 형식을 로그에 기록하므로 형식을 제어할 수 없고 그 특수성에 대응하고 변환해야 한다.
- 전체 엔지니어링 팀이 형식을 준수하면 데이터를 더욱 간단하고 효과적으로 수집할 수 있다.
로그에 포함할 유용한 정보
- 타임스탬프
  - 데이터가 상호적으로 연관되고적절한 순서를 갖도록 정하려면 로그 엔트리에 타임스탬프를 포함시켜야 한다.
  - 타임스탬프는 가능한 세밀하고 자세한 정보를 제공하는 것이 좋다.
  - 각 서비스는 자체 타임스탬프를 표현해야 하는데 가능하다면 마이크로세컨드가 좋다.
  - 타임스탬프는 시간대 정보를 포함해야 하는데 GMT/UTC로 수집하는 것이 좋다.
  - 이런 상세 정보가 있으면 다른 시간대의 서로 다른 서비스의 로그, 추적, 메트릭과 상호 연관 지을 때 발생하는 문제점을 피할 수 있다.
  - 발생 시간으로 데이터를 정렬하면 분석하기 쉽고 적은 문맥 정보가 필요하다.
  - 타임스탬프는 이벤트가 발생한 순서를 이해하기 위한 첫 번째 단계
- 식별자
  - 저장하려는 데이터에 가능한 많은 고유 식별자를 포함해야 한다.
  - 주문 ID, 트랜잭션 ID 등 다른 고유 식별자는 여러 소스의 데이터를 상호 참조할 때 중요한 가치가 있다.
  - 이를 이용할 때 서로 다른 소스의 데이터를 효과적으로 그룹화 할 수 있다.
  - 대부분의 경우 리소스를 식별하는데 ID를 사용하기 때문에 이런 ID는 이미 시스템에 존재한다.
  - 고유 식별자를 타임스탬프와 함께 사용하면 시스템에서 처리 흐름을 이해하는 강력한 도구가 된다.
  - 쇼핑몰의 경우 도메인은 고객과 상품을 기본으로 하며 트랜잭션 데이터인 주문을 생성한다.
  - 정의와 관리가 잘된 관측 가능성은 추적 ID를 통해서 주문의 처리와 지연시간을 모니터링
  - 업무를 처리하는 프로덕트 오너는 주문 ID를, 시스템을 관리하는 운영자는 추적 ID를 사용하는 것이 일반적이다.
  - 주요 키 정보는 로그에 나타나야 한다.
  - 다양한 시스템에서 로그를 정확히 수집했다는 가정하에 Elastic Search는 키 정보를 검색 조건으로 입력하고 시간 순서대로 정렬해서 문제와 원인을 빠르게 찾아낸다.
- 소스
  - 로그 엔트리의 소스를 식별하면 쉽게 디버깅 할 수 있다.
  - 일반적으로 소스 데이터는 호스트, 클래스, 모듈, 함수, 파일명 등이다.
  - 함수를 호출할 때 실행 시간을 추가하면 나중에 소스에 수집된 정보에서 성능을 계산할 수 있다.
  - 메트릭을 대체하는 것은 아니지만 병목 구간과 잠재적 성능 문제를 식별하는데 효과적이다.
- 레벨 또는 카테고리
  - 로그 엔트리는 카테고리를 포함시키는 것을 권장한다.
  - 카테고리는 로그 데이터의 유형이거나 로그 레벨일 수 있다.
  - 일반적인 로그 레벨은 ERROR, DEBUG, INFO, WARN의 값이 많이 사용된다.
  - 카테고리로 데이터를 그룹 짓고 분류할 수 있는데 로그 관리 시스템은 로그 파일을 파싱해 ERROR레벨을 가진 메시지를 찾아내 에러 보고 알람 등을 생성하고 이를 운영자에게 전송한다.
  - Elastic Search와 Loki 에서는 이러한 기능을 쉽게 개발할 수 있는 기능을 제공한다.
  - 최근에는 로그 엔트리를 운영자가 읽기 쉽고 기계가 파싱하는데 유리한 JSON 형식을 많이 사용한다.

로그 표준화

구조화된 로그를 사용하는 것을 권장한다.

golang 프로젝트에서는 go.uber.org/zap 라이브러리를 이용하는 경우가 있다. (병렬 처리 쪽에는 go가 굉장히 강력하다.)

package main
import (
	"time"
	"go.uber.org/zap"
)

func main() {
	logger, _ := zap.NewProduction()        // JSON 형식의 production logger 생성
	defer logger.Sync()                     // 버퍼에 있는 로그 플러시 (출력)
	logger = logger.Named("my-app")         // 로거에 이름 붙이기 (서브로거)
	logger.Info("failed to fetch URL",      // info 레벨 로그 출력
		zap.String("url", "<https://github.com>"),
		zap.Int("attempt", 3),
		zap.Duration("backoff", time.Second),
	)
}

# 로그
{"level":"info","ts":1691870012.153246,"logger":"my-app","msg":"failed to fetch URL","url":"<https://github.com>","attempt":3,"backoff":1}

관측 가능성 목표

멀티 클러스터와 멀티 테넌트 운영
- 일반적으로 관측 가능성은 쿠버네티스에 배포되고 운영되어야 한다.
- 쿠버네티스 런타임 환경에서 오토스케일링을 지원하고 수평적인 스케일 아웃이 되도록 확장할 수 있어야 한다.
  - 오토스케일링을 통해 확장된 리소스는 프로메테우스에 의해서 자동으로 서비스 디스커버리가 이루어져야 한다.
- 단일 클러스터를 넘어서 여러 개의 클러스터에서 운영되는 수준으로 확장성을 제공해야 한다.
대용량 시계열 빅데이터 수집/관리
- 관측 가능성에서 수집되는 데이터는 시계열 빅데이터이므로 특정에 맞게 저장하고 관리해야 한다.
- 수십 테라바이트의 빅데이터를 저장해야 하므로 내구성이 우수하고 병렬 처리가 가능한 객체 스토리지에 장기간 보관할 수 있어야 한다.
로그, 메트릭, 추적의 상호 관계 확립
트래픽의 관리와 가시성 확보
- 관측 가능성을 통해 시스템의 내부 정보를 자세히 이해하는 것과 동시에 가시성을 확보해서 장애를 미리 방지하고 복원력이 높은 탄력적인 시스템을 구축하는 것이 목표이다.
관측 가능성, 가시성 정보를 통합
- 관측 가능성(로그, 메트릭, 추적), 가시성(트래픽, 네트워크, 장애), 리소스(구성 정보), 서비스 등은 서로가 연관성을 가지고 있다.
- 이를 수집하고 활용할 수 있는 거버넌스와 데이터 탐색 시스템이 필요하다.
운영 비용 절감과 기술 내재화
- CSP(Cloud Service Provider)가 제공하는 가상 머신, 컨테이너 서비스는 저렴한데 관측 가능성 관리형 서비스를 구독하면 비용이 많이 증가한다.
- 오픈 소스를 사용해서 관측 가능성을 구축하면 운영 비용을 절감할 수 있고 지속적인 튜닝과 학습을 통해 비용을 더 절감할 수 있다.
운영의 자동화와 AIOps
근본 원인 분석

관측 가능성 오픈 소스

OpenTelemetry: 계측을 위한 도구
로키: 그라파나의 로그 관리 시스템
그라파나 미미르: 프로메테우스용 오픈 소스
타노스: 다수의 프로메테우스를 통합할 수 있는 글로벌 뷰를 제공한다.
예거: 분산 컨텍스트 전파를 포함한 마이크로서비스 기반 분산 시스템 모니터링과 추적을 위해서 사용

자원을 일정량 이상 사용하게되면 pod를 자동으로 늘려주는 것: HPA

→ + 프로메테우스랑 같이 써서

728x90