server 4

1. 왜 4번 서버에만 qps가 높을까?

추측되는 상황은..

일단, 1번 ~ 4번 디비들에 대한 커넥션 개수가 비슷하게 유지된다고 했으니. 정확히는 모르지만, 각 애플리케이션 데이터 소스에서 커넥션을 맺어 풀링 할 때 디비 load balancer 같은 녀석에 의해 각 디비 노드들에 비슷한 수의 커넥션이 고르게 맺어지도록 처리되는 모양? 그럼 왜 4번 디비에만 쿼리 요청이 많았을까?

dbcp에서 커넥션을 LIFO 알로리즘으로 할당하는데, LIFO는 가장 최근에 사용됐던 커넥션을 다시 재 사용함. 이때 최근 사용됐던 커넥션 중 다수가 4번 서버와 맺어진 커넥션들이고 디비 커넥션 요청이 다수가 4번 서버와 맺어진 커넥션들 범위 내에서(아래의 빨간 박스) 사용되고 반환되고 가 반복된다면, 지금 같은 현상이 발생할 수 있지 않을까? 라는 추측을 하게 되었습니다.

그래서 LIFO 알고리즘을 FIFO로 변경하여 풀링되고 있는 커넥션을 순차적으로 사용하도록 변경하면 특정 노드에 qps가 쏠리는 현상을 해결할 수 있지 않을까? 라는 생각으로 커넥션 할당 알고리즘을 FIFO로 변경해보기로 하였습니다. 알고리즘 정책을 변경하는 것이기 때문에 변경에 따른 사이드 이팩트가 발생할 수 있는지에 대한 고민이 있었는데, 두 알고리즘의 가장 큰 차이점은 커넥션 리소스 관리(idle 커넥션 관리)로 보였는데, maxidle, minidle 설정이 같다면 어떤 알고리즘을 쓰더라도 리소스 전체 크기는 차이가 없을 것 같았고, 설정 전,후로 ngrinder를 통한 부하테스트 시에 tps의 큰 차이가 보이지 않아 성능상의 문제도 없을 것으로 판단하였습니다. (배포후 지속적인 모니터링을 통해 변경 전, 후 를 비교했으나 차이가 존재하지 않음)

2. 의문점

1. 기존에도 LIFO로 썼을 건데 왜 해당 현상이 이번에만 발생? 이번에만 우연의 일치로 4번 서버 커넥션이 위 그림처럼 할당됐나?
2. Api 서버가 6개로 들었는데, 각각 서버마다 커넥션 풀이 각각 있다며 위 현상이 발생하기는 매우 힘들어 보임, 다수 서버에서 동시에 위 그림처럼 커넥션 풀이 구성됐다는 건데 확률적으로 가능성이 낮아 보임
3. 뭔가 다른 이유가 있을 것 같기도 한데, LIFO로 다시 바꿔서 배포한 후 해당 현상이 재발되는지 테스트해 봐도 괜찮을 듯? (해당 현상이 알람만 왔지 위험한 상황은 아닌 것 같으면)

3. 기타

1. 왜 dbcp는 기본 커넥션 할당 알고리즘이 LIFO 일까? 구글링 해도 명확한 검색 결과가 안 보임. 그래서 LIFO, FIFO 장단점 및 차이점을 토대로 추측.

   • LIFO 알고리즘은 데이터베이스에 대한 활성 연결 수를 줄이는 데 도움이 되고, 활성 연결 수가 적으면 데이터베이스 서버의 리소스 사용률을 낮출 수 있으므로
     • 최근 사용됐던 녀석을 계속 재 사용하므로, 요청이 많지 않다면 많은 활성 연결이 필요치 않음
   • Idle 상태의 커넥션 관리에 좋아서.
     • 예를 들어 min-idle, max-idle 값이 같으면 idle 리소스 관리 관점에서 FIFO나 LIFO나 차이가 없을 것 같음. 어떤 걸 쓰던지 idle 상태의 커넥션을 동일 수로 유지할 것이기 때문에. 하지만 minidle < maxidle인 경우는 다를 것으로 예상, FIFO는 오래된 녀석을 먼저 쓰므로 요청이 적더라도 상대적으로 idle timeout 이 발생하는 커넥션이 LIFO에 비해 작을 것이기 떄문

2. FIFO로 갔을때 문제점?

   • 아무래도 오래된 녀석부터 먼저 사용되기 때문에 minEvictableIdleTimeMillis 을 넘겨 idle 에서 제거되는 커넥션이 LIFO에 비해 적지 않을까 예상. maxactive, maxidle 값이 설정 돼 있다면 크게 문제될 건 없어보임.. (반환 안되도 사실 계속 쌓이지 않으면 문제 없어보임)