로그 엔진 용량 계획¶

Elasticsearch/OpenSearch를 Guance 로그/분산 추적 저장소로 사용하기 전에, 먼저 스토리지 용량과 클러스터 사양을 평가하세요. 이 문서에서는 커뮤니티 콘텐츠와 실제 테스트를 바탕으로 평가 알고리즘을 제공합니다.

Warning

Elasticsearch의 오픈소스 라이선스 변경으로 인해 OpenSearch 사용을 우선 권장합니다.
먼저 소규모 사양의 Elasticsearch/OpenSearch로 모니터링 데이터 생성 속도를 테스트한 후, 테스트 결과에 따라 클러스터를 계획할 것을 권장합니다.

데이터 압축¶

다음은 Elasticsearch 압축 알고리즘 테스트 결과입니다. 공식 esrally에 포함된 데이터셋 nyc_taxis(74GB)를 사용했습니다.

codec 설정	압축 알고리즘	압축 결과/GB	압축비
default	LZ4	35.5	0.48
best_compression	DEFLATE	26.4	0.36

다음은 OpenSearch 두 가지 압축 알고리즘의 테스트 결과입니다. opensearch-benchmark에 포함된 데이터셋 eventdata(15GB)를 사용했습니다.

codec 설정	압축 알고리즘	압축 결과/GB	압축비
default	LZ4	5.1	0.34
best_compression	DEFLATE	3.7	0.25

디스크 용량 추정¶

다음 조건을 가정합니다.

하루에 【1TB】 모니터링 원본 데이터 생성
압축비 【0.5】
각 인덱스에 【1】개 복제본 존재
모니터링 데이터 보존 기간 【7】일

Tencent Cloud Elasticsearch 스토리지 계산 공식을 참고합니다.

파라미터	참고값
데이터 팽창/인덱스 오버헤드	10%
내부 작업 오버헤드	20%
운영체제 예약	5%
안전 예약	15%

Guance의 데이터 보존 정책에 따라 안전 예약을 30%로 높이고, 원래 공식은 다음과 같습니다.

실제 공간 = 원본 데이터 x 압축비 × (1 + 복제본 수) × (1 + 데이터 팽창) / (1 - 내부 작업 오버헤드) / (1 - 운영체제 예약) x (1 + 예약 공간)

참고값을 대입하면 다음과 같습니다.

실제 공간 ~= 원본 데이터 x 압축비 x (1 + 복제본 수) × 1.89

최근 7일 데이터를 보존할 경우 발생할 수 있는 최대치는 다음과 같습니다.

7[일] x 1[TB] x 0.5 x (1 + 1) * 1.89 ~= 13[TB]

클러스터 계획¶

데이터 노드¶

다음은 Elasticsearch 클러스터 계획입니다. 단일 노드 사양이 높을수록 지원 가능한 클러스터 규모가 커집니다.

단일 노드 사양	클러스터 노드 수 상한	단일 노드 디스크 상한
2C4GB	10	200GB
2C8GB	10	400GB
4C16GB	20	800GB
8C32GB	40	1.5TB
16C64GB	80	3TB

【4C16GB】 노드를 사용할 경우, 위의 용량 추정 결과에 따른 권장 클러스터 데이터 노드 규모는 다음과 같습니다.

13T / 800G ~= 16

【8C32GB】 노드를 사용할 경우, 위의 용량 추정 결과에 따른 권장 클러스터 데이터 노드 규모는 다음과 같습니다.

13T / 1.5T ~= 9

【16C64GB】 노드를 사용할 경우, 위의 용량 추정 결과에 따른 권장 클러스터 데이터 노드 규모는 다음과 같습니다.

13T / 3T ~= 5

조정 노드¶

1:5 비율로 독립 조정 노드를 추가할 것을 권장합니다(최소 2개부터 시작). CPU:메모리는 1:4 또는 1:8입니다. 예를 들어 데이터 노드가 10개의 8C32GB인 경우, 2개의 8C32GB 독립 조정 노드를 구성할 것을 권장합니다. 관리 노드는 2n+1 고가용성 배포를 사용하여 클러스터 스플릿 브레인을 방지합니다.