1. ELK
Elastic Search, Log Stash, Kibana를 아우르는 말.
통상적인 용도는 로그 분석, 문서 검색, 보안 정보 및 이벤트 관리(SIEM), 관찰성 등 광범위한 문제를 해결하는 데 사용
1) 용도 정리
전문 (full text)검색 엔진
전문 full text : 단순한 문장부터 뉴스 기사나 논문 등 다양한 글의 전체 내용을 의미
엘라스틱 서치의 기본적인 용도는 전문 검색 엔진의 구현이다. 일반 RDB에 비해 엘라스틱서치의 검색 성능이 좋은 이유는 전문 검색을 빠르고 정확하게 하기 위해 용어 term 단위로 분석해 인덱싱을해두고 이를 기반으로 검색을 수행하는 역인덱싱 inverted indexing 기법이 활용되었기 때문이다. 엘라스틱 스택에는 용어 분석을 위한 다양한 언어별 분석기가 있고, 유사도 스코어링을 위해 다양한 방법을 제공한다.
로그 통합 분석
엘라스틱서치는 로여러 장비와 서비스에서 발생하는 로그들을 통합하고 검색하는 데 최적화된 솔루션이다. 로그를 별도의 복잡한 구성없이 바로 수집할 수 있다. 비츠를 이용해 적은 리소스로 로그들을 수집하고, 로그스태시로 다양한 필터를 통해 일원화된 형태로 가공하고, 엘라스틱서치로 대용량 로그를 빠른 인덱싱과 텍스트 검색을 통헤 로그들을 통합해 연관 분석을 지원할 수 있다. 또 키바나로 로그 UI나 대시보드를 사용해 모니터링을 할 수 있다.
보안 이벤트 분석
엘라스틱 SIEM(Security Information and Event Mangament)은 비츠의 모듈을 이용해 애플리케이션, 엔드포인트, 인프라스트럭처, 클라우드, 네트워크 등 다양한 소스에서 수집한 이벤드를 기반으로 엔드포인트 활동, 인증 로그, DNS 트래픽, 네트워크 플로우에서 이상 징후, 불법 로그인 시도, 사용자 접근 패턴 등의 문제를 빠르게 찾아낸다. 또한, SIEM UI에서 분석을 비롯한 고유한 탐지 규칙 또한 가능하다.
애플리케이션 성능 분석
엘라스틱 스택의 성능 모니터링 도구 APM, Application Performance Monitoring 은 프로그래밍 언어별 에이전트를 통해 성능 지표 수집을 돕고 분석을 위한 UI를 제공한다. 또한, 메트릭 비츠와 패킷 비츠를 사용해 시스템을 비롯해 연계된 다양한 서비스들의 성능 정보를 수집할 수 있게 도와준다. 이 기능은 다른 UI나 머신러닝 등의 기능과 연계하면 효과가 배가 된다.
머신러닝
엘라스틱 유료 라이선스를 구매할 경우 머신러닝 기능을 제공한다. 데이터를 엘라스틱 서치에 저장한 후 비지도 학습을 통해 데이터에서 패턴을 발견할 수 있고, 시계열 모델을 통해 이상 징후를 탐지하고 과거 데이터를 기반으로 동향을 예측하게 도와준다.
빅데이터 플랫폼
엘라스틱스택은 하둡, 카프카, RDB등과 연동하여 빅데이터 파이프라인의 일부로 동작할 수 있다.
ElasticSearchOperations vs ElasticSearchRepository
Spring Data Elasticsearch는 여러 가지 인터페이스를 사용하여 Elasticsearch 인덱스에 대해 호출할 수 있는 작업을 정의합니다(반응형 인터페이스에 대한 설명은 반응형 Elasticsearch 작업 참조).
IndexOperations는 인덱스 생성 또는 삭제와 같은 인덱스 수준에서 작업을 정의합니다.
DocumentOperations는 ID를 기반으로 엔티티를 저장, 업데이트 및 검색하는 작업을 정의합니다.
SearchOperations는 쿼리를 사용하여 여러 엔터티를 검색하는 작업을 정의합니다.
ElasticsearchOperations는 DocumentOperations와 SearchOperations 인터페이스를 결합합니다.
이러한 인터페이스는 Elasticsearch API의 구조화에 해당합니다.
인터페이스의 기본 구현은 다음과 같이 제공됩니다:
-인덱스 관리 기능.
- 도메인 유형에 대한 읽기/쓰기 매핑 지원.
- 풍부한 쿼리 및 기준 API.
- 리소스 관리 및 예외 번역.
ElasticSearchRepository 는 쿼리를 일부 자동화해주고, 직접 생성한 쿼리를 날릴때도 오퍼레이션을 간단하게 할 수 있기 때문에 사용한다.
2) 왜 어떤 부분이 잘못됐다고 하는 걸까?
예상 질문
- 키워드 관련 질문 + 키워드와 기능의 상관관계 질문
키워드 정리
1) 클러스터 : 노드 뭉치
2) 노드 : 서버- node.master: true ## 마스터 후보(master eligible) 노드 - node.data: true ## 노드가 데이터를 저장가능하도록 함 - node.ingest: true ## 데이터 색인시 전처리 작업인 ingest pipleline 작업의 수행을 할 수 있는지 여부를 지정 - node.ml: true ## 머신러닝 수행 가능 노드3) 샤드 : 루씬의 단일 검색 인스턴스
4) 도큐먼트 : ES의 데이터 단위
5) 인덱스 : 도큐먼트의 집합
2. 우리 프로젝트에서의 ELK 동작 흐름?? -> 설명하고, 사실 ELK의 용도는 데이터 로깅 및 모니터링의 목적이 강한데 단순히 데이터의 정합성을 맞추면서 검색 성능만을 향상시키는 것에 집중된 점이 잘못됐다(질문해야 꺼낼 내용, 먼저 꺼내지는 않기)
발표에서는 엘라스틱 서치의 검색 성능 향상 이론에 대해 집중하고 로그 스태시와 키바나는 딱 곁가지 그 이상 그 이하도 아니게 조곤조곤 읊기
엘라스틱 서치가 속도가 빠른 이론적 이유
- 역인덱싱 기반으로 키워드에 해당하는 ID를 전부 모아서 한번에 조회하기 때문에 검색 속도가 상대적으로 빠름
- 다만 한국어 시스템이어서 노리 토크나이저를 사용하였음
- 불용어의 검색 조건 배제, 빈번한 언어의 딕셔너리화 등 다양한 기능을 활용
- Scoring Algorithm (a.k.a Similarity Algorithm)이란, 입력한 쿼리에 가장 적합한 도큐먼트를 찾아내기 위해 점수를 매기는 알고리즘
match 쿼리 사용 이유 : 서비스의 특성 고려
(term 쿼리로 완벽히 일치하는 검색을 수행하는 것보다 통상적인 사용자가 원하는 결과를 받아낼 확률이 더 높아지므로) -> 네이티브 쿼리에서 엘라스틱 서치로 전환한 이유도 풀텍스트 적용 등, 확장성이 떨어지기 때문에 갈아탄 부분과 일맥상통함
2) 피드백 내용 분석...
대용량 트래픽이 발생하는 상황에서 데이터 정합성을 맞추기 위해 메인 DB인 mysql과 cache로 사용하시는 redis를 좀 더 심화해서 사용해서 해결할 수 있었을 것 같습니다. 특히 application 단에서의 heap 메모리 문제의 경우는 데이터를 한꺼번에 load하지 않고 분할해서 load하거나 server spec을 늘리는 식의 방안들도 고려되어야 했을 것 같습니다...
개인적인 생각 : 로그 스태시의 용도를 그저 검색 대상 데이터 수집용으로 한정해서 사용하였다는 점이 문제이려나...? 여기서 이어지면...
ELK는 로깅을 메인으로 삼는 시스템이지 검색만을 위한 시스템이 아니라는 것이 맘에 안 든 게 아닐까...?
이게 아닐까?
플젝 최종발표에서 개선점에 꼭 넣어야 될 듯?
지금 생각나는 개선점
러닝커브때문에 못했던 성능 비교 수행
ELK의 제대로 된 이해(검색 데이터의 관리에 대한 부재) 및 검색 데이터 수집 방안 대체제 마련
