0. Introduction: 웹 애플리케이션 기초
학습 목적
기반 지식을 다지기
사용자가 눈에 보이는 부분을 개발하는 부분을 프론트엔드 ,
사용자 눈에 보이지 않는 부분을 개발하는 부분을 백엔드 라 한다.
프론트엔드는 코드 실행 결과를 눈으로 직접 바로바로 확인이 가능하다.
하지만, 백엔드는 코드의 결과를 눈으로 확인하기 어렵다. 그래서 오류의 원인을 찾는 디버깅이 어렵다.
이 디버깅을 하기 위해서는 기반지식이 필요하다.
입문자가 생각하는 개발은 파이썬 코드라고 생각하지만, 실제 개발에 필요한 내용은 기반지식이다.
그래서 이번에 기반 지식 아래 내용을 학습해본다.
- 클라이언트 - 서버 구조
- 웹 서버 구조 설계
- 네트워크
1. 서버와 클라이언트의 개념
1.1 클라이언트-서버 구조
눈에 보이는 프론트엔드 부분을 어떻게 볼 수 있는 것일까?
- 웹 브라우저의 내용 구성: html, css, js
- 이 클라이언트 상에서 필요한 내용을 서버에 요청하며 서버가 그 해당 페이지에 필요한 내용을 보내어 응답한다.
서버는 하나의 컴퓨터로 생각하면 된다.
- 예전에는 하드웨어 컴퓨터를 직접 사용하여 서버를 구축하는 방식
- 하지만 지금은 AWS 서비스를 사용한다.
AWS란 아마존 웹 서비스를 말하는데, AWS에 서버가 엄청 많아서, 이 서버를 빌려주는 서비스를 말한다.
서버의 정의와 종류
서버(server)란?
- 클라이언트가 요청한 서비스를 제공해주는 프로그램
- 서버가 어떤 서비스를 제공하느냐에 따라 종류가 나뉜다.
서버의 종류
- 웹 서버
- 메일 서버
- 파일 서버
- 데이터베이스 서버
- 프록시 서버
웹서버
웹 서버(web server)란?: 웹 브라우저와 같은 클라이언트로부터 HTTP 요청을 받아들이고, HTML 문서와 같은 웹 페이지를 반환하는 ‘컴퓨터 프로그램’ 또는 이 기능을 제공하는 프로그램을 실행하는 ‘컴퓨터’를 의미
만일 “서버 만들겠다” 라는 말을 했다면, 컴퓨터 프로그램 을 의미한다.
“물리 서버가 고장났다” 라는 말을 했다면, 컴퓨터 프로그램이 아닌 프로그램을 제공하는 컴퓨터 를 의미한다.
HTTP
- Hypertext Transfer Protocol의 약어로, 웹 상에서 데이터를 전달할 때 사용하는 프로토콜
- Protocol: 원거리 장비 사이에서 메시지를 주고 받을 때 지켜야하는 규칙
- https = http + 보안기능(SSL: Secure Socket Layer)
2. 서버 구조 설계
웹서버 <=> WSGI <=> 웹 애플리케이션 <=> DB 이거나, 사용자가 많아지면 DB만 떼어놓는다
이번에는 서버 구조에 대해 알아보자.
만약 서버에서 Error가 발생했다면, 위 각 어느 부분에서 발생했는지를 알아야하기 때문에 이 기반지식이 필요하다.
2.1 웹서버
웹 서버(web server)란? 정적 페이지(static page)를 처리하는 서버로, 정적 페이지는 db와 연결할 필요 X
- static page: 누가 접속하든 동일하게 보여주는 page
- dynamic page(동적): static page의 반대로서, web framework를 사용해야한다.
2.2 웹 서버의 종류
APACHE 와 NGINX
2.2.1 아파치 HTTP 서버(Apache HTTP 서버)
프로세스 / 스레드 기반 구조
- 사용자의 HTTP 요청이 올 때마다 프로세스 또는 쓰레드 생성
- 1000개의 HTTP 요청 -> 1000개의 프로세스 또는 쓰레드 생성
- 따라서 사용자의 요청이 많아지면 프로세스 생성으로 인한 메모리 부족, CPU 과부하
- 아파치 HTTP 서버의 단점: 커넥션이 1만개가 넘어가면 하드웨어 성능에 상관 없이 더 이상 커넥션을 형성하지 못하는 C10K문제
- 동시 접속자가 만명이 넘어가면 더 이상 커넥션 형성 X
- 그래서 규모 있는 서비스를 만들려면 아파치를 사용하면 안된다.
2.2.2 NGINX HTTP 서버(Apache HTTP 서버)
아파치의 문제점을 해결한, 비동기 이벤트 기반 구조
- 이벤트란?
- 커넥션 생성 및 제거하거나, 새로운 요청을 처리하는 걸 의미
- 수 많은 요청이 들어와도 정해진 갯수의 프로세스만을 사용하여 비동기 방식으로 대기시켜서 먼저 등록된 요청부터 처리해주는 방식
- 예전에는 아파치를 자주 사용했지만, 요즘에는 Nginx를 사용하는 추세
그 외 내용
위의 아파치와 nginx 서버의 보다 자세한 구조와 내용을 알고 싶다면 먼저 아래 링크를 확인해보자.
[nginx] 아파치와 nginx를 비교해보자 와 apache, nginx 차이 를 참고한다.
2.2 WSGI(Web Server Gateway Interface)
웹 서버는 파이썬을 모르기 때문에, 웹 서버가 받아들인 요청을 WSGI가 파이썬 장고(웹 애플리케이션)에게 전달해주는 역할을 한다.
- 비유를 하자면 웹 서버는 한국어를 사용하고 웹 애플리케이션은 영어를 쓰는 상황에서, WSGI가 이를 통역하여 웹 애플리케이션에 전달하는 역할을 한다.
WSGI의 종류
gunicorn, uwsgi, uvicorn
gunicorn: 프로그래밍하는 건 gunicorn이 더 쉽기 때문에, 입문자에게는 이를 권장한다.
uwsgi: gunicorn보다는 어렵지만, 디테일하게 직접 설계하여 성능을 최대로 높일 수 있다.
uvicorn: WSGI가 아닌 ASGI로 Asynchronous Server Gateway Interface로, 동기 기반 프레임워크에느 사용할 수 없다. 그래서 FastAPI의 경우 gunicorn과 사용할 수 없다. 그래서 uvicorn만 사용하던가, gunicorn + uvicorn으로 함께 사용할 수도 있다. FastAPI 공식 문서인 Server Workers - Gunicorn with Uvicorn를 보면 확인할 수 있다.
2.3 WAS(Web Application Server, 웹 애플리케이션 서버)
동적 페이지(dynamic page)를 처리하는 서버로, 데이터베이스와 연결되어 필요한 데이터를 주고 받는다.
정적 페이지:
고객님, 환영합니다.동적 페이지:
홍길동님, 환영합니다.-> 고객이 누구냐에 따라 보여주는 페이지가 다르다.웹 애플리케이션의 종류
- Django(파이썬), Flask(파이썬), Ruby on Rails(루비), Spring(java) 등등
- Django로 만들면 나중에 ML 을 적용할려면 호환이 좋다. 하지만 루비는 그렇지 않다.
2.4 DB
RDB와 NoSQL
RDB의 종류: MySQL, PostgreSQL, Oracle
- 형식이 존재
NoSQL의 종류: MongoDB, Redis
- 형식 존재하지 않음
Summary
클라이언트 <=> 서버
예시로서 서버 안에서는 다음과 같은 구조를 가진다.
- web server - WSGI - WAS (application server + db server…)
- NGiNX <=> gunicorn <=> Django <=> PostgreSQL
- 서버개발자는 위 모든 것을 다 설치해야 하며, 장고 외의 것들도 어떻게 구성할지 고려해야한다.