관측 가능성 기반 기술

2.1 트래픽 관리

2.1.1 단일 장애점

• 시스템이나 네트워크 내에서, 해당 구성 요소가 실패하면 전체 시스템이나 서비스에 심각한 영향을 미치거나 전체적으로 작동을 멈출 수 있는 부분이다.
• 이를 해결하기 위해서는 고가용성 시스템을 구축하고 관측 가능성과 네트워크 트래픽 데이터를 통해 장애 원인 발견 및 대처가 중요하다. (그러나 관측 가능성은 시계열 데이터에 대해 많은 트랜잭션과 부하를 마주치기 때문에 장애가 발생할 가능성이 크다)

2.1.2 로드밸런서

• 안정적이고 탄력적인 네트워크 구축하기 로드밸런서가 필요하다.
• 플랫폼 로드 밸런서(ELB, nginx) -> 게이트웨이 -> 서비스
  • 플랫폼 로드 밸런서
    • 라운드 로빈 방식으로 사용자 트래픽 분산처리
  • 게이트웨이
    • API 게이트웨이
      • A/B 테스트, 카나리 등 배포 제공
      • 쿠버네티스과의 인그레스 기능
      • 프록시, 사이드카 패턴이 아니라 클라이언트 측 부하 분산에 비교해서 복원성 기능 부족
  • 클라이언트 측 부하 분산
    클라이언트 측 부하분산은 클라이언트 애플리케이션이 직접 서버 목록을 관리하고, 서버로의 요청을 분산하는 방식입니다. 이 방식은 클라이언트가 서비스 디스커버리 메커니즘을 통해 서비스 인스턴스의 위치와 상태 정보를 알아내고, 이를 바탕으로 요청을 분산합니다.
    • 이스티오
      이스티오는 서비스 메시(Service Mesh) 기술의 하나로, 마이크로서비스 간의 통신을 관리합니다. 이스티오는 각 마이크로서비스의 사이드카(Sidecar) 형태로 배포되는 프록시를 통해 트래픽을 제어하고, 서비스 간의 통신을 보안, 관찰 가능하며, 구성 가능하게 만듭니다.

2.1.3 복원성 패턴

서비스의 최초 진입점부터 트래픽을 전달할 인스턴스 선정까지 모든 과정을 모니터링하고 관리해야한다. 서비스 메시를 사용하면 네트워크 구간의 모니터링이 가능하고 복원성 패턴을 구현할 수 있다.

이스티오를 사용하여 FE, BE 로부터 컬렉터를 통해 관측 가능성 세 가지 요소(메트릭, 로그, 추적)을 가져오고, 서비스 메시를 통해 트래픽과 네트워크 로그도 가져온다.

복원성을 높이는 방법

개발 측면에서 타임아웃, 재시도, 예외 처리를 정의하거나 인프라 측면에서 서비스 메시 및 메시징을 사용한다.

• 재시도
  • 실패했을 때 다시 시도하는 방법
  • 단, 무분별하게 재시도하지 않도록 한다
  • 최대 재시도, 시간 간격 등 정책 필요
• 비율 제한
  • 인그레스, 게이트웨이 로드 밸런싱을 통해 들어오는 트래픽에 제한을 둠으로써 안정성을 높인다
• 벌크헤드
  • 다운스트림 서비스를 서로 격리하고 동시 처리 기능을 제한한다
  • 즉, 서비스 간 의존하게 되면 한 서비스가 먹통될 때 다른 서비스도 먹통될 수 있으므로 격리한다는 방식
  • 다운스트림이란?
    어떤 서비스 A에서 다른 서비스 B로 데이터를 요청하거나, 서비스 B의 기능을 호출할 때, 서비스 B는 서비스 A의 다운스트림 서비스이다
• 서킷 브레이커
  • 벌크헤드 패턴 확장 개념
  • 임계 비율 넘어갈 경우 회로를 열어 장애가 전파되지 않도록 하는것
  • 영화 추천 목록을 보여주는 서비스에서 특정 임계치를 넘어설 경우 추천이 아닌 일반 영화 목록(다른 서비스 또는 비교적 간단한 서비스)로 대체
    • 하위 서비스에서 특정 규칙에 의해 간단하게 반환값을 전달하는 것을 폴백이라 한다

2.1.4 가시성

어플리케이션 단의 관측 가능성을 보완하기 위해 인프라의 가시성을 단일한 시스템에 구축하는 것이 중요

2.1.5 서비스 메시

서비스 메시란 사이드카 등 프록시를 통해 서비스 간의 모든 네트워크 통신을 중재함으로써 개발자는 서비스 개발에만 집중하고 네트워크 관련해서는 프록시가 알아서 할 수 있도록 만든 인프라 계층이다

이스티오의 서비스 메시 단점

1. 이스티오는 서킷 브레이커보다는 벌크헤드 전략을 사용하기 때문에 타임아웃이 발생하면 통신을 끊어버리지만 인스턴스는 해당 요청을 계속 처리하고 있을 수 있다
2. YAML 수준 이상 정교하게 구성할 수 없다
   • 상세한 커널 수준의 서비스 메시를 구현하고 싶다면 eBPF 를 지원하는 실리움을 추천
3. 사이드카가 비싼 리소스이며, 이스티오의 내부 네트워크 처리과정이 다소 비효율적이다

2.2 쿠버네티스 오토스케일링

2.2.1 HPA

• 특정 메트릭을 보고 컨트롤러가 체크하여 부하에 따라 수평적으로 파드를 늘리거나 줄이는 방법이다.
• 표준 메트릭(CPU 사용률) 또는 사용자 정의 메트릭이 특정 임계값을 초과(또는 미만)한다면 파드 오토스케일러가 파드를 증가시키고 상황에 따라 노드 스케일러가 노드를 증가시킨다.
  • 추가로 drain, cordon, taint 명령어와 PDB, affinity 등 리소스 설정을 알아두면 유용하다
• 스케일 아웃보다는 인 과정에서 장애가 발생한다. 따라서 스케일 인에 대한 파라미터 세부 설정이 중요하다
• 사용자 정의 메트릭도 좋지만 복잡도가 높다면 표준 메트릭부터 시작하는 것을 권장한다

메트릭 서버

• 파드 -> kubelet -> 메트릭 서버 -> API server -> HPA
• 표준 메트릭 (컴퓨팅 자원 등)만을 지원

프로메테우스 어댑터

• 프로메테우스에서 사용하는 지표 지원
• 3장에서 다시 공부

KEDA

• 이벤트 기반 스케일링(예: 메시지 큐, 타이머, 이벤트 허브 등)
• 레디스, 카프카, 프로메테우스 등 자양한 자원 메트릭을 직접 측정하고 오토스케일링 가능

2.2.2 메트릭 측정

• 요청 수:
  • 어플리케이션 트래픽 패턴 (저녁시간 대 사람이 몰린다 등)
  • 예상한 트래픽 처리 가능한가?
  • 트래픽 요청들은 얼마나 성공적인가?
    => 서버 확장 여부
• 요청 기간:
  • 얼마나 걸렸는가
  • 각 서비스가 총 요청 기간에 소요 시간은 얼마인가?
  • 사용자 경험 측면은 어떻게 고려할 수 있는가?
    => 히스토 그램 등으로 표시하며 서버 상태 확인
• 동시 요청:
  • 병목현상 여부
  • 급증하는 요청 처리 가능?
    위 3가지를 통해 과연 우리 서비스는 한달에 얼마나 서버 유지비가 필요할까?

hpa 설정 주요 사항

• 메트릭 선택
  • 메트릭 값과 replica 개수 간 상관관계를 명확히 파악할 것
• 스래싱 방지
  • 파드가 초기화 될 때 높은 cpu 사용 제한하고 부하가 원활히 증가할 수 있도록
  • 또 스케일 다운 시에는 높은 권장 사항을 선택함으로써 사용량이 줄어드는 것을 방지
• 지연 반응
  • 지연이 없다면 기핟급수적으로 플랫폼 부하가 증가하고 스래싱도 증가할 수 있음
  • 변동/스래싱 방지를 위해 관련 매개변수 튜닝이 중요
• 쿠버네티스 훅 핸들러
  • 사용량을 고려하여 갑작스런 스케일 인을 피할 것
• HPA 설정
  • 단순 컴퓨팅 자원 뿐만 아니라 다른 고도화 지표도 적극 활용할 것

그라파나에서 주로 사용하는 메트릭

• request_duration_seconds_bucket = 처리시간(히스토그램)
• request_total = 총 요청 개수
• requre_duration_seconds = 수신한 http 요청 개수
• request_duration_seconds_count = 요청을 보낸 개수

2.3 관측 가능성 프로세스

2.3.1 관층 가능성 운영 프로세스

• 메트릭 분석 -> 추적 분석 <-> 로그 분석을 통해 장애가 없는 운영 프로세스 구축
  • SLI, SLO 등을 통해 알람 업무 규칙을 개발할 것
  • 메트릭과 추적은 중복성이 낮은(카디널리티가 높은) 태그를 최대한 사용할 것
    • 메트릭과 추적명을 일관성있게 유지할 것
  • 트래픽 증가 등으로 인해 지연이 발생한다며 해당 시간대의 트랜잭션을 확인하고 로그와 태그를 통해 상세히 분석한다
  • 로깅보다는 추적이 우선되어야 한다
    • 더 세부적인 정보가 많이 담겨있기 때문이다

2.3.2 관측 가능성 장애 프로세스

• 장애 발생 -> 알람 전송 -> 추적 분석 -> 로그 분석
  • 장애 확인 및 알람 발생
  • 일람을 생성한 주체(메트릭, 로그) 등에서 상세 내용 파악
  • 태그와 메타데이터가 포함된 추적을 통해 문제 파악 및 해결
    • 로그에서 상세한 분석에 도움을 받을 수 있다
    • 보통 성능 개선에 많은 도움을 준다

인공지능을 도입한 운영 프로세스는 다음과 같다

• 이상 탐지 -> 자동 복구 -> 필요 시 알람 전송 -> 운영자 개입
  • 여기서 중요한 것은 인공지능이 운영자를 대체하는 것이 아니라 불필요한 비용 절감 및 효율성을 꾀하는 점이다

2.4 수평 샤딩

프로메테우스로 개발된 그라파나는 다음과 같이 읽기와 쓰기 컴포넌트가 분리되어 있다

• 읽기 컴포넌트
  • 쿼리어
  • 쿼리 프런트엔드
• 쓰기 컴포넌트
  • 인젝스터
  • 디스트리뷰터

이러한 컴포넌트는 디플로이먼트로 전개되며 분리된 샤딩의 구성이 가능하다 (데이터베이스의 샤딩과 유사한 개념으로 구현되어 있다)
=> 로키같은 경우 이러한 샤딩 기술을 통해 대용량 시스템을 안정적으로 구축함 (단, 데이터를 균등하게 분배하기 위해 유명인사 문제 등 해결해야 함)