클라우드 운영전략

ㅇ 프록시 서버

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

보통 지역이 제한되어있는 서비스를 이용하기 위해 캐시를 통해 프록시 서버를 사용한다.

 

ㅇ 프록시 서버의 종류

1. Forward Proxy : 클라이언트 가까이에 위치한 프록시 서버로 클라이언트를 대신해 서버에 요청을 전달함. 주로 캐싱을 제공하는 경우가 많아 빠른 서비스를 이용할수 있도록 도와준다. 여러 클라이언트가 동일한 요청을 보내는 경우 첫 응답을 하며 결과 데이터를 캐시에 저장하고 재요청을 보내지 않아도 다른 클라이언트에게 빠르게 전달 가능하다. 그리고 ip 추적이 필요한 경우 클라ip가 아닌 프록시ip가 전달됨. 숨길수 있다는 뜻.

1. Reverse Proxy : 서버 가까이 에 위치한 프록시 서버로 서버 대신해 클라이언트에 응답을 대신 제공한다. 서버구조에 사용자가 많아져 서버에 과부하가 올 경우 부하를 분산시킬 수 있다. 프록시 서버로 요청이 들어오면 여러대의 서버로 요청을 나누어 전달 후 처리한다. 포워드와 반대로 클라에게 서버의 Ip주소를 숨길 수 있다.

ㅇ 로드밸런서

서비스에 너무 많은 클라이언트가 접속하면 과부하가 온다. 과부하가 올 경우 해결방법으론 서버의 하드웨어 업그레이드, 서버의 개수를 늘리는 법 중 하나를 선택할 수 있다.

1. Scale-Out : 물리적으로 서버의 사양을 높이는 법. 프로그램의 변화가 필요없다. 하지만 굉장히 높은 비용, 하드웨어 업그레이드엔 한계가 있다는 단점 존재함.
2. Scale-Out : 서버의 개수를 늘려 서버에 부하를 줄여준다. 요청을 늘어난 서버에 나눠주는 역할을 하는것이 로드 밸런서. 그 기술 or 프로그램은 로드 밸런싱이라고 한다.

 

ㅇ 로드밸런서의 종류

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

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

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

L7 : 응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱

 

ㅇ 오토스케일링(AWS 기반)

늘어난 서버의 부하를 분산시키기 위해 로드밸런싱을 사용함. 이전에 서버는 어떻게 늘릴까?

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

 

ㅇ 오토스케일링의 장점

1. 동적 스케일링 : 오토스케일링의 가장 큰 장점은 사용자의 요구수준에 따라 리소스를 동적으로 스케일링할 수 있다는 점. 
2. 로드 밸런싱 : 오토스케일링은 리소스를 동적으로 스케일업, 스케일다운할 수 있다. 로드 밸런서와 함께 사용하면 EC2인스턴스에게 워크로드를 효과적으로 분배 가능
3. 타겟 트래킹 : 특정 타겟에 대해서만 오토스케일링을 할수 있다. 타켓에맞춰 EC2인스턴스의 수를 조정함.
4. 헬스 체크와 서버 플릿 관리 : EC2 인스턴스의 헬스 체크상태를 모니터링가능하며, 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체가능하다.

*서버플릿이란?

다수의 EC2 서버에서 애플리케이션을 호스팅하는 경우, 이들 일련의 EC2 서버 집합을 AWS는 서버플릿이라 함. 오토스케일링은 적정수준의 서버플릿 용량을 유지하는데 도움을 준다.

 

ㅇ EC2 Auto Scaling 활용

오토 스케일링은 EC2인스턴스 말고도 다른 인스턴스와 결합가능하지만, EC2가 가장많이 쓰임

먼저 AMI의 ID, 인스턴스 유형, 키 페어, 보안그룹등 정보를 포함시켜 시작 구성을 생성한다. 그다음 Auto Scaling 그룹생성한다. EC2 인스턴스의 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있음. 

 

ㅇ Scaling 유형

1. 인스턴스 레벨 유지 : 항상 실행상태를 유지하고자하는 인스턴스의 수를 지정할 수 있음.
2. 수동 스케일링 : 오토스케일링 그룹의 크기를 수동으로 변경가능.
3. 일정별 스케일링 : 예측 스케일링트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느정도의 트래픽이 증가하는지 패턴파악하고 있다면 사용하는게 좋다!
4. 동적 스케일링 : 수요 변화에 대응해 오토스케일링그룹의 용량을 조정하는 방법을 정의함.

 

ㅇ Tomcat

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

• 특징 : 자바 애플리케이션을 위한 오픈소스. 독립적으로 사용가능하며 Apache같은 다른 웹 서버와 연동가능. 자바 서블릿 컨테이너에 대한 공식 구현체.

ㅇ Tomcat 실행 및 의존성 확인

SpringBoot에 내장되어있어 설치를 따로 할 필욘없다. 의존성확인은 IDE에 Gradle탭에서 추가한 의존성 모듈을 확인 가능함. 거기서 Spring-boot-starter-web에서 확인가능.

 

ㅇ Jetty

이클립스 재단의 HTTP서버이자 자바 서블릿 컨테이너임. 개발자는 톰캣, 제티중 원하는 서버를 선택해 프로젝트를 구성가능하다. 

• 특징 : 제티는 타 웹 애플리케이션 대비 적은 메모리를 사용해 가볍고 빠름. 애플리케이션에 내장 가능함. 경량이라 소형장비, 소규모 프로그램에 더 적합함.

Spring-boot-starter-web 의존성 부분에서 tomcat을 제외시키고 (exclude module: ‘spring-boot-starter-tomcat’)

Jetty의존성을 추가함.(implementation (‘org.springframework.boot:spring-boot-starter-jetty’))

 

서버의 종류는 다양함. 톱캣,제티말고도 Netty, Undertow등등 많음.

 

ㅇ Nginx - Proxy Server

가볍고 높은 성능을 보이는 오픈소스 웹 서버 소프트웨어. 톱캣,제티는 자바 서블릿 컨테이너,웹애플리케이션 서버고 NginX는 웹 서버로 클라이언트에게 정적 리소스를 빠르게 응답하기 위한 웹서버로 사용가능함.

• 특징 : 트래픽이 많은 웹 사이트의 확장성을 위해 개발된 고성능 웹서버. 비동기 이벤트 기반으로 적은 자원으로 높은 성능, 높은 동시성을 위해 개발됨. 다수의 클라이언트 연결을 효율적으로 처리가능함. 클라이언트와 서버 사이에 존재하는(서버에 가까운) 리버스 프록시 서버로 사용가능.

 

ㅇ SpringBoot와 연동하기

그동안은 8080포트로 바로 클라이언트와 연결했다. 이제부터 NginX를 이용해 80번 포트로 연결되게 해보자.

 

ㅇ nginx 설치부터 종료까지

$ brew install nginx #설치

$ brew services start nginx #실행

$ nginx -t

$ nano /opt/homebrew/etc/nginx/nginx.conf #편집

$ brew services restart nginx #재실행

$ brew services stop nginx #종료

 

 

ㅇ NGINX - Load Balancer

NginX 는 이전처럼 스프링부트 서버 앞에 위치해 클라이언트와 서버가 NginX를 통해 소통하도록되어있음. 이번엔 스프링부트 서버가 8080, 8081에서 실행되고있을 때의 로드밸런싱을 구성해본다. 

1. 두개의 스프링부트 서버 실행.

먼저 프로젝트를 빌드함. — ./gradle build

빌드 파일을 실행함. — java -jar sample-0.0.1-SNAPSHOT.jar

여기까지 하면 프로세스의 ID가 화면에 출력됨.

빌드 파일을 이용해 새 터미널에 다른포트에서 실행함. — java -Dserver.port=8081 -jar sample-0.0.1-SNAPSHOT.jar

8081로 접속하면 PID가 다른걸로 접속됨.

 

1. NGINX 설정파일 수정

nano NGINX

http {

upstream backend {

server localhost:8080;

server localhost:8081;

}

location / {

proxy_pass http://backend;

}

}

 

이렇게하고 새로고침을 계속누르면 8080, 8081로 번갈아 접속이된다.

 

 

 

ㅇ VPC

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

 

ㅇ IP Address

네트워크에서 장치들이 서로를 인식,통신하기 위해 사용하는 특수번호. IPv4, IPv6로 나위어있음.

ex) 172.16.0.0

 

ㅇ IP Address Class

IPv4주소에서 호스트가 연결되어있는 특정 네트워크를 가리키는 8비트의 네트워크 영역과 호스트의 주소를 가리키는 나머지 영역을 구분하기 위해 클래스를 사용했다. 클래스는 총 ABCDE 5가지로 나뉨. D,E클래스는 연구개발을 위한 예약 IP로 보통 사용되지 않음.

 

ㅇ CIDR(Classless inter-domain routing)

사이더는 클래스 없는 도메인 간 라우팅 기법으로 1993년 도입한 IP 주소 할당방법임.

CIDR은 원하는 만큼 Network Address를 지정해 운용할 수 있음.

 

ㅇ 서브넷(Subnet)

Subnetwork의 줄임말. IP네트워크의 논리적인 하위 부분을 가리킴. 서브넷을 통해 하나의 네트워크를 여러개로 나눌 수 있음. VPC를 사용하면 퍼블릭 서브넷, 프라이빗 서브넷, VPN only 서브넷등 다양한 서브넷을 생성할 수 있음. 최소크기의 서브넷은 /28임.

 

ㅇ 라우팅 테이블(Routing Table)

트래픽의 전송방향을 결정하는 라우트와 관련된 규칙을 담은 테이블로, 목적지를 향한 최적의 경로로 데이터 패킷을 전송하기 위한 모든 정보를 담고 있음. 모든 서브넷은 라우팅 테이블을 지님. 각각의 서브넷은 항상 라우팅 테이블을 가지고 있어야 하며, 하나의 라우팅 테이블 규칙을 여러개의 서브넷에 연결하는 것도 가능함.