주소로 고객 검색 서비스 구축하기(feat. Elastic Search v 8.6.2, MacOS) - 5탄

 

주소로 고객 검색 서비스 구축하기(feat. Elastic Search,  MacOS) - 5탄

안녕하세요. 클스 입니다.

* 목표

- Elastic Search & Kibana 설치 (1탄) - 보기

- Elastic Search Client for Python 설치 및 프로그램 (2탄) - 보기

- 주소 데이터 검색 구조 설계 및 bulk 생성/업로드 (3탄) - 보기

- 주소 데이터 검색 구조 설계 및 bulk 생성/업로드 (3.5탄)  - Polars vs Pandas

- 대량으로 검색 하기 (4탄) - 보기

- 데이터 백업 및 복구 <유지관리> (5탄)   - 현재글

지난 4탄까지 데이터 구조를 설계하고 벌크 업로드, 검색, 그리고 고객key와 매핑을 하였습니다. 

이번에는 데이터양에 따른 적절한 elastic search의 메모리 용량 설정, 유지보수를 위핸 백업/복구, 

데이터 관리 등을 다뤄볼 예정입니다.

1. elasticsearch 메모리 용량 산정

Elasticsearch의 용량 산정은 몇 가지 요인에 따라 달라집니다.

데이터의 양: Elasticsearch는 대용량 데이터를 처리하는 데 최적화되어 있으므로, 데이터의 양은 용량 산정에 가장 큰 영향을 미칩니다. 데이터의 양이 많을수록 더 많은 저장 공간이 필요합니다.


색인된 데이터의 구조: Elasticsearch는 각 필드의 값을 색인하여 검색할 수 있습니다. 필드의 수와 값의 길이에 따라 색인 크기가 달라질 수 있습니다.


검색 및 집계 요청의 복잡성: Elasticsearch는 검색 및 집계 요청을 처리할 때 추가적인 리소스를 필요로 합니다. 검색 요청이 복잡하고 집계 결과가 많을수록 더 많은 용량이 필요합니다.


클러스터 구성: Elasticsearch는 여러 노드로 구성된 클러스터로 동작할 수 있습니다. 클러스터에 사용할 노드의 수, 각 노드의 스펙 및 리플리카 설정에 따라 용량 산정이 달라질 수 있습니다.

따라서 Elasticsearch의 용량 산정은 해당 시스템에서 처리할 데이터의 양과 구조, 검색 및 집계 요청의 복잡성, 그리고 클러스터 구성 등 여러 가지 요인을 고려하여 평가해야 합니다. 일반적으로는 예상되는 데이터 양에 대한 30-50% 정도의 여유 공간을 확보하는 것이 좋습니다.

대략 물리메모리의 절반을 HEAP 메모리로 설정하는 것을 권장 합니다.

클러스터는 운영시 가용성을 확보하기 위한 것이라, 거의 필수 입니다. 

보유한 데이터를 저장하고 검색 하려면 노드별로 메모리, 디스크 용량을 산정해서 저장 해야 합니다.

https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

샤드와 백업 / 복구에 대한 설명 : 

https://jaemunbro.medium.com/elastic-search-%EC%83%A4%EB%93%9C-%EC%B5%9C%EC%A0%81%ED%99%94-68062271fb64

그리고 얼마 간격으로 데이터가 들어오는지? 보존 기간을 얼마로 할지 결정해야 합니다.

시나리오

연속성을 위해, 각 에이전트가 메트릭당 100바이트를 수집하고 10초마다 100개의 메트릭을 수집하며 데이터 보존 기간이 30일인 1,000개의 호스트를 모니터링하는 클러스터를 위한 비용 절약 전략을 알아보겠습니다. 또한 고가용성을 위해 클러스터에 데이터 복제본을 저장하겠습니다. 이것은 노드 작동에 장애가 생길 경우 데이터 손실을 방지해줍니다. 얼마나 저장 공간이 필요하게 될지 계산해보겠습니다.

호스트 1,000개 * 100바이트 * 메트릭 100개 * 60/10 분당 빈도수 * 60*24*30(30일 동안) * 2(복제본당) = 5184000000000바이트 또는 5.184TB https://www.elastic.co/kr/blog/cost-saving-strategies-for-the-elasticsearch-service-data-storage-efficiency

     설명이 잘되어 있습니다.

2. elasticsearch 데이터 관리 (백업/복구)

  Docker나 Kubernetes 로 elastic search cluster를 구성하여 관리하면 제일 편하고 좋습니다.

  그러나 데이터 확장과 장애시 복구를 위한 스토리지 설정등이 필요합니다.

  Docker 로 구성할때는 docker-compose를 이용해서 합니다.

  elasticsearch data/log 폴더 설정

       docker 인스턴스가 올라갔다 내려갈 때마다 es data를 잃기 싫다면 설정해주어야 합니다.
       es의 데이터와 es의 로그가 저장될 곳입니다.

$ mkdir es_data es_log

본인 혼자 사용한다면 해당 폴더들을 777권한을 줘도 됩니다. 안해주면 permission 문제로 인스턴스가 뻗는다
$ chmod -R 777 es_data/ es_log/

(OR) 권한에 민감한 경우라면 docker elasticsearch 공식 인스턴스가 요구하는 uid, gid를 맞춰서 설정해야 합니다.

$ chown -R 1000:1000 es_data/ es_log/

일반적으로 uid:gid 가 1000 입니다.

이상 길고 길었던, 주소 기반으로 고객을 검색하기 위해 필요한 기본적인 내용들을 다뤄봤습니다.

감사합니다.