Elasticsearch는 Apache Lucene 기반의 오픈소스 분산 검색 엔진이며, 로그 처리 3단계의 저장을 맡고 있다
대용량 데이터를 실시간에 가까운 속도로 처리(저장, 검색 등)할 수 있으며,
이 때문에 로그 파일 관리나 실시간 검색 서비스 등과 같이 대용량 데이터를 빠르게 처리해야 하는 경우 주로 사용된다
🔎 분산 구조
대용량 데이터를 다루어야 하기에, 이에 최적한 분산 구조를 가지고 있다
비정형 데이터를 가공하여 대상에게 전달하는 것이 목적이다
이를 위해 데이터를 받아들이기 위한 입력(Input), 이를 가공하는 필터(Filter), 특정 대상에게 보내는 출력(Output)의 3단계 파이프라인으로 구성되어 있다
🔎 유연한 데이터 형식
LogStash의 파이프라인은 다양한 플러그인의 조합으로 동작한다
이는 곧, 현재 지원하지 않는 기능이 있을 때 관련 플러그인을 만들면 된다는 소리다
때문에 종류에 구애받지 않고 다양한 데이터 타입을 처리할 수 있다
🔎 저장 기능 지원
로그와 같은 형태가 없고 방대한 데이터들은 데이터의 구조와 정합성이 중요한 RDB를 활용하는 것은 매우 비효율적이다
ElasticSearch의 경우 데이터가 구조가 없는 JSON 형식으로 처리되고 무엇보다 분산 시스템으로 설계되었기에 방대한 로그 데이터에도 유연하게 대처할 수 있다
(하지만 지원을 한다는 것일 뿐, 저장은 주요 목적이 아님을 명심하자)
🔎 최적화 된 검색
로그 데이터는 구조화되어 있지 않고 비구조화된 텍스트로 이뤄져있다
비구조화된 많은 로그 데이터들을 RDB에서 조회하려면 복잡한 텍스트를 검색하기 힘들뿐더러, 인덱싱과 같은 추가 작업이 요구되어 시스템 부하가 증가할 수 있다
반면에 Elasticsearch는 전체 텍스트 검색에 최적화된 엔진(Lucene 기반)을 사용해 대용량 데이터에서도 빠르게 정보를 찾을 수 있다
또한 모든 데이터를 역 색인 구조로 저장해 가공된 텍스트를 검색한다
거의 실시간 검색으로 사용할 수 있기 때문에 보안 분석, 인프라 모니터링 같은 사용 사례에 적합하다
ElasticSearch는 분산 구조로 되어있다보니 쿠버네티스의 설계와 매우 흡사하다
이에 대해 간략히 알아보도록 하자
사실 이를 알아보기 전까지는 단순히 PVC를 만들어서 각 파드에 마운트하여 해결하려고 했다
해야할 별다른 작업도 없을뿐더러, 로그 파일도 서버 자체에서 롤링하여 내보낼 수도 있기 때문이다
(API 서버 - logback 등, Nginx - 각종 로그 설정들)
하지만 문제는 늘 그렇듯 선택과 집중에 있는 것 같다
Elastic Stack은 정형/비정형 로그 데이터를 일관된 방법으로 수집 -> 가공 -> 시각화 하기위한 방법이다
즉 서버가 몇 대 안되는 단순한 인프라에는 굳이 필요 없겠으나, 쿠버네티스로 파드를 여러개 띄워야하는 경우엔 다음 의문점이 계속 떠오른다
어떻게 A 서비스를 별도로 일관되게 제공할 수 있지?
따라서 지금 서비스에는 오버스펙일 수 있으나, 로그 관리를 독립적으로 일관되게 제공하기 위해 ELK를 사용하려고 한다
다음 편에는 어떻게 적용하는지에 대해 알아보도록 하겠다