지난 XX월 저희 모니터링 서버가 느려지는 현상이 있었습니다.
| XX월 중순부터 진행한 “TMS기능” PoC로 Elasticsearch성능 저하 유발되었습니다. TMS는 네트워크 장비에서 각 포트별 Flow 정보를 분석하여 트래픽을 상세히 분석할 수 있는 기능인데, 해당 기능이 과도한 데이터 발생으로 성능통계(Elasticsearch)부분에 많은 부하를 발생하였습니다. XX 연구소와 같이 원인 분석하였지만 원인 파악은 안되었고, 해당 기능은 disable 되었습니다. ※ 해당 TMS기능은 ‘PRTG’ 등 대체 솔루션이 있으며, 이를 대신하여 검토 중입니다. |
위 내용은 모니터링 서버 담당자의 원인 분석 메일입니다.
Elasticsearch를 공부하고 있던 입자에서 해당 현상이 왜 생겼는지 궁금했습니다.
그래서 알아본 내용이고, 사실 이 내용은 초보자의 좁은 시각이니 이해해주시기 바랍니다...ㅎㅎ
<Elasticserach 기본 용어>
| 이름 | 용도 | |
| 색인 | 데이터를 Elasticsearch에 저장하는 행위 | |
| 인덱스 (index) | Elasticsearch에 저장되는 데이터의 집합 | |
| 샤드 (shard) | 데이터를 나눈 것 (샤드가 모여 인덱스를 이룸) | |
1. 현재 Elasticsearch 구성
현재 elasticsearch는 6대로 운영 중입니다. 5번기가 현재 master로 설정되어 있으며 6개 노드 전부 Master/data 노드 역할을 수행할 수 있도록 설정되어 있습니다.
그리고 다음과 같이 shard 4개와 복제본 2개로 data를 인덱싱하고 있습니다.
(현재 Tabular, metric 말고도 다양한 종류의 데이터가 수집되고 있습니다. Flow_proto, event_row 등…)
Elasticsearch는 크게 튜닝을 하지 않고 기본 설정만으로도 충분한 성능을 보여줍니다. 하지만 대용량의 로그 정보 수집의 경우 적정한 수치를 확인하고 적용한다면 더 좋은 성능을 보여 줄 수 있는데요, 그 중 하나의 필요 설정 수치가 샤드의 개수입니다.
빨간 네모 박스처럼 tubular에서 쌓이는 데이터와 metric에서 쌓이는 하루 데이터 용량은 차이가 있습니다. (tabular=11.2G / metric=1.02G)
그리고 이렇게 차이 나는 데이터를 같이 수집하기 위해, 샤드/복제본의 개수는 성능 향상을 위한 고민 요소 중 하나 입니다.
그리고 아래 4가지는 적정 샤드를 찾기 위한 문제입니다.
(1) 클러스터가 저장해야 할 전체 데이터의 크기
(2) 예상하는 최대 동시 인입 쿼리 수
(3) 목표로 하는 검색 시간
(4) 실제 서비스에서 사용할 수 있는 하드웨어 스펙 결정
2. 샤드/복제본 개수의 중요성
해당 내용은 "강진우"님의 작성하신 글에 잘 정리되어 있어 참조한 글입니다. (아래 참조 페이지 참고)
위 그림은 데이터 저장의 한 예시입니다. 그림처럼 0번 샤드는 데이터 노드#1에 복제본은 데이터 노드#2에 배치가 됩니다. 이 상황에서 데이터의 색인은 초록색 0번 샤드, 즉 데이터 노드#1에서만 발생합니다. (데이터 저장 후, 남은 노드에 복제하는 방식) 즉, 데이터 노드는 2대지만 색인은 데이터 노드#1에서만 하고 있는 것입니다. 데이터 노드#2는 색인을 하지 않고 검색에만 참여하게 됩니다. (데이터 조회 시에는 데이터를 #1에서 가져오든 복제본이 있는 #2에서 가져오든 상관 없기 때문입니다.)
만약 데이터 노드#1만 있다면? 위 그림 구조와 비교했을 때, 색인 성능은 그대로고 데이터를 읽는 속도는 느려지게 되는 것입니다.
그럼 색인 성능을 늘리고 싶다면 어떻게 해야할까요?
단순히 데이터 노드(Elasticsearch)를 늘리는 것이 아닌 그림처럼 샤드의 개수를 추가해야 합니다. 위 그림과 같이 이제는 데이터 수집을 #1과 #2가 동시에 참여하게 되어 기존보다 두 배 빠르게 동작할 수 있게됩니다.
물론 샤드/복제본의 개수만 늘린다고 해서 데이터의 색인, 검색 속도가 빨라지는 것은 아닙니다. 사용하고자 하는 데이터 노드의 수, 데이터의 크기 등을 잘 고려해야해서 샤드/복제본의 개수를 저장해야 할 것입니다.
3. 결론
저희 모니터링 서버 elasticsearch로 수집하는 데이터의 종류는 다양합니다. 그리고 각자 하루에 쌓이는 데이터 용량도 다릅니다.
이렇게 데이터의 용량이 각각 달랐어도 크게 성능에 문제가 없었던 이유는 elasticsearch 입장에서 ‘그 정도 데이터 차이 정도는 크게 문제 없음’ 이였던 것 같습니다.
반면 TMS 기능으로 수집하는 데이터의 크기는 너무 컸거나 검색 쿼리문에서 큰 차이가 있었을 것 같습니다.
제가 생각한 개인적인 해결책 두 가지 방안입니다.
1) TMS 기능 데이터와 현재 다양한 수집하는 데이터(Tabular, metric, flow 등)가 공존하기 위한 적정한 샤드/복제본의 개수를 찾기 위한 테스트 진행
2) 기존 데이터와 공존하기 위한 샤드/복제본 개수를 찾을 수 없을 경우, TMS 데이터 수집을 위한 elasticsearch 노드 생성 (당연히 기존 6개의 elasticsearch 노드와 데이터가 섞이지 않도록 master 노드 분리)
위 내용이 맞았는지는 제가 elasticsearch를 좀 더 공부한 후에 한번 테스트를 해보겠습니다...ㅎㅎ
(추가)
처음에 공부할 때는 단순히 elasticsearch에 데이터를 저장하고 kibana로 시각화하는 것에 중점을 두었는데요,
조금 공부해보니 해당 부분 보다는 elasticsearch 자체에 대한 학습이 먼저임을 알게 되었습니다.
elasticsearch를 통해 어떤 데이터를 수집할 것인지, 어떻게 데이터를 저장하고, 어떻게 데이터를 보관할 것인지, 한정된 자원에서 운영하기 위한 성능 튜닝 들을 고민하는 것이 중요하다는 뜻입니다.
처음 학습할 때 도움이 많이 되었던 곳입니다. elasticsearch의 기본 용어부터 정확한 동작 방식까지 자세하게 설명이 되어있습니다.
4. 참조
https://alden-kang.tistory.com/13?category=965077
'OpenSource' 카테고리의 다른 글
| Kafka없이 Logstash만 써도 될까? (0) | 2022.12.05 |
|---|---|
| WEB - WAS를 연동해서 쓰는 이유 (1) | 2022.03.18 |
