[인프런] 실리콘밸리 엔지니어와 함께하는 샐러리(Celery) 학습 소감
- celery 강좌는 정말 만나기 힘들다. 더군다나 최신 강좌라니... 그래서 구입했다.
- 이미 celery를 여러 채널을 통해 학습을 하고 사용하던 나에게 대부분 알고 있었거나 익숙한 내용이었지만 20~30% 정도는 새로운 정보였다.
- 독립적으로 celery를 사용하는 방법을 초반에 알려주는데 후반에는 전혀 다루지 않는게 아쉬웠다.
- 중반 이후로는 옵션들에 대해서 강사의 판단으로 정리된 항목들에 대해 학습을 하는데 모르는 것보다 알면 좋지만 선정된 기준들에 대해서는 잘 모르겠더라.
- 문제 해결을 위해 검색을 하면서 얻게된 판단으로 django와 함께 사용되는 celery는 결국 독립적으로 사용되기 보다 django에 붙어서 사용되는 경우가 대부분이다. django의 패키지를 사용해야 하는 경우가 많기 때문이다가 될 것이다. 하지만 머신러닝/AI 그리고 전혀 관계가 없을 독립적인 일을 할 경우는 main.py를 이용해도 충분하다. 특히 부하가 많은 작업은 더욱 그렇다.
- lock/좀비 프로세스가 발생하는 경우에 대해 질문을 해봤지만, 일반 process와 같은 처리 외엔 방법이 없는것 같다.
- django에서 request를 celery로 arg를 이용해 전달할 수 없다. 시리얼라이저 문제라 하던데 대신 ip 등의 정보를 추출하여 해당 view/api 클래스를 생성하면 request를 얻을 수 있다는 글을 읽은적이 있었다. 혹은 pickle을 사용하는 경우도 있었지만 그렇게 추천하지는 않았다.
- 해당 고민을 토대로 강사에게 질문을 했었지만, 필요한 대답을 얻을 수 없었다. 내가 view/api가 아닌 celery에서 응답을 처리하고 완료하는 방법을 고민했던 것은 django 서버에서 SSE 처리를 하게되면 그만큼 서버에 과부하가 발생하기에 분산 서버로 해당 작업을 넘길 수 있을까 생각한 것이었다. 헌데 질문을 하고 다시 검색을 하면서 느끼게 된 것은 방법의 문제가 아니라 역할 범위의 문제라 생각이 들었다.
- render, StreamingHttpResponse 등 어떤 처리를 하던 결국 같은 도메인을 가지고 있는 서버에서 최종 응답을 전달하는게 맞다는 것이다. 과부하의 문제는 캐시나 다른 문제로 해결해야 하는 것이고 I/O는 서버의 스케일업이나 스케일아웃의 다른 관점에서 처리를 해야 하는 것이기 때문에 django에서 처리를 완료해야 하는 역할 범주의 기준을 굳이 넘어서는 설계를 할 필요가 없다는 것이었다.
- 질문을 하면 해외에 있으신 강사분이라 그런지 밤이 지나면 답글이 달린다. 하지만 핑퐁이 될만큼 충분히 적극적으로 대응을 해주신다.
- 개인적으로 프로젝트를 중요하게 생각하는데 celery의 사용방법에 집중되어 있어서 활용한 프로젝트는 없다.
- 누군가에게 질문을 하고 같이 고민을 할 수 있는 채널이 있다는 것은 너무나 감사하고 행복한 일이다. 때문에 celery를 잘 모르는 사람이라면 강좌를 듣자. 그리고 공식 메뉴얼을 보자. 구글에 넘치는 포스트들을 보자. 강좌를 먼저 보고 항해를 하는게 더 편할 것이라 자신한다.