Elasticsearch - ELK 스택을 사용하면서 겪었던 이슈들

키바나가 죽었어요. 복구해주세요.

라는 질문을 자주 받는다. 

ELK(Elasticsearch-Logstash-Kibana) 스택을 사용할 때에, Kibana에서 로그 조회가 불가능한 경우에 위같은 질문이 쏟아진다.

Kibana는 로그를 조회하는 곳이니 문제를 일으킨 경우가 거의 없었다.

하지만 ES와 Logstash는 여태까지 여러 문제를 겪은 경험이 있다. 이번 글에서는 내가 겪었던 문제들에 대해 어떤 것이 원인이었고, 어떤식으로 이를 해결할 수 있었는지 다루려고 한다. 

---

먼저, ES가 장애를 일으킨 문제에는 아래와 같은 것들이 있었다.

1. Request Time-out

루씬 쿼리가 복잡하거나, 검색 날짜의 텀이 길면 생기는 문제인 듯 하다.

대부분 일정 기간을 기다리면 다시 살아난다. 

하지만 살아나지 않는 경우, 다시 껐다 켠 경우 해결되었다.

2. No Living Connection이 Kibana에서 발생하고, ES에서 OutOfMemoryException이 발생한 경우.

ES 프로세스가 죽어있는 경우에 나오는 메세지이다.

누군가가 프로세스를 의도적으로 종료하지 않는 이상, ES가 종료된 원인을 찾아야 한다.

내가 겪었던 케이스는 ES node에 할당되어있는 Heap 사이즈가 모자라서 엘라스틱서치가 종료된 경우가 있었다.

ES는 JAVA 기반으로 돌아가기 때문에, Heap 크기가 성능을 좌우한다. 

ES 프로세스를 별도의 Heap 사이즈 할당 없이 기본 상태로 실행시키면, 프로세스는 1gb의 메모리를 할당받게 되어 있다.

관련된 정보를 stackoverflow 등에서 찾아 본 바로는, 1gb의 메모리는 ES 프로세스에게 터무니없이 적은 양이다.

이를 수정해주려면 환경변수를 통해서 직접 ES에 할당되는 메모리의 양을 늘려주어야 한다. 

ES_HEAP_SIZE라는 변수를 세팅해주면 되는데, 문제는 메모리를 얼마나 할당해줄 것이냐? 이다.

큰 규칙은 아래와 같다고 한다.

1. 시스템 전체 메모리의 절반이 넘지 않도록 한다.

2. 32gb이상 할당하지 않도록 한다.

위 규칙 하에서 사용자가 적당한 메모리 용량으로 설정하라는 이야기가 대부분이었다.

나의 경우에는 32gb가 전체 메모리였기에 절반인 16gb를 사용했다.

남은 메모리는 루씬 쿼리에서도 사용되기 때문에 너무 적어서는 안된다고 한다.

ES에 할당된 Heap의 사이즈가 너무 적은 경우에는 내가 겪었던 것 처럼 OutOfMemoryException 을 야기할 수 있으며,

Heap의 사이즈가 너무 큰 경우에는 gc 기능이 오래걸리고, 'stop-the-world' 시간이 길어진다. 자연스럽게 es 응답시간이 느려질 수 있다. 

적당한 Heap 사이즈는 ES를 사용해보고 조율해가는 방향으로 해결해야 할 것 같다.

---

아래는 아직 정확히 파악하지 못한, 생겼던 문제들이다.

1. 로그가 RDS DB에 input은 되나, output이 되지 않아 Kibana에서 쿼리로 조회가 되지 않는 경우.

이 경우에는 다행히 input에 장애가 있던 것이 아니라서 로그가 쌓이지 않아 누락되는 문제는 없었다.

2. RemoteTransportException

원인 파악을 못하고 있어서, 해결 후에 다시 작성해야 할 것 같다.

3. 로그의 input이 되지 않아 로그가 누락되는 경우

이전 로그들이 쌓여서 storage의 용량이 가득 차서 생기는 문제였다. 로그를 압축하여 해결하였으나,

최근에는 ES의 index의 용량이 너무 커져서 이에 대한 해결방법을 찾아야 한다. index를 없앨 수 있으면 없애거나, 그게 아니라면 storage를 확장해야 할 것 같다.