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

데이터 노드의 경우는 기본값이나 직접 설정이 가능한가요? 따로 설정한 부분이나 설명이 없는데 초기 그림부터 세개의 데이터 노드가 존재하는 부분에 의문이 생깁니다.데이터 노드의 갯수와 프라이머리 샤드, 레플리카 샤드의 갯수 설정과는 연관이 없습니다. 데이터 노드는 운영자의 의지에 따라 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 에러와 관련된 내용 입니다. 강의에서 언급 되었던 것처럼 데이터 노드 증설이 효과를 보려면 샤드의 개수를 조절할 수 있어야 합니다. 그래서 샤드의 개수를 조절할 수 없다면 데이터 노드 증설은 효과를 볼 수 없습니다. 검색 엔진 용도의 클러스터라면 노드를 증설하고 샤드의 개수를 늘린 새로운 인덱스를 만들어 재색인을 해야 효과를 볼 수 있습니다. 만약 로그 수집 용도의 클러스터라면 오늘치 로그는 어쩔 수 없어도, 내일부터 쌓이는 로그는 정상적으로 쌓이도록 인덱스 템플릿 등에서 샤드의 개수를 수정하는 방식으로 진행할 수 있습니다.

동잭매핑 매핑 시 색인 질문

네. 이거 제가 직접 해보니 말씀 하신 것처럼 ratings: "3.0" 도 색인이 되네요. 다만 ratings: "abc" 이렇게 같은 따옴표라도 명시적으로 문자열인 경우에는 매핑 에러가 발생하구요.그리고 처음부터 ratings: "3.0" 으로 색인할 경우에는 매핑이 keyword 로 되긴 합니다. 따라서 현재 이슈는 float 타입으로 생성된 매핑 정보에서 "숫자" 타입의 데이터가 색인이 되는 게 문제로 보입니다. 이건 시간을 두고 좀 더 확인해 봐야 할 것 같습니다. 업데이트 되는 내용이 있으면 다시 공유 드리겠습니다.

좀비프로세스,자식프로세스

네 안녕하세요.고아 프로세스는 부모 프로세스가 죽은 것이 맞고, 좀비 프로세스는 자식이 부모에게 자신의 종료를 제대로 전달하지 못해서, 부모가 자식 프로세스의 정보를 정리하지 못하는 경우를 의미 합니다. kill 명령 등으로 강제로 죽일 수 있지만, 그런 외부의 방법이 아니고서는 프로세스가 정리되지 않습니다. 자식프로세스를 호출하지 못한다는 의미가 좀 애매한데, 좀비가 된 자식 프로세스는 이제 자신이 해야 할 모든 일을 마쳤기 때문에 스케쥴링 되지 않고 따라서 CPU 와 메모리 같은 리소스를 사용하지 않습니다. 따라서 자원회수가 안된다기 보다는 PID 회수가 안된다고 보는 게 더 정확 합니다.swap cached 는 강제로 스왑을 다시 생성할 경우 정리가 되지만 그 외의 경우는 특별히 없어지진 않습니다. 메모리가 부족해서 메모리 영역의 재할당이 필요할 경우에는 정리가 될거구요. 스왑 영역을 재할당 하는 방법은 (https://brunch.co.kr/@alden/22) 를 참고 하시면 됩니다. 하지만 운영 환경의 서버에서는 특별한 경우가 아니면 하지 않기를 권고 합니다. 어떤 부작용이 일어날지 알 수 없기 때문 입니다. I/O가 갑자기 증가하거나, CPU 사용량이 증가할 수 있습니다.현업에서는 특별히 고아 프로세스가 문제를 일으킨 적은 없기 때문에 따로 확인하진 않았습니다. 실제로 좀비 프로세스의 경우도 문제가 되는 경우는 극히 드물었습니다.

좀비프로세스 자원 관련 질문입니다

네. 좀비 프로세스는 CPU나 메모리를 사용하진 않습니다. 다만 PID를 차지하고 있기 때문에 다수가 쌓이게 되면 PID 고갈 현상이 발생할 수 있습니다.좀비 프로세스를 확인하려면 ps aux | grep Z 와 같이 입력해서 확인할 수 있습니다.

네트워크 소켓 옵션 확인 방법 관련

답변이 늦었습니다. 사실 제가 지금까지 네트워크 트러블슈팅을 경험할 때에는 소켓 옵션까지 확인할 필요는 없었어서 SO_REUSEADDR과 같은 소켓 옵션이 적용되어 있는지 여부를 확인하진 않았습니다.찾아보니 ss, netstat 명령으로도 소켓 옵션은 확인이 불가능 한 것 같습니다.저는 보통 ss -s, netstat -napo 명령을 주로 사용 했었습니다. 특히 netstat -napo 는 소켓 킵얼라이브 타이머를 함께 볼 수 있어서 좀비 커넥션 같은 것들을 추적하는데 유용하게 사용 했었습니다.

Elastic Search 동작 이해하기 색인 설명 관련

네. 말씀 드렸던 것처럼 샤드를 도중에 변경할 수는 없습니다. 그래서 운영 환경에 적용하기 전에 충분히 테스트를 해야 합니다. 예를 들어 프라이머리 샤드의 개수가 몇 개일 때 우리가 원하는 성능이 나오는지 수차례 테스트 하면서 그 최적의 값을 찾아야 합니다. 그리고 만약 운영 환경에 이미 적용한 후에 이런 과정을 거치려면 Reindex API를 통해서 새로운 인덱스에 재색인을 하는 방식으로 진행 해야 합니다.

Compressed OOP 조건에 따른 ES Heap Size 제약

_bulk 인덱싱 할 때 데이터 노드들에게만 REST API로 요청을 하셨을까요? ES는 클러스터 이기 때문에 마스터 노드, 코디네이팅 노드에게 인덱싱을 해도 내부에서 데이터 노드로 라우팅이 되는 구조이기 때문에 명시적으로 데이터 노드를 통해서만 인덱싱을 하는 게 좋습니다. 쿠버네티스로 구성 하셨다고 하니 인덱싱을 위해 생성한 엔드포인트 URL 이 데이터 노드들만 가리키는지를 확인해 볼 필요가 있습니다.데이터 노드 파드들이 죽을 때 OOM으로 죽은 걸까요? 파드가 죽을 때 죽는 이유가 나올 텐데 그 이유가 명확하게 어떤 게 나오는지 궁금합니다.위에 말씀해 주신 제약 조건 이면 데이터 노드들의 힙 메모리로 30GB 정도 주는 것은 충분할 것 같습니다. 서킷브레이킹 리밋을 줄이는 건 임시 방편이고, 메모리가 제대로 비워지지 않는 이유를 확인해야 합니다. Old GC가 발생해도 Old 영역에 메모리가 비워지지 않는 이유를 봐야 하는데요 필드 데이터 때문에 이런 경우가 발생할 수 있으니 텍스트 타입의 필드들에 필드 데이터가 켜져 있는지 살펴 보시면 좋을 것 같습니다. (https://www.elastic.co/guide/en/elasticsearch/reference/current/text.html#fielddata-mapping-param)

top 명령어 살펴보기 (2)에서의 좀비 프로세스에 대한 질문입니다.

네. 이건 제가 표현을 제대로 못한 것 같네요. 자식 프로세스가 부모 프로세스보다 먼저 종료된다기 보다는 (대부분 자식이 먼저 종료되는 게 맞긴 하겠죠~) 자식 프로세스의 종료를 부모 프로세스가 정리하지 못하게 되는 경우, 즉 부모 프로세스가 wait() 를 호출하지 못하는 경우에 발생 합니다. 이를 부모 프로세스가 먼저 죽은 경우로 표현 했는데 이 부분은 제가 잘못 알고 실수 한 것 같습니다.(사진)이 그림과 이 다음 그림(사진)에서 부모가 exit()로 끝나는 게 아닌 어떤 이유로 wait()를 호출하지 못하는 경우로 바꿔야 할 것 같네요. 알려 주셔서 감사합니다. 강의는 최대한 빠르게 수정 하도록 하겠습니다.