[엘라스틱 스택 8] 데이터 수집과 인제스트

모든 종류의 데이터에 대한 확장 가능한 검색 엔진이자 분석 엔진인 엘라스틱서치, 엘라스틱서치 데이터를 효과적으로 탐색하고 사용할 수 있게 해주는 인터페이스 키바나를 협업할 수 있도록 해주는 결정적인 기능이 인제스트(ingest)이다.

비츠를 활용해 환경 전반에서 데이터 수집하기

비츠는 경량 애플리케이션(에이전트)로, 여러 유형의 데이터를 수집해 엘라스틱서치나 로그스태시, 카프카 같은 수신처로 전송할 수 있다.

• 파일비트(Filebeat): 로그 데이터 수집
• 메트릭비트(Metricbeat): 메트릭 데이터 수집
• 패킷비트(Packetbeat): 네트워크 패킷 메타데이터의 수집과 디코딩
• 하트비트(Heartbeat): 시스템/서비스 가동 시간과 지연 데이터 수집
• 오딧비트(Auditbeat): OS 감사 데이터 수집
• 윈로그비트(Winlogbeat): 윈도우 이벤트와 애플리케이션, 보안 로그 수집
• 펑션비트(Functionbeat): AWS Lambda 같은 서버리스 컴퓨팅 인프라에서 데이터 수집을 수행

비츠는 립비트(Libbeat)라는 오픈소스 라이브러리를 사용한다. 립비트는 입력 데이터와 출력 데이터의 목적지를 구성하는 범용 API를 제공한다. 비츠는 특정 데이터 유형(ex. 로그나 메트릭)에 맞는 데이터 수집 기능을 구현한다.

비츠 모듈과 엘라스틱 공통 스키마

사용 가능한 비츠 모듈을 일관된 데이터 세트를 수집해 즉시 사용 가능한 대시보드와 머신러닝 작업, 경보로 보내는 유스케이스에 활용할 수 있다.

통합 데이터 모델의 중요성

중앙집중식 로깅 플랫폼으로 데이터를 인제스트할 때의 가장 중요한 측면은 사용 중인 데이터 형식에 주의를 기울이는 것이다. **통합 데이터 모델(Unified Data Model; UDM)은 특히 유용한 도구로, 일단 데이터가 로깅 플랫폼으로 인제스트되면 최종 사용자가 데이터를 쉽게 사용할 수 있다.

• 로그를 생성하는 애플리케이션에 대해 사내 로깅 표준 또는 사양을 적용
  • 구현과 유지 관리, 확장에 상당한 비용 발생
  • 소스에서 로그 스키마 변경시 데이터를 사용하는 다른 애플리케이션의 다운스트림에 의도하지 않게 영향을 미칠 수 있음
  • 수집된 로그의 특성과 내용에 따라 UDM이 상당히 빠르게 진화
  • 다양한 기술 스택과 프레임워크를 사용하는 조직에서는 환경 전반에 걸쳐 일관성과 통일성을 가지고 로깅하는 것이 어려움
• UDM을 준수하기 위해 로그스태시와 같은 ETL 도구를 사용해 수신 데이터의 필드를 변환 또는 이름을 변경
  • 로깅 형식 및 스키마를 개정할 때 초기 비용을 상당히 절감 가능
  • 로그를 올바르게 추출하고 저장하도록 구문 분석기를 관리하고 지속 업데이트해야 함
  • 대부분 구문 분석 작업은 셀프 서비스 또는 데브옵스 스타일의 운영 모델을 따르기보다는 조직의 중앙 기능에서 수행(또는 감독)해야 함
    • 중앙집중식으로 변환하므로

엘라스틱 공통 스키마 (Elastic Common Schema; ECS)

엘라스틱에서 설정한 통합 데이터 모델

• 필드에 대한 엘라스틱 인덱스 매핑을 설정
  • 메트릭 집계와 범위가 데이터에 올바르게 적용될 수 있게 하므로 중요
  • 네트워크 요청의 일부로 수신한 바이트의 수와 같은 숫자 필드는 정수 값으로 매핑해야 함
  • 데이터를 시각화할 때 특정 기간 동안 수신한 총 바이트 수를 합산할 수 있음
  • HTTP 상태 코드 필드는 시각화 단계에서 애플리케이션에서 발생한 500개의 오류 수를 계산할 수 있게 키워드로 매핑
• 데이터가 ECS와 호환되는 경우 대시보드, 시각화, 머신러닝 작업, 경보와 같은 즉시 사용 가능한 콘텐츠를 활용할 수 있음
  • 오픈소스 커뮤니티에서 콘텐츠를 사용하고 공유가능
• ECS 사양에 정의된 명명 규칙에 따라 ECS에 사용자 정의 필드 또는 내부 필드를 추가할 수 있음.
  • ECS 사양에 있는 필드만 사용할 필요는 없음

비츠 모듈

• 지원되는 다양한 데이터 소스의 로그와 메트릭을 ECS 호환 스키마로 자동 변환
• 로그와 메트릭을 즉시 사용 가능한 대시보드, 머신러닝 작업, 경보로 전송
• 새로운 데이터 소스를 엘라스틱서치에 매우 쉽게 온보딩할 수 있음

대규모 데이터 소스의 온보딩 및 관리

새로운 데이터 소스를 온보딩하려면 구성 파일을 업데이트 후 이 파일을 적합한 호스트 시스템에 배포해야 한다. 엘라스틱 에이전트(Elastic Agent)는 사용 환경에서 로그, 메트릭, 가동시간 데이터를 수집하는 데 사용할 수 있는 단일 통합 에이전트이다. 엘라스틱 에이전트는 핵심 비츠 에이전트를 내부적으로 조정하므로 하나의 에이전트 관리마능로 배포와 구성 프로세스를 간소화한다.

Fleet Server라는 컴포넌트와 함께 작동해 에이전트와 에이전트가 수집하는 데이터의 지속적인 관리를 단순화할 수 있다. Fleet을 사용해 추가 관리 작업 없이 중앙에서 정책을 내려 보내 데이터 수집을 제어하고 에이전트 버전 업그레이드를 관리할 수 있다.

로그스태시를 활용한 중앙집중식 데이터 추출, 변환, 로드

비츠는 새로운 데이터 소스를 매우 편리하게 온보딩할 수 있지만, 성능 측면에서 가볍게 설계되었다. 비츠 자체로 대량의 처리, 변환, 보강 기능을 제공하지 않는다. 이 경우 로그스태시를 도입해 수집 아키텍처를 지원한다.

로그스태시는 다양한 소스 시스템/통신 프로토콜의 데이터를 입력하도록 설계된 범용 ETL 도구이다. 입력 데이터를 필터 세트를 통해 처리하며, 필요한 경우 이 과정에서 필드를 변경하거나 추가, 보강, 제거할 수 있다. 최종적으로 이벤트를 여러 대상 시스템으로 전송할 수 있다.

비츠와 로그스태시 중 어떤 것을 사용할지 결정하기

비츠를 사용하는 경우

• 환경 전반에 걸쳐 수많은 호스트 또는 시스템에서 데이터를 수집해야 하는 경우
  • 수백 개의 웹 서버로 구성된 동적 그룹에서 웹 로그를 수집
  • 쿠버네티스 같은 컨테이너 오케스트레이션 플랫폼에서 실행되는 다수의 마이크로서비스에서 로그 수집
  • 클라우드/온프레미스에서 실행되는 MySQL 인스턴스 그룹에서 매트릭 수집
• 사용 가능한 비츠 지원 모듈이 있는 경우
• 엘라스틱서치에서 데이터를 사용하기 전에 대량의 변환/처리를 수행할 필요가 없는 경우
• 웹 소스에서 데이터를 사용하는 경우 단일 비트 인스턴스에 대해서는 확장/처리량을 걱정할 필요 없다

로그스태시를 사용하는 경우

• 중앙 집중화된 장소에서 대량의 데이터를 소비하고 인제스트 처리량을 확장할 수 있어야 하는 경우
  • ex. 파일 공유, AWWS s3, 카프카, AWS kinesis
• 대량의 데이터를 변환하거나 복잡한 스키마/코덱을 구문 분석해야 하는 경우
  • 특히, 정규표현식이나 Grok을 사용하는 경우
• 여러 로그스태시 인스턴스 간에 인제스트 로드 밸런싱을 수행할 수 있어야 하는 경우
• 사용 가능한 비츠 지원 모듈이 없는 경우

비츠 에이전트는 릴리스마다 지속해서 업데이트되고 향상된다. 로그스태시와 비츠의 기능 간 격차는 상당히 좁혀졌다.

비츠와 로그스태시를 함께 사용하기

• 비츠와 로그스태시를 둘 다 활용해 각각의 좋은 점만 취하는 것도 일반적
• 다양한 소스에서 데이터를 수집(비츠)하는 동시에 이벤트의 중앙집중식 처리와 변환이 가능합니다.(로그스테시)