8/9 (화) [Cloud] 운영 전략

 

 

 

 

 

🧊 프록시 서버(Proxy Server)

 

 

Proxy는 대리라는 뜻

클라이언트가 서버와 소통할 때 서버와 바로 통신하지 않고 프록시 서버를 통해 서버에 접근할 수 있다. ➡️ 대리 서버

 

일반 사용자는 지역이 제한되어 있는 서비스를 이용하기 위해 IP를 우회하거나, 캐시를 통해 더 빠른 이용을 하기 위해 프록시 서버를 사용한다.

 

 

🍹 프록시 서버의 종류

 

위치에 따라 Forward Proxy와 Reverse Proxy 두가지로 나뉜다.

 

 

 

🍺 Forward Proxy

 

Forward Proxy

 

클라이언트 가까이에 위치한 프록시 서버

클라이언트를 대신해 서버에 요청을 전달한다.

주로 캐싱을 제공하는 경우가 많아 사용자가 빠른 서비스 이용을 할 수 있도록 도와준다.

 

 

➡️ Forward Proxy를 사용할 경우 이점

 

✅ 캐싱을 통해 빠른 서비스 이용 가능

여러 클라이언트가 동일한 요청을 보내는 경우 첫 응답 결과 데이터를 캐시에 저장해놓고, 이후 서버에 재요청을 보내지 않아도 다른 클라이언트에게 빠르게 전달할 수 있다.

 

✅ 보안

서버에서 클라이언트의 IP추적이 필요한 경우 클라이언트의 IP가 아닌 프록시 서버의 IP가 전달된다. 서버가 응답받은 IP는 프록시 서버의 IP이기 때문에 서버에게 클라이언트를 숨길 수 있다.

 

 

 

🍺 Reverse Proxy

 

Reverse Proxy

 

서버 가까이에 위치한 프록시 서버이다.

서버를 대신하여 클라이언트에 응답을 제공한다.

 

 

➡️ Reverse Proxy 사용할 경우 이점

 

✅ 분산처리

클라이언트-서버 구조에서 사용자가 많아져 서버에 과부하가 올 경우를 위해 부하를 분산할 수 있다. 프록시 서버로 요청이 들어오면 여러대의 서버로 요청을 나누어 전달한다.

 

✅ 보안

Forward Proxy와는 반대로 클라이언트에게 서버를 숨길 수 있다. 클라이언트 입장에서는 요청을 보내는 서버가 프록시 서버이므로 실제 서버 IP 주소가 노출되지 않는다.

 

 

 

🧊 로드밸런서

 

웹 서버로 너무 많은 사용자가 요청을 보낼 경우 서버는 감당하지 못하고 과부하가 오게 된다.

과부하가 올 경우 서비스를 정상적으로 제공하지 못하는 문제가 생긴다.

이를 해결하기 위해 서버의 하드웨어를 업그레이드 하는 방법과 서버의 개수를 늘리는 방법이 있다.

 

 

 

🍹 Scale-Up

 

물리적으로 서버의 사양을 업그레이드하는 방법이다. (HDD, 메모리 등)

수직적 스케일링

 

🍺 장점

서버의 수를 늘리지 않고 프로그램 구현에 있어 변화가 필요없다.

 

🍺 단점

서버의 사양을 높이는 데는 굉장히 높은 비용이 든다.

하드웨어의 업그레이드에는 한계가 있다.

 

 

🍹 Scale-Out

 

서버의 개수를 늘려 하나의 서버에 줄 부하를 분산시키는 방법이다.

수평적 스케일링

많은 요청이 오더라도 여러대의 서버가 나눠서 처리를 하기 때문에 서버의 사양을 높이지 않고도 비교적 저렴한 방법으로 부하를 처리할 수 있다.

 

Scale-Out 방법으로 서버를 여러대 있을 경우 서버에 요청을 나눠 처리할 수 있는 역할이 필요하다. ➡️ 로드 밸런서

여러 서버에 교통정리를 해주는 기술 혹은 프로그램을 로드 밸런싱이라고 부른다.

 

※ 추가학습) Scale-Up vs Scale-Out

 

 

 

🍹 로드 밸런서 종류

 

클라이언트의 요청을 어떤 기준으로 분산하냐에 따라 네종류로 나뉜다.

 

L2 : 데이터 전송 계층에서 Mac 주소를 바탕으로 로드 밸런싱한다.

L3 : 네트워크 계층에서 IP 주소를 바탕으로 로드 밸런싱한다.

L4 : 전송 계층에서 IP주소와 Port를 바탕으로 로드 밸런싱한다.

L7 : 응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱한다. ex) 엔드포인트

 

 

 

 

🧊 오토스케일링 (AWS의 Auto Scaling 기준)

 

오토스케일링은 Scale-Out 방식으로 서버를 증설할 때 자동으로 서버(리소스)를 관리해주는 기능이다.

클라이언트의 요청이 많아져 서버의 처리 요구량이 증가하면 새 리소스를 자동으로 추가하고 반대로 처리 요구량이 줄어들면 리소스를 감소시켜 효율적으로 관리해준다.

 

 

🍹 Auto Scaling의 장점

 

🍺 동적 스케일링

사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있다.

스케일 업 할 수 있는 서버의 수에 제한이 없고, 필요한 경우 즉시 수백~수만대로 늘릴 수 있다.

 

🍺 로드 밸런싱

로드 밸런서와 함께 사용하면, 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있다. 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리할 수 있다.

※ 워크로드(Workloads) :  애플리케이션이나 백엔드 프로세스 같이 비즈니스 가치를 창출하는 리소스 및 코드 모음

 

🍺 타겟 트래킹

사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있다.

사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정한다.

 

🍺 헬스 체크와 서버 플릿 관리

EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있다.

특정 인스턴스의 문제가 감지되면 자동으로 다른 인스턴스로 교체한다.

 

 

※ 서버 플릿(Fleet)

Fleet은 직역하면 함대라는 의미이다.

다수의 EC2 서버에서 애플리케이션을 호스팅하는 경우,

호스팅하고 있는 일련의 EC2 집합을 AWS는 서버 플릿(Fleet)이라고 부른다.

Auto Scaling은 적정 수준의 서버 플릿 용량을 유지하는데 도움을 준다.

Auto Scaling은 한대 또는 그 이상의 서버가 다운되면 서버 인스턴스 처리용량을 유지하기 위해 부족한 만큼 새로운 서버를 추가로 실행시키는 방식으로 서버 플릿을 유지한다.

 

※ 참고자료) EC2 Fleet 설명서

 

 

 

🍹 EC2 Auto Scaling 활용

 

Auto Scaling은 EC2 인스턴스 뿐만 아니라 다른 인스턴스와도 결합이 가능하다.

EC2 Auto Scaling은 오직 EC2 서버(리소스)만 대상으로 한다.

 

 

🍺 시작 템플릿(Launch Template)

시작 템플릿을 통해서 인스턴스를 확장할 때 구성 정보를 쉽게 적용할 수 있다.

인스턴스를 늘릴 때마다 매번 parameter들을 설정할 필요없이 시작 템플릿으로 쉽게 설정하고 확장할 수 있다.

시작 템플릿은 AMI ID, 인스턴스 타입, 네트워크 세팅 등의 인스턴스 생성시 필요한 정보를 담고 있다.

여러 시작 템플릿 버전을 만들어서 서로 다른 launch parameter를 가진 템플릿을 여러개 만들수있다.

 

※ AWS 공식문서

 

 

🍺 Auto Scaling 그룹

 

스케일업 및 스케일다운 규칙의 모음이다.

EC2 인스턴스 시작부터 삭제하기까지의 모든 동작에 대한 규칙과 정책을 담고 있다.

 

 

🍺 Scaling 유형

 

🥑 인스턴스 레벨 유지

기본 스케일링 계획이라고 불린다.

항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있다.

일정한 수의 인스턴스가 필요한 경우 최소, 최대, 원하는 용량에 동일한 값을 설정할 수 있다.

 

🥑 수동 스케일링

기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있다.

수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가하거나 삭제해야 한다. 이 방식은 추천하지 않는 방식이다.

 

🥑 일정별 스케일링

예측 스케일링 트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋다.

 

🥑 동적 스케일링

수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조절하는 방법을 정의한다.

CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정한다.

예를 들어 CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가한다.

동적 스케일링 정책을 정의할 때는 스케일 업과 스케일 다운 두 가지의 정책을 작성해야 한다.

 

 

 

 

🧊 TOMCAT

 

Tomcat

 

🍹 Tomcat 이란?

 

Apache사에서 개발한 서블릿 컨테이너만 있는 오픈소스 웹 애플리케이션 서버이다.

 

 

🍺 Tomcat의 특징

 

🥑 자바 애플리케이션을 위한 대표적인 오픈소스 WAS(Web Application Server)이다.

🥑 오픈소스이기 때문에 라이선스 비용 부담없이 사용할 수 있다.

🥑 독립적으로도 사용 가능하며 Apache 같은 다른 웹 서버와 연동하여 함께 사용할 수 있다.

🥑 Spring Boot의 내장 서버이기 때문에 별도의 설치 과정 없이 사용할 수 있다.

🥑 spring-boot-starter-web 모듈 속에 내장되어있다.

 

 

 

🧊 Jetty

 

jetty

 

🍹Jetty 란?

 

Jetty는 이클립스 재단의 HTTP 서버이자 자바 서블릿 컨테이너 이다.

 

 

🍺 Jetty의 특징

 

🥑 2009년 이클립스 재단으로 이전하며 오픈소스 프로젝트로 개발되었다.

🥑 Jetty는 타 웹 애플리케이션 대비 적은 메모리를 사용하여 가볍고 빠르다.

🥑 애플리케이션에 내장 가능하다.

🥑 경량 웹 애플리케이션으로 소형 장비, 소규모 프로그램에 더 적합하다.

 

 

🍹 Tomcat에서 Jetty로 서버 변경하기

 

build.gradle 파일

➡️ spring-boot-starter-web 의존성 추가된 부분에 Tomcat을 제외시켜준다.

dependencies {
	implementation ('org.springframework.boot:spring-boot-starter-web') {
		exclude module: 'spring-boot-starter-tomcat'
	}
}

 

Jetty 의존성을 추가한다.

implementation ('org.springframework.boot:spring-boot-starter-jetty')

 

Tomcat을 모듈에서 제외시켰고 Jetty 모듈을 추가했기 때문에 서버를 실행할 때 Jetty로 실행되는 것을 확인할 수 있다.

 

 

 

🧊 NGINX

 

NGINX

 

🍹 NGINX란?

 

🥑 NGINX는 가볍고 높은 성능을 보이는 오픈소스 웹 서버 소프트웨어이다.

🥑 Igor Sysoev 라는 러시아 개발자가 개발했다.

🥑 동시접속 처리에 특화된 웹 서버 프로그램이다.

🥑 Apache보다 동작이 단순하고 전달자 역할만 하기 때문에 동시접속 처리에 특화되어 있다.

🥑 Nginx는 클라이언트에게 정적 리소스를 빠르게 응답 하기 위한 웹 서버로 사용할 수 있다.

 

 

🍺 NGINX의 특징

 

🥑 트래픽이 많은 웹 사이트의 확장성을 위해 개발된 고성능 웹 서버이다.

🥑 비동기 이벤트 기반으로 적은 자원으로 높은 성능과 높은 동시성을 위해 개발되었다.

🥑 다수의 클라이언트 연결을 효율적으로 처리할 수 있다.

🥑 클라이언트와 서버 사이에 존재하는 리버스 프록시 서버로 사용할 수 있다.

🥑 Nginx를 클라이언트와 서버 사이에 배치하여 무중단 배포를 할 수 있다.

 

 

🍹 Spring Boot와 Nginx 연동하기

 

nginx를 이용해서 Spring Boot 앞에 프록시 서버를 구축할 수 있다.

그래서 클라이언트가 실제로 통신하는 포트를 Spring Boot 서버와 분리할 수 있다.

 

클라이언트 - NGINX - Spring Boot

 

 

🍺 NGINX 설치 및 실행 (Mac OS)

 

✅ 설치

brew install nginx

 

✅ 실행

brew services start nginx

 

✅ 중단

brew services stop nginx

 

 

 

🍺 NGINX 설정 파일(.conf 파일) 찾기

 

nginx의 설정파일(.conf 파일)로 여러가지 설정을 변경할 수 있다.

(사용할 포트번호, 연결할 서버의 포트 번호 등)

 

✅ 설정파일 위치 찾기

nginx -t

 

텍스트 편집기 실행 후 설정 변경

nano /opt/homebrew/etc/nginx/nginx.conf

 

 

 

🍺 NGINX로 Proxy Server 만들기

 

설정파일에 아래와 같이 코드 작성

 

http {
	...
	server{
		listen 80; #8080 포트에서 80번 포트로 변경한다
		...
		location / {
			root html;
			index index.html index.htm;
			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;
		}
		...
	}
}

 

 

설정파일 수정 뒤에는 재시작을 해준다.

brew services restart nginx

 

 

 

🍹 NGINX를 Load Balancer로 활용하기

 

 

NGINX를 통해 로드밸런싱을 구성할 수 있다.

로드밸런싱에 추가할 서버를 실행한다.

NGINX 설정 파일에 들어가서 서버 그룹을 만들고 해당 서버 포트 번호를 추가해준다.

 

http {
	upstream backend {
		server localhost:{포트번호1};	#로드밸런싱할 서버1
		server localhost:{포트번호2};	#로드밸런싱할 서버2
		...
	}
	location / {
		proxy_pass http://backend;
	}
}

 

upstream 뒤에 적은 backend는 지정한 서버 그룹이름이다.

원하는 그룹이름으로 적으면 된다.

 

추가자료) nginx 공식 문서

 

 

 

 

🧊 VPC

 

 

🍹 VPC 란?

 

VPC : Vitual Private Cloud 서비스

클라우드 내 private 공간을 제공해서 클라우드를 public과 private 영역으로 논리적으로 분리할 수 있게 해준다.

 

 

 

🍹 VPC 구성 요소와 주요 용어

 

 

🍺 IP Address

 

IP는 컴퓨터 네트워크에서 장치들이 서로를 식별하기 위해 사용하는 특수한 번호이다.

OSI의 3계층인 네트워크 계층에 해당된다.

IPv4, IPv6로 나뉘어 있으며 혼용하여 사용하고 있다.

IPv4는 각 8비트, IPv6는 각 32비트로 4개의 옥텟으로 이루어져 있다.

네트워크 주소와 호스트 주소로 나뉘어 진다.

 

🌱 네트워크 주소 : 호스트들을 모은 네트워크를 지칭하는 주소이다. 네트워크 주소가 동일한 네트워크를 로컬 네트워크라고 한다.

🌱 호스트 주소 : 하나의 네트워크 내에 존재하는 호스트를 구분하기 위한 주소

 

네트워크 주소와 호스트 주소를 나누는 경계점이 고정되어 있지 않다.

IP주소는 네트워크 주소와 호스트 주소를 나누는 경계점에 따라 클래스(Class)를 나눈다.

호스트 IP 개수에 따라 네트워크의 크기를 다르게 할당할 수 있다.

클래스는 총 5가지(A, B, C, D, E)로 나뉘어져 있다.

D와 E 클래스는 멀티캐스트용, 연구 개발을 위한 예약 IP라서 보통은 사용하지 않는다.

 

A, B, C 클래스의 맨 앞자리 숫자만 보면 무슨 클래스인지 식별이 가능하다.

클래스풀(Classful) 방식이라고 부른다.

 

A 클래스

Network Address	Host Address	Host Address	Host Address
0 ~ 127	0 ~ 255	0 ~ 255	0 ~ 255

0.0.0.0은 자체 네트워크를 의미하고 127.0.0.0 ~ 127.255.255.255는 자기자신을 가리키기 위해 예약된 IP 주소이기 때문에 사용할 수 없다.

 

B 클래스

Network Address	Network Address	Host Address	Host Address
128 ~ 191	0 ~ 255	0 ~ 255	0 ~ 255

 

C 클래스

Network Address	Network Address	Network Address	Host Address
192 ~ 223	0 ~ 255	0 ~ 255	0 ~ 255

 

모든 클래스의 맨 앞 주소는 네트워크 주소로, 맨 뒤 주소는 브로드캐스트 주소로 사용하므로 실제 사용할 수 있는 IP는 2^n - 2이다.

 

 

🍺 CIDR(Classless inter-domain routing)

 

클래스 없는 도메인 간 라우팅 기법으로 사이더라고 불린다.

국제 표준의 IP 주소 할당 방법이다.

클래스풀 방식을 대체한 방식이다.

 

기존에는 클래스에 따라 정해진 Network Address와 Host Address를 사용했지만 CIDR은 원하는 블록만큼 Network Address를 지정할 수 있다.

AWS의 VPC는 CIDR 방식이다.

 

ex) 172.16.0.0/24

-> /24 이 서브넷 블록, 네트워크 주소에 16비트만 할당한다는 의미이다. 총 2^인 개의 IP 주소를 사용할 수 있다.

 

AWS VPC에서는 /16 블록을 사용하도록 권장하고 있다.

※ 추가 자료) AWS VPC 기본 및 연결 옵션

 

 

🍺 서브넷(Subnet)

 

Subnetwork의 줄임말이다.

IP 네트워크의 논리적 하위 부분을 가리킴

서브넷을 통해 하나의 네트워크를 여러 개로 나눌 수 있음

VPC를 사용하면 필요에 따라 다양한 서브넷을 생성할 수 있음

• 퍼블릭 서브넷: 인터넷을 통해 연결할 수 있는 서브넷
• 프라이빗 서브넷: 인터넷을 연결하지 않고, 보안을 유지하는 배타적인 서브넷
• VPN only 서브넷 : 기업 데이터 센터와 VPC를 연결하는 서브넷

 

VPC

 

서브넷은 VPC의 CIDR 블록을 이용해 정의된다.

최소 크기의 서브넷은 /28 이다.

서브넷은 AZ(Availability Zone, 가용 영역)당 최소 하나를 사용할 수 있고, 여러 개의 AZ에 연결되는 서브넷은 만들 수 없다.

 

AWS가 확보한 서브넷 중 처음 네 개와 마지막 IP 주소는 인터넷 네트워킹을 위해 예약되어 있다. 예를 들어 10.0.0.0/24 체계의 CIDR 블록이 있는 서브넷에서 10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.255 는 IP 주소가 예약되어 있다.

 

 

🍺 라우팅 테이블(Routing Table)

 

트래픽의 전송 방향을 결정하는 라우트와 관련된 규칙을 담은 테이블이다.

목적지까지 최적의 경로로 데이터 패킷을 전송하기 위한 모든 정보를 담고 있다.

모든 서브넷은 라우팅 테이블을 가진다.

하나의 테이블 규칙을 여러 서브넷에 연결할 수 있다.

서브넷 생성 후 별도의 라우팅 테이블을 생성하지 않으면 클라우드가 자동으로 VPC의 메인 라우팅 테이블과 연결한다.