asgi.py와 wsgi.py 이제는 이해하자

스터디 하면서도 봤었고 배운 개념인데, 막상 또 쳐다보면 모르겠어서 최종_최종_최종으로 공부하기. 

 

Django runserver의 정체 

• 서버라기 보단 배포전에 이런 식으로 동작할 거야 하고 보여주는 프로토타입 같은 느낌이다. 실험용으로.. 

근데 외부 접근도 가능하다고 하긴 한다. 같은 네트워크에 연결된 다른 기기에서도 ..? 

와이파이나 네트워크도 공부해야 하는데 아직 모르겠다... 

python manage.py runserver 0.0.0.0:8000

이렇게 켠 다음에 같은 와이파이에 있는 다른 기기의 브라우저에서 http://<서버 PC의 로컬 IP>:8000 으로 접속하면 된다. 

 

안될 수도 있는 경우는 다음과 같다. 

• 방화벽이 Python 수신을 막지 않게 허용 
• 공유기 설정에 AP 격리(클라이언트 간 차단)이 켜져있으면 서로 못 봄

음... 무슨 말인지 아직 모르겠음. 방화벽이나 공유기 설정/AP 격리는 나중에 찾아보자. 

---

동기와 비동기 

이건 여러 번 들어서 알고 있다. 동기는 요청 후 응답 올 때까지 대기(즉 멈춰있는 거)하고, 비동기는 요청을 보내고 안 기다리고 다른 것도 시작하는 것이다. 즉, 동시에 다른 요청을 처리할 수 있다. 순서 제어를 포기하고 응답 속도를 높이려는 것... 

• 따라서 동기 방식은 구조가 단순하고 디버깅하기가 쉽다. 따라서 안정적이다. (순서가 보장되므로) 
• 비동기 방식은 전체적인 성능을 올려줄 수는 있는데, 구조가 복잡하니까 버그가 발생하기가 쉽다. 
• 두 개가 상호배타적이진 않다. 적절하게 쓰도록... 

---

WSGI 

• Web Server Gateway Interface 
• 동기 방식으로 처리 
• 먼저 등장한 방식 (2003년 경) 

---

ASGI 

• Asynchronous Server Gateway Interface 
• 비동기 방식으로 처리 

---

asgi.py와 wsgi.py는 그래서 뭔데

Django가 웹 서버와 연결되는 gateway 역할을 한다. (이름에서 나와있듯이) 

근데 이해가 안 갔다.. Django가 웹 서버와 연결된다는 말 너무 추상적이다. Django가 뭔데..? 

→ 갑자기 이거 고민하다가 깨달음을 얻음 

• Django는 요청을 처리하는 파이썬 코드 묶음이다. 즉 요청을 받는 능력이 없음. 그래서 실행기가 따로 돌려줘야 한다.
• 그 실행기가 gunicorn / uvicorn이다. 
•  그래서 gunicorn의 경우 wsgi.py를 통하고, uvicorn의 경우 asgi.py를 통해서 장고와 상호작용 한다. 
• 이 서버들이 브라우저(클라이언트) 요청을 받아 장고에 전달하고, 장고는 views.py 코드로 처리해서 결과를 응답으로 보내는 것. 

---

프로그램이 돌아간다는 말의 뜻 

네트워크에서 요청이 오면, gunicorn/uvicorn이 그걸 받아서 장고를 실행시키고, 장고가 계산한 결과를 다시 사용자에게 돌려주는 이 순환(요청-응답 사이클) 자체가 계속 유지되는(활성화되는) 상태 

---

nginx 복습 

그래서 nginx 같은 필수적으로 붙이는 프록시 서버가 필요하다. 

위와 같은 앱 서버는 보통 앱 실행에 집중하고, 웹 서비스 운영 기능은 nginx가 대신 맡는 게 훨씬 효율적이기 때문이다. 

HTTPS / 인증서	보안 연결 처리
정적 파일(css, js, 이미지)	파일만 서빙하므로 빠름
로드밸런싱	여러 Django 인스턴스로 분산
요청 제한 / 버퍼링	서버 과부하 방지
방화벽, 접근제어	악성 요청 차단

---

이해한 김에 ci/cd 파일 보기 

우리 팀 workflow.yml 파일 일부.. 

gunicorn config.wsgi:application
--bind 0.0.0.0:8000
--access-logfile /********_app/logs/gunicorn_access.log
--error-logfile /********_app/logs/gunicorn_error.log
--log-level debug

• gunicorn config.wsgi:application → Django 코드를 실행할 서버(gunicorn) 시작
• --bind 0.0.0.0:8000 → 외부에서 :8000 포트로 들어오는 요청을 받겠다는 뜻
• --access-logfile ... → 접속 로그 저장 (누가 들어왔는지 기록)
• --error-logfile ... → 에러 로그 저장 (문제 생기면 확인용)
• --log-level debug → 로그를 자세히 찍기 (개발/디버깅용)

다른 사람에게 wsgi/asgi 차이가 뭐야? 하면 설명할 수 있을 정도는 된 것 같다