본문 바로가기
ML & DL/[NLP] LLM

[ELK] 개념 및 구조

by IT손흥민 2024. 7. 17.

     


    Architecture

    Elasticsearch + Logstash + Kibana

    • Logstash로 데이터를 수집
    • Elasticsearch는 수집된 데이터의 db역할. 인덱싱
    • Kibana를 통해 그래프 형태로 표현

     

     

     

    Elastic search

    • Apache Lucene 기반의 오픈소스 실시간 분산 검색 엔진
    • 검색엔진: 사용자가 특정 키워드나 검색어를 입력하면 데이터 소스에서 정보를 검색할 수 있도록 설계된 서비스
    • 검색엔진 종류: elasticsearch, solr, amazon cloudsearch, microsoft azure search
    • RDBMS 처럼 테이블을 만들고 각 필드를 정의하지않고 자동으로 document 분석 후 스키마 동적으로 생성
    • RESTfule API를 지원하며 URI를 사용한 동작이 가능
    • JSON 기반의 문서 구조 사용하여 데이터 색인, 쿼리 언어를 통해 검색 및 분석 가능
    • Apache Lucene은 Inverted File Index(역인덱스) 활용하여 색인 구조 생성

     

    • 역인덱스

    • 일반적인 인덱스는 docID와 내용을 매핑. 역인덱스는 어떤 내용이 몇번 문서에 담겨있는지 보여줌
      다량의 데이터를 신속하게 색인하고 검색할 수 있도록 설계
    • 데이터가 추가되더라도 행이 늘어나는 것이 아니라 역 인덱스가 가리키는 id의 배열이 늘어나는 것이므로 큰 속도저하가 일어나지 않음. 이런 과정을 저장이 아닌 색인이라고 표현함
    • 역인덱스를 사용하여 데이터를 더 빠르게 찾을 수 있음

     


    Elasticsearch 물리적 구조

    • 이미지 좌측처럼 단일 노드로 구성되어 있으면 노드에 문제 발생시 서비스 전체 shut down
    • 여러대의 노드로 구성된 클러스터 구조라면 일부 노드에 장애가 발생되어도 나머지 노드로 클러스터 구조를 유지해 서비스 운영할 수 있음. 안정성 보장

     

    • 보통 3개 이상의 node(elastic서버)를 클러스터로 구성
    • 데이터를 shard로 저장시 클러스터 내 다른 호스트에 복사본(replica)를 저장해 놓기 때문에 하나의 노드가 죽거나 샤드가 깨져도 복제되어있는 다른 샤드를 활용할기 때문에 데이터 안정성 보장
    • 데이터 분산과 병렬처리가 되므로 실시간 검색 및 분석 가능.
    • 노드를 수평적으로 늘릴 수 있게 설계되어 있으므로 더 많은 용량이 필요할 경우 노드 추가 가능
    • elasticsearch는 동작 중 일부 노드에 문제가 생기더라도 문제 없이 서비스 제공
    • RDBMS같은 스키마 개념이 없으며 데이터 인덱싱을 사용자가 커스터 마이징 가능
    • 클러스터
      • 전체 데이터를 저장하고, 모든 노드를 포괄하는 통합 색인 화 및 검색 기능 제공
      • 가장 큰 시스템 단위. 최소 1개 이상의 노드로 이루어진 노드들의 집합
      • 대용량 데이터의 증가에 따른 스케일 아웃과 데이터무결성을 유지하기 위한 클러스터링
    • 노드
      • 클러스터에 포함된 단일 서버
      • 데이터를 저장하고 클러스터의 색인화 및 검색기능
      • 개발 및 테스트에는 싱글 노드에서 모든 역할 수행이 가능하지만 실제 운영에서는 다수의 노드를 각각 목적에 맞게 설정해 운영하는 것이 좋음
      • 엘라스틱 서치에서 제공하는 노드
        1. 마스터 노드
          클러스터 관리 노드
          노드 추가/제거, 인덱스 생성/삭제 등 클러스터의 전반적 관리 담당.
          node.mastre:true
        2. 데이터 노드
          데이터가 저장되는 노드
          (데이터를 분산 저장하는) 샤드가 배치되는 노드
          색인/검색/통계 등 데이터 작업 수행(리소스 많이 필요. 모니터링 필수)
          마스터와 분리 필요
          node.data:true
        3. 코디네이팅 노드
          사용자의 요청을 받고 라운드로빈 방식으로 분산시켜주는 노드
          클러스터 관련된 것은 마스터 노드로 넘기고 데이터 관련은 데이터 노드로 넘김
          elasticsearh.yml 내부의 노드 종류 관련 옵션 모두 false
        4. 인제스트 노드
          문서 전처리 작업 수행
          인덱스 생성 전 문서의 형식 변경을 다양하게 할 수 있음
          node.ingest:true
    • 샤드

    • 인덱스에 색인되는 문서들이 저장되는 논리적인 공간
    • 인덱스 내부에는 색인된 데이터들이 존재. 이 데이터를 물리적 공간에 여러개 부분들로 나뉘어서 존재.
      이것을 샤드(Shard)라고 함.
    • 인덱스가 각 노드에 저장될 때 분리되는 단위
    • 인덱스를 여러 샤드로 나누어 저장하기에 콘텐츠 볼륨의 수평 분할/확장 가능, 작업을 여러 샤드에서 수행하기에(병렬화) 성능/처리량을 늘릴 수 있음
    • 원본 데이터와 백업용 복제 데이터의 개념으로 이해하면 쉬움

    • 동일한 데이터를 포함하는 프라이머리, 레플리카는 같은 노드에 존재할 수 없게 설정되어 잇음
    • 클러스터 상태는 green/ yellow / red
      green: 프라이머리 샤드, 레플리카 샤드 모드 안정적
      yellow: 프라이머리 샤드는 온전하나, 레플리카 샤드 배치 불가
      red: 프라이머 샤드 1개 이상 유실된 상태
    1. 프라이머리 샤드(Primary Shard)
      데이터 원본
      개수는 최소 인덱스를 생성할 때 설정 후 변경 불가 (레플리카 샤드는 변경 가능)
      엘라스틱 서치에 데이터 업데이트 요청을 날리면 반드시 프라이버 샤드에 요청하게 되고 해당 내용은 레브리카에 복제된다. 검색 성능 향상을 위해 클러슽 샤드 갯수 조정 튜닝을 함
    2. 레플리카 샤드(Replica Shard)
      프라이머리 샤드 복제본
      원본데이터가 무너졌을 때 장애 극복 역할
      기본적으로 프라이버리 샤드와 동일한 노드에 배정되지 않음

     

    •  
    • 세그먼트

    • 샤드의 데이터를 실제로 가지는 물리적 파일
    • 샤드는 다수의 세그먼트로 이루어져 있음
    • 엘라스틱 문서의 빠른 검색을 위해 설계된 자료 구조

     

    Elasticsearch 논리적 구조

    index_definition = {
        "settings": {
            "number_of_shards": 1,
            "number_of_replicas": 1,
            "analysis": {
                "analyzer": {
                    "default": {
                        "type": "standard"
    	                }
                }
            }
        },
        "mappings": {
            "properties": {
                "Name": {
                    "type": "text",
                    "analyzer": "standard"
                },
                "Synopsis": {
                    "type": "text",
                    "analyzer": "standard"
                },
                "synopsis_vector": {
                "type": "dense_vector",
                "dims":  768,
                "index": True,
                "similarity": "l2_norm",
                "index_options": {
                    "type": "hnsw",
                    "m": 16,
                    "ef_construction": 100
                }
            }
        }
    }}
    • Document
      • 엘라스틱서치 최소 단위
    • Type
      • 7.0부터 사라짐
      • 여러개의 도큐먼트가 모여서 한개의 타입을 이룸
      • 현재 Index가 RDBMS의 테이블과 데이터베이스 역할을 한다고 생각하면 됨
    • Field
      • document에 들어가는 타입으로 RDBMS의 열과 비슷
      • RDMBS는 하나의 열이 하나의 데이터 타입만 가질 수 있지만 하나의 Field는 여러개 데이터 타입 가능
    • Mapping
      • 필드와 필드의 속성을 정의하고 색인방법 정의
    •  
    • Index

    • 여러개의 (비슷한 특성을 가진)도큐먼트가 모여 하나의 Index를 이룸 (RDMBS의 database와 비슷)
    • RDMBS는 쿼리하나로 여러 데이터 베이스 데이터를 조회할 수 없지만 elasticsearch는 가능함(멀티테넌시)
    • 엘라스틱서치를 클러스터(분산환경)으로 구성했을 경우 index는 여러 노드에 분산 저장/관리 됨
    • 기본 설정은 5개의 프라이머리 샤드, 1개의 레플리카 샤드로 생성 (변경 가능)



    Logstash

     

    • 파이프라인 환경은 yaml 파일을 통해 수정
    • 로그스태시 플러그인 리스트
    Input
      - Files
      - Syslog
      - SQL Queries
      - HTTP request
      - Elasticsearch
      - Beats
      - Metrics systems
      - And More..
    
    Filter
      - log 파싱
      - 데이터 확장
      - 태그 추가
      - And More..
    
    Output
      - Elasticsearch
      - Data 보관소 (ex : Amazon S3)
      - Alterting & Monitoring system
      - And more..
    • 파이프라인 설정은 3단계로 구성

    input

    • 모든 소스, 사이즈 및 형태의 데이터를 수집
      다양한 입력(Filebeats, Rebbitmq, Redis, Salesforce)을 지원하여 여러 소스로부터 로그 수집 가능
    • file : 리눅스의 tail -f 명령처럼 파일을 스트리밍하며 이벤트를 읽어 들인다.
    • syslog : 네트워크를 통해 전달되는 시스로그를 수신
    • kafka : 카프카 토픽에서 데이터를 읽어드린다
    • jdbc: JDBC 드라이버로 지정한 일정마다 쿼리를 실행해 결과를 읽어들인다

     

    Filter

     

    • 데이터를 원하는 형태로 가공
    • grok : grok 패턴을 사용해 메시지를 구조화된 형태로 분석한다. grok 패턴은 일반적인 정규식과 유사하나, 추가적으로 미리 정의된 패턴이나 이름 설정, 데이터 타입 정의 등을 도와준다.
      • NUMBER | 십진수 인식
      • SPACE | 스페이스, 탭 등 하나 이상의 공백 인식
      • URI | URI 인식
      • IP | IP 주소 인식
      • SYSLOGBASE | 시스로그의 일반적인 포맷에서 타임스탬프, 중요도, 호스트, 프로세스 정보까지 메시지 외의 헤더 부분 인식
      • TIMESTAMP_ISO08601 | ISO08601포맷의 타임스탬프 인식 (2020-02-02T12:00:00+09:00와 같은 형태)
      • DATA | 이 패턴의 직전 패턴부터 다음 패턴 사이 인식
      • GREEDYDATA | DATA타입과 동일하지만 표현식의 가장 뒤에 위치시킬경우 해당 위치부터 이벤트 끝까지 값으로 인식
    • dissect : 패턴을 사용해 메시지를 구조화 된 형태로 분석. 정규식을 사용하지 않아 grok에 비해 자유도는 조금 떨어지지만 더 빠른 처리 가능.
    • mutate : 필드명을 변경, 문자열 처리 등 일반적인 가공 함수들을 제공
      • split | 쉼표 공백 같은 구분 문자를 기준으로 문자열을 배열로 나눔
      • rename | 필드이름을 바꿈
      • replace | 해당 필드값을 특정값으로 바꿈
      • uppercase | 문자를 대문자로
      • lowercase | 문자를 소문자로
      • join | 배열을 쉼표같은 구분 문자로 연결해 하나의 문자열로 합
      • gsub | 정규식이 일치하는 항목을 다른 문자열로 대체
      • merge | 특정 필드를 다른 필드에 포함
      • coerce | null인 필드값에 기본값을 넣음
      • strip | 필드값의 좌우 공백 제거
      • date : 문자열을 지정한 패턴의 날짜형으로 분석한다.
      • add_field | 새로운 필드 추가
      • add_tag | 성공한 이벤트에 태그 추가
      • enable_metric | 메트릭 로깅 활성화 또는 비활성화
      • id | 플러그인의 아이디 설정
      • remove_field | 필드 삭제
      • remove_tag | 성공한 이벤트에 붙은 태그 제거

    Output

    • 처리한 로그 전송
    • elasticsearch: bulk API 사용해 엘라스틱 서치에 인덱싱 수행
    • file: 지정한 파일의 새로운 줄에 데이터 기록
    • kafka: 카프카 토픽에 데이터 기록
    input {
      file {
        path => "/Users/soojung/Company/Project/Work/docker-elk/logstash/input/kdrama.csv"
        start_position => "beginning"
      }
    }
    
    filter {
    }
    
    output {
      elasticsearch {
        hosts => "elasticsearch:9200"
        user => "logstash_internal"
    	password => "${LOGSTASH_INTERNAL_PASSWORD}"
        index => "kdrama"
      }
      stdout {
        codec => rubydebug
      }
    }

     

     

     

    Kibana

     

    • Management - Index Management
    • 인덱스 확인

     

    댓글