개선 대상 및 현재 한계점
K3s에서 Pod를 구성할 때, CPU Limits을 설정하지 않는 것이 좋습니다. 왜냐하면 CPU는 압축가능한 자원이기 때문에, Limits를 설정하지 않아도 Throttling으로 치명적인 오류가 발생하지 않고 Utilization을 극대화할 수 있기 때문입니다.
다만 CPU Limits를 제거하면, 채점 서버에 수정이 필요합니다.
채점 서버는 현재 CPU 정보 (정확히는 코어 수)를 기반으로 아래 두 가지를 결정하고 있습니다.
- gunicorn 워커 개수
- 병렬 채점할 multiprocessing Pool 개수
따라서 위 2가지를 CPU 자원 정보 기반이 아닌 고정 값으로 수정하는 것이 가장 안정적일 것으로 생각합니다. 예를 들어, 채점 서버마다 4개의 워커 프로세스를 생성하고, 최대 8개의 채점을 동시에 처리할 수 있도록 고정해두면 코드플레이스의 동시 채점 가능 수를 쉽게 계산할 수 있습니다.
제안하는 개선 사항
- 채점 서버에 워커 개수, Pool 크기를 CPU 자원 기반이 아닌 고정 값으로 설정합니다. (환경 변수로 오버라이드 할 수 있도록 구성합니다)
- 채점 서버가 백엔드에 보내는 Heart Beat에 최대 동시 처리 가능 개수를 전달하고, CPU 정보를 제거 혹은 참고용으로 변경합니다.
- 백엔드가 채점 서버에 요청을 보낼 때 각 서버의 동시 처리 가능 개수와 현재 해당 서버가 채점하고 있는 개수를 통해 채점 요청을 라우팅합니다.
참고 자료
N/A
Acceptance Criteria
개선 대상 및 현재 한계점
K3s에서 Pod를 구성할 때, CPU Limits을 설정하지 않는 것이 좋습니다. 왜냐하면 CPU는 압축가능한 자원이기 때문에, Limits를 설정하지 않아도 Throttling으로 치명적인 오류가 발생하지 않고 Utilization을 극대화할 수 있기 때문입니다.
다만 CPU Limits를 제거하면, 채점 서버에 수정이 필요합니다.
채점 서버는 현재 CPU 정보 (정확히는 코어 수)를 기반으로 아래 두 가지를 결정하고 있습니다.
따라서 위 2가지를 CPU 자원 정보 기반이 아닌 고정 값으로 수정하는 것이 가장 안정적일 것으로 생각합니다. 예를 들어, 채점 서버마다 4개의 워커 프로세스를 생성하고, 최대 8개의 채점을 동시에 처리할 수 있도록 고정해두면 코드플레이스의 동시 채점 가능 수를 쉽게 계산할 수 있습니다.
제안하는 개선 사항
참고 자료
N/A
Acceptance Criteria