피드로 돌아가기
Dev.toBackend
원문 읽기
supabase-async: ThreadPoolExecutor에서 httpx AsyncClient로 리팩토링
httpx AsyncClient 도입으로 응답 속도 3배 향상 및 메모리 28% 절감
AI 요약
Context
ThreadPoolExecutor 기반의 Wrapper 구조로 인해 비동기 API 호출임에도 실제로는 동기적 I/O가 발생하는 Pseudo-async 구조의 한계 직면. 스레드 생성 오버헤드와 고정된 max_workers 설정으로 인한 낮은 동시성 및 메모리 낭비 문제 발생.
Technical Solution
- ThreadPoolExecutor를 제거하고 httpx AsyncClient 기반의 Native Async I/O 체계로 전환
- Lazy Initialization 패턴을 적용한 _get_client 메서드 설계로 클라이언트 생성 시점 최적화
- httpx.Limits 설정을 통한 max_connections 제어로 시스템 자원 사용량과 동시 요청 수의 균형 유지
- Context Manager(aenter, aexit) 구현을 통한 Connection Pool의 안정적인 생명주기 관리
- 요청 메서드의 통합 추상화를 통한 HTTP Method별 확장성 확보 및 중복 코드 제거
Impact
- 평균 응답 시간: 450ms에서 150ms로 단축
- 메모리 사용량: 250MB에서 180MB로 28% 감소
- 초당 처리량(TPS): 6.7 req/s에서 20 req/s로 약 3배 증가
- 최대 동시 요청 수: 3개에서 10개로 233% 확장
Key Takeaway
단순히 비동기 함수로 래핑하는 방식은 I/O Bound 작업에서 진정한 동시성을 보장하지 못함. 라이브러리 내부의 I/O 구현체가 Native Async를 지원하는지 확인하고, Connection Pooling 전략을 통해 시스템 리소스 효율을 극대화하는 설계가 필수적임.
실천 포인트
1. 비동기 라이브러리 채택 시 내부적으로 ThreadPool을 사용하는 Pseudo-async인지 검증
2. HTTP 클라이언트 사용 시 단일 세션(Client)을 재사용하는 Connection Pooling 적용 여부 확인
3. 비동기 자원 해제를 보장하기 위한 Async Context Manager 구현 검토
4. 동시성 목표 수치에 따른 max_connections 및 timeout 설정값 튜닝