개선 대상 및 현재 한계점
코드플레이스의 base 레포지토리인 OnlineJudge는 각 서비스에 하나의 컨테이너 생성을 전제로 각 서비스는 Supervisord와 Gunicorn 등을 활용해 멀티 프로세스 환경으로 실행되었습니다.
하지만 코드플레이스에서 Docker Swarm 및 K3s로 환경을 이전하면서, 여러 개의 Replica를 생성하는 방법을 사용하면서, 컨테이너 내부에 프로세스를 생성하는 것이 오히려 불편함을 만들고 있습니다.
- Liveness 추적의 어려움: Liveness는 프로세스의 상태를 체크하는데, 하나의 Pod에 여러 개의 프로세스가 있는 경우 모든 프로세스를 추적하기 어렵습니다.
- 좀비 프로세스 가능성: 여러 프로세스가 실행되고 있고, Pod 외부에서 이 프로세스의 Liveness를 정확히 추적할 수 없기 때문에, 좀비 프로세스가 쌓일 가능성이 있습니다.
- 리소스 관리 어려움: 컨테이너 단위로 CPU/메모리 제한이 있는 경우, 멀티 프로세스에서 어떤 프로세스가 자원을 많이 차지하고 있는지 파악하기 어렵습니다.
- 로그 관리 복잡성 및 확장성 저하: 현재
supervisord와 gunicorn등을 사용하면서 로그를 파일로 저장하고 있습니다. 하지만 추후 로그 수집기를 사용하는 경우 stdout으로 로그가 생성되어야 수집할 수 있으므로, 현재는 로그 수집기를 추가하기 어려운 구조입니다.
제안하는 개선 사항
각 Pod에는 하나의 프로세스만 실행하도록 수정합니다.
- Backend (Django):
supervisord로 멀티 프로세스 사용 중
- Celery Beat (Celery):
supervisord로 멀티 프로세스 사용 중
- Celery Worker (Celery):
supervisord로 멀티 프로세스 사용 중
- Judge Server (Python + C++):
gunicorn으로 멀티 프로세스 사용 중
위 서비스들을 단일 프로세스로 변경합니다.
참고 자료
N/A
Acceptance Criteria
개선 대상 및 현재 한계점
코드플레이스의 base 레포지토리인 OnlineJudge는 각 서비스에 하나의 컨테이너 생성을 전제로 각 서비스는
Supervisord와Gunicorn등을 활용해 멀티 프로세스 환경으로 실행되었습니다.하지만 코드플레이스에서 Docker Swarm 및 K3s로 환경을 이전하면서, 여러 개의 Replica를 생성하는 방법을 사용하면서, 컨테이너 내부에 프로세스를 생성하는 것이 오히려 불편함을 만들고 있습니다.
supervisord와gunicorn등을 사용하면서 로그를 파일로 저장하고 있습니다. 하지만 추후 로그 수집기를 사용하는 경우stdout으로 로그가 생성되어야 수집할 수 있으므로, 현재는 로그 수집기를 추가하기 어려운 구조입니다.제안하는 개선 사항
각 Pod에는 하나의 프로세스만 실행하도록 수정합니다.
supervisord로 멀티 프로세스 사용 중supervisord로 멀티 프로세스 사용 중supervisord로 멀티 프로세스 사용 중gunicorn으로 멀티 프로세스 사용 중위 서비스들을 단일 프로세스로 변경합니다.
참고 자료
N/A
Acceptance Criteria