[TIL] 운영 전략 (1)

🤘🏻 Proxy Server : 프록시 서버

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

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

---

📍프록시 서버 종류

  ① Forward Proxy

  - 프록시 서버가 클라이언트에 가까이 있는 경우

  - 클라이언트 가까이에 위치한 프록시 서버로 클라이언트를 대신하여 서버에 요청 전달

  - 주로 캐싱을 제공하는 경우가 많아 사용자가 빠른 서비스 이용 가능하도록 도와줌

---

   📍 Forward Proxy 장점

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

     - 클라이언트는 서버가 아닌 프록시 서버와 소통

     - 여러 클라이언트가 동일한 요청을 보내는 경우,

         첫 응답을 하고 결과 데이터를 캐시에 저장 해놓고 이후 서버에 재요청을 보내지 않아도 빠르게 응답 전달 가능

     ▸ 보안

     - 클라이언트에서 프록시 서버를 거친 후 서버에 요청이 도착하기 때문에 서버에서 클라이언트의 IP 추적이 필요한 경우

        클라이언트의 IP가 아닌 서버의 IP가 전달됨

         → 즉, 서버에게 클라이언트를 숨길 수 있음

---

  ② Reverse Proxy

  - 프록시 서버가 서버에 가까이 있는 경우

  - 서버에 가까이 위치한 프록시 서버로 서버를 대신하여 클라이언트에 응답 제공

  - 분산 처리를 목적으로 하거나 보안을 위해 프록시 서버를 이용

---

   📍 Reverse Proxy 장점

     ▸ 분산 처리

     - 클라이언트-서버 구조에서 사용자가 많아져 서버에 과부하가 올 경우 부하를 분산할 수 있음

     - 프록시 서버로 요청이 들어오면 여러 대의 서버로 요청을 나누어 전달하여 처리

     ▸ 보안

     - 클라이언트에게 서버를 숨길 수 있음

     - 클라이언트 입장에서의 요청 보내는 서버가 프록시 서버가 되므로 실제 서버의 IP 주소가 노출되지 않음

---

🙌🏻 Load Balancer : 로드밸런서

  - 서버의 과부하로 인해 원활한 서비스를 제공하지 못하는 경우 해결하기 위한 방법

   ① Scale Up : 서버의 하드웨어 업그레이드

  - 물리적으로 서버의 사양을 높이는 하드웨어적 방법

  - 서버의 수를 늘리지 않고 프로그램 구현에 있어 변화가 필요 없음

  - 서버의 사양을 높이는데 굉장히 높은 비용이 들고 하드웨어의 업그레이드에 한계가 있음

  - 사양을 늘린만큼 클라이언트 요청이 많아지면 서버에 발생하는 부하는 여전히 해결하지 못한 상황이 됨

---

   ② Scale Out : 서버의 갯수를 늘리는 방법

  - 서버의 갯수를 늘려 하나의 서버에 줄 부하를 분산시키는 방법

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

---

  💡 여러 대의 서버로 부하를 처리하는 경우, 클라이언트로 요청을 어느 서버로 보내서 처리해야 할까?

    : 로드 밸런서

     - 요청을 여러 서버에 나누어 처리할 수 있도록 교통정리 해줌

     - 여러 서버에 교통 정리를 해주는 기술 혹은 프로그램을 로드 밸런싱이라고 함

---

📍로드 밸런서 종류

  : 클라이언트의 요청을 어떤 것을 기준으로 분산시키냐에 따라 네 가지 종류로 나뉨

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

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

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

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

---

👏🏻 Auto Scaling : 오토 스케일링

  - Scale-Out 방식으로 서버를 증설할 때 자동으로 서버(리소스)를 관리해주는 기능

  - 클라이언트 요청이 많아져 서버의 처리 요구량이 증가하면 새 리소스를 자동으로 추가

    + 반대로 처리 요구량이 줄어들면 리소스를 감소시켜 적절한 분산 환경을 만들어줌

  📍 Auto Scaling 장점

    ▸ 동적 스케일링

     - 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있음

     - 스케일업 할 수 있는 서버의 수는 제한이 없음

       → 필요한 경우 서버 두 대에서 수백~수만 대의 서버로 즉시 스케일 업 할 수 있음

    ▸ 로드 밸런싱

     - 리소스를 동적으로 스케일업 혹은 스케일다운함

     - 로드 밸런서와 함께 사용하면 다수의 EC2 인스턴스에게 워크 로드를 효과적으로 분배할 수 있어 사용자가 정의한

        규칙에 따라 워크로드를 효과적으로 관리 가능

    ▸ 타겟 트래킹

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

    ▸ 헬스 체크와 서버 플릿 관리

     - Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있음

     - 헬스 체크 과정에서 문제가 감지되면 자동으로 다른 인스턴스로 교체

---

   💡 서버 플릿 : Server Fleet

    - 다수의 EC2 서버에서 애플리케이션을 호스팅하는 경우 이들 일련의 EC2 서버 집합

    - Auto Sacling은 적정수준의 서버 플릿 용량을 유지하는데 도움을 줌

---

 ▪️   EC2 Auto Scaling 활용

    - 오직 EC2 서버라는 리소스만을 대상으로 함

   📍 시작 템플릿 : Launch Configuration

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

       → 이는 시작 템플릿을 통해 가능

       → AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있음

     - 만약 시작 템플릿을 사용하지 않고 생성하지 않으면 시작 구성을 생성할 수 있음

    💡 시작 구성

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

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

---

   📍 Auto Scaling 그룹 생성

    - Auto Scaling 그룹은 스케일업 및 스케일다운 규칙의 모음

    - 인스턴스 시작부터 삭제까지 모든 동작에 대한 규칙과정책을 담고 있음

---

   📍 Scaling 유형

    ① 인스턴스 레벨 유지

      - 기본 스케일링 계획이라고도 함

      - 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있음

      - 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정 가능

    ② 수동 스케일링

      - 기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있음

      - 사용자가 직접 콘솔, API, CLI 등을 이용해 수동으로 인스턴스를 추가하거나 삭제해야 함

    ③ 일정별 스케일링

      - 예측 스케일링 트래픽의 변화를 예측 가능

      - 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링 사용 추천

    ④ 동적 스케일링

      - 수요 변화에 대응하여 그룹의 용량을 조정하는 방법

      - Cloud Watch가 모니터링하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정함

---