문제 상황
나는 서버에 두 개의 GPU를 보유하고 있으며, 이를 활용하여 효율적인 로드밸런싱을 구현하려는 고민을 하고 있다. 현재 서버는 동시 요청 114건을 처리하는 데 약 2분 30초가 소요되며, 이는 H800*1EA GPU 하나만 사용한 결과다. 나는 LLM 추론 API 개발을 직접 했고, 프롬프트 엔지니어링 및 GPTQ 양자화, 적절한 비동기 스트리밍 처리 등을 직접 진행하였다.
해결방안 모색
두 가지 방안을 고민했다:
Nginx 설치를 통한 로드밸런싱: Nginx를 이용하여 웹 서버 두 개를 띄워서 각각 GPU 하나씩 점유하도록 강제하여 로드밸런싱을 처리하는 방법. 이는 더 안정적이고 장기적인 관리 측면에서 유리할 수 있으며, HA 까지도 확보할 수 있다고 생각하였다. 유일한 단점은, 현재 시간이 없는 상황에서 내부망 오프라인 환경에 NGINX를 구축하는 것.
코딩을 통한 직접 로드밸런싱 구현: 유닉스 타임을 기준으로 홀수 초에는 GPU A를, 짝수 초에는 GPU B를 사용하는 방식으로 로드밸런싱을 코드 적으로 구현하는 방법. 이는 빠른 해결책이지만, 내 머리에서 나온 하나의 대안이며, 이렇게 구현한 사례가 있는 지도 잘 모르겠고, 장기적으로는 기술 부채가 될 가능성이 있다. 다만 바로 적용 가능하다.
의사결정 과정
나는 두 가지 방안을 면밀히 검토했다. Nginx 설치를 동료 개발자에게 맡기기에는 아직 인프라적 이해도가 부족하여 믿음이 가지 않았기 때문에 내가 직접 해야했고, 현재 물리적인 시간이 절대적으로 부족하다. 후배 개발자는 GPU 두 개의 로드밸런싱이 큰 부하를 초래하지 않을 것이라며 개발적으로 해결하자는 반응을 보였으나, 나는 고민 끝에 최종적으로 Nginx 설치를 통한 로드밸런싱이 더 현명하고 장기적인 해결책이라고 판단했고, 직접 작업을 진행했다.
최종 결정 및 결과
결국 Nginx를 도입하여 GPU 간의 로드밸런싱을 구현하기로 결정했다. 이는 기술 부채를 줄이고, 장기적으로 더 관리하기 쉬운 방안이었다. 실제로 설치를 진행해보니, Nginx는 의존성이 적고 설치가 간편하여 예상 공수보다 적은 노력으로 내부망에 구축하였다. 다만, 복잡한 스트리밍 쪽 SSE를 처리하는 API에는 추가적인 설정이 필요했으나, 그다지 문제가 되지는 않았다. Nginx 설치 후, 동시 접속 114명의 요청을 모두 1분대에 처리할 수 있게 되었다. 이는 초기 2분 30초에서 크게 개선된 결과였다.
결론
이번 사례는 효율적인 자원 관리와 로드밸런싱의 중요성을 보여준다. 단기적인 해결책보다는 장기적인 안정성과 관리 용이성을 고려한 결정을 내린 점이 주목할 만하다. 또한, 개발자의 역량과 신뢰 문제를 고려한 의사결정 과정도 중요한 교훈을 제공한다. 이 사례는 엔지니어링 문제를 해결하는 데 있어 기술적 선택의 중요성과 그에 따른 관리 전략의 필요성을 잘 보여준다고 생각한다. 한 층 더 성장한 느낌을 받았다.
다음은 PostgreSQL DBMS 이중화 작업을 진행하고 포스팅해보고자 한다.
