Elasticsearch의 클러스터링 적용 이유

부하 테스트와 엘라스틱 서치 클러스터링 적용 이유

1. 문제 발생

저번 테스트에서 생긴 TPS에 대한 원인을 특정할 수 있었다. 원래는 성능 테스트가 목적이었지만 엘라스틱 서치가 부하를 버티지 못하고 끊기는 스트레스, 부하테스트를 한 상태가 되었던 것이 문제였다. 테스트 결과를 분석한 결과, 특정 구간에서 TPS(Transactions Per Second) 값이 급격히 하락하는 문제가 발생했다. 이는 시스템이 특정 시점에서 부하를 감당하지 못하거나, 처리 한계를 초과했음을 의미했다.

2. 문제 원인

• TPS의 급격한 하락
  • 초기 TPS가 일정하게 유지되다가 특정 시점에서 크게 하락하는 패턴이 반복됨.
  • 이는 과부하 상태에서 시스템이 응답하지 못하거나, 노드 간 부하 분산이 제대로 이루어지지 않는 문제일 가능성이 있음.
• 성공한 테스트 대비 높은 에러율
  • 총 테스트 요청: 57,058건
  • 성공한 테스트: 40,912건
  • 에러 발생: 16,146건 → 약 28%의 실패율
  • 높은 에러율은 노드의 부하 분산이 제대로 이루어지지 않거나, 특정 트랜잭션이 처리되지 못하는 문제가 있을 가능성을 시사함.
• TPS의 변동성
  • TPS가 140에서 280까지 변동하는 것을 보면, 일정한 부하를 유지하지 못하고 성능이 들쭉날쭉함.
  • 이는 단일 노드 또는 특정 서버가 병목이 되어 전체 성능을 저하시킬 가능성이 큼.

 

3. 문제 해결책 수립

해결 방법 비교

해결 방법	설명	장점	단점
단일 노드 확장	서버의 스펙을 올려 처리 성능 증가	설정이 간단하고 빠른 대응 가능	확장성이 떨어지고, 비용이 급증함
로드 밸런서 추가	부하 분산을 위한 로드 밸런서를 활용	부하 균등 분배 가능	부하 분산만으로 해결되지 않는 경우도 있음
엘라스틱 서치 클러스터링 적용	다중 노드 분산 처리로 부하 분산	확장성이 뛰어나고, TPS 유지 가능	초기 설정 및 운영 복잡성 증가

 

4. 왜 클러스터링을 선택했는가?

(1) 단일 노드 확장의 한계

• 단일 노드의 스펙을 올리는 방식은 일정한 한계치(물리적인 성능 한계)에 도달하면 더 이상 확장할 수 없음.
• 노드 하나에 부하가 집중되면 하드웨어 장애 발생 시 서비스 전체가 다운될 위험이 있음.
• 비용이 선형적으로 증가하지 않고, 급격히 증가하는 경향이 있음.

(2) 로드 밸런서만으로는 해결되지 않는 문제

• 로드 밸런서는 요청을 여러 서버로 분산해주지만, 엘라스틱 서치 내부의 인덱스와 샤드 관리는 그대로 단일 노드의 성능에 의존.
• 검색 및 인덱싱이 단일 노드에서 수행되면 백엔드에서 처리 부하를 감당하지 못하는 문제가 발생.
• 결국, 내부적으로 데이터 저장과 검색 성능을 분산할 수 있는 구조가 필요.

 

5. 문제 해결: 엘라스틱 서치 클러스터링 적용

(1) 부하 분산을 위한 클러스터링

• 단일 노드의 한계를 극복하기 위해 엘라스틱 서치 클러스터링을 적용했다.
• 기존에는 단일 노드에서 모든 검색 요청을 처리했으나, 여러 개의 노드가 부하를 나누어 처리하도록 구성하여 TPS를 안정적으로 유지할 수 있도록 함.
• 클러스터링을 통해 특정 노드가 과부하 상태가 되더라도, 다른 노드가 부하를 분산하여 트랜잭션 실패율을 감소시킬 수 있음.

(2) 데이터 샤딩(Sharding) 최적화

• 기존에는 하나의 인덱스에 모든 데이터가 저장되었지만, 샤딩을 통해 데이터를 여러 개의 노드에 분산 저장함.
• TPS가 일정 수준에서 급격히 하락하는 현상을 줄이기 위해, 샤드 크기를 최적화하여 처리 속도를 향상시킴.

(3) 고가용성을 위한 리플리카(Replica) 설정

• 특정 노드가 과부하로 다운되거나 장애가 발생하더라도, 리플리카 노드를 통해 동일한 데이터를 제공할 수 있도록 설정.
• 이를 통해 TPS 변동성을 최소화하고, 부하가 증가하더라도 안정적인 성능을 유지할 수 있도록 함.

 

6. 결론

• 부하 테스트 결과, 단일 노드 운영으로 인해 TPS 변동성이 크고, 특정 시점에서 성능이 급격히 저하되는 문제가 발생했다.
• 이를 해결하기 위해 엘라스틱 서치 클러스터링을 적용하여 다중 노드 운영을 통해 부하를 분산시켰다.
• 클러스터링을 선택한 이유는 단일 노드 확장의 한계를 극복하고, 로드 밸런서만으로 해결할 수 없는 내부 데이터 분산을 최적화하기 위함이다.
• 샤딩 및 리플리카 설정을 최적화하여 검색 성능을 유지하면서도, 안정적인 TPS를 확보할 수 있도록 했다.
• 결과적으로, 대규모 트랜잭션이 발생하는 환경에서도 확장성과 성능을 보장할 수 있도록 시스템을 개선했다.