-
질문 & 답변
카테고리
-
세부 분야
데브옵스 · 인프라
-
해결 여부
해결됨
ES 데이터노드의 적합한 인스턴스 타입이 궁금합니다.
23.03.15 01:50 작성 23.03.15 01:52 수정 조회수 277
0
안녕하세요.
사내에서 검색엔진으로 k8s에 ES를 운영하고 있는 와중에 강진우님의 Elasticsearch 강의가 있는 것을 알게되어 하루만에 빠르게 완강했습니다.
한가지 문의사항이 있어서 문의드리게 되었는데요..!
저희 사내 검색엔진 ES의 데이터 노드가 하루 중 사용량이 많은 시간대에는 CPU가 85~95%까지 치고 평소에는 3~40%를 유지중입니다.
현재 데이터노드의 인스턴스타입은 RAM(메모리 타입)인데요. 하나의 노드가 하나의 샤드와 레플리카들을 가지고 있습니다.
별다른 장애는 없었지만 매일 CPU가 95%까지 육박하고, Load average는 cpu core 수의 2~3배를 치고 있어서 개선할 수 있는 방법을 고민해보고 있는데요.
JVM 힙메모리는 맥스 30G 중 21G 정도를 상시 유지중이고, ES의 캐싱메모리를 쓰는 탓인지 Pod의 메모리는 상시 90~95%를 유지중입니다.
하여,,
Q. ES를 운영할 때 어떤 인스턴스 타입으로 운영하는게 좋을지 궁금하여 자문을 드리게 되었습니다ㅠㅠ
CPU 타입으로 하는게 좋을지,, 중간 타입으로 하는게 좋을지,, RAM(메모리) 타입으로 그대로 하는게 좋을지 잘 감이 안서네요.. 우선 RAM 타입으로 하였습니다.
감사합니다!
답변을 작성해보세요.
1
강진우
지식공유자2023.03.15
먼저 질문하신 내용에 대한 답변을 먼저 하자면 확인해 봐야 할 지표들이 조금 더 있습니다.
JVM 힙메모리는 맥스 30G 중 21G 정도를 상시 유지중
Old GC의 발생 주기가 어느 정도인지 확인이 필요한데요, 발생 주기가 길다면 메모리는 충분하기 때문에 메모리를 조금 낮추고 CPU 파워를 높일 수 있는 선택지가 있을 수 있습니다. 현재 상태에서 메모리는 낮추지 않고 CPU 파워만 높이는 게 가장 좋은 선택지 인 것 같지만 만약 그게 불가능 하다면 메모리는 낮춰도 좋을 것 같습니다.
하지만 Old GC의 발생 주기가 짧다면 CPU 파워만 높이는 선택지가 필요 합니다. ES의 색인/검색 요청 처리 자체에도 CPU가 사용 되지만 Old GC를 처리하는 과정에도 CPU가 사용되기 때문에 높은 CPU Usage가 색인/검색 요청 때문인지, 아니면 잦은 Old GC를 처리하기 위함인지를 확인해 볼 필요가 있습니다.
하루치 정도의 CPU, 메모리, 색인 및 검색 요청에 대한 지연 시간, JVM 힙메모리 의 메트릭을 볼 수 있으면 저도 더 정확한 판단이 가능할 것 같습니다.
그리고 성능 튜닝에 대해 조금 더 설명 하자면, 목표를 명확하게 잡는 게 중요 합니다. 목표가 없으면 끝이 없는 작업이 될 수 있기 때문에 예를 들어 검색 지연 시간의 99 퍼센타일 값을 100 ms 이하로 유지한다 와 같은 목표를 설정하는 게 필요 합니다.
목표를 설정 했다면 그 후에 어떤 메트릭을 개선할 것이냐를 설정해야 합니다. 말씀해 주신 상황을 가정한다면 높은 CPU Usage 가 성능에 영향을 주었을 가능성이 가장 크기 때문에 CPU Usage를 낮추는 방향으로 작업을 진행해야 합니다.
사람마다 다르겠지만 경험 상 CPU Usage는 최대 50% 미만으로 유지하도록 하는 게 좋습니다. 언급해 주신 것처럼 80~95% 에다가 Load Average 가 코어 수의 2~3배 이상의 지표로 나오는 경우가 있다면 노드가 처리할 수 있는 것보다 더 많은 요청이 인입된다고 볼 수 있기 때문에 이걸 낮추는 걸 첫번째 개선 작업으로 설정하고 진행하면 됩니다.
그럼 이제 CPU Usage를 낮추기 위해 어떻게 해야 하는가 라는 과제가 남는데요, 이 부분은 스케일 업 혹은 스케일 아웃 둘 중에 한가지를 선택해 볼 수 있습니다. 스케일 업은 노드의 사양을 높여서 노드 당 처리할 수 있는 처리량을 높이는 것, 스케일 아웃은 노드를 늘려서 노드 당 처리해야 하는 요청량을 줄이는 것 으로 생각하시면 됩니다.
스케일 업 을 할 것이냐 스케일 아웃을 할 것이냐를 결정하는 것은 정답은 없습니다만, 어떤 환경에 있느냐를 기준으로 결정해 볼 수 있습니다. 예를 들어 일별 로그를 수집하고 조회하는 시스템의 경우는 인덱스가 일 별로 생성되기 때문에 상대적으로 인덱스의 프라이머리 샤드 개수를 유연하게 가져갈 수 있기 때문에 (ex. 오늘은 5개, 내일은 10개 등으로 바꿔가며 테스트가 가능) 스케일 아웃을 좀 더 고려해 볼 수 있습니다. 노드를 늘려 놓고 샤드 설정도 변경해 놓고 다음날 쌓이는 로그부터는 더 많은 노드에게 분산되어 저장되고 검색될 수 있도록 해서 성능을 향상 시키는 방법 입니다.
하지만 검색 엔진으로 사용하는 경우는 프라이머리 샤드 개수를 유연하게 가져갈 수 없기 때문에 스케일 업 방식을 사용하는 게 더 나을 수 있습니다. 스케일 아웃 하고 프라이머리 샤드 개수를 더 늘리려고 한다면 재색인 과정이 필요하기 때문 입니다.
스케일 업을 할 때는 두 가지를 고려해 볼 수 있는데요, 말씀하신 것처럼 메모리 위주의 스케일 업이냐 CPU 위주의 스케일 업이냐 입니다. 이건 지표를 확인해 보면 명확한데요, Old GC의 발생 주기가 짧다면 메모리가 부족하다고 판단할 수 있기 때문에 메모리를 늘리고 JVM 힙 메모리를 늘리는 방식으로 스케일 업 하는 게 좋습니다. 반대로 지금 질문 주신 것처럼 GC 지표는 크게 문제가 없다면 CPU 위주의 스케일 업이 필요 합니다. 더 많은 코어 혹은 더 빠른 클럭 수를 가진 노드로 스케일 업 해서 더 많은 요청을 처리할 수 있도록 해줍니다.
이후에도 지속적으로 성능 튜닝이 필요한 상황이 이어진다면 위에 설명드린 내용들 바탕으로 진행해 보시면 좋을 것 같습니다.
파이썬고수
질문자2023.03.16
안녕하세요! 사실 성능에 크게 이슈는 없었지만 CPU 리소스가 매일 90%이상 치다보니 불안한 마음에 질문을 드려보게 되었는데 생각외로 너무 자세히 답변해주셔서 정말 감사드립니다..!
오전 10시에 발생한 Metric은 풀색인을 하며 발생한 메트릭이며, 밤 10시 ~ 새벽 2시 사이에 발생한 메트릭들은 주로 검색 요청에 대한 메트릭들입니다.
하루치의 Data 노드 메트릭입니다. 이정도면 될지 모르겠지만 우선 공유드려봅니다..!
GC Count, GC Duration, JVM Heap, CPU Utilization, System Load, Latency
Pod의 Memory (RSS + Cache)
검색 - Rate, Latency
인덱싱 - Rate, Latency
감사합니다.!
강진우
지식공유자2023.03.16
네 메트릭을 보니까 좀 더 이야기가 쉬울 것 같습니다.
검색 요청의 지연 시간이 50ms 내외로 보이는데 이게 만약 목표 하는 수치 이내 라면 현재 상황에서 특별히 성능 개선을 위한 작업은 하지 않아도 된다고 생각 합니다. 사실 CPU Usage와 Load Average가 높은 것 자체가 문제라기 보다는 그로 인해 발생하는 성능 저하 현상이 문제인데요, 현재의 성능이 목표 치 이내 라면 굳이 문제 상황으로 인식하진 않으셔도 됩니다.
다만 검색 요청의 지연 시간을 10ms로 만들어 보자 라는 목표를 삼는다면 그 때는 성능 개선이 필요한 상황이라고 생각이 되고, 지표를 보고 판단해 보자면 CPU 컴퓨팅 파워가 더 좋은 노드로 변경하는 게 좋을 것 같습니다. 재색인이 가능한 상황이라고 하면 노드를 더 늘리고 샤드도 더 늘려서 더 분산 시키는 것도 좋은 선택지가 됩니다.
재색인이 불가능한 상황이라면, 지금 같은 경우는 검색 요청이기 때문에 노드를 늘리고 레플리카 샤드만 더 분산 시킴으로서 성능을 향상 시킬 수도 있습니다.
그래서, 문의 주신 내용에 대한 답변을 하자면 경우에 따라 다르지만 지금 상황에서는 메모리 보다는 CPU 컴퓨팅 파워가 더 높은 노드가 어울리는 클러스터 환경이라고 볼 수 있습니다.
답변 1