CS/데이터베이스

Cloud - 운영 전략 1

RangA 2023. 6. 20. 21:55

Proxy Server

프록시 서버

  • 대리라는 뜻의 Proxy에서 알 수 있듯 프록시 서버(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     응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱 함  


오토스케일링(AWS의 오토스케일링에 기반)

  • 서버의 부하를 분산시키기 위해 로드밸런싱을 사용하며, 서버의 부하가 심해져 제대로 된 서비스를 제공하지 못하는 순간이 오지 않도록, 계속 지켜보다 부하가 일정 수치를 넘기면 서버를 증설한 뒤 연결할 수 있음
  • 반면에, 개발자가 직접 라이브로 지켜보며 수동으로 서버를 증설해야 한다면 너무나 번거롭고 갑작스럽게 발생한 문제에 대처하기도 한계가 있음
  • 이런 상황은 오토스케일링을 통해 보다 간편히 해결할 수 있음
  • 오토스케일링은 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 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있음
  • Auto Scaling 그룹을 생성하기 위해서는 스케일링 정책 및 유형에 대해서 잘 숙지하고 있어야 함

Scaling 유형

  • 인스턴스 레벨 유지
    • 기본 스케일링 계획으로도 부르며, 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있음
    • 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정할 수 있음
  • 수동 스케일링
    • 기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있음
    • 수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제해야 함
    • 추천하지 않는 방식
  • 일정별 스케일링
    • 예측 스케일링트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋음
    • 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면 낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운 하는 규칙을 추가하면 됨
  • 동적 스케일링
    • 수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의함
    • CloudWatch가 모니터링하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정함
    • 만약, CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가하는 방식
    • 스케일링 정책을 정의할 때는 항상 스케일 업과 스케일 다운 두 가지의 정책을 작성해야 함
저작자표시 비영리 변경금지