Implementation of K8s
쿠버네티스 도입 배경과 CodeMentoor 프로젝트 개선 과정
Last updated
쿠버네티스 도입 배경과 CodeMentoor 프로젝트 개선 과정
Last updated
컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법입니다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고, 가동 중지 시간이 없는지 계속 확인해야합니다. 예시로 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야할때, 이 작업을 시스템에 의해 처리되야합니다. 쿠버네티스는 이러한 작업들을 탄력적으로 실행하기 위한 프레임워크를 제공합니다.
CodeMentor 프로젝트는 처음 단일 서버로 시작했었습니다. 모든 요청들이 하나의 서버에서 처리되었고, 이는 조회 요청에는 효율적이었지만, 유저 코드 제출과 같은 복잡한 작업에서는 문제가 있었습니다.
저희 프로젝트는 유저 코드 제출시, 기존 코드가 정답인지 확인을 하는 작업이 필요했고, 이는 코드가 실행되는 서버를 별도에 두고 실행을 해야했습니다. Time Out을 설정하긴 했지만, 코드 실행에 시간이 많이 소요가 되었습니다. 코드 실행 뿐만 아니라, GPT3.5 모델을 통해 유저의 코드에 대한 피드백과 모범 수정 코드를 생성하는 요청도 같이 보냈었습니다. 단일 요청에 대해서 두가지 과정을 다 거치고 요청 값을 돌려주는데에 짧게는 몇초, 길게는 2분의 시간 지연이 발생했었습니다. 여러 요청들이 들어왔을때, 앞의 요청들이 끝나지 않아서 뒤에 있는 요청들이 기다리는 시간이 길어지는 병목현상이 나타났습니다. 이를 해결하기 위한 새로운 접근 방식이 필요했습니다.
위 문제를 해결하고자 비동기 처리 방식을 도입했습니다.
@Async를 도입하면서, 저희 서비스는 이제 다수의 요청을 동시에 처리할 수 있게 되었습니다. 이는 각 요청이 독립적으로 처리됬고, 결과적으로 전체 시스템의 응답 시간을 크게 단축시켰습니다. 이 방식을 통해 대기 시간을 최소화하여 처리 속도를 효율적으로 개선했었습니다.
하지만, 이번에는 코드 실행 서버에서 문제가 발생했었습니다. 많은 요청들이 한꺼번에 들어오게 됐을때, 해당 서버가 터지는 등, 비정상적인 종료가 발생했었습니다.
수직적 확장과 수평적 확장을 통해 해당 문제를 해결할 수 있을거라 생각하였습니다. 저희는 수평적 확장을 생각했었고, 그 이유는 수직적 확장은 한계가 있고, 리소스 낭비가 심할거라 생각했습니다. 당장은 4개의 서버로 확장을 했었고, 이는 적절한 해결법이 아니었습니다. 결국 4개의 서버가 수용할 수 있는 요청들을 넘어가는 경우도 고려를 했었고, 중간에 Kafka*와 Evaluation(리스너) 서버를 둬서 많은 요청에 대해서도 적절히 요청을 분배하고, 수용 가능한 요청들에 대해서만 처리하도록 설계하여, 부하가 커질때에도 코드 실행 서버가 비정상적으로 종료되지 않도록 하였습니다. 하지만, 이는 시스템적 문제는 해결하였지만, 성능적 문제는 해결하지 못했습니다. 이번에는 처음 요청을 받는 Execute 서버에서 병목 현상이 생기기 시작했습니다.
유저 코드 제출이 가장 부담이 큰 요청이긴 하지만, 유일한 요청은 아니기 때문에, 다른 조회나 로그인, 회원가입 등의 요청에 지장이 생기기 시작했습니다. 기본적으로 유저 코드 제출은 관련 문제들과 실행이 되기 위한 코드 등, 여러번의 DB Read가 일어났고, 요청에 대해 총 3번의 Write가 발생합니다*. 성능적으로 저하되는 부분을 해결하고자, 하나의 서비스를 도메인으로 분리하였습니다.
*(Trade-off를 고려했을때 실시간성이 더 중요하다 판단하여 내린 결정이었습니다.)
API게이트웨이 서버를제외하고 총 3개의 도메인으로 분리를 하였고, DB 또한 각각의 도메인 별로 나누게 됬었습니다. 결론적으로, 프로젝트는 총 5개의 서버로 이루어지게 되었고 큰 프로젝트가 되었습니다.
서버를 개별로 관리하다보니 관리하기가 어려웠습니다. 이를 해결하기 위해 쿠버네티스 도입과 모노레포를 시도해봤습니다. 쿠버네티스를 직접 구축하기에는 시간이 촉박하여 옵스 개발자의 도움을 받아서 쿠버네티스 환경을 만들었었습니다. (많은 도움을 주신 팀원 이강훈 님께 감사드립니다..!) 이를 통하여 많은 병목 현상을 해결하였고, 모노레포를 통해 관리가 많이 편해졌었습니다.
k8s 도입으로, 각 pod에 대한 헬스체크가 가능해졌었습니다. 이를 통해 기존에 여러 서버를 띄어놨던 코드 실행 서버들을 두개로 줄였고, Liveness Probe를 통해, 카프카의 상태에 따라 동적으로 확장되어 많은 요청에 대해 유연하게 처리함과 동시에, 리소스를 아낄 수 있게 되었습니다.
결론적으로, 작은 프로젝트의 규모가 생각보다 커지게 됬습니다. MSA로 전환을 통해 프로젝트가 더욱 빠르고 안정성이 높아졌지만, 이를 위해 의존성 분리 등, 리팩토링 작업이 너무 고단했습니다.... 하지만 프로젝트의 목적을 위해서는 필요한 작업이었다고 생각합니다. (백준에서 문제를 푸는데 코드 결과를 받기 위해 몇분을 기다린다는건 말도 안된다 생각이 되고, 처리속도가 느리다면 답답했을것 같습니다.) 최대한 기술블로그들을 참고하여 MSA로 전환하기는 했지만, 아직까지는 올바르게 전환이 이루어졌는지 확신이들지는 않습니다.
*(카프카 도입에 대한 설명은 따로 정리했습니다. )
