사내에서 mlflow를 활용해서 모델을 서빙해보고 부하 테스트를 진행하고 있었다.
공식 문서엔 서빙 CLI 입력 시 워커 프로세스가 4개가 기본 값인데, 워커 프로세스가 1개만 뜨고 있었다.
처음엔 공식 문서를 믿고 다른 요인으로 인해 1개가 뜬다고 생각했다. 1 vCPU를 1만 요청하는 파드를 써서 그런가 보다 했다.
따로 그런 로직이 있을 것 같지 않아, mlflow 코드를 직접 보다보니 공식 문서와 실제 기본 값이 다르다는 것을 확인하고, 바로 이슈를 남겼다.
하루쯤 뒤 커미터분이 문서 오류로 확인하고 이슈를 assign해주셨다.
(내심 문서대신 기본값이 4가 되도록 코드를 고쳐달라 말씀하길 원했다. ㅎㅅㅎ)
Docs 폴더에 들어가서 값만 변경해주면 되는 쉬운 작업일 줄 알았으나, Docs에 해당 문서를 가르키는 것으로 보이는 rst 파일을 찾아가도 다음 값밖에 보이지 않았다.
알고보니 sphinx라는 도구를 활용해서 코드의 docstring 기반으로 문서를 빌드하는 것으로 보였다.
추후 내 프로젝트에도 활용하면 좋겠다.
아무튼 소스코드에서 해당 argument가 정의된 코드를 찾아서 4를 1로 변경해주었다.
그 밖에 컨트리뷰트 가이드 문서를 읽으며 Docs를 빌드해서 직접 테스트도 해보고
(캐시 때문인지, 수정 사항이 바로 안보여서 당황하기도 했다),
커밋에 사인을 넣어야하는 것 등등 고려할 점들이 있었다.
사실 이슈 및 PR 문서를 작성하는 것이 가장 어려웠다.
그렇게 정말 작은 작업을 기여할 수 있었다.
-
큰 오픈소스들은 코드 구조나 디자인 패턴을 배우기에 좋은 교보재들이라고 생각한다. 특히 제어를 맡기게 되는 프레임워크들은 항상 코드를 자주 뜯어보게 되는 것 같다.
-
당연하지만 어느정도의 영어 실력이 참 중요함을 또 느낀다. 읽는 것은 그래도 나쁘지 않은데, 이런 간단한 이슈도 영어로 작성하는 것이 너무 어렵더라. ;ㅅ;
-
github 잔디 밑에 mlflow가 뜨는 것을 보며 행-복 (사실 이거 보여주고 싶어서 글 썼다.)
