서론
diff 모델을 이용한 생성형 AI 프로젝트를 구현하고 있는데, 중간에 큰 문제에 봉착하고 말았다. 문제인즉슨 비동기 통신을 위해 도입한 Celery와 diff 모델이 둘 다 multiprocess 라이브러리를 사용하는 과정에 있어, 데드락 문제가 발생하는 것이었다. 이 문제의 경우 프로그램이 아무런 오류 메시지도 출력하지 않고 뻗어버리기에 해결하기 매우 곤란했었다.
본론
1. 문제 원인 파악
해당 문제를 해결하기 위해서 코드가 어디까지 실행되는지 정확하게 파악해야 하기에, 라인별로 로깅을 찍어보는 와중에 self.saving_result_pool(8) 부분에서 문제가 생기는 것을 확인했다.
def test_start(self):
print("TAG7")
self.saving_result_pool = Pool(8)
print("TAG8")
...더 자세한 문제 원인을 파악하기 위해 multiprocess 라이브러리 내부에 Pool() 함수의 정의를 찾아보았고 이곳에서 추가적으로 로깅 작업을 해본 결과
self._processes = processes
try:
self._repopulate_pool()
except Exception:
for p in self._pool:
if p.exitcode is None:
p.terminate()
for p in self._pool:
p.join()
raise
terminate 부분에서 문제가 생기는 것을 확인할 수 있었다.
즉..! process terminate 과정에 문제가 생긴 것이다.
더 정확한 문제 원인 파악을 위해 해당 공식 문서를 찾아보던 와중 terminate와 관련된 중요한 사항을 파악하게 된다.
multiprocess 공식문서
https://docs.python.org/ko/3/library/multiprocessing.html
추가적으로 Celery Worker 내부에서도 multiprocess 라이브러리를 사용한다는 것을 알았기에, Celery Worker와 AI 모델이 서로 프로세스를 생성하고, 종료하는 과정에 있어 데드락 문제가 발생한다는 것을 깨닫게 되었다.
2. 해결
AI 모델 부분의 내부 코드를Pool(8) 건들여 봤으나, 역시나 해결되지 않았기에 골머리를 썩고 있는 차..
Celery Worker 관련 자료
https://celery.school/celery-worker-pools
위의 자료를 참고하여 Celery의 옵션을 설정할 수 있다는 사실을 깨달았다.
기본적으로 Celery Worker의 default 옵션이 prefork이기에 해당 옵션을 threads로 변경하면, 서로 프로세스를 생성하고 제거하는 것이 아니라 한쪽은 프로세스를 사용하고, 한쪽은 threads를 사용해서 문제가 해결될 수 있다고 생각하여 옵션을 조정 한 결과..
정상적으로 실행 되었다!
결론
비동기 통신과 같은 복잡한 시스템을 구현할 때 여러 외부 라이브러리를 함께 사용하는 경우, 예상치 못한 상호작용으로 인해 문제가 발생할 수 있음을 실감했습니다.. 특히, 위의 경우처럼 문제가 발생했을 때 명확한 오류 메시지가 없었기에, 더욱 힘들었던 것 같습니다 ㅠㅠ
역시나 이러한 문제 해결 과정에서 가장 중요했던 점은 체계적인 문제 접근 방식과 근본 원인 분석이 중요한 것 같습니다. 코드의 실행 과정을 단계별로 추적하고, 문제가 발생하는 지점을 정확히 파악하는 것이 해결의 첫걸음이었습니다. 또한, 문제의 근본 원인을 이해하기 위해 공식 문서와 관련 자료를 꼼꼼히 검토한 것도 큰 도움이 되었습니다!!
특히, 이 문제로 거의 1주일을 붙잡고 있었기에.. 해결했을 때 더 짜릿했던 것 같습니다. 또 프로젝트를 진행하면서 특이사항이 생긴다면 다음글로 찾아뵙도록 하겠습니다.
