Project Improvement (Architectural Enhancements)
CodeMentor 프로젝트 개선 과정
Last updated
CodeMentor 프로젝트 개선 과정
Last updated
CodeMentor 프로젝트는 처음 단일 서버로 시작했었습니다. 모든 요청들이 하나의 서버에서 처리되었고, 이는 조회 요청에는 효율적이었지만, 유저 코드 제출과 같은 복잡한 작업에서는 문제가 있었습니다.
저희 프로젝트는 유저 코드 제출시, 기존 코드가 정답인지 확인을 하는 작업이 필요했고, 이는 코드가 실행되는 서버를 별도에 두고 실행을 해야했습니다. Time Out을 설정하긴 했지만, 코드 실행에 시간이 많이 소요가 되었습니다. 코드 실행 뿐만 아니라, GPT3.5 모델을 통해 유저의 코드에 대한 피드백과 모범 수정 코드를 생성하는 요청도 같이 보냈었습니다. 단일 요청에 대해서 두가지 과정을 다 거치고 요청 값을 돌려주는데에 짧게는 몇초, 길게는 2분의 시간 지연이 발생했었습니다. 여러 요청들이 들어왔을때, 앞의 요청들이 끝나지 않아서 뒤에 있는 요청들이 기다리는 시간이 길어지는 병목현상이 나타났습니다. 이를 해결하기 위한 새로운 접근 방식이 필요했습니다.
요약:
문제: 단일 서버에서 모든 요청을 처리하면서 코드 실행과 GPT 피드백 처리로 인해 병목 현상이 발생
단일 요청에 대해 코드 실행 및 GPT 응답 과정이 순차적으로 처리되어 지연 발생
요청 대기 시간이 길어지며 시스템 응답 속도가 저하
Python 코드는 평균 1.53초, Java 코드는 2.98초 소요
위 문제를 해결하고자 비동기 처리 방식을 도입했습니다.
@Async를 도입하면서, 저희 서비스는 이제 다수의 요청들을 동시에 처리할 수 있게 되었습니다. 이는 각 요청이 독립적으로 처리됬고, 결과적으로 전체 시스템의 응답 시간을 크게 단축시켰습니다. 이 방식을 통해 대기 시간을 최소화하여 처리 속도를 효율적으로 개선했었습니다.
하지만, 이번에는 코드 실행 서버에서 문제가 발생했었습니다. 많은 요청들이 한꺼번에 들어오게 됐을때, 해당 서버가 터지는 등, 비정상적인 종료가 발생했었습니다.
요약:
해결: 비동기 작업으로 다수의 요청을 병렬 처리하여 응답 시간을 단축
새로운 문제: 트래픽이 더욱 커지면, 코드 실행 서버가 비정상적으로 종료
수직적 확장과 수평적 확장을 통해 해당 문제를 해결할 수 있을거라 생각하였습니다. 저희는 수평적 확장을 생각했었고, 그 이유는 수직적 확장은 한계가 있고, 리소스 낭비가 심할거라 생각했습니다. 당장은 4개의 서버로 확장을 했었고, 이는 적절한 해결법이 아니었습니다. 결국 4개의 서버가 수용할 수 있는 요청들을 넘어가는 경우도 고려를 했었고, 중간에 Kafka*와 Evaluation(리스너) 서버를 둬서 많은 요청에 대해서도 적절히 요청을 분배하고, 수용 가능한 요청들에 대해서만 처리하도록 설계하여, 부하가 커질때에도 코드 실행 서버가 비정상적으로 종료되지 않도록 하였습니다. 하지만, 이는 시스템적 문제는 해결하였지만, 성능적 문제는 해결하지 못했습니다. 이번에는 처음 요청을 받는 Execute 서버에서 병목 현상이 생기기 시작했습니다.
요약:
해결: 메시징 큐를 도입하고, Evaluation서버를 추가해 요청을 분산 처리
메시징 큐를 통해 요청을 일시적으로 저장, 안정적 처리를 보장
서버의 수평적 확장을 통해 트래픽 부하를 분산
새로운 문제: Execute 서버에서 다른 API 요청(문제 조회 등)으로 인해 병목 현상이 재발 가능
특정 도메인의 트래픽 급증이 전체 시스템 성능에 영향을 미침
유저 코드 제출이 가장 부담이 큰 요청이긴 하지만, 유일한 요청은 아니기 때문에, 다른 조회나 로그인, 회원가입 등의 요청에 지장이 생기기 시작했습니다. 기본적으로 유저 코드 제출은 관련 문제들과 실행이 되기 위한 코드 등, 여러번의 DB Read가 일어났고, 요청에 대해 총 3번의 Write가 발생합니다*. 성능적으로 저하되는 부분을 해결하고자, 하나의 서비스를 도메인별로 분리하였습니다.
*(Trade-off를 고려했을때 실시간성이 더 중요하다 판단하여 내린 결정이었습니다.)
요약:
해결: 도메인별 서버 분리 및 데이터베이스 재설계
주요 도메인을 User, Question, Execute로 분리
각 도메인에 최적화된 데이터베이스 설계를 통해 효율성 강화
API 게이트웨이를 통해 요청을 분배하고 각 도메인에 특화된 서버로 요청 처리
API게이트웨이 서버를제외하고 총 3개의 도메인으로 분리를 하였고, DB 또한 각각의 도메인 별로 나누게 됬었습니다. 결론적으로, 프로젝트는 총 5개의 서버로 이루어지게 되었고 큰 프로젝트가 되었습니다.
서버를 개별로 관리하다보니 관리하기가 어려웠습니다. 이를 해결하기 위해 쿠버네티스 도입(모노레포)을 시도해봤습니다. 쿠버네티스를 직접 구축하기에는 시간이 촉박하여 옵스 개발자의 도움을 받아서 쿠버네티스 환경을 만들었었습니다. (많은 도움을 주신 팀원 이강훈 님께 감사드립니다..!) 이를 통하여 많은 병목 현상을 해결하였고, 모노레포를 통해 관리가 많이 편해졌었습니다.
k8s 도입으로, 각 pod에 대한 헬스체크가 가능해졌었습니다. 이를 통해 기존에 여러 서버를 띄어놨던 코드 실행 서버들을 두개로 줄였고, Liveness Probe를 통해, 카프카의 상태에 따라 동적으로 확장되어 많은 요청에 대해 유연하게 처리함과 동시에, 리소스를 아낄 수 있게 되었습니다.
아키텍처:
유저의 상호작용: 유저는 API Gateway를 통해 Server-Sent Events(SSE) 연결을 맺습니다. 이 연결을 통해 유저는 정답 코드를 제출하게 됩니다.
인증 및 라우팅: 제출된 코드는 먼저 인증 과정을 거친 후, URI prefix에 기반하여 적절한 서버(이 경우 Execute서버)로 라우팅됩니다.
Question 서버와의 상호작용: Execute서버는 Question서버에 문제 정보, 테스트케이스 및 언어별 실행 코드를 요청합니다.
메시징 큐를 통한 데이터 처리: Usercode에 정보를 저장한 후, 요청을 일시적으로 저장하기 위해 메시징 큐로 전송합니다.
Evaluation 서버의 역할: 코드 실행 서버와 GPT API를 비동기 방식으로 호출합니다.
결과의 전달: 처리된 결과는 초기에 맺은 SSE 연결을 통해 유저에게 결과를 전달합니다.
결론적으로, 작은 프로젝트의 규모가 생각보다 커지게 됬습니다. MSA로 전환을 통해 프로젝트가 더욱 빠르고 안정성이 높아졌지만, 이를 위해 의존성 분리 등, 리팩토링 작업이 너무 고단했습니다.... 하지만 프로젝트의 목적을 위해서는 필요한 작업이었다고 생각합니다. (백준에서 문제를 푸는데 코드 결과를 받기 위해 몇분을 기다린다는건 말도 안된다 생각이 되고, 처리속도가 느리다면 답답했을것 같습니다.)
비즈니스 성과
비동기 처리로 코드 실행 및 GPT 응답 시간이 단축, 전체 처리 속도 개선
메시징큐 및 Evaluation 서버 도입으로 요청 처리 안정성 확보
도메인을 분리하여 트래픽 분산 및 응답 속도 개선
*(카프카 도입에 대한 설명은 따로 정리했습니다. )
