Elasticsearch 고도화 및 성능 최적화 사례

저희 회사에서 발생하는 모든 보안 관련 데이터는 엘라스틱스택을 통해 수집 및 분석되고 있습니다.
일일 평균 로그량은 이벤트 수 기준으로 평일에는 약 5억 건 정도이며, 서비스는 계속 추가되고 있고 보안 로그는 지속적으로 증가하고 있는 상황이라 SIEM의 고도화가 필요했습니다. 이러한 환경에서 엘라스틱 스택을 확장하거나 축소하여 사용할 수 있는 방법에 대해 소개해드리겠습니다.

현재 저희 회사의 가장 큰 고민거리는 엘라스틱서치 기반의 SIEM 시스템이 가진 한계입니다. 검색 시 오류가 발생하고, 저장 공간이 부족해 주기적으로 인덱스를 삭제해야 하는 상황이었습니다.

 

현재 문제점 요약

DATA 저장공간 부족

 

서비스 증가와 로그 증가로 Disk 스토리지 저장 공간 부족 최소 6개월은 data를 보관해야하지만 부족한 상황
일 평균 80G~90G, 월2TB 이상 사용, 현재 저장 공간 유저블 15TB 운영

CPU 자원부족

 

복잡한 다중 검색 및 로그 병합 작업시 속도 저하 및 과부하 발생으로 성능 저하
평균 CPU 사용량 50%~60% 이상 -> 로그 검색시 결과값을 반환하는데 성능 저하 및 에러 발생

Memory 자원 부족

 

메모리 자원 부족 -> VM(가상머신) 추가 구성 불가
JAVA 기반 Elasticsearch 사용, Heap 메모리 부족 현상 자주 발생 (GC가 빈번하게 발생)
현재 전체 메모리 총 384G 중 95% 사용중 (거의 Full상태)

해결책으로 SIEM 시스템 서버의 리소스(자원)증설과 아키텍처의 구성 변경을 진행하여 현재 문제점에 대한 해결책을 찾으려고 고도화 작업을 진행하였습니다.

 

엘라스틱서치-고도화
엘라스틱서치-고도화-아키텍처

 

 

리소스 추가 및 아키텍처 변경 진행 과정

현재 Elastic Stack SIEM 구성은 VM 총 10대로 구성되어 있음. logstash node 3대, master 3대, data node 4대. 수정 변경되는 아키텍처 구성은 data node가 추가 증설되고 검색 성능을 높이기 위해 client node도 별도로 추가할 계획 총 추가되는 VM 대수는 12대 이상입니다.

 

하기 구성 변경 고도화 계획 구성도를 보시면 이해가 쉽게 되실겁니다. 참고용도로 활용하시기 바랍니다.

 

위 구성도에서 가장 중요한 포인트는 Elastic DATA 노드 리소스 부족 현상으로 다중 쿼리 검색이나 병합 작업시 속도저하와 성능저하 문제가 빈번하게 발생되어 DATA 노드를 추가증설하고 분산하는 아키텍처입니다. 실제 구성시에는 다양하게 구성 변경하여 자사의 서비스에 맞게 아키텍처를 설계할 필요가 있습니다.

 

고도화로 인한 개선 효과 요약

1) 서버 리소스 증설 -> CPU 32Core, MEMORY 512G, DISK 20TB 추가

2) 아키텍처 구성 변경 -> SIEM(Elasticsearch) VM 증설 및 DATA 노드(로그 저장 및 검색) 분산

3) SIEM 운영 효율성, 민첩성 증대

4) VM 증설 및 아키텍처 변경시스템 성능 향상, 검색 속도 향상

5) 로그 보관 주기 연장 (최소 6개월 이상 보관 목표로 설정)

6) 실시간 사이버 보안 위협에 대한 신속한 대응과 효율적 대응 가능.

 

본문의 내용에서도 알 수 있듯이, 기업의 환경에 맞춰 엘라스틱 스택을 구성하는 것이 좋습니다.

 

데이터 노드 개수, 스토리지 용량 등은 실제로 서비스를 운영할 때 여러 가지 문제를 일으킬 수 있습니다. 또한, 엘라스틱 노드의 경우 한 번 구축하면 이후 수정 및 보완이 어렵기 때문에 처음부터 신중하게 접근해야 합니다.

 

 


게시됨

카테고리

작성자

댓글

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다