<aside> 💡 Elasticsearch 문서를 새로 생성하면서 새로 생성한 document 클래스를 인지하지 못하고 빌드가 되지 않는 문제가 발생하였다. 문제의 원인을 분석해보자

</aside>

문제상황

Django와 Elasticsearch는 django_elasticsearch_dsl이라는 패키지를 통해 매우 간편하게 인덱스를 관리할 수 있다. Django의 ORM을 사용하듯이 인덱스의 이름과 문서의 필드를 설정하여 Elasticsearch 클러스터에 DB에 있는 데이터를 쉽게 전달 할 수 있다.

• 모식도

  간단하게 다음과 같은 그림으로 이해할 수 있다.

  

  정상적인 상황

• 문제상황

  Django에서 아래와 같이 정의한 문서의 설정 정보를 읽지 않는 문제가 발생함

  

문제원인

⭐참고링크⭐ → 완벽하게 이해하지는 못했지만 나중에 꼭 다시 읽어보자!

문제의 원인으로 들어가기전에 먼저 django 서버를 디버깅모드(manage.py runserver)로 실행하였을 때, django에서 어떤 동작이 일어나는지 알아보자

서버 준비 과정

• apps.populate(settings.INSTALLED_APPS)

  django.setup()이 실행되면 내부에서 실행되는 한수로 세팅에 등록한 앱들을 로딩한다.

  GIL과는 별개로 파이썬 내에서 thread가 공유하는 메모리로 인해서 프로그램이 꼬일 수 있는데 이를 위해서 RLock을 통해 thread safe를 보장할 수 있다.

  1. 앱 설정을 초기화하고, 중복된 앱 이름이 있는지 검사한다.
  2. 앱에 존재하는 모델 모듈을 가져온다.
  3. 각 앱 설정에 있는 ready function을 실행한다.

• routing 설정과 관련된 view로드도 이 단계에서 실행이 된다.

서버 유지 과정

<aside> 💡 ManagementUtil을 실행하여 django의 서버가 exception에 잘 대처하도록 하는 단계이다. 우리가 흔히 잘못된 코드를 입력하여도 django는 대기 중에 있다가 파일 올바르게 변경될 경우 제대로 작동하는 경험을 하였을 것이다.

</aside>

• django 내부에는 서버를 재시작하는 autoreloader에의해 시작된 프로세스에 문제가 발생하였을 경우에 처리하는 핸들러가 갖춰져있다.

  → 반대로 --noreload 플래그를 통해 autoreloader를 실행한다면 관련 처리를 할 수 없다.

• self.autocomplete(): bash 명령어에 자동완성기능?

• self.fetch_command(subcommand).run_from_argv(self.argv)

  먼저, fetch_command의 경우는 서브 커맨드(runserver, command dic)를 인자로 받아 검증 후에 콜백 앱과 command dict를 반환한다.

  다음으로 run_from_argv는 argv인자값을 받는 함수이다. argv에 들어있는 인자값은 file location과 command에 대한 정보이다.

  • django의 runserver 클래스를 실행

  • base check/migration check

  • handle(): IP 주소와 관련된 체크를 진행, 포트 확인

  • run(): user_reload 옵션에 따라서 재시작 옵션을 실행하게 된다.

    INOTIFY를 이용해서 파일의 변화를 트랙킹하고, 이를 통해서 재시작을 하는 기능을 구현한다. → 디버깅 모드에서 보게되는 형태

결론

• document 내부에 있는 파일의 경우는 manage.py가 실행하여 로딩을 하는 영역보다 깊숙히 들어가 있기 때문에 ready function이 임포팅을 하지 않은 경우 읽지 않는다.
• django가 관리를 하는 주체이기 때문에 document 클래스에 대한 정보를 읽지 못할 경우 당연히 elasticsearch로 관련 정보를 전달하지 못하게 된다.
• 따라서 위의 문제를 해결하기 위해서는 특정 경로의 파일의 클래스를 사전에 읽을 수 있도록 하는 조치가 필요할 것으로 보인다.