ELK

강력한 유연성과 호환성
엘라스틱서치, 로그스태시, 키바나는 각각 데이터의 쿼리(검색), 수집, 시각화를 담당한다. 용도별로 분리하여 발전하는 솔루션이기에 구조적 안정성은 물론 다른 시스템과도 유연한 호환성을 가진다.

자유 스키마
JSON 방식의 Key-Value 형식의 데이터를 사용하므로 형식에 자유롭다.

인덱스 와일드카드 지원
관계형 데이터베이스로 치면 테이블(Table)에 해당하는 개념인 인덱스(Index)의 Union 또는 Join이 경우에 따라 와일드 카드(*) 표기 하나로 끝날 수도 있다.

확장(Scale-out) 가능 데이터베이스
처음부터 확장을 고려하여 만들어졌기 때문에, 여러대의 서버를 엮어서 성능 향상을 기대할 수 있는 클러스터 방식을 구성할 때 관계형 데이터베이스보다 상대적으로 관련 정보에 쉽게 접근이 가능하다.

데이터 처리 절차를 '레거시 코딩'보단 개별 설정으로 가능
데이터 처리 절차를 프로그래밍 언어를 이용한 코딩으로 명시한다면, 향후 유지보수가 용이하지 않고 불필요한 종속성이 높아지는 문제가 있지만 로그스태시(Logstash)를 포함하는 ELK 스택 구성 시 유연성 확보가 가능하다.

사전에 준비된 시각화 도구와 부가기능
데이터를 시각화하여 보여주기 위한 사용자 인터페이스(UI)를 내보낼 프로그램을 따로 작성하지 않아도, 이미 사전에 준비된 시각화 도구를 가진 키바나(Kibana)가 마우스 몇번 조작하면 거진 다 알아서 해준다. 그 외 데이터베이스 관리자를 위한 부가기능이 포함되어 있다.

실시간 데이터 처리
메시지 큐(Message Queue, MQ)와 결합하면 강력한 실시간(Realtime) 데이터 수집 및 처리 시스템이 된다.

엘라스틱서치의 버전 별 벌크(Bulk) 방법 차이를 완화
엘라스틱서치의 벌크(Bulk)는 관계형 데이터베이스에서 삽입(Insert)에 해당한다. 프로그래밍으로 직접 구현할 경우 엘라스틱서치 버전 별 벌크 방법의 차이가 크기 때문에, 인터넷에 떠돌아다니는 튜토리얼만 보고 진행하기에는 오래된 자료도 많아 무리가 따를 수 있다. 로그스태시(Logstash)로 엘라스틱서치를 다룬다면 이런 걱정은 하지 않아도 된다.

초기 데이터 구성 및 이관 문제
빠른 데이터 처리를 장점으로 표방하고 있으나, 초기 데이터 구성이 기존에 보유한 데이터를 엘라스틱서치로 이관하는 것에서 시작하는 경우가 많음에도 공식적으로 공개된 튜토리얼은 심각한 성능 저하를 일으킬 수 있는 내용이 주를 이루고 있다. 문제는 대부분 실시간(Realtime) 데이터를 처리하는데 적합한 방식을 대용량 데이터 이관에도 유용하다고 소개하는 점에서 비롯된다. 가령, 메시지 큐(Message Queue, MQ)를 이용하면 실시간 데이터 처리는 분명 안정성과 속도면에서 강점이 있으나, 100 기가바이트(GB) 이상의 관계형 데이터베이스(ex. MySQL, 오라클 데이터베이스)의 데이터 이관 절차에 그대로 적용하면 상당한 성능 저하의 우려가 있다. JDBC를 이용한 방법도 공식 튜토리얼이나 지나친 메모리 누수 문제로 인해 데이터가 몇 기가 정도만 되어도 사실상 데이터 이관 용도로는 사용이 불가능하다. 하지만 해결책은 있다. 데이터 이관이 목적인 경우, 데이터베이스 테이블 내용 전체를 파일로 저장한 다음 파일비트(Filebeat)[1]를 쓰는게 훨씬 빠를 수 있다.[2] 기존 데이터의 용량이 너무 커서 어쩔 수 없이 네트워크를 이용한다 하여도 로그스태시(Logstash)의 접점에서 속도 저하 및 메모리 누수를 최소화할 수 있도록, 목표한 파일이나 데이터베이스 테이블의 행을 하나 이상 씩 일정한 수로 읽으면서 TCP 또는 UDP 등 소켓을 기반으로 데이터를 전송하는 프로그램을 직접 구현하면 해결이 가능하다.

커널 변수의 불필요한 사용
ELK 스택을 구성하는 솔루션 중 로그스태시(Logstash)는 리눅스 운영체제 커널의 cgroups에 해당하는 변수를 참조하는 내용이 포함되어 있는데, 이것은 운영체제에서 정한 임계값을 파악하기 위함이다. 하지만, 커널 컴파일 설정에 따라 cgroups 내의 변수는 일부는 존재하지 않을 수 있음에도, 데이터 수집이라는 목적에 구지 필수적이지 않은 변수가 존재하지 않는 이유로 프로그램이 중단되는 문제점이 있다. 주로 운영체제의 커널 크기를 최소화하려는 시도가 반영되었거나, 커널 공유 방식의 가상화(커널 공유 방식은 저가형 데이터 센터에서 종종 쓰임)을 진행하는 환경에서 문제가 발생하며 정상 설치 리눅스 운영체제의 경우 문제가 발생하지 않는다.

초창기부터 현재까지도 원활하지 못한 시간대(Timezone) 처리
3개의 스택(로그스태시->엘라스틱서치->키바나)로 데이터가 넘어가는 과정에서 시간대(Timezone) 일관성이 깨지는 문제가 있다. 'Asia/Seoul'같은 명시를 하여도, 마치 2중 환전을 연상케하는 시간대 변환 오류를 쉽게 범한다. 하지만 3개 솔루션 모두 기본 시간대가 UTC라는 점을 인지하고, 시간대 설정의 가능한 경우를 최대한 시도하여 일관성을 유지하려는 노력으로 극복이 가능하다.

초기 데이터 구성 및 이관 문제는 데이터의 무결성을 높여야 하는 상황에서는 문제가 되지 않을 수 있다. 데이터 입출력 속도가 저하되는 문제이지 데이터의 무결성에는 영향을 주지 않고 큐(Queue)에 의한 철저한 FIFO가 보장되므로 데이터 무결성을 보장하는 선택이 될 수 있다. 애초에 실시간 데이터가 아닌 과거의 데이터는 이관에 소요되는 시간보다 손실이나 변형을 최소화한 이관이 더 중점이 되기도 한다. 오히려 무리하게 데이터 입출력 속도를 가속하면, 로그스태시의 자체 큐 운용 방식과 엘라스틱서치의 고가용성 정책이 더해져 불필요한 데이터 복제(한 번 입력했는데 두 번 올라갈 수 있다.)가 일어날 수 있으므로 별도의 데이터 무결성 확인을 해야 할 수도 있다. 그러니 단점인지 장점인지 여부보다는 상황에 맞는 선택을 하여야 한다.

계정 관리 및 로그인 등의 부가 기능이 필요한 경우 엘라스틱서치 개발사에서 배포하는 X-Pack을 이용할 수 있다. 무료 플랜부터 가격대 별 유료 플랜이 있으며 플랜에 따라 각기 다른 부가 기능이 추가되어 제공된다.

키바나(Kibana)의 경우 대체 가능한 소프트웨어로 그라파나(Grafana)가 있다. 데이터베이스 관리자가 주로 사용할 법한 기능을 일부 제외하고 사용자 인터페이스(UI) 측면을 강화한 특징이 있다.

Apache Spark와 연동해서 사용하고자 하는 경우, 엘라스틱서치에 elasticsearch-hadoop 패키지를 추가하여 활용이 가능하다. 하지만 단순히 파일이나 관계형 데이터베이스 연동을 생각한다면 아무런 성과를 거두지 못한채 낭패를 보기 쉽다. 일괄처리가 아닌 전체 데이터를 작은 단위로 분할해서 병렬 처리하고자 하는 성격을 가진 플랫폼 위에서는 엘라스틱서치도 이런 성격에 부합하는 적절한 분할 쿼리 전략이 있어야 한다. Apache Spark에서는 이러한 특징이 RDD(Resilient Distributed Datasets) 데이터 형식과 워커(Worker)로 구현되는데, RDD를 엘라스틱서치에 벌크(Bulk)하는건 별도의 분할 쿼리 전략이 필요 없기 때문에 상대적으로 쉽다. 하지만 엘라스틱서치를 데이터 소스로 하여 RDD를 활용하는 것은 예제가 적어 어려움이 따를 뿐만 아니라, 그나마 있는 예제도 소용량 데이터 처리를 가정한 일괄처리를 다루기 때문에, 대용량 처리의 성능을 기준으로 한다면 적절한 예제를 찾기가 쉽지 않다.

애초에 엘라스틱서치는 검색 엔진이라는 점을 인지해야 한다. 대량의 데이터로부터 정제된 소량의 결과를 내놓는 작업에는 적합하지만, 출력하는 데이터가 대용량인 작업에는 적합하지 않을 수 있다. 출력해야 할 데이터가 많을 때는 페이징(From-size 또는 Scroll), 정렬(Sort), 집합(Aggregation)을 적절하게 사용해야 한다. 각각은 관계형 데이터베이스에서 LIMIT, ORDER BY, GROUP BY에 해당하지만 일반적인 그것과는 의미가 다르다. 쉽게 말하면 구글에서 검색을 할 때와 같다. 한 페이지 안에 지나치게 많은 정보를 담지 않으며, 자료의 순서는 확률적인 적합도과 관련이 있지 절대적이지 않다.

리눅스의 cgroups 변수는 Docker와 같은 가상화 시스템에서도 선택적으로 참조하기 때문에, 이 변수를 참조하는 것이 나쁜 것은 아니다.

엘라스틱서치와 연동하여 사용하는 시각화 도구인 키바나(Kibana) 또는 그라파나(Grafana)는 JSON 데이터가 평탄화(Flatten)되어 있어야만 호환이 가능하다. JSON을 평탄화한다는 것은 JSON 데이터를 최대한 관계형 데이터베이스의 모양과 가깝게 키(Key) 위주로 정렬하고 분할해야 함을 의미한다. 보통은 프로그래밍을 통해 직접 작성해야 한다. 이론적으로는 루씬 쿼리도 가능은 하지만, 객체와 배열이 심각하게 뒤섞인 형태의 데이터를 루씬 쿼리만으로 정렬할 수 있는 고이다 못해 썩은물이 있을 가능성은 거의 희박하다.

로그스태시와 연동되는 주요 메시지 큐는 레디스(Redis), 아파치 카프카(Apache Kafka), 래빗MQ(RabbitMQ) 등이 있다.

엘라스틱서치를 포함한 ELK 스택에서 시간 설정을 올바르게 하기 위해선, 시간대의 이해와 함께 ISO 8601 시간 표기법에 대해 알아야 한다. 사용자가 정의한 날짜와 시간 형식을 사용하고자 한다면, 로그스태시의 필터(Filter)로 변환하는 방법과, 엘라스틱서치의 mappings 항목으로 지정하는 방법이 있다.

엘라스틱서치는 Java로 작성된 시스템으로서, 기본 할당된 힙 메모리 크기는 최소 256MB에서 최대 1GB이다. 물리 메모리가 아무리 많아도 Java 가상 머신의 설정에 따라 메모리 사용량이 제한되므로, 실 사용 환경에서는 엘라스틱서치 환경 설정 파일에서 메모리 할당량을 조정해야 한다.