Cloud(술,맥주 아님)

프록시 서버(Proxy Server)

쁘락치 서버?ㅋㅋ

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

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

프록시 서버의 종류

위치에 따라 Forward Proxy와 Reserve Proxy 두 가지로 나뉜다.
거두절미하고, 프록시 서버가 클라이언트에 가까운지 서버에 가까운지로 구분한다.

1. Forward Proxy

Forward Proxy는 클라이언트 가까이에 위치한 프록시 서버로 클라이언트를 대신해서 서버에 요청을 전달한다.
주로 캐싱을 제공하는 경우가 많아서 사용자가 빠른 서비스를 이용할 수 있도록 도와준다.

Forward Proxy의 장점

1. 캐싱을 통해 빠른 서비스 이용 가능
   클라이언트는 서비스의 서버가 아닌 프록시 서버와 소통하게 되는데, 동시에 여러 클라이언트가 동일한 요청을 보내는 경우 첫 응답을 하고, 결과 데이터를 캐시에 저장해놓는다. 이후 서버에 재요청을 보내지 않아도 다른 클라이언트에게 빠르게 전달한다.
2. 보안
   클라이언트에서 프록시 서버를 거친 후 서버에 요청이 도착하기 때문에, 서버에서 클라이언트의 IP추적이 필요한 경우 클라이언트의 IP가 아닌 프록시 서버의 IP가 전달된다.
   서버가 응답받은 IP는 프록시 서버의 IP이기 때문에 서버에게 클라이언트를 숨길 수 있다.

Reverse Proxy

Revers Proxy는 Forward Proxy와는 반대로 서버 가까이에 위치한 프록시 서버로 서버를 대신해서 클라이언트에 응답을 제공한다.
주로 분산처리를 하거나 보안을 위해 Reverse Proxy 서버를 이용한다.

Reverse Proxy의 장점

1. 분산처리
   클라이언트-서버 구조에서 사용자가 많아져 서버에 과부하가 올 경우를 위해 부하를 분산할 수 있다.
   Reverse Proxy구조에서 프록시 서버로 요청이 들어오면 여러대의 서버로 요청을 나누어 전달한다.
2. 보안
   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	응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱 한다.(예 : 엔드포인트)

오토 스케일링

주의 : AWS의 오토스케일링에 기반해서 작성

처음 오토스케일링을 들었을 때가 MBC 뉴스.. 당시 백신 신청이 더럽게 안 됬을 때, 하버드 컴공 출신 당시 국힘 당대표였던 준스톤이 오토스케일링을 말하던데 그 때 들었다... 댓글이 웃겼다.. "오토스케일링을 뉴스에서 듣다니 ㄷㄷ"이런식으로..

오토스케일링은 Scale-Out방식으로 서버를 증설할 때 자동으로 서버(리소스)를 관리해주는 기능이다.
클라이언트의 요청이 많아져 서버의 처리 요구량이 증가하면 새 리소스를 자동으로 추가하고 반대로 처리 요구량이 줄어들면 리소스를 감소시켜서 적절한 분산 환경을 만들어준다.

Auto Scaling의 장점

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

EC2 Auto Scaling 활용

Auto Scaling은 EC2 인스턴스를 뿐만 아니라 다른 인스턴스와도 결합 가능하지만, EC2 사용자에게 가장 인기가 많은 서비스이다. EC2 AutoCaling은 오직 EC2 서버라는 리소스만 대상으로 한다.

시작 템플릿(Launch Configuration)

• Auto Scaling으로 인스턴스를 확장 또는 축소하려면 어떤 서버를 사용할지 결정해야한다.
• 시작 템플릿을 통해서 가능하며, AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있다.
• 만약 시작 템플릿을 사용하고 있지 않고 시작 템플릿을 생성하지 않으려는 경우에는 대신 시작 구성을 생성할 수 있다.
• 시작 구성은 EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷하다.
• 사용할 AMI의 ID, 인스턴스 유형, 키 페어, 보안 그룹 등의 정보를 포함시켜서 시작 구성을 생성한다.

Auto Scaling 그룹 생성

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

• Auto Scaling 그룹을 생성하기 위해서 스케일링 정책 및 유형에 대해서 잘 숙지하고 있어야 한다.

Scaling 유형

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

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

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

• 동적 스케일링
  수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의한다.
  이 방식은 CloudWatch가 모니터링하는 지표를 추적하여 경보 상태일 떄 수행할 스케일링 규칙을 정한다.

웹 서버(Web Server)

Tomcat

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

특징

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

Jetty

Jetty는 이클립스 재단의 HTTP 서버이자 자바 서블릿 컨테이너이다. Jetty도 Tomcat과 같이 자바 서블릿 컨테이너이자 서버로 사용할 수 있다.

특징

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

NginX

• 가볍고 높은 성능을 보이는 오픈소스 웹 서버 소프트웨어
• 웹 서버로 클라이언트에게 정적 리소스를 빠르게 응답하기 위한 웹서버로 사용할 수 있다.

NGINX 특징

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

VPC(Virtual Private Cloud)

• 클라우드 내 프라이빗 공간을 제공함으로써, 클라우드를 퍼블릭과 프라이빗 영역으로 논리적으로 분리할 수 있게 한다.

서브넷

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

서브넷은 VPC의 CIDR 블록을 이용해 정의하며, 최소 크기의 서브넷은 /28이다. 서브넷은 AZ당 최소 하나를 사용할 수 있고, 여러개의 AZ에 연결되는 서브넷은 만들 수 없습니다.

Tips ) AWS가 확보한 서브넷 중 처음 네 개의 IP주소와 마지막 IP주소는 인터넷 네트워킹을 위해 예약되어 있다.