[AWS] VPC - EC2 초기 설정

VPC (Virtual Private Cloud)

여러 IP를 제공할 수 있는 가상 클라우드 공간

VPC 공간 안에서 Public과 Private Subnet을 분리하고, EC2와 연결.
외부 요청은 Public Subnet의 웹 서버 (EC2)가 받고, 실제 데이터 처리는 Private Subnet의 서버나 DB에서 수행하는 형태

VPC의 기능

• 서브넷(Subnet) : VPC를 다시 쪼갠 작은 네트워크 단위
  • IP 그룹
  • Private Subnet과 Public Subnet 있음.
  • Private은 DB용으로 많이 사용함.
  • EC2를 생성해서 EC2와 Public Subnet과 연결하면 외부에서 접근 가능한 EC2가 됨.
    그 반대로 EC2와 Private Subnet과 연결하면 내부에서만 접근 가능한 EC2가 됨.
• 인터넷 게이트웨이(IGW) : VPC와 인터넷 사이의 통로 역할
• 라우팅 테이블 (Route Table) : 목적지가 어디냐에따라 어느길로 가야하는지 정해놓는 테이블
  (내부 통신이면 a로 외부 통신이면 b로 결정해줌)
• 탄력적 IP : EC2는 껏다키고 하면 IP가 바뀜. 그래서 탄력적 IP로 고정 IP를 발급받아서 도메인(DNS)연결하는 형태

EC2

가상의 컴퓨터를 만드는것. 처음 생성할 때 인스턴스 유형(가상 컴퓨터 사양)을 선택할 수 있다.
CPU, 메모리(RAM), 네트워크 성능, 스토리지 성능
공부하면서 visual studio 연결할거면 4GiB정도 사용은 해야한다. (t3.medium)

키 페어를 사용해서 인스턴스에 안전하게 접근할 수 있는데 private key와 public key가 존재한다.
Public Key는 AWS가 보관하고 Private Key는 생성하면 바로 .pem 파일이 다운로드 된다. 딱 한번만 다운로드 가능하니 잘 보관해놔야함. 해당 Private Key는 추후 생성된 EC2 가상 컴퓨터에 접근하기에 필수로 필요함.

# key file 접근권한을 나만 읽을 수 있도록 설정 필요.
# 다른 사람이 읽을 수 있으면 SSH 클라이언트가 보안 취약점으로 간주하고 에러내는 경우가 있음.
sudo chmod 400 my-key-pair.pem

보안 그룹(방화벽)은 모든 연결을 받아주는게 아니라 IP 주소에서 특정 port만 접근 가능하도록 문을 열어주는것.
ssh 연결은 22port. 80port는 웹서버용. 8888port는 runpod 기본 port.

Public 보안 그룹 생성 : 유형(protocol), 소스 유형(IP), Port

EC2를 생성하면 이제 터미널로 접근할 수 있다.

ssh -i "{pem 경로}" {name}@{public_ip}

# 처음 접근 후 초기화 세팅
# 현재 상태와 우분투(OS)와 SW 업데이트 할거 있는지 확인
sudo apt update
# 업데이트 내용이 있으면 업데이트 실행하기
sudo apt upgrade

django 세팅

Nginx는 밖에서 손님을 맞이하고 보안을 책임지는 입구고,
Gunicorn은 안에서 Python 코드를 돌려 실질적인 비즈니스 로직을 처리하는 엔진

NGiNX (Web Server)

# nginx (웹 서버) 설치
sudo apt install nginx

사용자 요청에따라 즉시 응답하거나 WSGI Server로 넘기거나 결정한다. TCP/IP 소켓을 열고, 데이터를 패킷 단위로 주고 받으며, 수천 개의 동시 연결을 관리하는 역할들을 한다.

• 리버시 프록시 (Reverse Proxy) : 외부의 요청을 받아 내부 서버(Gunicorn)로 전달합니다. 보안상 실제 서버를 외부에 노출하지 않는 방패 역할을 합니다.
• 정적 파일 처리: 이미지, CSS, JS 같은 파일은 주방(Gunicorn)까지 갈 필요 없이 매니저가 직접 내어줍니다. 속도가 훨씬 빠릅니다.
• 부하 분산(Load Balancing): 손님이 너무 많으면 여러 명의 요리사에게 골고루 주문을 나눠줍니다.
• 보안 및 암호화: HTTPS(SSL) 인증서를 설치하여 통신을 암호화하는 작업을 담당합니다.

Gunicorn (WSGI 서버, WSGI HTTP Server)

Python 웹 앱(Flask, Django 등)은 웹 서버(Nginx)와 직접 전달할 수 없다. WSGI(Web Server Gateway Interface)를 통해 Python 웹 앱 결과 값을 가져올 수 있다. 추가적으로 WSGI 서버는 서버가 죽지 않게 관리하는 프로세스 관리자도 존재한다.
django만 실행해준다. 즉, View, Template, Model만 실행해준다. -> Image랑 JS는? Nginx(Web Server)가 진행함.

Python 웹 앱과 웹 서버는 왜 직접 대화 할 수 없는가❓Why❓

Nginx(Web Server, C언어 기반)는 텍스트 기반인 HTTP 프로토콜의 바이트(Byte) 스트림을 직접 파싱한다. Python code는 알지 못함.
Python 웹 앱(Flask, Django 등)은 Python 객체와 함수로 이루어진 코드라서 HTTP가 뭔지, 소켓 통신이 뭔지 이해할 수 없다. 

결국 WSGI 서버는 Python code를 실행해서 응답하는 역할을 한다는 것.
즉, 정적인 요청은 WebServer에서 바로 응답하고 동적인 경우에는 WSGI를 통해서 응답을 가져온다.

CollectionStatic

NGINX가 서비스하는 Static 요청에대한 응답은 이곳저곳에 있으면 안된다. 한 곳에 몰아넣어야하는게 그 작업을 하기위한 명령어. CollectionStatic