connection pool에서 connection 순환 속도을 고려하지 않으면 조용히 서비스 성능이 악화된다.

요약

• 핵심 아이디어 한 줄 요약
• “이 노트는 왜 중요한가?” → 맥락 설명

본문

• connection pool은 현대적인 어플리케이션에서 비싼 network socket들을 재사용하려는 방식임
• 50 connection은 수 백만개의 요청을 처리할 수 있음
• 하지만 connection이 stuck 되고 pool이 shrink되다가 0이되면 느려지는게 아니라 죽음
• connection pool과 관련된 다양한 사례들
  • 링크드인은 stored procedure가 느려지면서 4시간 outage를 겪었음
  • Stripe는 downstream 서비스가 느려지면서 statving connection과 blocking all transaction으로 연속적인 결제 실페 을 겪음
• 이런 사례들은 단순히 capacity에 대한 문제가 아니라 circulation 문제 였음

core insight: 가용성을 넘는 순환 속도

• 50개의 공간을 가진 connection pool을 생각해보자
• 각 요청은 일시적으로 해당 공간을 점유함
• 만약 하나의 요청이 10ms라면 space는 빠르게 양도 될 것임 하지만 만약 어떤 사람이 10초동안 점유하고 있다면 50개의 공간은 long term parker로 인해 과도하게 점유 될 것임
• queue가 넘칠 것이고 결국에는 모든게 멈춤
• 여기 불확실한 측면이 있음 100개의 풀이 있고 각 쿼리가 평균 10ms라면 각각은 10,000QPS를 handle 할 수 있음
• 하지만 1000 pool이 100ms 쿼리라면 circulation이 느리기 때문에 더 자주 exhausted 될 것임

참고

https://howtech.substack.com/p/connection-pool-exhaustion-the-silent

˜