본문 바로가기

Data Engineering/ELK

[ELK] 개념

1. 개념

이번 장에서는 ELK란 무엇인가에 대해서 알아보도록 한다.


Elastic 공식문서에 따르면 검색, 해결 및 성공을 지원하는 검색 플랫폼이라고 되어 있다.

“ELK”는 Elasticsearch, Logstash 및 Kibana 3개의 오픈 소스 프로젝트의 첫글자를 따서 만들어졌다.

EKS는 데이터를 추출할 수 있는 어떠한 소스에서나 데이터를 안정적으로 추출하여 실시간 검색, 분석, 시각화를 도와준다.

Elasticsearch

Elasticsearch는 Apache Lucene 검색 엔진을 기반으로 하는 오픈 소스로 JSON 기반의 분산형 오픈 소스 RESTful 검색 엔진으로, 사용이 쉽고 확장이 용이하다. 특히 대규모 데이터를 분석하기 위한 목적으로 만들어진 만큼 빠르게 저장, 검색, 분석을 할 수 있게 해준다.


Logstash

Logstash는 Elasticsearch가 추출해야 하는 데이터를 쌓아주는 역할을 한다.

Logstash는 실시간 파이프라이닝 기능을 갖춘 오픈 소스 데이터 수집 엔진으로 서로 다른 소스의 데이터를 동적으로 통합하고 선택한 대상으로 데이터를 정규화할 수 있다. 다양한 다운스트림 분석 및 시각화 사용 사례를 위해 모든 데이터를 정리한다.

원래 로그를 수집하는 용도로 개발되었지만 현재는 로그뿐만 아니라 다양한 목적으로 사용되고 있다. 다양한 입력, 필터 및 플러그인으로 모든 유형의 이벤트를 변환할 수 있기 때문에 데이터를 수집하는 프로세스를 단순화 한다.


Kibana

Kibana는 Elasticsearch로 추출한 데이터를 시각화하고 ELK Stack을 탐색하는 역할을 한다.

로그 분석, 보안 취약성 찾기 등 수많은 기능을 통해서 데이터를 검색, 관찰 및 보호한다.

Elasticsearch를 통해 얻을 수 있는 데이터를, 차트, 게이지, 지도, 그래프등으로 시각화하여 대시보드와 결합하여 사용자가 손쉽게 데이터를 분석할 수 있게 해준다.

데이터를 관리하는 것 뿐만 아니라 ELK Stack 클러스터의 상태를 모니터링하는 역할을 한다.


Beats

이전부터 ELK를 사용하던 사용자들의 “파일을 추적하고 싶다”라는 니즈를 충족시키기 위해 2015년 Beats가 도입되었다. Beats는 ELK Stack에 경량의 단일 목적 데이터를 수집하는 제품이다.

로그 파일, 메트릭, 네트워크 데이터와 같은 모든 유형의 데이터를 수집할 수 있으며 수집된 데이터를 Logstash나 Elasticsearch에게 전송하는 역할을 한다.


데브시스터즈 Data Platform Group 사용 사례

지금까지 ELK Stack에 무엇이 있고 어떤 역할을 하는지에 대해서 알아보았다.

한 문장으로 정리해 보면, “Logstash나 Beats를 통해서 모든 종류의 소스에서 다양한 데이터를 가져오고, Elasticsearch를 통해 데이터를 분석할 수 있으며, Kibana를 통해 시각화할 수 있다.” 정도가 될 듯하다.

대략 무엇인지는 알겠는데 어디에 어떻게 사용해야 할지 감이 오지 않는다. (사람마다 다를 수 있겠지만 적어도 필자는 그렇다.) 지금부터 데브시스터즈의 데이터 플랫폼 팀이 서비스에 ELK를 어떠한 방식으로 녹여넣었는지 알아보도록 한다.

데브시스터즈 로깅 플랫폼에서 생산/수집하는 다양한 로그에는 아래와 같은 종류가 있다.

  • 액세스 로그: 어떤 주체(ex. 유저, 다른 서버)로 부터의 접근/응답 기록
  • 유저 CS 대응용 로그: 결제, 재화 지급 등 유저로 부터의 CS 요청에 대응하기 위한 로그
  • 분석 로그: 제품의 핵심 성과 지표(KPI)를 비롯해 제품의 분석을 위해 남기는 로그
  • 애플리케이션 로그: 서버 또는 클라이언트에서 디버깅, 운영 등의 목적으로 남기는 로그
  • 감사(audit) 로그: 운영툴, 인프라 작업 등 다양한 행동에 대한 감사 로그

아래는 로그의 예시를 보여준다.

{
    "timestamp": "2020-10-15T18:25:53.342+90:00",
    "logType": "access",
    "level": "info",
    "messageId": "AAAAAAA~ ...",
    "userId": "ABCDE1234",
    "requestMethod": "POST",
    "requestAPI": "/game/play/save",
    "request": {
        "stageId": "1-1",
        "character": { "id": 100100, "lv": 1 },
        "score": 12345,
        "playTime": 1000
    },
    "responseCode": "200",
    "response": {
        "responseType": "OK",
        "userInfo": { "coin": 52300, "exp": 20033 }
    }
}

대략적으로 하루에 누적되는 로그의 양은 아래와 같다.

  • 일일 로그 건수: 3억
  • 일일 로그 용량: 500GB
  • 로깅 플랫폼을 사용하는 서비스의 수: 6

대략적인 인프라 구성도는 아래와 같다.

대표적으로 EC2, 쿠버네티스에서 실행되는 Filebeat Agent를 통해서 로그를 수집한다.

여러 소스에서 수집되는 데이터는 카프카를 통해 Logstash와 Spark로 전달된다. Logstash로 전달된 데이터는 Elasticesearch에 인덱싱하고 최근 2주간의 로그를 저장하여 실시간 로그 조회, 검색, 분석에 이용한다.

Filebeat Agent

쿠버네티스 클러스터와 도커 컨테이너의 로그를 수집하기 위하여 Filebeat Agent를 사용한다. 지정한 로그 파일이 변경되면 추가(append)되는 메시지를 전송하는 기능을 가지고 있다.

Docker Input 설정을 살펴보면 input type은 도커로 설정되어 있고 타겟 컨테이너는 모든 컨테이너인 것을 알 수 있다.

processors를 확인해보면 도커의 메타데이터를 추가하는 것을 확인할 수 있고 이렇게 설정되는 경우 로그에는 도커컨테이너의 아이디와 같은 추가적인 정보가 포함되게 된다.

Filebeat Agent에서 로그 파일의 전처리를 해서 Logstash로 전달하는 것이 가능하다. 하지만 실행되고 있는 호스트에 부하를 유발할 수 있다.

만약 Filebeat에서 Elasticsearch로 바로 로그를 보내는 경우 Elasticsearch Ingest Node Pipeline을 사용하여 Elasticsearch 노드에서 전처리가 가능하다.

데브시스터즈의 경우 Kafka Streams를 통해 데이터 전처리를 진행하고 있다.

로그 전처리 전과 후는 아래의 이미지와 같다.

실제로 로그가 전달되는 순서는 아래의 이미지와 같다.

Logstash가 Kafka에서 전처리가 완료된 로그를 가져오고, Logstash는 전처리된 데이터에 로그가 생성된 일자를 기준으로 인덱싱하여 Elasticsearch로 로그를 전달한다.

이후 로그는 Elasticsearch에 저장되고 Kibana에서 조회할 수 있다.

사용 사례

  1. 서버 모니터링과 운영

  1. 실시간 게임 운영 대응 수단
    게임 디자이너도 Kibana를 통하여 손쉽게 게임의 현황 모니터링이 가능하다.
    어뷰징 유저, 패치 오류 신속대응이 가능하며, 이슈에 대해 영향을 받은 유저나 분포도 간편하게 확인이 가능하다.

  1. 실시간 지표 대시보드


참고 자료