ES의 shard initialize 에 대해...

며칠 전 데이타 손실이 발생하여 내용을 공유하기 위해 기록합니다. 

일단 구축한 시스템은 사내에 ES로 시스템을 구축해두고, 각 컨텐츠 별로 REST API 서버  + Redis로 중간 저장소를 만들어 둔 상태입니다. 그리고 사내의 세팅된 Logstash에서 방화벽이 열리는 시간에 컨텐츠 별 중간 저장소로 접속해 그동안 쌓여있는 로그를 가져오도록 되어 있습니다. 

이렇게 세팅된 이유는 Node 별 초기/유지 비용을 줄이고 (사내에서 PC로 시스템을 구축해 둠. 서버와 비슷한 성능의 시스템을 저렴하게 구축할 수 있으며, IDC의 상면비 등을 절감할 수 있기 때문입니다. 문제 발생 시 접근성도 용이합니다.), 운영자들의 접근 속도도 높이기 위함입니다. ES외에도 리포트 사이트를 구축하여 Kibana로는 결과를 만들 수 없는 리포트를 원하는 대로 만들 수 있도록 구축해 두었습니다. 

문제는 주말이 지난 후에 발생했습니다. 

월요일 오전이면 주말 동안 가져오지 않고 쌓여 있던 데이타들을 한번에 가져오게 됩니다. 평소에 별 이상이 없었는데, 이날은 Master Node 하나가 다운되면서 발생했습니다. 가끔 다운되는 경우가 있었기에 (과도한 양의 쿼리를 하는 등으로 메모리 초과되면서 다운되는 경우가 종종 있었습니다.), 이날도 그대로 node를 기동해 두었죠. 

그런데 운영자들로부터 몇몇 데이타들이 검색되지 않는다고 보고를 받게 됩니다. 어차피 지표를 보기 위한 데이타이기에 손실이 일부 있다고 큰 문제는 되지 않지만, 이 시스템을 통해 매출 리포트를 자동화 시켜두어, 수동 매출 리포트와 결과가 틀리다는걸 바로 듣게 되었습니다. 

살펴본 결과, 실제 documents의 수가 평소 주말보다 30~50% 정도 적은 것을 확인했습니다. Facebook elasticsearch user group에 문의한 결과 아래와 같은 원인을 알게 되었습니다. 

- node를 재가동하면 shard initialize를 진행하는데, GET _cat/indices?v 로 인덱스들의 상태를 살펴보면 green이 아닌 red로 표기되는 것들이 있습니다. 혹은 ElasticHQ로 보면 unassigned Shards, Initializing Shards에 표기된 숫자들을 볼 수 있습니다. 

- 초기화가 진행되는 동안 데이터가 들어오면 bulk rejected가 되는데, 이 때 bulk queue에 보관하고 있다 작업이 완료되면 처리되도록 되어 있습니다.

- 그런데, 입력이 과다할 경우 누락이 발생되기도 한다고 합니다. 

제가 겪었던 월요일 오전의 그 사건이 딱 이런 경우였습니다. 

그래서 이를 방지하기 위해 조치를 하고, 혹시 몰라 밀려오는 데이터들을 일시적으로 redis에 expire 1주일 설정을 해두고서 마무리를 해 두었습니다. 

끝!!!