[Elasticsearch] ELK스럽게 데이터 수정하기 (역색인구조)

Elasticsearch

졍 2023. 4. 24. 17:38

이번 포스팅은 Elasticsearch와 Kibana를 처음 사용하면서 공부했던 부분들에 대해 남겨보고자 한다.

(공부중인 부분이라 용어가 적절하지 않거나 틀린부분이 있을 수 있습니다! 알려주시면 감사하겠습니다 :))

ElasticSearch에 metic 정보를 넣어 Kibana로 시각화하려고 했을 때, 뭔가 잘 되지않는 문제가 있었다.

예를 들어 host의 cpu 사용개수를 표현하려고 했다고 하자.

내가 ES에 적재하는 정보는 다음과 같았다.

이런 방식으로 적재하면 Kibana에서 시각화를 할 때 Field(host)별로 view를 추가해줘야했다. 이 말인즉슨 host가 추가되거나 삭제되는 경우, 일일이 Kibana에서 수기로 작업을 해줘야하는 상태였다.

host는 수시로 추가/삭제 될 수 있기 때문에 위와 같은 방식으로 사용하는 것은 무리가 있다고 판단하였다.

위 블로그의 글을 읽고 내가 이상하다고 느낀 지점이 맞다고 느꼈다.

일반적으로는 Metric - prometheus+grafana, Logs - ELK를 쓰는 듯 했다. (꼭 이렇게 쓰는 것은 절대 아니다. 다른 기술도 매우 많고 상황에 따라, 이유에 따라 다르게 쓸 수도 있다.)

그렇다면 현재 상황에서 metric을 저장하는데 ELK를 쓰려고 하는 이유가 뭔지 궁금해서 물어보았다...

1. metric 값의 장기 보관

- Prometheus는 기본적으로 장기보관을 제공해주지는 않는다. 따라서 Elasticsearch에 적재하여 장기보관을 하고자 한다. (보안심사 등의 이유로?)

(하지만 파라미터 값을 수정해 최대 30일 까지 보관하거나, 따로 스토리지를 붙여주는 방식으로 장기보관할 수 있는 듯 하다.)

2. 시계열 모니터링 구축

(Prometheus + Grafana도 시계열 모니터이 가능하다.)

이후에 기존에 쓰던 Prometheus에 장기 스토리지를 붙여 사용하거나, metricbeat를 사용하는 것을 검토해보는 것은 어떤지 다시 어쭤보았다.

1. metricbeat는 서버에 전부 agent를 설치하는 방식인데, 이 방식은 지양하시는 듯 했다. (서버가 너무 많아서)

2. 이미 ELK 대시보드를 어느정도 구축해두었기 때문에 이 방식을 사용하고자 하시는 듯 했다.

이러한 이유로 ELK를 계속 사용하기로 하였다.

일단 위의 형태로 Document가 계속 쌓이면, Kibana에서 계속 수동 작업을 해주어야했기 때문에, 데이터의 형식을 바꿔줄 필요가 있겠다고 느껴졌다.

여기서 Elasticsearch의 역색인 구조에 대해 공부하게 되었다.

(역색인 구조는 따로 포스팅 예정)

기존 색인 구조처럼 Document를 쌓았을 때는 다음과 같이 저장이 되었다.

역색인 구조에 맞게 데이터 형식을 변환한 후에는 다음과 같이 데이터가 저장되도록 하였다.

이런 방식으로 저장하면 Kibana의 Visualize를 적용할 때, Used CPU에 대한 Field만 넣으면 자동으로 host별 CPU사용 개수가 매핑된다.

하지만 이렇게 저장했을 때의 문제점이라고 생각되었던 부분은..

"CPU사용 개수만큼 Document가 들어오기 때문에, script를 1분마다 돌린다고 할 때 1분에 많게는 몇백, 몇천개씩 document가 쌓이게 된다."는 점이었다.

그런데 이 부분은 여쭤보니, 실무에서는 로그가 1초에도 엄청난 양으로 쌓이기도 하기 때문에 이 것까지는 고려하지 않아도 된다고 말씀해 주셨다.

나중에 알게된 건데 이런 부분에 대한 성능 테스트를 진행할 수 있다고 한다.

결론을 얘기하자면, 위와 같이 test했던 내용을 실제 반영하지는 못했다.

반영하더라도 만일 Aggregation(리소스 종류)이 추가되면 Dashboard 수동 매핑을 피할수 없었기 때문이다.

시간과 경험이 좀 더 있는 상태였다면..하는 아쉬움도 있지만, 정말 많이 배울 수 있는 기회였던 것 같다. 기술적인 것도 그렇지만, 여러 사람들에게 물어보고 찾아보면서 이 문제를 해결할 수 있는 방식이 정말 다양하다는걸 알 수 있었다.

무엇보다 성능 테스트가 엄청 궁금하다. 그때는 이런게 있는지 몰라서 못했었는데, 성능 테스트를 통해 수치적으로 뭐가 더 나은지 설명할 수 있었다면 좀 더 좋았을 것 같다는 생각이 든다.

+) 사실 저렇게 데이터를 수정하는게 맞았는지 아직 잘 모르겠다. 최대한 Kibana로 표현하기 용이하게 수정하긴 했지만, 아마 저렇게 쓰면 중복 document가 많이 쌓이기 때문에 리소스 낭비가 있었을 것이다.