[0418] AWS - 수평 확장

학습 목표

• Cloud와 Deployment의 의미를 각각 알고, 서비스를 다른사람에게 배포할 수 있다.
• 클라우드 컴퓨팅이 무엇인지 설명할 수 있다.
• 애플리케이션 배포가 어떻게 변화되어 왔는지 이해할 수 있다.
• AWS의 각 서비스가 어떤 목적에 부합하는지 이해할 수 있다.
• S3의 목적과, 정적 웹 사이트 배포 방법을 이해할 수 있다.
• EC2의 주요 용어를 이해할 수 있다. (AMI, 인스턴스, 인스턴스 유형, 스토리지 타입, 퍼블릭/프라이빗 IP)
• EC2의 인스턴스 시작/중지/종료에 대해 이해할 수 있다.
• RDS와 EC2에서의 MySQL 사용이 어떻게 다른지 이해할 수 있다.
• CloudFront의 목적을 이해할 수 있다.
• Auto Scaling의 특징 및 역할을 알 수 있다.
• 로드 밸런서 중 ELB, 그 중에서 Application Load Balancer의 목적을 이해할 수 있다.
• AWS 인프라 중 VPC에 대해서 이해할 수 있다.
• Route 53의 목적을 이해하고, 도메인을 연결해 HTTPS로 배포할 수 있다.
• 빌드 및 배포시 필요한 환경 설정을 할 수 있다.
• 배포 시 발생하는 문제를 이해하고 고칠 수 있다.

---

Auto Scaling Group

---

• 미리 정해 놓은 규칙에 따라 워크로드(작업량)를 자동으로 확대 또는 축소할 수 있는 기술
• 클라우드가 제공하는 탄력성에 의해 만들어지며, 사용자의 요구 수준을 반영할 수 있음
• 과잉 프로비전을 할 필요성이 사라짐
  • 프로비전: 필요한 컴퓨팅 리소스들을 필요한 곳에 배치, 유휴 자원들을 다시 회수하는 일련의 작업들
  • 피크 워크로드(처리 요구량이 급등하는 시기)에 맞춰 새 리소스를 자동으로 추가하고 환경설정
  • 처리 요구량이 줄어들면 해당 리소스를 감소시킴
• 장점
  • 동적 스케일링
    • 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있음
    • 스케일 업 할 수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업할 수 있음
  • 로드 밸런싱
    • 리소스를 동적으로 스케일업 혹은 스케일다운 함
    • 로드밸런서와 함께 사용하면, 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있고, 다수의 AZ에 분포된 EC2 인스턴스에 대한 워크로드도 자동으로 분배하도록 설정할 수 있음
    • 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리 할 수 있음
  • 타겟 트래킹
    • 사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있으며, 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정함
  • 헬스 체크
    • EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있음
    • 헬스 체크를 하는 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체함
  • 서버 플릿 관리
    • 플릿(Fleet): 다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우, 이들 일련의 EC2 서버 집합
    • 적정 수준의 서버 플릿 용량을 유지하는 데 도움을 줌
    • 한 대 또는 그 이상의 서버가 다운 되면 Auto Scaling은 기존 서버만큼의 서버 인스턴스 처리 용량을 유지하기 위해 부족분만큼의 서버를 추가로 실행시키는 방식으로 서버 플릿을 유지
• 시작 템플릿(Launch Configuration)
  • AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있음
  • 작 템플릿을 사용하고 있지 않고 시작 템플릿을 생성하지 않으려는 경우에는 대신 시작 구성을 생성할 수 있음
  • 시작 구성은 EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷함
  • 사용할 AMI의 ID, 인스턴스 유형, 키 페어, 보안 그룹 등의 정보를 포함시켜서 시작 구성을 생성함
• Scaling 유형
  • 인스턴스 레벨 유지
    • 기본 스케일링 계획
    • 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있음
    • 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정하면 됨
  • 수동 스케일링
    • 기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있음
    • 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제 해야함
    • 추천하지 않는 방식
  • 예측 스케일링
    • 트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋음
    • 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면 낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운 하는 규칙을 추가하면 됨
  • 동적 스케일링
    • 수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의함
    • CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정함
    • 스케일링 정책을 정의 할 때는 항상 스케일 업과 스케일 다운 두 가지의 정책을 작성해야 함
      • ex) CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가하는 방식
• 동적 스케일링 정책
  • 타겟 트랙킹 스케일링
    • 미리 정의된 성능 지표를 이용하거나, 커스텀 성능지표(custom metric)을 사용하여 타겟 값으로 설정
  • 단순 스케일링
    • 단 하나의 스케일링 설정에 따라 그룹의 현재 용량을 늘리거나 줄임
    • 새 인스턴스를 시작 혹은 정지 시키기 위한 대기 시간(쿨다운 기간)도 정의할 수 있음
      • ex) CPU 활용지표가 80% 에 도달할 때 하나의 인스턴스를 추가하고, 40% 미만으로 떨어질 때 인스턴스 하나를 감소시키는 방식
  • 단계 스케일링
    • 단순 스케일링은 특정 이벤트에 대해 매번 같은 액션을 한다면, 단계 스케일링은 좀 더 세분화 해서 단계를 나누어 규칙을 추가할 수 있음
• 인스턴스 삭제 정책
  • 명확하게 몇 개의 인스턴스를 삭제할 것인지 정의할 수 있으며, 어떤 인스턴스를 먼저 셧다운 할 것인지 환경 설정을 통해 결정할 수 있음
  • 사용자의 서버 플릿에서 가장 오랫동안 실행된 서버를 삭제
    • 가장 오랫동안 실행된 서버일수록 패치 수준이 낮고 메모리 누수 등의 문제가 누적해 있을 가능성이 크기 때문
    • 이를 삭제함으로써 최신의 성능 기준을 유지할 수 있다는 장점
  • 시간 단위 과금이 임박한 서버를 삭제
    • Auto Scaling의 특유 장점을 최대한 살려, 과금 부담을 줄일 수 있음

---

Elastic Load Balancing

---

• 로드 밸런싱
  • 서비스 가용성을 높이기 위해 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데, 각 서버의 IP 주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 함 → 로드 밸런서 사용
  • 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 서비스 요청을 분산시켜 부하를 분산
• ELB
  • 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산
  • 등록된 대상의 상태를 모니터링 하면서 상태가 양호한 대상으로만 트래픽을 라우팅
• 장점
  • 고가용성
    • 고가용성 아키텍처를 구현하는데 도움을 줌
    • 다수의 EC2 인스턴스, 컨테이너 등에 트래픽을 분산 시키며 다수의 AZ에 배포된 EC2 인스턴스에 애플리케이션을 배포해 트래픽을 여러 AZ로 분산 시킬 수 있음
    • 하나의 AZ가 모두 다운 돼도 사용자의 애플리케이션은 문제 없이 실행 상태를 유지할 수 있음
  • 탄력성
    • ELB의 최대 장점 → 자동적 확장성
    • 관리자는 인스턴스 추가 또는 삭제를 위한 어떤 수작업도 할 필요가 없으며, 수동으로 뭔가를 할 여지도 없음
  • 안전성
    • 통합 인증관리, SSL 복호화, 포트 포워딩 등 다수의 보안 기능을 제공
    • 현대 웹사이트 운영자는 웹 애플리케이션 레벨에도 암호화 기법을 적용하며, 다수의 보안 정책을 제공
  • 높은 처리량
    • 트래픽 증가를 처리할 수 있도록 설계되었으며 초당 수백만 개의 요청을 로드 밸런싱할 수 있음
    • 갑작스럽고 변동이 심한 트래픽 패턴도 처리할 수 있음
• 작동 방식
  • 로드 밸런서는 클라이언트에 대한 단일 접점으로, 클라이언트에서 오는 트래픽을 허용하고, 하나 이상의 가용 영역에서 등록된 대상(EC2 인스턴스)으로 요청을 라우팅
  • 등록된 타겟의 상태를 모니터링하고 정상 타겟으로만 트래픽이 라우팅 되도록 함
  • 비정상 타겟을 감지하면, 해당 타겟으로 트래픽 라우팅을 중단
  • 타겟이 다시 정상으로 감지되면 트래픽을 해당 타겟으로 다시 라우팅
  • 리스너
    • 구성한 프로토콜 및 포트를 사용하여 클라이언트의 연결 요청을 확인
    • 리스너에 대해 정의한 규칙에 따라 로드 밸런서가 등록된 타겟으로 요청을 라우팅하는 방법이 결정됨
    • 각 규칙은 우선 순위, 하나 이상의 작업, 하나 이상의 조건으로 구성
    • 규칙에 대한 조건이 충족되면 작업이 수행됨
    • 각 리스너에 대한 기본 규칙을 정의해야 하며, 필요에 따라 추가 규칙을 정의할 수 있음
  • 각 타겟 그룹
    • 지정한 프로토콜과 포트 번호를 사용하여 EC2 인스턴스 같은 하나 이상의 등록된 타겟으로 요청을 라우팅
    • 여러 대상 그룹에 타겟을 등록할 수 있음
    • 타겟 그룹 기준으로 상태 확인을 구성할 수 있음
    • 로드 밸런서의 리스너 규칙에서 지정한 타겟 그룹에 등록된 모든 타겟에서 헬스 체크를 수행함
• 유형
  • Application Load Balancer
    • OSI 모델의 레이어 7에 해당하며, HTTP와 HTTPS를 지원함
    • 로드 밸런서는 요청을 받으면 우선 순위에 따라 리스너 규칙을 평가하여, 적용할 규칙을 결정한 다음 규칙 작업의 타겟 그룹에서 타겟을 선택함
    • 애플리케이션 트래픽의 콘텐츠를 기반으로 다른 타겟 그룹에 요청을 라우팅하도록 리스너 규칙을 구성할 수 있음
    • 헤더 수정이 가능함
    • ALB의 호스트 기반 라우팅을 통해 HTTP 헤더의 Host 필드에 따라 클라이언트 요청을 라우팅 할 수 있고, 경로 기반 라우팅을 통해 HTTP 헤더의 URL 경로에 따라 클라이언트 요청을 라우팅 할 수 있음
  • Network Load Balancer
    • TCP 로드 밸런서라고 부르며, OSI 모델의 레이어 4에서 작동함
    • 로드 밸런서가 연결 요청을 받으면 기본 규칙의 타겟 그룹에서 대상을 선택함
    • 리스너 구성에 지정된 포트에서 선택한 타겟에 대한 TCP 연결을 열려고 시도함
    • TCP 트래픽의 경우
      • 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트, TCP 시퀀스 번호에 따라 흐름 해시 알고리즘을 사용하여 타겟을 선택함
      • 클라이언트로부터의 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 타겟에 라우팅될 수 있음
      • 각 TCP 연결은 연결 수명 동안 하나의 타겟에 라우팅됨
    • UDP 트래픽의 경우
      • 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 타겟 IP 주소, 타겟 포트에 따라 흐름 해시 알고리즘을 사용하여 타겟을 선택함
      • UDP 흐름은 소스와 목적지가 동일하기 때문에 수명이 다할 때까지 일관되게 단일 타겟으로 라우트됨
      • 서로 다른 UDP 흐름에는 서로 다른 소스 IP 주소와 포트가 있으므로 다른 타겟으로 라우팅될 수 있음