SUMMARY
- 파티셔닝 전/후 메모리 부하 분산 확인
- 임계치 초과 시 slack alert
과정
- maxlen 근사치면, produce 하기전에 에러 반환하도록 하였습니다. PDL 은 따로 구성하지 않고 즉시 에러를 반환하도록 하였고 trimming 하기엔 너무 위험해서 애초에 produce 못하도록 막는게 좋습니다.
- grafana alert 통해서 임계치 알림을 전송하도록 하였습니다.
- 총 6개의 파티션을 구현하여 노드 3대에 고르게 분산되도록 설정하였고 단일 파티션 vs 멀티 파티션 분산 정도를 관측하였습니다.
테스트용 메모리 사용률 10% 이상 alert. instance 와 사용률을 메세지에 전송하도록 하였습니다.
이제 메세지 정상적으로 수신받는 것을 확인하였으니 50% 임계값 올려놓고 단일 파티션 테스트를 수행해보겠습니다.
단일 파티션 로드 테스트 수행하였고 9123 master 9125 slave 에서 50% 임계값 넘어가자마자 슬랙이 도착하였습니다! 로컬 ollama ai 에 요청하고있어서 처리량이 매우매우매우 낮습니다(gamma3 500 token 요청 시 1 tps). 그래서 lag 는 줄긴 줄지만 거의 안줄어들고 있는 것을 확인할 수 있습니다.
lag 가 쌓여있는 모습도 아래와 같이 모니터링 가능.
50% 임계치 초과 시 어떤 인스턴스가 초과한 지 슬랙 알림 및 recovered 또한 아래와 같이 전송.
파티셔닝 구현된 이후 부하분산 지표확인
이제 단일 파티션을 확인하였으니 클라이언트에서 처리하였을 떄 분산되는 것을 확인해보겠습니다. 파티셔닝 키는 arxiv 로 부터 수신받는 논문 개별 id 를 사용하였습니다.
15000 개의 논문요약 이벤트를 파티셔닝하였고 결과로 약 2500개씩 잘 분배되는 것을 확인할 수 있었습니다. 각 노드의 사용율은 30% 근처로 단일노드에 부하가 걸리는 문제를 전체노드에게 정상적으로 분산시킴으로써 해결하였습니다.