프록시 서버의 종류
1. Forward Proxy: 클라이언트 가까이에 위치한 프록시 서버
- 캐싱을 통해 빠른 서비스 이용 가능
- 보안 - 서버에게 클라이언트를 숨길 수 있다.
2. Reverse Proxy: 서버 가까이에 위치한 프록시 서버
- 분산처리 - 프록시 서버로 요청이 들어오면 여러대의 서버로 요청을 나누어 전달 후 처리한다.
- 보안 - 클라이언트에게 서버를 숨길 수 있다.
📌 수평확장
로드밸런서
Scale-Up: 물리적으로 서버의 사양을 높이는 하드웨어적인 방법
Scale-Out: 서버의 갯수를 늘려 하나의 서버에 줄 부하를 분산시키는 방법 →로드 밸런서: 요청을 여러 서버에 나눠 처리할 수 있도록 교통정리를 해주는 역할
| 로드 밸런서의 종류 | 로드밸런싱의 기준 |
|---|---|
| L2 | 데이터 전송 계층에서 Mac 주소를 바탕으로 로드 밸런싱 |
| L3 | 네트워크 계층에서 IP 주소를 바탕으로 로드 밸런싱 |
| L4 | 전송 계층에서 IP주소와 Port를 바탕으로 로드 밸런싱 |
| L7 | 응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱 (예, 엔드포인트) |
오토스케일링
Auto Scaling의 장점
동적 스케일링: 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있다.로드 밸런싱: 로드밸런서와 함께 사용하면, 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있어 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리 할 수 있다.타겟 트래킹: 사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있으며, 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정한다.헬스 체크와 서버 플릿 관리: Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있다. 헬스 체크를 하는 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체 한다.
- 다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우, 이들 일련의 EC2 서버 집합을 AWS는서버 플릿(Fleet)이라 부른다. 적정 수준의 서버 플릿 용량을 유지하는 데 도움을 준다.
📌 웹 서버
TOMCAT
- Apache사에서 개발한 서블릿 컨테이너만 있는 오픈소스 웹 애플리케이션 서버
Jetty
- 이클립스 재단의 HTTP 서버이자 자바 서블릿 컨테이너
- 타 웹 애플리케이션 대비 적은 메모리를 사용하여 가볍고 빠르다.
- 애플리케이션에 내장 가능하다.
NginX
- 트래픽이 많은 웹 사이트의 확장성을 위해 개발된 고성능 웹 서버
- 비동기 이벤트 기반으로 적은 자원으로 높은 성능과, 높은 동시성을 위해 개발되었다.
- 다수의 클라이언트 연결을 효율적으로 처리할 수 있다.
- 클라이언트와 서버 사이에 존재하는 리버스 프록시 서버로 사용할 수 있다.
- Nginx를 클라이언트와 서버 사이에 배치하여 무중단 배포를 할 수 있다.
NginX - Proxy Server
Spring Boot와 Nginx 연동 실습
# Nginx 설치
$ brew install nginx
# *Nginx* 실행
$ brew services start nginx
# *Nginx* 설정 파일 수정
$ nginx -t
$ nano /opt/homebrew/etc/nginx/nginx.conf
=>
server {
listen 80; # (Mac OS) 8080 포트에서 80번 포트로 변경한다.
...
location / {
...
proxy_pass http://localhost:8080; # 요청을 8080 포트로 넘긴다.
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
}
# Nginx 재시작
$ brew services restart nginx
# Nginx 종료
$ brew services stop nginx*NGINX - Load Balancer
로컬 환경에서 로드밸런싱 구성 실습
1. 두 개의 스프링부트 서버 실행
- 프로젝트 빌드
./gradlew build - 빌드 파일 실행(8080 포트)
java -jar sample-0.0.1-SNAPSHOT.jar - 빌드 파일 실행(8081 포트)
java -Dserver.port=8081 -jar sample-0.0.1-SNAPSHOT.jar
2. NGINX 설정파일 수정
http {
upstream backend {
server localhost:8080;
server localhost:8081;
}
location / {
proxy_pass http://backend;
}
}
# backend라는 서버 그룹을 만든 뒤 그룹 자체로 전달📌 VPC
VPC 관련 개념
CIDR(Classless inter-domain routing)
클래스 없는 도메인 간 라우팅 기법으로 1993년 도입되기 시작한 국제 표준의 IP주소 할당 방법이며, IP 클래스 방식을 대체한 방식
CIDR은 원하는 블록만큼 Network Address를 지정하여 운용할 수 있다.
| CIDR 블록 | IP 주소의 수 |
|---|---|
| /28 | 16 |
| /24 | 254 |
| /20 | 4094 |
| /18 | 16,382 |
| /16 | 65,536 |
서브넷(Subnet)
- 서브네트워크(Subnetwork)
- IP 네트워크의 논리적인 하위 부분을 가리킨다. 서브넷을 통해 하나의 네트워크를 여러 개로 나눌 수 있다.
- VPC를 사용해 다양한 서브넷을 생성할 수 있다.
- 서브넷은
AZ(Availability Zone)당 최소 하나를 사용할 수 있고, 여러 개의 AZ에 연결되는 서브넷은 만들 수 없다.
라우팅 테이블(Routing Table)
- 트래픽의 전송 방향을 결정하는 라우트와 관련된 규칙을 담은 테이블로 목적지를 향한 최적의 경로로 데이터 패킷을 전송하기 위한 모든 정보를 담고 있다. (하나의 지점에서 또 다른 지점으로 가기 위한 모든 정보를 제공하기 위한 테이블)
- 각각의 서브넷은 항상 라우팅 테이블을 가지고 있어야 하며, 하나의 라우팅 테이블 규칙을 여러 개의 서브넷에 연결하는 것도 가능하다. 서브넷을 생성하고 별도의 라우팅 테이블을 생성하지 않으면 클라우드가 자동으로 VPC의 메인 라우팅 테이블을 연결한다.
VPC
- Virtual Private Cloud
- AWS의 가상 네트워크
- AWS 서비스의 네트워크 연결을 제어
- 클라우드 내 프라이빗 공간을 제공함으로써, 클라우드를 퍼블릭과 프라이빗 영역으로 논리적으로 분리할 수 있게 한다.
인터넷에 연결된 VPC 만들기 : 단계별
1. IP 주소 범위 선택
- CIRD 이용
- RFC 1918 규약 지킬 것 권장
2. 가용 영역(AZ)별 서브넷 설정
- VPC 서브넷 권고사항
- /16 VPC (64K addresses)
- /24 subnets (251 addresses)
3. 인터넷으로 향하는 경로(route) 만들기
- 인터넷 게이트웨이(igw) : 외부 인터넷 ↔ VPC 내에 있는 리소스
4. VPC로/부터의 트래픽 설정
Network ACLs- Stateless firewalls
- 서브넷 단위로 방화벽 설정
Security groups: 애플리케이션 구조- 예) webservers, backends 로 그룹화 해서 설정
- 체크 포인트
- 최소 권한 원칙 준수
- Stateful -> VPC는 egress / ingress 각각에 대한 Security Group 생성
VPC 연결 설정
- 서브넷별로 각기 다른 라우팅
- NAT gateway: 아웃바운드 전용 인터넷 허용
- VPC 간 연결: VPC peering
- VPC 사용 예: 공유 서비스 VPC
- Exatablish a VPC peering : 요청 시작 → 요청 수락 → 경로 생성
- 회사 네트워크에 연결: Virtual Private Network(VPN) & Direct Connect(DX)
