대규모 로그 처리 by Elasticsearch 클러스터

[참고](https://toss.tech/article/slash23-data)

토스증권이 Elasticsearch 클러스터로 대규모 로그를 처리하는 방법을 살펴보자

 

로그 수집 현황

서비스와 인프라에서 피크 시간에 초당 200만 이상의 인덱싱, 하루 기준 170억 건의 로그를 처리

Elasticsearch 클러스터는 커질수록 공간롸 관리 부담이 있어서 효율적인 관리가 필요

 

안정적인 Elasticsearch

Hot-warm 아키텍처 도입

효율적인 Elasticsearch 클러스터를 위해 Hot-warm 아키텍처 도입

Hot-warm 아키텍처

• Hot 노드보다 큰 Warm 노드를 생성
• 생성된 지 오래 된 로그는 Warm 노드로 이동, 일정 기간이 지나면 삭제
• 최근 로그를 더 오래 보관하고 싶으면 Hot 노드 증설
• 전체 로그를 더 오래 보관하고 싶으면 Warm노드만 증설

 

fielddata 옵션

• 문제 상황
  • 매우 많은 fielddata 메모리 사용
  • 매우 긴 가비지 컬렉션

• 원인
  • 인덱스 매핑에서 일부 필드 설정에 fielddata 옵션 잘못해서 문제 발생한 것
  • 필드에 대해 aggregation과 정렬을 하기 위해서 필드의 값들을 fielddata라는 메모리 영역으로 올려서 메모리, JVM이 부족했던 것임

• 해결
  • 파일 시스템을 사용하고 컬럼 기반인 Doc value 스토리지 도입해서 힙 메모리를 덜 사용하고 운영체제 레벨 캐시를 사용하는 방향으로 해결

 

인덱스 매핑

인덱스 매핑이 비효율적으로 정의되어서 느려지고 불안정해져서 확인이 필요

• 인덱스에 너무 많은 필드들이 매핑 되어있는지 확인
• fielddata 옵션능 사용하는 필드가 있는지
• default dynamic mapping을 사용하고 있는지 점검

Elasticsearch는 명시적인 설정을 하지 않는다면 json의 형태 그대로 인덱싱을하고 동적으로 인덱스 매핑을 업데이트함

• json에 key가 많다면 mapping explosion 발생
• 마스터 노드가 클러스터 상태를 업데이트하고 관리하는 데 리소스를 매우 많이 사용함
  • 어쩔수 없이 임의의 구조로 가진 데이터를 인덱싱 해야한다면 flattened type를 사용
  • dynamic filed를 false로 설정 : 명시적으로 매핑한 필드만 인덱싱 됨

 

적절한 샤드 갯수

프라이머리 샤드 갯수와 Hot 노드수의 배수로 설정 : 샤드가 특정 노드에 쏠리면 안되므로

 

Vector 로그 파이프라인 전환

• Logstash 대신 Vector로 로그 파이프라인 사용하는 이유
  • Logstash 단점
    • JVM 기반이라서 리소스를 많이 먹음
  • Vector 장점
    • Rust 기반 경량 log shipper
    • 높은 워크 로드 환경에서 리소스 효율적으로 로그 파이프라인 운영
    • prometheus exporter로 모니터링 쉽게 구현 가능
    • 시스템 자원 절약(260GB -> 10GB)

 

여러 데이터센터 간 클러스터링

• 사용한 이유
  • 서로 데이터센터 간 클러스터링은 비추
  • 네트워크 레이턴시가 높으면 성능이 낮아지므로 가까우면 ㄱㅊ다고 생각
  • 로그 수집 분석이라서 지연보다는 비용절감이 더 중요했음

• 방법
  • Elasticsearch 클러스터 전용회선 별도 구축
  • replica shard는 서로 다른 IDC에 저장하도록 구성
  • 각각의 IDC에 마스터 노드 1개씩 배치, AWS에 투표 전용 마스터노드 배치
    • IDC1 + IDC2 + AWS
    • DCI 단절 시 발생할 수 있는 split brain 방지 가능
  • shard awareness를 설정
    • 데이터센터가 장애가 발생했을 때 데이터 유실을 방지하기 위해서
    • primary shad와 replica shard가 서로 다른 IDC에 배치되도록 함
  • force awareness 를 설정
    • 일시적 DCI 장애 시 샤드 복제가 과도하게 일어나는 것을 방지하기 위해
    • IDC1과 IDC2의 데이터 노드들이 클러스터에 합류했을 때만 샤드 배치가 일어나도록 함
  • 전송계층에서 인덱싱 데이터에 대해 압축 설정
    • 전송시 발생하는 네트워크 대역폭 크게 줄일 수 있음

• 결과
  • 데이터센터 장애에도 견딜 수 있는 Elasticsearch 운영 가능

• 과정
  • DCI간 네트워크 발생 -> 투표전용 마스터 노드 투표로 IDC1 or IDC2의 마스터노드 선출 -> 그 구역 노드들만 클러스터에 남음 -> DCI 해결되면 다시 클러스터에 합류