하루 100GB 로그를 30기간 저장하는 클러스터 예시중 질문이 있습니다.

안녕하세요.하루에 600GB가 쌓이는 게 아니고 하루에 100GB 씩 쌓이는 로그가 30일 보관 되는 예시 입니다. nginx-access-log-2025.01.01 , nginx-access-log-2025.01.02 이런 식으로 하루에 100GB의 로그가 최대 30개까지의 인덱스가 쌓이는 거죠. 그래서 말씀 하신것처럼 매일매일 노드는 20GB 씩 저장공간이 필요하고 30일이니까 노드 당 최소 600GB의 저장공간이 필요해 집니다.계산은 바르게 된 것 같은데 혹시 더 궁금하신 게 있으실까요~? 😃

노드당 샤드수 제한 질문입니다.

max_shards_per_node 설정 이슈라기보다는, 특정 노드에 샤드가 몰리는 현상으로 이해했습니다. 맞나요? 😃전체 샤드가 노드에 얼마나 균등하게 배치되는지는 인덱스별 샤드 개수에 따라 달라지고, 샤드 배치 전략의 영향을 받기 때문에 모든 노드가 비슷한 수의 샤드를 가지지 않을 수도 있습니다. 샤드 밸런싱을 맞추기 위해 샤드가 지속적으로 이동 중일 가능성도 있습니다.고려해야 할 변수가 많아서 딱 어떤 문제다 라고 말씀드리긴 어렵지만, 우선 인덱스별 샤드 수가 고르게 설정되어 있는지, 각 노드의 저장 공간은 유사한지 등을 확인해 보시면 좋을 것 같습니다.

lscpu -e 옵션과 dmesg -T 옵션이 없습니다.

제가 답변을 너무 늦게 달았네요. CentOS 6.3 은 너무 오래된 버전이라서 일부 명령어들의 옵션이 부족할 수 있습니다. 이런 경우에는 (사실 OS 버전 업그레이드가 가장 좋겠지만) lscpu나 dmesg 명령의 최신 버전 소스 코드를 받아서 직접 컴파일 해서 사용하는 방법도 있긴 하지만 단순히 두 명령어 사용을 위해 컴파일까지 하는 건 오버 엔지니어링이 될 수도 있습니다.대체할 만한 다른 옵션은 특별히 존재하진 않아서 lscpu 명령이나 dmesg 명령의 결과를 파싱해서 확용해 보는 추가적인 방법이 있을 수 있습니다.

노드에서의 가용영역 이슈

Logstash가 자신과 같은 리전에 있는 데이터노드에 데이터를 적재 한다고 해도, ES 데이터노드 간 레플리카 설정으로 인해 리전 간 데이터 전송이 발생할 수 밖에 없는 구조 입니다. 또한 결국 ES 인덱스의 샤드가 원하는 데이터노드에 배치되어야 하는 조건도 있어서 굉장히 복잡한 구조가 될 수 있습니다. ES는 클러스터이고 어떤 노드에 어떤 데이터를 넣어도 색인이 된다는 게 유연하면서도 지금같은 경우에는 많은 양의 리전간 트래픽을 발생 시킬 수 밖에 없죠.그래서 AWS 상에 구축할 때는 OpenSearch를 많이 사용 합니다. OpenSearch는 데이터노드 간 주고 받는 리전 간 트래픽은 과금이 되지 않거든요.그럼에도 불구하고 꼭 ES를 구축해서 사용해야 한다면 레플리카 설정을 줄이는 게 하나의 방법이 될 수 있습니다. 로그의 원본을 S3에 저장하고, 원활한 조회를 위해 ES에 쌓는다면 ES에 쌓을 때는 레플리카를 0 으로 만들어서 최소한 샤드 간 복제를 위한 데이터 만이라도 줄일 수 있겠죠. 대신 이럴 경우 데이터 노드에 이슈가 발생할 경우 클러스터가 바로 RED 상태가 될 수 있고, ES에 색인되는 로그들이 유실될 수 있는 가능성이 있지만 로그 원본이 S3에도 저장되고 있기 때문에 필요하다면 S3에 저장된 로그를 다시 ES에 색인하는 식으로 해결도 가능 합니다. 결국 비용을 줄이고 운영 부담을 늘리느냐를 결정해야 하는 문제가 됩니다.

노드당 샤드 수 질문입니다.

아마도 ElasticSearch를 운영하면서 가장 많이 고민하게 되는 것들 중 하나가 노드 당 샤드 수 일 겁니다. 과연 노드 당 몇 개의 샤드를 가지는 게 적절한가 라는 건 ES를 운영하는 수많은 엔지니어들의 고민이 될 겁니다. 😅첫 번째 질문인 1400개일 경우 적절한지 혹은 2~3천개로 늘려도 괜찮을까요? 부터 생각해 본다면, 제 개인적인 경험 상 2~3천개 까지도 크게 성능 저하가 없긴 했습니다. 다만, 그 때 당시 제가 사용하던 노드들의 하드웨어 사양이 꽤 좋았기 때문에 (CPU 코어 수 16개, 메모리 32GB 정도) 성능을 충분히 낼 수 있었을 거라고 생각 합니다. 결국 성능에 영향이 없다면 조금씩 계속 늘려가도 괜찮다고 생각 합니다.두 번째 질문인 노드당 샤드수가 많을 경우 발생할 수 있는 문제점이 무엇인지 궁금합니다. 를 생각해 본다면, 이게 가장 중요한 질문이긴 한데, 결국 성능 저하가 발생할 수 있다는 것이겠죠. 노드 당 샤드 수가 많을 경우 힙메모리 사용량이 증가하고 이로 인해 GC가 자주 발생하게 되는 경우가 생길 거고, max shards per node 와 같은 설정을 변경하지 않으면 이로 인한 이슈가 발생할 수도 있겠죠. 결국 노드 당 샤드 수는 몇 개가 적절한가는 사용하는 노드의 사양에 따라 다를 겁니다. 샤드의 크기를 크게 해서 노드 당 샤드 수를 줄일 수도 있고, 샤드의 크기를 작게 해서 노드 당 샤드 수를 늘릴 수도 있구요. 중요한 건 설정을 계속 바꿔 가면서, 성능에 영향이 있느냐 없느냐를 모니터링 하는 방법 밖에 없습니다. 노드의 CPU, 메모리 사용량이 어떻게 변화 하는지, 색인 성능과 검색 성능, GC 성능이 어떻게 변화하는지를 계속 모니터링 하고 추적해 가면서 현재 환경에서의 가장 적절한 값을 찾아야 합니다.위에 언급한 지표들 역시 환경에 따라 다를텐데, 이에 대한 기준도 세울 필요가 있습니다. 예를 들어 CPU Usage 30% 미만, 색인 성능은 100ms 미만, 검색 성능은 10ms 미만 을 성능의 마지노선을 삼겠다고 기준을 삼았다면 이에 맞게 노드 당 샤드 수를 늘리거나 줄이면서 저 지표들이 어떻게 변화하는지를 보는거죠. 그래서 본인의 환경에 맞는 최적의 값을 찾을 수 있어야 합니다.

메모리 관련 문의드립니다.

free 명령어의 used 영역은 시스템에서 사용하는 전체 메모리의 양 입니다. 따라서 RSS 영역의 총합과 정확히 같지는 않고, 조금 더 크게 나올 수 있습니다.아래 명령어를 사용하면 ps 명령의 결과 중 RSS 값(프로세스들이 실제 사용하는 메모리의 총합)을 구할 수 있습니다.ps aux | awk '{sum += $6} END {print sum}'이 값을 free -k 명령의 used 값과 비교하면 됩니다. 큰 차이는 없겠지만, 커널이 사용하는 메모리 등 개별 프로세스 외에도 메모리를 사용하는 영역이 있기 때문에 차이가 발생할 수 있습니다.실제 서버 모니터링에서는 RSS를 직접 측정하고 관리하지 않습니다. 개별 프로세스의 메모리를 모니터링하면 좋겠지만, 서버 부하 증가 등의 이유로 일반적으로는 전체 시스템 메모리를 모니터링하는 방식이 더 유용합니다.하지만 전체 시스템 메모리가 지속적으로 증가하는 경향(우상향)이 보인다면, 그때는 RSS 모니터링을 통해 어떤 프로세스에서 메모리 사용이 증가하는지를 분석하는 것이 도움이 될 수 있습니다. 😊

루트 모듈 구성

질문 감사합니다. ^^ 개별적 관리와 중앙 집약적 관리가 정확히 어떤 걸 의미하는지 모르겠지만 우선 본 강의에서 예제로 사용하고 있는 구조 (이하 1번 구조라고 칭하겠습니다.) 와 S3ymphony 님이 생각하시는 구조 (이하 2번 구조라고 칭하겠습니다.) 중 어떤 게 베스트 프랙티스인지 문의 하신 걸로 이해했습니다.모듈은 말 그대로 모듈이기 때문에 이곳 저곳에서 확장성 있게 사용 될 수 있어야 하고, 다른 모듈과의 조합을 통해 구성을 효율적으로 사용할 수 있어야 합니다. 사실 그걸 달성할 수 있다면 구조는 큰 문제가 되진 않습니다.예를 들면 아래와 같은 구조도 가능하겠죠.modulesvpcmain.tfoutputs.tfvariables.tfbastionmain.tfoutputs.tfvariables.tfoimarketapne2vpc.tf bastion.tf usw1vpc.tf bastion.tf 모듈만 잘 나눠져 있다면 그걸 사용하는 구조는 어떻게 되어도 괜찮다는 이야기 입니다. 다만 2번 구조의 경우 vpc 모듈과 ec2 모듈을 다른 코드에서 사용하려면 어떻게 할 수 있을지 확장성이 잘 안보이긴 합니다. 이미 최상단에 main.tf 파일이 위치해 있어서 하단에 있는 모듈을 사용하게 한다면 그 모듈을 사용할 또 다른 main.tf는 어디에 있는게 좋을지는 결정하기 어려워 보이긴 합니다.

색인과정 이해하기 중 질문입니다.

데이터 노드의 경우는 기본값이나 직접 설정이 가능한가요? 따로 설정한 부분이나 설명이 없는데 초기 그림부터 세개의 데이터 노드가 존재하는 부분에 의문이 생깁니다.데이터 노드의 갯수와 프라이머리 샤드, 레플리카 샤드의 갯수 설정과는 연관이 없습니다. 데이터 노드는 운영자의 의지에 따라 1대로 구성할 수도, 100대로 구성할 수도 있습니다. ElasticSearch를 설치하고 노드 타입을 데이터 노드로 설정한 후에 클러스터에 조인만 시키면 되거든요. 문의 주신 것처럼 프라이머리 샤드, 레플리카 샤드의 설정 값이 모두 1인데 데이터 노드가 10개라면 나머지 8대는 아무것도 하지 않고 놀고 있겠죠. (물론 인덱스의 개수가 다수이고 이에 따라 샤드가 전체 노드에 퍼져 있다면 아무것도 하지 않고 놀고 있진 않겠지만, 하나의 인덱스에서 발생하는 색인이나 검색을 기준으로 한다면 8대가 놀고 있는 건 맞습니다.)따라서 데이터 노드의 대수를 기준으로 샤드의 배치를 고려해서 프라이머리 샤드와 레플리카 샤드의 설정 값을 조정해야 합니다.요약 하자면, 데이터 노드의 개수는 운영자의 의지를 바탕으로 자유롭게 조정이 가능하다 라고 보시면 됩니다.혹시 답변이 되셨을까요?

xlsx 파일 색인 중 CircuitBreakingException 발생

정확하게 어떤 요소들이 힙 메모리를 채우고 있는지 확인하려면 꽤 복잡한 분석 과정을 거쳐야 합니다. VisualGC 등을 이용해서 힙 메모리를 시각화 하는 것도 필요하죠. 지금같은 경우 그렇게 복잡하게 분석 과정을 거치기 어렵다면 다음과 같은 방법들을 사용해 볼 수 있습니다.엑셀 파일을 일정한 크기로 잘라서 나눠 색인 해보기 -> 이렇게 해서 문제가 발생하지 않는다면 파일 용량에 따른 이슈로 판단하고 엑셀 파일을 잘라서 색인해 볼 수 있겠죠.기본 애널라이저로 설정해서 색인 해보기 -> 이렇게 해서 문제가 발생하지 않는다면 애널라이저에 따른 이슈로 판단하고 min_gram 값을 변경하거나 등의 다양한 색인 방법을 고민해 볼 수 있겠죠.힙 메모리를 늘려서 색인 해보기 -> 이렇게 해서 문제가 발생하지 않는다면 힙 메모리 부족으로 생각하고 늘려서 대응할 수 있겠죠.이렇게 몇가지 가설을 세워 놓고 각 가설에 따른 테스트 결과를 바탕으로 원인을 파악하고 해결하는 것도 좋은 방법 입니다. 시간은 조금 더 걸리겠지만 테스트를 진행하면서 조금 더 동작 원리를 이해할 수 있는 계기가 될 수도 있습니다.

ES 트러블슈팅 사례분석 강의 내용중 궁금한 게 있습니다.

워터마크 설정을 %로 하는 것과 용량으로 하는 것은 의미가 동일 합니다. cluster.routing.allocation.disk.watermark.high: 22.0gb는 남은 디스크 용량이 22gb 이하인 노드들의 샤드를 강제로 다른 노드로 배치 시키는 설정 입니다. 샤드를 강제로 옮겨서 해당 노드의 디스크 용량을 확보하게 됩니다. 자세한 설명은 https://www.elastic.co/guide/en/elasticsearch/reference/7.17/modules-cluster.html 을 참고 하시면 됩니다. 트러블슈팅 사례 #3의 경우는 큐에 담을 수 있는 이상의 문서를 색인할 때 발생하는 Rejected 에러와 관련된 내용 입니다. 강의에서 언급 되었던 것처럼 데이터 노드 증설이 효과를 보려면 샤드의 개수를 조절할 수 있어야 합니다. 그래서 샤드의 개수를 조절할 수 없다면 데이터 노드 증설은 효과를 볼 수 없습니다. 검색 엔진 용도의 클러스터라면 노드를 증설하고 샤드의 개수를 늘린 새로운 인덱스를 만들어 재색인을 해야 효과를 볼 수 있습니다. 만약 로그 수집 용도의 클러스터라면 오늘치 로그는 어쩔 수 없어도, 내일부터 쌓이는 로그는 정상적으로 쌓이도록 인덱스 템플릿 등에서 샤드의 개수를 수정하는 방식으로 진행할 수 있습니다.