코드스테이츠 74일차

학습목표

• 프록시 서버가 추가된 2-Tier Architecture는 어떻게 작동하는지 설명할 수 있다.
• 로드밸런서가 필요한 이유를 이해할 수 있다.
• 오토스케일링의 장점을 설명할 수 있다.
• 다양한 웹 서버의 주요 목적을 설명할 수 있다.
• NGINX를 사용하여 프록시 서버를 구성할 수 있다.
• NGINX를 사용하여 로드밸런싱을 구성할 수 있다.
• VPC를 이용해 안전한 배포 아키텍쳐를 구성할 수 있다.

 

프록시 서버

프록시 서버(Proxy Server)는 클라이언트가 서버와 소통할 때, 서버에 바로 접근하지 않고 자신을 통해 서버에 접근할 수 있도록 해주는 일종의 대리 서버이다.

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

하지만 이 외에도 프록시 서버를 통해 얻을 수 있는 이점들이 있는데, 프록시 서버의 종류와 사용함으로써 얻을 수 있는 장점에 대해 알아보자

 

프록시 서버의 종류

프록시 서버는 위치에 따라 Forward Proxy와 Reverse Proxy 두 가지로 나뉜다.

간단하게 보자면 프록시 서버가 클라이언트에 가까이 있는지, 서버에 가까이 있는지로 구분할 수 있다.

각각 다른 목적을 기대하기 때문에 상황을 고려하여 판단을 내릴 수 있다.

 

1. Forward Proxy

Forward Proxy는 클라이언트 가까이에 위치한 프록시 서버로 클라이언트를 대신해 서버에 요청을 전달한다.

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

 

Forward Proxy의 장점

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

• 클라이언트는 서비스의 서버가 아닌 프록시 서버와 소통하게 된다. 그러한 과정에서 여러 클라이언트가 동일한 요청을 보내는 경우 첫 응답을 하며 결과 데이터를 캐시에 저장해놓고, 이후 서버에 재 요청을 보내지 않아도 다른 클라이언트에게 빠르게 전달할 수 있다.

보안

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

 

2. Reverse Proxy

Reverse Proxy는 반대로 서버 가까이에 위치한 프록시 서버로 서버를 대신해서 클라이언트에 응답을 제공한다.

 

Reverse Proxy의 장점

분산처리

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

보안

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

 

로드밸런서

만약 서비스에 너무 많은 사용자(클라이언트)가 접속하면 어떻게 될까?

하나의 서버에 너무 많은, 혹은 너무 잦은 요청을 보낸다면 서버에는 과부하가 올 것이다.

과부하로 인해 서버가 원활한 서비스를 제공하지 못하는 경우를 해결하기 위해 크게 서버의 하드웨어를 업그레이드하는 방법과 서버의 갯수를 늘리는 방법, 두가지 선택을 할 수 있다.

 

1. Scale-Up

Scale-Up은 물리적으로 서버의 사양을 높이는 하드웨어적인 방법이다.

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

하지만 서버의 사양을 높이는데엔 굉장히 높은 비용이 들고, 하드웨어의 업그레이드엔 한계있다는 큰 단점이 있다.

또한 사양을 늘린만큼 클라이언트의 요청이 더욱 많아진다면, 서버에 발생하는 부하는 여전히 해결하지 못한 상황이 된다.

 

2. Scale-Out

Scale-Out은 서버의 갯수를 늘려 하나의 서버에 줄 부하를 분산시키는 방법이다.

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

 

Scale-Out방법으로 여러대의 서버로 부하를 처리하는 경우, 클라이언트로부터 온 요청을 여러 서버 중 어느 서버에 보내서 처리해야할까?

요청을 여러 서버에 나눠 처리할 수 있도록 교통정리를 해줄 역할이 필요한데, 이 역할을 하는게 바로 로드 밸런서이고, 여러 서버에 교통정리를 해주는 기술 혹은 프로그램을 로드 밸런싱이라고 부른다.

 

로드 밸런서의 종류

로드 밸런서의 종류	로드밸런싱의 기준
L2	데이터 전송 계층에서 Mac 주소를 바탕으로 로드 밸런싱 한다.
L3	네트워크 계층에서 IP 주소를 바탕으로 로드 밸런싱 한다.
L4	전송 계층에서 IP주소와 Port를 바탕으로 로드 밸런싱 한다.
L7	응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱한다. (예, 엔드포인트)

 

오토스케일링

위를 통해 서버의 부하를 분산시키기 위해 로드밸런싱을 사용한다는 것을 깨달았다.

그렇다면 서버는 언제, 어떻게 추가해야할까?

개발자가 직접 라이브로 지켜보며 수동으로 서버를 증설해야한다면 너무나 번거롭고 갑작스럽게 발생한 문제에 대처하기도 한계가 있다.

이런 상황은 오토스케일링을 통해 보다 간편히 해결할 수 있다.

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

클라이언트의 요청이 많아져 서버의 처리 요구량이 증가하면 새 리소스를 자동으로 추가하고 반대로 처리 요구량이 줄어들면 리소스를 감소시켜 적절한 분산 환경을 만들어준다.

 

Auto Scaling의 장점

• 동적 스케일링 : Auto Scaling의 가장 큰 장점은 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있다는 점이다. 스케일 업 할 수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업 할 수 있다.
• 로드 밸런싱 : Auto Scaling은 리소스를 동적으로 스케일업 혹은 스케일다운 한다. 로드밸런서와 함께 사용하면, 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있어 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리 할 수 있다.
• 타겟 트래킹 : 사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있으며, 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정한다.
• 헬스 체크와 서버 플릿 관리 : Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있다. 헬스 체크를 하는 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체 한다.

 

다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우, 이들 일련의 EC2 서버 집합을 AWS는 서버 플릿(Fleet)이라 부른다.

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

예를 들어, 어떤 기업의 애플리케이션이 6대의 EC2 서버에서 실행 중일 때 6대 서버에 대한 헬스 체크 상태를 모니터링 하다가 특정 서버에 문제가 생기면 즉시 대응 조치를 할 수 있다.

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

 

EC2 Auto Scaling 활용

Auto Scaling은 EC2 인스턴스 뿐만 아니라 다른 인스턴스와도 결합 가능하지만, EC2 사용자에게 가장 인기가 많은 서비스이다.

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

 

시작 템플릿(Launch Configuration)

Auto Scaling으로 인스턴스를 확장 또는 축소하려면 어떤 서버를 사용할지 결정해야한다.

이는 시작 템플릿을 통해서 가능하며, AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있다.

만약 시작 템플릿을 사용하고 있지 않고 시작 템플릿을 생성하지 않으려는 경우에는 대신 시작 구성을 생성할 수 있다.

시작 구성은 EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷하다.

사용할 AMI의 ID, 인스턴스 유형, 키 페어, 보안 그룹 등의 정보를 포함시켜서 시작 구성을 생성한다.

 

Auto Scaling 그룹 생성

Auto Scaling 그룹은 스케일업 및 스케일 다운 규칙의 모음으로 EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있다.

 

Scaling 유형

인스턴스 레벨 유지

• 기본 스케일링 계획으로도 부르며, 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있다. 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정할 수 있다.

수동 스케일링

• 기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있다. 수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제 해야한다. 해당 방식은 추천하지 않는 방식이다.

일정별 스케일링

• 예측 스케일링트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋다. 예를 들어 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면 낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운 하는 규칙을 추가하면 된다.

동적 스케일링

• 수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의한다. 이 방식은 CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정한다. 예를 들어 CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가하는 방식이다. 이와 같은 스케일링 정책을 정의 할 때는 항상 스케일 업과 스케일 다운 두 가지의 정책을 작성해야 한다.

 

TOMCAT

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

Spring Boot의 내장 서버이기 때문에 우리는 별도의 설치 과정 없이 자연스럽게 Tomcat을 사용해왔다.

Tomcat은 다음과 같은 특징을 가지고 있다.

• 자바 애플리케이션을 위한 대표적인 오픈소스 WAS(Web Application Server)이다.
• 오픈소스이기 때문에 라이선스 비용 부담 없이 사용할 수 있다.
• 독립적으로도 사용 가능하며 Apache 같은 다른 웹 서버와 연동하여 함께 사용할 수 있다.
• Tomcat은 자바 서블릿 컨테이너에 대한 공식 구현체로, Spring Boot에 내장되어있어 별도의 설치 과정이 필요 하지 않다.

 

Jetty

Spring Boot에는 Tomcat이 내장 되어있어 별다른 설치 과정 없이 Tomcat을 통해 실행됨을 확인했다.

하지만 Tomcat이 아닌 다른 서버를 통해서도 프로젝트를 실행할 수 있다.

 

Jetty?

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

Jetty도 Tomcat과 같이 자바 서블릿 컨테이너이자 서버로 사용할 수 있기 때문에 개발자는 원하는 서버를 선택하여 프로젝트를 구성할 수 있다.

Jetty의 특징은 다음과 같다.

• 2009년 이클립스 재단으로 이전하며 오픈소스 프로젝트로 개발되었다.
• Jetty는 타 웹 애플리케이션 대비 적은 메모리를 사용하여 가볍고 빠르다.
• 애플리케이션에 내장 가능하다.
• 경량 웹 애플리케이션으로 소형 장비, 소규모 프로그램에 더 적합하다.

 

Spring Boot 서버 Jetty로 변경하기

build.gradle 파일에서 spring-boot-starter-web 의존성이 추가되어있는 부분을 확인하여 포함되어있는 Tomcat을 제외시킨 후 프로젝트를 재 빌드하면 의존성이 제거 되었음을 확인할 수 있다.

Tomcat을 제외했다면 대체할 서버로 Jetty 의존성을 추가한 후 프로젝트를 재 빌드하면 Jetty에 대한 의존성이 추가되었음을 확인할 수 있다.

다른 서버 역시 변경하고 싶다면 Tomcat 의존성을 제외하고, 원하는 서버의 의존성을 추가하여 연결할 수 있다.

 

Nginx?

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

이전에 살펴본 Tomcat과 Jetty는 자바 서블릿 컨테이너 혹은 웹 애플리케이션 서버였다면, Nginx는 웹 서버로 클라이언트에게 정적 리소스를 빠르게 응답하기 위한 웹 서버로 사용할 수 있다.

Nginx는 다음과 같은 특징을 가지고 있다.

• Nginx는 트래픽이 많은 웹 사이트의 확장성을 위해 개발된 고성능 웹 서버이다.
• 비동기 이벤트 기반으로 적은 자원으로 높은 성능과, 높은 동시성을 위해 개발되었다.
• 다수의 클라이언트 연결을 효율적으로 처리할 수 있다.
• 클라이언트와 서버 사이에 존재하는 리버스 프록시 서버로 사용할 수 있다.
• Nginx를 클라이언트와 서버 사이에 배치하여 무중단 배포를 할 수 있다.

 

VPC

VPC는 Virtual Private Cloud 서비스로, 클라우드 내 프라이빗 공간을 제공함으로써, 클라우드를 퍼블릭과 프라이빗 영역으로 논리적으로 분리할 수 있게 한다.

이전에 VPC가 없었을 때는 클라우드에 있는 리소스를 격리 할 수 있는 방법이 없었고, 따라서 인스턴스들이 서로 거미줄처럼 연결되고, 인터넷과 연결되어 시스템의 복잡도를 엄청나게 끌어올릴 뿐만 아니라, 의존도가 매우 높았다.

따라서 유지 및 관리에 많은 비용과 노력을 투입해야 하는 단점이 있었다.

그러나 VPC를 분리함으로써 확장성을 가질 수 있고, 네트워크에 대한 완전한 통제권을 가질 수 있게 되었다.

 

VPC 이해를 위한 구성 요소와 주요 용어

IP Address

IP는 컴퓨터 네트워크에서 장치들이 서로를 인식하고 통신을 하기 위해서 사용하는 특수한 번호로, IPv4, IPv6로 나뉘어 있으며 혼용하여 사용하고 있다.

IPv4를 기준으로 예를 들면, 172.16.0.0의 모습으로 이루어져 있다.

하지만 표에서 보이는 십진수의 형태는 보기 편하도록 변형한 것이고, 실제의 형태는 2진수 8자리의 형태, 즉 각 8bit(비트)씩 총 32bit로 구성되어 있다.

이때 각 8bit를 Octet이라고 부르며, .으로 구분한다.

그러므로 IPv4는 4개의 Octet(옥텟)으로 이루어져 있다고 할 수 있다.

 

IP Address Class

이전에는 IPv4 주소에서 호스트가 연결되어 있는 특정 네트워크를 가리키는 8비트의 네트워크 영역(Network Address)과 해당 네트워크 내에서 호스트의 주소(Host Address)를 가리키는 나머지 영역을 구분하기 위해서 클래스(Class)를 사용했다.

클래스는 총 5가지(A, B, C, D, E) 클래스로 나누어져 있지만 D와 E 클래스는 멀티캐스트용, 연구 개발을 위한 예약 IP이므로 보통 사용되지 않는다.

 

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

 

CIDR(Classless inter-domain routing)

CIDR는 사이더라고 불리우며, 클래스 없는 도메인 간 라우팅 기법으로 1993년 도입되기 시작한 국제 표준의 IP주소 할당 방법이며, 앞서 살펴본 IP 클래스 방식을 대체한 방식이다.

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

 

위의 예시에 따르면, /16은 첫 16bit를 Network Address로 사용한다는 의미로, 총 2^16인 65,536개의 IP주소를 사용할 수 있는 커다란 네트워크 블록을 이러한 방식으로 표시한다.

CIDR 블록	IP 주소의 수
/28	16
/24	254
/20	4094
/18	16,382
/16	65,536

 

서브넷(Subnet)

서브넷은 서브네트워크(Subnetwork)의 줄임말로 IP 네트워크의 논리적인 하위 부분을 가리킨다.

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

VPC를 사용하면 퍼블릭 서브넷, 프라이빗 서브넷, VPN only 서브넷 등, 필요에 따라 다양한 서브넷을 생성할 수 있다.

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

서브넷은 VPC의 CIDR 블록을 이용해 정의되며, 최소 크기의 서브넷은 /28이다.

이때 주의 할 점은 서브넷은 AZ당 최소 하나를 사용할 수 있고, 여러 개의 AZ에 연결되는 서브넷은 만들 수 없다.

Tips ) AWS가 확보한 서브넷 중 처음 네 개의 IP주소와 마지막 IP주소는 인터넷 네트워킹을 위해 예약되어 있다. 서브넷에서 가용 IP주소를 계산할 때는 항상 이 부분을 기억하고 있어야 한다. 예를 들어, 10.0.0.0/24 체계의 CIDR 블록이 있는 서브넷에서 10.0.0.0, 10.0.0.1, 10.0.02, 10.0.0.3, 10.0.0.255 등 5개의 IP주소는 예약 되어 있다.

 

라우팅 테이블(Routing Table)

라우팅 테이블은 트래픽의 전송 방향을 결정하는 라우트와 관련된 규칙을 담은 테이블로 목적지를 향한 최적의 경로로 데이터 패킷을 전송하기 위한 모든 정보를 담고 있다.

쉽게 말하자면 라우팅 테이블은 하나의 지점에서 또 다른 지점으로 가기 위한 모든 정보를 제공하기 위한 테이블이다.

모든 서브넷은 라우팅 테이블을 지닌다.

각각의 서브넷은 항상 라우팅 테이블을 가지고 있어야 하며, 하나의 라우팅 테이블 규칙을 여러 개의 서브넷에 연결하는 것도 가능하다.

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