[모니터링] 관측 가능성 및 오토스케일링 기술

728x90

관측 가능성 및 오토스케일링 기술

1. 트래픽 관리

단일 장애점 (Single Point of Failure)

시스템의 특정 구성 요소가 고장 나면 전체 시스템에 영향을 미칠 수 있는 지점을 의미한다. 이를 방지하기 위해 다양한 복원성 패턴을 적용하여 시스템의 안정성을 강화한다.

로드 밸런서 (Load Balancer)

트래픽을 여러 서버로 분산시켜 단일 장애점을 제거하며, 시스템의 성능과 가용성을 높인다. 로드 밸런서를 통해 특정 서버의 과부하를 방지하고, 시스템의 전체적인 안정성을 확보한다.

복원성 패턴

재시도 (Retry): 요청이 실패했을 경우, 이를 다시 시도하여 성공 확률을 높인다.
비율 제한 (Rate Limiting): 요청의 속도를 제한해 과도한 트래픽으로 인한 시스템 과부하를 방지한다.
벌크헤드 (Bulkhead): 자원을 격리하여 특정 구성 요소의 문제가 전체 시스템에 영향을 미치지 않도록 한다.
서킷 브레이커 (Circuit Breaker): 장애가 발생한 서비스로의 요청을 중단해 전체 시스템 보호.
분산 메시지 시스템: Kafka나 RabbitMQ 같은 메시징 시스템을 통해 대량의 데이터를 안정적으로 처리한다.

관측 가능성은 비즈니스 애플리케이션에 비해 대용량 트랜잭션을 처리하는 것이 일반적이다.
관측 가능성을 운영하면 메시지 유실이 빈번하고 시스템 증설의 필요성이 여러 차례 부각될 것이다.

가시성 (Visibility)

가시성은 시스템 상태를 명확히 파악할 수 있는 정도를 의미하며, 주로 하드웨어와 인프라를 대상으로 한다.

시스템 모니터링: 장애를 빠르게 탐지하고 해결할 수 있는 능력을 제공한다.
메트릭 관리: 다양한 벤더가 제공하는 메트릭 데이터를 활용해 시스템 상태를 분석한다.

서비스 메시

서비스 메시 기술을 사용하면 각 서비스 간의 통신 상태를 모니터링할 수 있다. Istio와 같은 서비스 메시 도구는 클라이언트 측 부하 분산 및 오토스케일링을 지원한다. 이를 통해 복잡한 마이크로서비스 환경에서도 가시성을 높이고 관리 효율성을 개선할 수 있다.

ISTIO와 넷플릭스의 open source software가 많이 사용되는데, OSS가 이스티오가 제공하지 않는 세밀한 조정도 수행한다.
ISTIO에 대비한 오픈 소스 소프트웨어의 특징
- 클라이언트 측 부하 분산을 사용해서 오토스케일링을 구현한다.
- OSS는 Go와 파이썬을 사용해서 애플리케이션을 개발했기 때문에, 다양한 플랫폼과 개발 언어를 지원하지 못한다.

2. 쿠버네티스 오토스케일링

HPA (Horizontal Pod Autuscaler)

HPA는 애플리케이션 부하에 따라 Pod(파드)의 개수를 자동으로 조정하는 기능이다.
주로 CPU 사용률, 메모리 사용률 같은 메트릭 데이터를 기반으로 동작한다.

지정한 메트릭을 컨트롤러가 체크해서 부하에 따라 레플리카 수가 되도록 자동으로 파드를 늘리거나 줄이는 것이다.

HPA는 파드를 오토스케일링하고, 다음 리소스들에 대해 스케일링을 사용할 수 있다.

Deployment
ReplicaSet
ReplicaController
StatefulSet

오토스케일링의 필요성

관측 가능성 시스템은 대량의 트래픽을 안정적으로 처리해야 하므로 오토스케일링이 중요하다.

AWS는 EC2 가상머신을 기반으로 오토스케일링 기능을 제공한다.
그러나, 가상 머신은 OS를 중심으로 네트워크, 스토리지가 모두 결합되므로 의존성이 높고, 용량이 커서 오토스케일링에 필요한 복제과정에서 시간이 오래 걸린다. 또한, 애플리케이션의 수평적인 확장 시 불필요한 부분까지 확장이 되므로 비용과 자원의 최적화 측면에서 비효율적이다. 따라서 수평적 확장이 어렵기 때문에 컨테이너 사용을 권장한다.

오토스케일링의 작동 원리

메트릭 측정: CPU와 메모리 사용률 측정
메트릭 서버 사용: 메트릭 서버는 기본적으로 CPU, 메모리만 지원하므로 Prometheus Adapter나 KEDA를 활용한다.
파드 분산: 늘어난 파드로 트래픽을 고르게 분산한다.
로드밸런서: 쿠버네티스 서비스 앞에 로드밸런서를 두어 트래픽을 관리한다.

HPA 컨트롤러의 작동 방식

메트릭 측정: HPA 설정에 따라 스케일링 된 파드에 대한 메트릭을 가져온다.
메트릭 API를 통해 데이터를 수집한다.
- 파드 레벨의 자원 메트릭은 쿠버네티스 메트릭 API에서 가져오고,
- 다른 모든 메트릭은 쿠버네티스 사용자 정의 메트릭 API에서 가져온다.
현재 메트릭을 목표 메트릭 값과 비교하여 필요한 레플리카 수를 계산한다.
계산된 값 중 가장 높은 값을 기준으로 파드를 늘리거나 줄인다.
- 각 메트릭을 개별적으로 평가한 후 가장 큰 값을 제안한다.
- 계산을 완료하면 요청한 임계값 이하이면서 요청한 레플리카 수보다는 이상인 정수를 오토스케일링 한 값으로 최종 선택한다.

HPA가 평가하는 메트릭 유형

표준 메트릭: CPU 사용량 등 기본 메트릭. 일반적으로 메트릭 서버에서 제공하는 가장 사용하기 쉬운 메트릭
사용자 정의 메트릭: Prometheus와 같은 외부 시스템을 통해 수집된 메트릭

권장 사항

파드 레벨과 노드 레벨 오토스케일링 병행

파드 레벨의 오토 스케일링과 노드 레벨의 오토 스케일링(클러스터)을 함께 사용하는 것을 권장한다.

파드 레벨 오토스케일링: 애플리케이션의 부하에 따라 파드 수를 늘리거나 줄인다.
노드 레벨 오토스케일링 (클러스터 오토스케일링): 클러스터 노드 수를 자동으로 조정하여 자원 부족 문제를 해결한다.
이 두 방식은 서로 보완적으로 작동하며, 함께 사용하면 더욱 안정적이고 효율적으로 시스템을 운영할 수 있다.

스케일 인(파드 감소)에서의 주의할 점

스케일 아웃(파드 증가)보다는 스케일 인(파드 감소) 과정에서, 트래픽을 처리 중인 파드가 갑작스레 종료되면 장애가 발생할 가능성이 있다. 이를 방지하기 위해 아래와 같이 설정할 수 있다.

스케일 인을 위한 상세 매개변수를 설정: 트래픽을 적절히 분산하거나 기존 요청 처리가 끝난 후 파드를 종료하도록 설정
PDB(Pod Disruption Budget): 특정 시점에 종료될 수 있는 파드의 수를 제한

고도화된 오토스케일링

프로메테우스와 같은 메트릭 수집 도구를 사용해 커스텀 메트릭 기반 오토 스케일링을 추천한다.
복잡한 마이크로서비스 환경에서는 CPU, 메모리와 같은 주요 리소스를 기반으로 먼저 시작한 후, 점진적으로 고도화하는 것을 권장한다.

노드 오토스케일러는 대부분 자동화 기능을 제공해주기 때문에 운영자 입장에서는 수작업이 필요없는 경우가 대부분이지만 drain, cordon, taint 명령과 PDB, affinity 등 리소스 설정은 쿠버네티스 운영에 유용하다.

그라파나 관측 가능성 헬름(Helm) 차트를 기본적으로 메트릭 서버를 사용해서 CPU, 메모리 기반의 오토스케일링과 PDB를 사용하며 KEDA를 사용해서 요구사항에 적합하게 고도화할 수 있다.

3. 오토스케일링 관련 주요 오픈소스

Metric Server
Prometheus Adapter
KEDA

1) Metric Server

역할: 쿠버네티스에서 CPU와 메모리 같은 리소스 메트릭을 수집, 집계해 HPA가 사용할 수 있도록 제공한다.
작동 원리:
1. 노드 에이전트(Kubelet)에서 메트릭을 수집한다.
2. Metric Server가 이를 처리해 쿠버네티스 API Server에 전달한다.
3. kubectl top 명령으로 메트릭을 확인할 수 있다.
설정: 파드 배포 시 resources 섹션에 CPU와 메모리 사용량을 명시하는 것이 필수다.

resources:
  limits:
    cpu: 500m
  requests:
    cpu: 200m

2) Prometheus Adapter

역할: 프로메테우스의 메트릭 데이터를 활용해 HPA를 통한 오토스케일링 가능
사용법:
1. Prometheus Adapter에서 모니터링할 네임스페이스와 메트릭을 설정한다.
2. HPA 정의에서 설정한 메트릭을 참조해 오토스케일링을 구현한다.

3) KEDA (Kubernetes Event-driven Autoscaler)

역할: 이벤트 기반 메트릭(e.g., Kafka 메시지 수)을 활용해 HPA와 연동, 빠르게 확장 처리
특징:
- Kafka, Redis 등 다양한 이벤트 소스와 통합 가능
- 애플리케이션이 메시지를 Kafka로 전송하면, Kafka가 KEDA에 이벤트를 전달해 필요한 파드 수를 조정
- 메시지가 없으면 디플로이먼트를 0으로 축소
- 메시지가 추가되면 디플로이먼트를 활성화하고 필요에 따라 수평 확장
워크 플로
- pending(처리 보류) 메시지가 없으면 KEDA는 디플로이먼트를 0으로 확장한다.
- 메시지가 도착하면 KEDA는 이것을 이벤트로 감지하고 디플로이먼트를 활성화 한다.
- 디플로이먼트가 실행되면 컨테이너 중 하나가 카프카에 연결되고 메시지를 가져오기 시작한다.
- 카프카 토픽에 더 많은 메시지가 도착하면 KEDA는 이 데이터를 HPA에 공급하여 수평 확장시킬 수 있다.

메트릭 서버는 CPU 등 컴퓨팅 자원만을 지원하고, 프로메테우스 어댑터는 프로메테우스만 지원한다.
그러나, KEDA는 redis, kafka, prometheus 등 다양한 자원의 메트릭을 직접 측정하고 오토스케일링할 수 있다.

프로메테우스 어댑터는 프로메테우스 에코 시스템과 쿠버네티스와 호환이 필요하기 때문에 KEDA 사용을 권장한다.

4. 메트릭 측정 및 중요성

1) 기존 성능 관리에서 중요한 메트릭

초당 처리량(Throughput): 단위 시간당 처리 가능한 요청의 수를 측정하며, 시스템의 전반적인 처리 성능을 평가하는 핵심 지표이다.
처리 지연 시간(Latency): 요청이 완료되는 데 걸리는 시간
- 사용자 경험 측면에서도 중요한 지표

2) 메트릭 활용

초당 요청 수나 지연 시간을 기반으로 애플리케이션 확장 여부를 판단한다.
사용자 경험을 개선하기 위해 단순한 처리 속도뿐 아니라 안정적이고 예측 가능한 성능 제공이 중요하다.

3) 메트릭 선정

측정하고자 하는 메트릭을 식별했으면 부하 테스트를 거쳐 검증한다.

스트레스 테스트를 진행하면서 메트릭 증감을 모니터링 해야 한다.

# 스트레스 테스트 시 활용할 수 있는 명령어
kubectl top pod
kubectl top node

4) 지연 시간 분석 사례

히스토그램을 활용하여 지연 시간을 시각적으로 분석하면 성능 문제를 명확히 파악할 수 있다

첫 번째 사례: 오토스케일링 불필요
- 0.1초 이내에 60% 처리
- 0.25초 이내에 30% 처리
- 0.5초 이내에 8% 처리
- 1초 이내에 2% 처리
  → 이 경우 대부분의 요청이 0.25초 이내에 처리되므로, 오토스케일링 없이도 안정적인 성능을 유지할 수 있다.
두 번째 사례: 오토스케일링 필요
- 0.1초 이내에 30% 처리
- 0.25초 이내에 25% 처리
- 0.5초 이내에 20% 처리
- 1초 이내에 15% 처리
  → 시간대별로 처리량의 차이가 크지 않으므로, 오토스케일링을 적용하여 지연 시간을 최소화하는 것이 필요하다.

5. 관측 가능성 프로세스

1) 운영 프로세스

정상 상태:
- 메트릭 분석 → 추적 분석 ↔ 로그 분석
  → 성능 및 안정성을 유지하기 위해 지속적인 분석이 이루어져야 한다.
장애 발생 시:
- 장애 발생 → 알람 전송 → 추적 분석 → 로그 분석
  → 빠른 장애 대응을 위해 명확한 프로세스 설정이 중요하다.

2) AIOps 활용

최근에는 AI 기반 운영(AIOps) 기술이 도입되고 있다.
- 주요 효과: 불필요한 비용 절감 및 운영 업무 효율성 향상.
- AIOps는 메트릭 분석 자동화와 장애 예측에 유용하다.

6. 수평 샤딩 (Horizontal Sharding)

샤딩 개념

데이터베이스를 여러 분할된 단위(Shard)로 나누는 방식이다.
→ 시스템 확장성, 성능 향상, 안정성 강화에 유리하다.

관측 가능성에서 샤딩 활용

그라파나(Grafana) 기반 관측 가능성 도구:

주요 도구: 미미르(Mimir), 템포(Tempo), 로키(Loki)
프로메테우스(Prometheus) 기반으로 설계
읽기와 쓰기 작업을 분리하여, Ingester, Distributor, Querier, Query Frontend로 구성
개별 샤딩 구성이 가능해 확장성과 유연성을 제공

유사 기술 사례

카프카(Kafka), 레디스(Redis), 카산드라(Cassandra), MongoDB 등에서도 비슷한 개념을 활용한다.
→ 이러한 기술은 대규모 데이터 처리 및 클러스터 운영에서 높은 효율성을 제공한다.