django를 열기 위한 ubuntu 서버

Question

안녕하세요 만으로 2년이 조금 안 되는 경력을 갖고 있는 백엔드 개발자입니다.
회사의 서비스를 운영하면서 프론트엔드를 제외한 모든 개발 업무들을 도맡아 해왔는데요

서버 부분은 매번 상황이 터질 때마다 그 상황들을 해결해나가면서 조금씩 성장하는건가 라는 느낌만 받고 있었습니다.

사수분도 따로 없고, 주변에 서버 관련한 시니어분도 없어서 이렇게 질문을 넣게 되었습니다.

python django - gunicorn/uvicorn - nginx 이렇게 서버단을 구성하고 있습니다.

초반에는 서버에 관한 지식이 전무하여서 그냥 부팅만 시켜주면 되는건가 했는데, 메모리 누수에 관한 내용을 접하고 우리 서비스도 이런 이유 때문에 셧다운되면 곤란하겠다 싶어서 gunicorn.service에 --max-requests와 --max-requests-jitter를 걸어서 조금이나마 서버가 터지는 일이 없도록 하려고 했습니다.

그렇게 max-requests는 70으로, jitter는 50으로 해서 정말 적은 요청 값을 받고 워커를 리로드하고 하는 식으로 반복을 했는데, 이마저도 버티지를 못하는지 잘 작동해오다가 한 3분? 동안에 갑자기 메모리 사용량이 폭증을 해버렸네요..

평소에 30~50퍼대의 메모리 사용량을 유지하고 있기에, 절대적인 서버의 사이즈가 문제라고는 생각되지 않았습니다. 그리고 시스템의 로그를 찾아봐도(/var/log/syslog) 특별한 로그가 찍히지 않아서 그냥 답답하기만 했습니다..

어떤 사유들 때문에 순간적으로 메모리 사용량이 폭증해서 oom-kill이 발생하는지 원인들도 알고 싶고, 그러한 부분들을 막을 수 있는 방법들이 뭐가 있는지도.. 그냥 시니어분들의 조언을 듣고 싶습니다 ㅠㅠ

박범수 · Accepted Answer

현재는 증거가 너무 적어서 범인을 찾는 것이 거의 불가능합니다.

먼저 OOM을 유발한 프로세스가 Django 인지 확실하지 않습니다. 그럴 가능성이 높아 보이긴 하지만 100%는 아닙니다. 프로세스의 메모리 사용량을 모니터링해서 이 부분부터 확실히 해야 합니다.

Django가 범인인 것이 확실하다면 syslog를 보는 것은 별 의미가 없습니다. 문제는 어플리케이션 코드 어딘가에 있습니다. 따라서 정확히 어떤 코드에서 메모리를 많이 사용하는지를 찾아야 합니다. 이 과정은 쉽지 않습니다.

먼저 APM 모니터링을 걸고, 로그를 더욱 상세하게 남기는 등 최대한의 가시성을 확보하세요. OOM이 발생한 시각에 어플리케이션이 어떤 일을 하고 있었는지를 이 모니터링을 바탕으로 복원해야 합니다.

어떤 일을 하고 있었는지를 대강 알게 되었다면, 해당 부분의 코드를 상세히 검증하면서 OOM을 유발할만한 부분이 있는지를 찾아야 합니다. 배열이나 해시맵 등의 컬렉션에 너무 많은 데이터가 담기는 것이 일반적인 원인 중 하나입니다.

또 OOM의 원인을 찾는 것과 별개로, OOM과 같은 일이 발생하더라도 서비스 전체 장애로 이어지지 않게 할 방법을 고민하셔야 합니다. 이중화, 고가용성 같은 키워드를 검색해서 학습할 필요가 있습니다.