IT 정보/기타 정보

[Cloud] 운영 전략

개발하는 동그리 2022. 8. 9. 14:47
728x90
반응형

프록시 서버

프록시 서버란!?

클라이언트와 서버가 소통할 때, 서버에 바로 접근하지 않고 자신을 통해 서버에 접근할 수 있도록 해주는 대리 서버이다. 지역이 제한되어 있는 서비스를 이용하기 위해서 우회하거나, 캐시를 통해 더 빠른 이용을 하기 위해 프록시 서버를 사용한다. 

프록시 서버의 종류 

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

  • 캐싱을 통한 빠른 서비스 : 여러 클라이언트가 요청한 경우 첫 응답 후 결과 데이터를 저장해놓고 이후 서버에 재요청하지 않고 다른 클라이언트에게 결과를 전달한다. 
  • 보안 : 클라이언트에서 프록시 서버를 거친 후 서버에 도착하기 때문에, 서버에서 클라이언트의 IP 추적이 필요한 경우 프록시 IP가 전달된다. 따라서 서버로부터 클라이언트가 보호된다. 

Reverse Proxy : 서버와 가까이 위치한 프록시 서버로 서버를 대신해서 클라이언트에게 응답을 제공한다. 로드 밸런서 챕터에서 배울 분산처리를 목적으로 하거나 보안을 위해 사용

  • 분산처리 : 서버 구조에서 사용자가 많아져 서버에 과부하가 올 경우를 대비해서 부하를 분산할 수 있다. 프록시 서버에 요청이 들어왔을 때 여러 대의 서버로 요청을 나누어 전달 (로드 밸런서 관련)
  • 보안 : 실제 서버의 IP를 노출시키지 않는다. 

 

로드 밸런서

많은 클라이언트가 서버에 접속했을때 과부하가 발생할 수 있다. 대비할 수 있는 방법 2가지가 있다

  • Scale - Up : 물리적으로 서버의 사양을 높이는 하드웨어적인 방법이다. 서버의 수를 늘리지 않고 프로그램 구현에 있어 변화가 필요하지 않다. 하지만 사양을 높이는 데에는 높은 비용이 들고, 업그레이드에도 한계가 있다는 치명적인 단점을 가지고 있다.  
  • Scale - Out : 서버의 갯수를 늘려 하나의 서버에 줄 부하를 분산시키는 방법이다. 많은 요청이 오더라도 여러 대의 서버가 나눠서 처리를 하기 때문에 서버의 사양을 높이지 않고도 비교적 저렴한 방법으로 부하를 처리할 수 있다. 클라이언트의 요청을 나눠서 처리할 수 있도록 도와주는 역할을 하는 것이 바로 로드밸런서이고, 프로그램을 로드 밸런싱이라 부른다. 
    • 로드 밸런서의 종류
      • L2 : 데이터 전송 계층에서 Max 주소를 바탕으로 로드 밸런싱
      • L3 : 네트워크 계층에서 IP 주소를 바탕으로 로드 밸런싱
      • L4 : 전송 계층에서 IP 주소와 Port를 바탕으로 로드 밸런싱
      • L7 :응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱 

 

오토 스케일링 (AWS)

로드 밸런싱을 사용하여 서버에 부하를 분산시킨다. 이때 서버를 When, how 추가할 수 있는가!? 

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

동적 스케일링 

가장 큰 장점은 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링할 수 있다는 점이다. 스케일 업 할수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두대에서 수백~수만 대의 서버로 즉시 스케일 업 할 수 있다. 

로드 밸런싱

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

타겟 트래킹

사용자가 특정 타겟에 대해서만 Auto Scaling 할 수 있으며, 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정한다. 

헬스 체크와 서버 플릿 관리

Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있다. 헬스 체크 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체한다. 

EC2 Auto Scaling

기존의 Auto Scaling은 EC2 인스턴스 뿐만 아니라 다른 인스턴스도 결합이 가능하다. EC2 Auto Scaling은 오직 EC2 서버 리소스만 대상으로 한다. 

시작 템플릿(Launch Configuration)

Auto Scaling으로 인스턴스를 확장 또는 축소하려면 어떤 서버를 사용할지 결정해야 한다. 이때 위 시작 템플릿을 통해서 가능하다. AMI(Amazon Machine Image)는 상세 정보 { ID, 인스턴스 유형, 키 페어, 보안 그룹 }을 담고 있다.

Scaling 유형

인스턴스 레벨 유지

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

수동 스케일링

기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있다. 수동을 선택하면 사용자가 직접 콘솔, API, CLI를 이용해 수동으로 인스턴스를 추가, 삭제해야 한다 - 권장하지 않음

일정별 스케일링

스케일링 트래픽의 변화를 예측할 수 있다. 따라서 트래픽의 증가 패턴을 알고 있다면 사용하기 좋다.

동적 스케일링

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

Tomcat

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

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

 

Jetty

build-gradle을 아래와 같이 수정하여 tomcat을 제외하고 jetty 의존성을 추가 하여 Spring boot의 내장 서버를 변경할 수 있다. 

implementation ('org.springframework.boot:spring-boot-starter-web') {
		exclude module: 'spring-boot-starter-tomcat'
	}
    
implementation ('org.springframework.boot:spring-boot-starter-jetty')
  • 타 웹 애플리케이션에 대비 적은 메모리 사용하여 가볍고 빠름
  • 애플리케이션에 내장 가능
  • 경량 웹 애플리케이션으로 소형 장비, 소규모 프로그램에 적합

 

Nginx

가볍고 높은 성능을 보이는 오픈소스 웹 서버 소프트웨어이다. Tomcat, Jetty는 자바 서블릿 컨테이너 혹은 웹 애플리케이션 서버였는데 반해, Nginx는 웹 서버로 클라이언트에게 정적 리소스를 빠르게 응답하기 위한 웹 서버이다. 

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

 

VPC 

EC2 생성했을 때 어떤 VPC를 사용했는데, 어떤 서브넷을 이용하는지 확인할 수 있다. 왜냐하면 생성되어있는 기본 VPC를 사용했기 때문이다. 기본 VPC가 아닌 직접 생성하고 설정한 VPC를 사용할 수도 있다. 

Virtual Private Cloud 서비스로, 클라우드 안에서 프라이빗 공간을 제공함으로써, 클라우드를 퍼블릭과 프라이빗 영역으로 논리적으로 분리할 수 있게 도와준다. VPC가 없었을 때는 클라우드에 있는 리소스를 격리할 수 있는 방법이 없어서 인스턴스들이 연결되어 복잡도와 의존도가 높았다. VPC를 통해 분리함으로써 확장성과 네트워크에 대한 통제권을 가질 수 있게 되었다. 

AWS 서비스를 제공하기에 가장 중요하다. (위치를 정하는 것) 마치 가상의 데이터센터처럼 구성 

CIDR (IP Address 표현)

172.31.0.0 / 16 <-- 앞에 4개는 고정 

  • Recommended : RFC1918 range
  • Recommended : / 16 (64k addresses)
서브넷
라우팅 테이블
Security Groups
NAT gateway
VPC peering (VPC 간 연결)

 

728x90
반응형
저작자표시 비영리 동일조건 (새창열림)