시작은 Django의 official documentation을 확인해보자.
개발자 입장에서 배포하는 건 deploy라고 함
Django currently supports two interfaces: WSGI and ASGI.
WSGI is the main Python standard for communicating between web servers and applications, but it only supports synchronous code.
ASGI is the new, asynchronous-friendly standard that will allow your Django site to use asynchronous Python features, and asynchronous Django features as they are developed.
여기서 synchronous/asynchronous 라고 하고 있다.
1. Synchronous Code (동기식 코드)
- 코드가 한 줄 한 줄 순차적으로 실행됩니다.
- 이전 작업이 완료되기 전까지는 다음 줄로 넘어가지 않습니다.
- 예: 파일을 읽거나 서버에서 데이터를 가져오는 경우, 데이터가 준비될 때까지 기다렸다가 다음 코드가 실행됩니다.
예시
data = fetch_data() # 이 작업이 끝날 때까지 기다림
print("Data received:", data) # 위 작업이 끝나면 출력- 여기서 fetch_data() 함수가 완료될 때까지 기다리므로, 아래 코드(출력문)는 fetch_data가 끝난 후에 실행됩니다.
- 따라서, 데이터가 느리게 응답되면 그동안 프로그램 전체가 멈춘 것처럼 보일 수 있습니다.
2. Asynchronous Code (비동기식 코드)
- 코드가 순서와 상관없이, 작업이 완료되면 알림을 받고 처리합니다.
- 기다리지 않고 바로 다음 줄을 실행하여, 여러 작업을 동시에 처리할 수 있습니다.
예시
async def main():
task = fetch_data_async() # 기다리지 않고 바로 다음 줄로 넘어감
print("Data request sent!")
data = await task # 데이터가 준비되면 실행
print("Data received:", data)- 위 예시에서 fetch_data_async()는 **데이터가 준비될 때까지 기다리지 않고 다음 코드(출력문)**를 바로 실행합니다.
- await 키워드는 데이터가 준비되면 그때 데이터를 받아오는 방식으로, 다른 작업과 동시에 실행할 수 있어 프로그램이 멈추지 않고 계속 진행됩니다.
3. 왜 Asynchronous Code가 필요할까?
- 시간이 오래 걸리는 작업 (예: 파일 읽기, 네트워크 통신 등)에서는 비동기 코드가 매우 유용합니다.
- 사용자는 프로그램이 멈춘 것처럼 느끼지 않고, 다른 작업을 하면서도 요청한 작업을 기다릴 수 있기 때문입니다.
- 예를 들어, 웹 애플리케이션에서 페이지를 로드하는 동안 데이터를 비동기로 가져오면 사용자가 더 빠르게 화면을 볼 수 있게 됩니다.
4. 동기식과 비동기식 코드 비교
| 특징 | Synchronous Code | Asynchronous Code |
| 작업 처리 방식 | 순서대로 작업을 마칠 때까지 기다림 | 작업이 끝나기 전에 다음 코드로 넘어감 |
| 응답 지연 | 응답이 느리면 코드 전체가 멈추는 효과가 생김 | 응답을 기다리는 동안 다른 작업을 처리 |
| 사용성 | 간단한 프로그램에 적합 | 서버 요청, 파일 I/O 등 오래 걸리는 작업에 적합 |
| 예 | 단순 연산, 작은 계산 | 네트워크 요청, 데이터베이스 조회, 대용량 파일 처리 |
결론
동기식 코드는 작업이 순서대로 처리되므로 이해하기 쉽고 직관적이지만, 응답 지연이 생기면 프로그램 전체가 멈출 수 있습니다. 반면, 비동기식 코드는 동시에 여러 작업을 처리할 수 있어 성능이 더 좋지만, 코드 작성이 약간 더 복잡해질 수 있습니다.
즉, 아직까지 내가 작성한 코드에서는 비동기식 코드는 없다. 그러니까,
WSGI 를 선택하면 된다.
WSGI : Web Server Gateway Interface (python 웹 어플리케이션과 웹 서버 간의 표준 인터페이스)
웹 서버 소프트웨어와 파이썬으로 작성된 웹 응용 프로그램 간의 표준 인터페이스
ASGI : Asynchronous Server Gateway Interface (비동기 웹 서버와 웹 어플리케이션 간의 인터페이스)
* 나중에 필요시 추가 공부 필요함.
장고 docs 에서 확인가능함. gunicorn 이라는 걸 사용함 (python WSGI HTTP Server for UNIX, UNIX도 LINUX의 일종이라고 함)
gunicorn 에서도 documentation을 확인 가능함.
pip install gunicorn
이라고 해서, 파이썬 패키지 형태로 설치를 하는 것.
그리고나서, Deploying Gunicorn 이라는 Docs를 확인해보면, using Gunicorn behind a proxy server 를 강권하고 있다.
그리고 많은 HTTP proxies가 있지만, Nginx (엔진엑스) 사용을 강권한다고 한다.
proxy : 중간에서 요청을 대리 처리하는 서버, 네트워크 통신에서 중간 역할을 하는 서버로 클라이언트(사용자)와 서버(목적지) 사이에서 데이터 요청과 응답을 중계한다.
잠깐 정리를 좀 해보자면, Django Documentation을 확인해보니 WSGI 서버로 Gunicorn 사용을 이야기했다.
- Gunicorn : Django 같은 Python 웹 어플리케이션이 HTTP 요청을 처리할 수 있게 해주는 어플리케이션 서버 (Python WSGI 서버)
- Nginx : 요청 중계와 부하 분산 (클라이언트의 요청을 받아 Gunicorn 같은 어플리케이션 서버로 전달한다)
그러니까,
- 클라이언트 요청
--> Nginx 로 도착
--> Nginx (Nginx는 리버스 프록시 종류라고 함) 가 정적 파일을 바로 제공하거나, Gunicorn으로 요청을 전달
--> Gunicorn (WSGI 서버) 가 Python 웹 어플리케이션 (Django 등) 을 실행해서 요청을 처리하고 응답을 생성
--> 응답 반환은 Nginx 가 Gunicorn 으로부터 받은 응답을 클라이언트에게 전달
PostgreSQL (RDS - AWS에서 제공하는 DB 서비스)
|
Django - Python - Gunicorn - Nginx (Lightsail Ubuntu (우분투 리눅스))
|
도메인 (Route 53 - AWS에서 제공하는 도메인 관련 서비스)
|
웹브라우저 - 사용자
왜 Nginx와 Gunicorn을 함께 사용하는가?
- 성능 최적화: Nginx는 정적 파일 처리가 빠르고, Gunicorn은 애플리케이션 로직 처리가 강점이므로 역할을 나눌 수 있습니다.
- 안정성 향상: Nginx가 리버스 프록시 역할을 하며, Gunicorn에 트래픽을 분배하고 서버 장애를 방지.
- 확장성: Nginx는 Gunicorn 서버들을 로드밸런싱하며 여러 인스턴스에 트래픽을 나눠 보낼 수 있어 대규모 트래픽을 처리할 수 있습니다.
이렇게 Nginx와 Gunicorn을 조합하면 안정적이고 확장성 높은 웹 애플리케이션 환경을 구축할 수 있습니다.
* 마찬가지로 Nginx도 홈페이지에 documentation이 있음.
PostgreSQL (RDS - AWS에서 제공하는 DB 서비스)
|
Django - Python - Gunicorn - Nginx (Lightsail Ubuntu (우분투 리눅스))
|
도메인 (Route 53 - AWS에서 제공하는 도메인 관련 서비스)
|
웹브라우저 - 사용자
이렇게 구조는 이해가 되었다.
이제, 여기서부터는 AWS에서 제공하는 서비스를 이용하는 단계로 넘어가야 한다.
그 시작을, DB부터 가보자.
PostgreSQL이 이미 내 컴퓨터에 있다. 그런데 내 컴퓨터에서 돌아가는 프로젝트를 생각하는게 아니지 않는가.
AWS 상에서 돌아가도록 해야 하는데, 그러면 서버 위에서 작동하는 DB가 필요하다. PostgreSQL을 AWS에서도 제공한다고 한다. 그게 RDS 라는 이름의 서비스로 되어 있다고 했던 것 같다.
일단은 AWS에 가입하고 카드 등록을 해야 한다...... 이 프로젝트를 해보기 위해서 내 피같은 돈이 들어가지만, 그러니까 더 잘 해야겠지.
첫 로그인 화면. 이제부터 저기 recently visited를 채워나갈 예정이다!
일단, 뭐든 처음하면 어렵고, 어색하고, 알아야 하는게 정말 많다.
AWS console에서 제공하는 것도 너무나도 많다. 그래서 진입장벽이 있다는 생각이 들 수 있다는 생각이 든다.
나도 이제 막 처음 접해본 사람이니까, 혼자서 이걸 하고 있다고 생각하면 좀 막막했을 것 같다.
GPT가 없을때에는, 정말 하나 하나 검색해서 찾아보는데에 모든 시간이 다 쓰였을 거 같다. 근데 이제는 GPT도 있고, 강의를 들을 수도 있고, 아무튼 혼자서 맨땅에 헤딩하는 일은 없다.
그럼에도 불구하고 AWS 메인 콘솔을 그대로 이용하는건 좀 헷갈릴 수 있다. 그리고 내가 모르는 용어와 단어들이 난무하게 된다. 그러면 AWS 이용해보겠다고 마음먹었던 사람들이 떠날 수가 있으니, AWS 측에서 초보들을 위해 가벼운 콘솔을 제공하고 있다. 그게 Lightsail 이다.
그래서 지금은 RDS (relational database system) 을 이용하려고 하는거니까,
Databases에 들어가보자.
PostgreSQL을 이용하겠다는 플랜(?), 암튼 생성한다.
어찌됐든 공부를 하고 있는거니까 DB를 MSA 형식으로 해보기로 했다.
monolithic 하게 DB를 운영하는게 아니라, MSA (Micro Service Architecture) 형식으로 DB를 운영한다면,
어찌됐든 외부에서 접근할 수 있는 방법을 DB가 제공해야 한다.
그래서 endpoint, port, user name+password 같은 정보를 제공해주게 된다.
pgAdmin4로 로컬에서 운영할 때 PostgreSQL에 접근했었는데,
pgAdmin4로 서울 어딘가에 있는 AWS에서의 PostgreSQL에 접근하는 것도 원격으로 가능해야 한다.
로컬에 있는 pgAdmin4으로 클라우드에 있는 PostgreSQL에 원격으로 접속할 수 있는 기능을 제공한다는 것!
접속을 해보려고 하는데, 접속이 안 된다.
생각해보면, DB에 접근이 그렇게 쉬운 것도 이상한 것.
심지어 아이디랑 비밀번호를 알고 있더라도 접근 권한이 없으면 안 된다.
또는, 접근 권한이 있더라도 원격 접속을 허용해놓지 않으면 접근이 안 된다.
지금 바로 위에 있는 <이미지>의 가장 아랫쪽을 보면, public mode is disabled
그러니까 저걸 abled로 변경해주어야 한다.
* 실제로는 DB에 접근할 일이 실제로는 많이 없다고 한다. 하지만, 지금은 공부 중이니까 이렇게 원격으로 접속해서 확인을 해보기 위함이다.
pgAdmin 4 에서 확인이 가능.
로컬에서, 클라우드에 있는 DB를 확인가능하고,
로컬 프로그램인 pgAdmin4 에서 DB를 생성하면, 그게 원격으로 클라우드에서도 DB가 생성되는 것.
굿굿!