Cloud/Amazon Web Services

AWS Technical Essentials; Module 6

체원 2022. 6. 9. 15:09
Module 6 : Monitoring, Optimization and Serverless

모듈 6 : 모니터링, 최적화 및 서버리스

6-1) 애플리케이션 관리

  1. app 성능 및 리소스 활용 방법에 대한 insight 부족
    • 해결 방안 : Amazon Cloudwatch (모니터링 도구)
    • app에 대한 요구 사항 이해
  2. 확장성 해결 필요
    • app 수요가 항상 일정 ❌ ➡ 수요에 따라 리소스 추가, 용량 줄이며 비용을 절감하는 프로세스 자동화 방법
    • 트래픽 전달하고 용량이 변동하는 리소스에서 로드 밸런싱하는 방법

6-2) 모니터링

최종 사용자가 알아차리기 전에 운영 문제에 대응할 수 있는 것이 이상적

  • 적절한 모니터링 마련
    • 시스템에 대한 다양한 유형 정보 수집 ➡ 지표 수집, 로그 수집, 네트워크 트래픽 감시
    • 정보 수집 ➡ 기준 설정 ➡ 운영 원활 여부 판단
    • 시스템을 사전 예방적으로 모니터링, 운영하여 최종 사용자의 만족도 유지
    • 들어오는 데이터를 기반으로 자동화된 작업 트리거 가능

모니터링 목적

웹 사이트를 운영 시 발생 질문

- 매일 몇 명이나 사이트를 방문하고 있는가?
- 시간 경과에 따른 방문자 수를 추적하려면 어떻게 해야 하는가?
- 웹 사이트에 성능 또는 가용성 문제가 있는지 어떻게 알 수 있는가?
- Amazon Elastic Compute Cloud(EC2) 인스턴스의 용량이 부족하면 어떻게 되는가?
- 웹 사이트가 다운되면 알림을 받을 수 있는가?

질문 답하는데 도움 되는 것 ➡️ 모니터링
  • 리소스 운영 상태, 사용량에 대한 데이터를 수집, 분석 방법 필요
  • 모니터링 : 데이터를 수집, 분석 사용하여 의사 결정 or IT 리소스, 시스템에 대한 질문에 답하는 행위
  • 모니터링은 시스템에 거의 실시간으로 제공
  • 수집한 데이터 사용 ➡️ 운영 문제 감시
    • 운영 문제 : 리소스 과다 사용, 애플리케이션 결함, 리소스 구성 오류 또는 보안 관련 이벤트 통해 발생됨
  • 모니터링 통해 수집된 데이터 : 시스템의 출력 or 지표

지표를 사용하여 문제 해결

  • 솔루션을 호스팅하는 AWS 리소스 ➡️ 수집 될 수 있는 다양한 형태의 데이터 생성
  • 리소스가 생성하는 각 개별 데이터 포인트는 지표
  • 지표는 통계가 된다.
    • 시간 경과에 따라 수집 및 분석되는 지표는 시간 경과에 따른 평균 CPU 사용률과 같은 통계가 됩니다.
지표 예시

Amazon EC2 인스턴스의 상태를 평가하는 한 가지 방법은 CPU 사용률을 이용하는 것입니다.
일반적으로 EC2 인스턴스의 CPU 사용률이 높으면 요청 폭증을 의미할 수 있습니다.
또는 오류가 발생하여 CPU를 너무 많이 소비하는 프로세스를 반영할 수 있습니다.
CPU 사용률을 분석할 때 비정상적인 기간 동안 특정 임계값을 초과하는 프로세스를 파악합니다.
비정상적인 이벤트를 인스턴스 조정과 같은 작업을 통해 수동으로 또는 자동으로 문제를 해결할 수 있는 큐로 사용합니다.
  • EC2 인스턴스 제공 지표 예 : 네트워크 사용률, 디스크 성능, 메모리 사용률, Amazon EC2 위에서 실행되는 애플리케이션에서 생성한 로그

지표의 유형

  • AWS의 리소스마다 다른 유형의 지표를 생성
  • 리소스, 목표 및 질문에 따른 → 다양한 지표에 관심

Amazon Simple Storage Service(Amazon S3)

  • Amazon S3 버킷에는 CPU 사용률 ❌ (↔️ EC2 인스턴스 ✅)
  • Amazon S3는 버킷에 저장된 객체와 관련된 지표를 생성
    • 예) 버킷 전체 크기, 버킷 내 객체 수
  • Amazon S3에는 버킷에 대한 요청과 관련된 지표 존재
    • 예) 객체 읽기, 쓰기 등

Amazon Relational Database Service(Amazon RDS)

  • Amazon RDS 지표 : 데이터베이스 연결, 인스턴스의 CPU 사용률, 디스크 공간 소비
  • 전체 목록은 아니지만, 리소스마다 다른 지표 생성한다는 것 확인 가능

모니터링 이점

모니터링 ➡️ 리소스에 대한 가시성 확보
새로운 의문 ‘모니터링이 왜 중요한가?'

최종 사용자가 운영 문제를 인식하기 전에 사전 대응할 수 있습니다. 

최종 사용자가 애플리케이션이 중단되었다고 보고할 때까지 기다리는 것은 좋지 않은 관행입니다. 
모니터링을 통해 오류 응답률 및 요청 대기 시간과 같은 지표에 대한 탭을 유지할 수 있습니다. 
시간이 경과하면서 지표는 중단이 발생할 징후를 확인하는 데 도움이 됩니다. 
이를 통해 자동으로 또는 수동으로 작업을 수행하여 중단을 방지하고 최종 사용자가 문제를 인식하기 전에 문제를 해결할 수 있습니다.

최종 사용자가 애플리케이션이 중단되었다고 보고할 때까지 기다리는 것은 좋지 않은 관행입니다. 모니터링을 통해 오류 응답률 및 요청 대기 시간과 같은 지표에 대한 탭을 유지할 수 있습니다. 시간이 경과하면서 지표는 중단이 발생할 징후를 확인하는 데 도움이 됩니다. 이를 통해 자동으로 또는 수동으로 작업을 수행하여 중단을 방지하고 최종 사용자가 문제를 인식하기 전에 문제를 해결할 수 있습니다.

리소스의 성능 및 안정성을 개선합니다. 

애플리케이션을 구성하는 다양한 리소스를 모니터링하면 솔루션이 시스템으로 동작하는 방식을 종합적으로 파악할 수 있습니다. 
모니터링은 제대로 수행할 경우 병목 현상과 비효율적인 아키텍처를 밝힐 수 있습니다. 
그러면 성능을 높이고 안정성을 향상시킬 수 있습니다.

애플리케이션을 구성하는 다양한 리소스를 모니터링하면 솔루션이 시스템으로 동작하는 방식을 종합적으로 파악할 수 있습니다. 모니터링은 제대로 수행할 경우 병목 현상과 비효율적인 아키텍처를 밝힐 수 있습니다. 그러면 성능을 높이고 안정성을 향상시킬 수 있습니다.

보안 위협 및 이벤트를 인식합니다. 

시간 경과에 따라 리소스, 이벤트 및 시스템을 모니터링하면 기준선이라고 하는 것을 만듭니다. 
기준선은 정상적인 활동을 정의합니다. 
기준선을 사용하면 비정상적인 트래픽 스파이크 또는 리소스에 액세스하는 비정상적인 IP 주소와 같은 이상 현상을 발견할 수 있습니다. 
이상 현상이 발생하면 알림을 전송하거나 이벤트를 조사하기 위한 조치를 취할 수 있습니다.

시간 경과에 따라 리소스, 이벤트 및 시스템을 모니터링하면 기준선이라고 하는 것을 만듭니다. 기준선은 정상적인 활동을 정의합니다. 기준선을 사용하면 비정상적인 트래픽 스파이크 또는 리소스에 액세스하는 비정상적인 IP 주소와 같은 이상 현상을 발견할 수 있습니다. 이상 현상이 발생하면 알림을 전송하거나 이벤트를 조사하기 위한 조치를 취할 수 있습니다.

비즈니스를 위해 데이터 중심의 의사 결정을 수립합니다. 

모니터링은 IT 운영 상태를 주시하고 비즈니스 의사 결정을 지원합니다. 
예를 들어 
고양이 사진 앱의 새 기능을 시작했고 이제 해당 기능이 사용되고 있는지 알고 싶다고 가정합니다.
애플리케이션 수준 지표를 수집하고 새 기능을 사용하는 사용자 수를 볼 수 있습니다. 
결과를 통해 새로운 기능을 개선하는 데 더 많은 시간을 투자할지 여부를 결정할 수 있습니다.

모니터링은 IT 운영 상태를 주시하고 비즈니스 의사 결정을 지원합니다. 예를 들어 고양이 사진 앱의 새 기능을 시작했고 이제 해당 기능이 사용되고 있는지 알고 싶다고 가정합니다. 애플리케이션 수준 지표를 수집하고 새 기능을 사용하는 사용자 수를 볼 수 있습니다. 결과를 통해 새로운 기능을 개선하는 데 더 많은 시간을 투자할지 여부를 결정할 수 있습니다.

보다 비용 효율적인 솔루션을 구축합니다. 

모니터링을 통해 사용량이 부족한 리소스를 확인하고 리소스를 사용량에 맞게 조정할 수 있습니다. 
이를 통해 비용을 최적화하고 필요 이상으로 더 많은 돈을 지출하지 않도록 할 수 있습니다.

모니터링을 통해 사용량이 부족한 리소스를 확인하고 리소스를 사용량에 맞게 조정할 수 있습니다. 이를 통해 비용을 최적화하고 필요 이상으로 더 많은 돈을 지출하지 않도록 할 수 있습니다.

가시성

  • AWS 리소스 ➡️ 지표, 로그, 네트워크 트래픽, 이벤트 등 통해 모니터링할 수 있는 데이터 생성
    • 데이터 ➡️ 분산된 구성 요소에서 생성됨
  • 이를 모두 검토할 수 있는 중앙 집중식 장소 ❌ 경우 → 필요한 데이터 수집 어려움
  • AWS 해결책 : Amazon CloudWatch 서비스

Amazon CloudWatch

  • 데이터를 수집하는 모니터링 및 관찰 기능 서비스 ➡️ 솔루션을 한곳에서 모두 모니터링 가능
  • 애플리케이션에 대한 실행 가능한 인사이트 제공
  • 시스템 전체의 성능 변화에 대응, 리소스 사용 최적화, 운영 상태에 대한 통합된 보기를 얻을 수 있도록 지원
  • 데이터는 클라우드 기반 인프라에서 수집되므로,
    • EC2 지표, RDB, DynamoDB 수집되는 DB 지표와 같은 항목
    • aws솔루션 구성하는 다른 서비스의 지표(Metric) 확인 가능

CloudWatch 사용 시 작업 수행 목록

  • 환경에서 이상 동작을 감지
  • 문제가 있을 때 알리도록 경보를 설정
  • AWS 관리 콘솔을 사용하여 로그 및 지표를 시각화
  • 크기 조정과 같은 자동화된 작업을 수행
  • 문제 해결
  • 애플리케이션을 정상으로 유지하기 위한 인사이트를 발견

리소스

6-3) Amazon CloudWatch

Amazon CloudWatch

  • 리소스 생성시 많은 aws서비스가 자동으로 cloudwatch에 지표를 보고하기 시작
  • Metric or Log
  • 다른 사용자와 공유하여 대쉬보드 이용 가능 ➡ 모든 사용자가 health check가능

CloudWatch 작동 방식

  • CloudWatch : 기본 인프라를 관리하지 않고도 모니터링에 사용할 수 있는 관리형 서비스
직원 디렉터리 앱은 빌딩 블록으로 연동하는 다양한 AWS 서비스로 구축됩니다.
개별 서비스를 독립적으로 모니터링하는 일은 어려울 수 있습니다. CloudWatch는 지표를 수집하고 분석하는 중앙 집중식 장소의 역할을 합니다.

여러분은 이미 EC2 인스턴스가 CPU 사용률을 CloudWatch에 지표로 게시하는 방법을 배웠습니다.
AWS 리소스마다 모니터링할 수 있는 다양한 지표를 게시합니다. 리소스 섹션에서 CloudWatch로 지표를 전송하는 서비스의 목록을 볼 수 있습니다.
  • 대부분 AWS 서비스는 5분 간격으로 CloudWatch에 지표를 무료로 자동 전송 ➡️ 지표당 하나의 데이터 포인트의 속도
  • 기본 모니터링 : 5분 마다 지표 게시
    • 추가 비용 없이 시스템에 대한 가시성 확보
    • 대부분의 애플리케이션에는 기본 모니터링이 적합
  • 세부 모니터링 : 1분 마다 지표 게시
    • EC2 인스턴스에서 실행되는 애플리케이션의 경우 적합
    • 세부 모니터링은 요금이 부과

CloudWatch 지표

  • CloudWatch의 각 지표에는 타임스탬프 존재
  • 네임스페이스라는 컨테이너로 구성
  • 서로 다른 네임스페이스의 지표는 서로 격리 ➡️ 서로 다른 범주에 속함
  • CloudWatch로 데이터를 전송하는 AWS 서비스는 각 지표에 차원 연결
    • 차원 : 지표의 자격 증명에 속하는 이름/값 페어
  • 차원 사용 ➡️ CloudWatch가 반환하는 결과 필터링
  • 예) 검색할 때 InstanceId 차원을 지정하여 특정 EC2 인스턴스에 대한 통계를 얻을 수 있습니다.

사용자 지정 지표

애플리케이션이 있고, 웹 사이트의 페이지 뷰 수를 기록하려고 한다고 가정해 보겠습니다.
CloudWatch에서 이 지표를 어떻게 기록하시겠습니까?

첫째, 이것은 애플리케이션 수준 지표입니다.
즉, EC2 인스턴스가 기본값으로 CloudWatch에 게시하는 지표가 아닙니다. 여기서 사용자 지표가 필요해집니다.
사용자 지정 지표를 사용하면 자체 지표를 CloudWatch에 게시할 수 있습니다.

둘째, 보다 세분화된 가시성을 확보하려면,
고분해능 사용자 지정 지표를 사용하여 1초 분해능으로 사용자 지정 지표를 수집할 수 있습니다.
즉, 사용자 지정 지표당 매초 하나의 데이터 포인트를 보낼 수 있습니다.

사용자 지정 지표의 예

  • 웹 페이지 로드 시간
  • 요청 오류율
  • 인스턴스의 프로세스 또는 스레드 수
  • 애플리케이션에서 수행하는 작업량

사용자 지정 지표 시작 방법

  • PutMetricData API 사용 ➡️ 프로그래밍 방식으로 지표를 CloudWatch로 전송하여 사용자 지정 지표 시작

CloudWatch 대시보드

AWS 리소스 프로비저닝 → CloudWatch로 지표를 전송 → CloudWatch 콘솔 대시보드 
  • CloudWatch 콘솔 대시보드 사용 ➡️ 해당 데이터 시각화, 검토 가능
  • 대시보드 : 그래프 또는 텍스트와 같은 위젯을 사용하여 하나 이상의 지표에 대한 데이터 시각화에 사용하는 사용자 정의 가능한 홈페이지
  • 다양한 사용자 지정 대시보드 구축 가능
  • 사용자 환경에 대한 고유한 보기에 초점 맞출 수 있음
  • 여러 리전의 데이터를 단일 대시보드로 추출 ➡️ 아키텍처의 전역 보기 생성 가능

CloudWatch 에서

  • 그래프 생성, 지표 요청 → 지정한 기간에 따라 통계 집계
    • 지표 위젯에 라이브 데이터 표시 여부 선택 가능
    • 라이브 데이터 : 완전히 집계되지 않은 마지막 순간에 게시된 데이터

CloudWatch 지표 수집 방법

  • 모든 시각화 요구 사항에 CloudWatch 사용하는 것 ❌
  • GetMetricData API 사용 ➡️ 외부 or 사용자 지정 도구 사용하여 CloudWatch 지표 수집, 분석 가능

CloudWatch 보안

  • IAM 사용자, IAM 그룹, IAM 역할과 연결되는 AWS Identity and Access Management(IAM) 정책
  • AWS IAM 정책 통해 → CloudWatch 대시보드 보거나 관리할 수 있는 액세스 권한 가진 사용자 제어

Amazon CloudWatch Logs

  • CloudWatch : Amazon CloudWatch Logs 사용하여 로그 저장, 분석 가능한 중앙 집중식 장소
  • CloudWatch Logs ➡️ Amazon EC2 인스턴스, AWS Lambda 함수, 기타 소스에서 실행되는 애플리케이션 로그 파일을 모니터링, 저장, 액세스
  • 로그 데이터 쿼리, 필터링 가능
예를 들어
애플리케이션에서 애플리케이션 로직 오류를 조사하는 중이고 이 오류가 발생하면 스택 추적이 기록된다는 것을 알고 있다고 가정해 보겠습니다.

오류가 기록되다는 것을 알고 있으므로 CloudWatch Logs에서 로그를 쿼리하여 스택 추적을 찾습니다.
또한 로그에 지표 필터를 설정하여 로그 데이터를 그래프로 표시하여 대시보드에서 사용할 수 있는 수치형 CloudWatch 지표로 변환합니다.

일부 서비스는 AWS Lambda와 같이 최소한의 노력으로 로그 데이터를 CloudWatch Logs로 전송하도록 설정되어 있습니다.
AWS Lambda를 사용하는 경우,
Lambda 함수에 로그를 CloudWatch Logs에 게시할 수 있는 올바른 IAM 권한을 부여하기만 하면 됩니다.

다른 서비스에는 더 많은 구성이 필요합니다.
예를 들어
EC2 인스턴스에서 애플리케이션 로그를 CloudWatch Logs로 보내려면, 먼저 EC2 인스턴스에 CloudWatch Logs 에이전트를 설치하고 구성해야 합니다.
CloudWatch Logs 에이전트를 사용하면 Amazon EC2 인스턴스가 자동으로 로그 데이터를 CloudWatch Logs로 보낼 수 있습니다. 에이전트가 설치 및 구성되면 CloudWatch Logs에서 애플리케이션 로그를 볼 수 있습니다.

에이전트 구성 요소

  • 로그 데이터를 CloudWatch Logs 스크립트로 푸시하는 AWS Command Line Interface(AWS CLI)에 대한 플러그 인
  • 데이터를 CloudWatch Logs에 푸시하는 프로세스를 시작하는 스크립트
  • 데몬이 항상 실행되도록 보장하는 cron 작업

CloudWatch Logs 용어

CloudWatch Logs로 전송되는 로그 데이터는 여러 소스에서 나온다
    ➡️ 로그 구성 방식, 로그를 설명하는 데 사용되는 용어 이해 중요
로그 이벤트 로그 이벤트는 모니터링되는 애플리케이션 또는 리소스가 기록한 활동의 레코드이며, 타임스탬프와 이벤트 메시지가 있습니다.
로그 스트림 로그 이벤트는 로그 스트림으로 그룹화됩니다.
로그 스트림은 모두 모니터링되는 동일한 리소스에 속하는 로그 이벤트의 시퀀스입니다.
예를 들어 EC2 인스턴스에 대한 로그는 인사이트를 필터링하거나 쿼리할 수 있는 로그 스트림으로 그룹화됩니다.
로그 그룹 로그 스트림이 로그 그룹으로 구성됩니다.
로그 그룹은 동일한 보존 및 권한 설정을 공유하는 로그 스트림으로 구성됩니다.
예를 들어 애플리케이션을 호스팅하는 EC2 인스턴스가 여러 개 있고 애플리케이션 로그 데이터를 CloudWatch Logs로 보내는 경우 각 인스턴스의 로그 스트림을 하나의 로그 그룹으로 그룹화할 수 있습니다. 그러면 로그를 체계적으로 구성할 수 있습니다.

 

CloudWatch 경보 (Amazon CloudWatch alarm)

CloudWatch 경보 생성 ➡️ 지표의 지속적인 상태 변화에 따라 자동으로 작업 시작
경보가 트리거되는 시기, 수행할 작업 구성
  • 모니터링 중인 지표에 대한 임계값 생성 가능
  • 임계값은 지표값에 대한 일반 경계 정의 가능
  • 지표가 일정 기간 동안 경계를 벗어난다면 ➡ 트리거 ➡ 자동화 작업 수행

 

먼저 경보를 설정할 지표를 결정한 다음, 경보를 트리거할 임계값을 정의해야 합니다. 다음으로 임계값의 기간을 정의합니다.

예를 들어
CPU 사용률이 임계값 80%를 초과할 때 트리거하도록 EC2 인스턴스에 대한 경보를 설정하려면 CPU 사용률이 임계값을 초과하는 기간도 지정해야 합니다.
CPU 사용률의 일시적인 스파이크를 기반으로 경보를 트리거하고 싶지는 않을 것입니다.
CPU 사용률이 지속적인 시간 동안 상승한 경우에만 경보를 트리거하려고 합니다.

예를 들어,
5분 이상 CPU 사용률이 80% 이상인 경우 리소스 문제가 발생한 것일 수 있습니다. 이 모든 것을 염두에 두고 경보를 설정하려면 지표, 임계값 및 기간을 선택해야 합니다.

경보 상태

  1. OK: 지표가 정의된 임계값 내에 있습니다. 모든 것이 정상 작동하는 것처럼 보입니다.
  2. ALARM: 지표가 정의된 임계값을 벗어납니다. 이는 운영상의 문제일 수 있습니다.
  3. INSUFFICIENT_DATA: 경보가 방금 시작되었거나, 지표를 사용할 수 없거나, 지표의 경보 상태를 확인할 수 있는 데이터가 충분하지 않습니다.

 

  • 경보 상태 변경 시 트리거 가능 (한 상태에서 다른 상태로 전환될 때)
  • 경보가 트리거되면 작업 시작 가능
    • 작업 : Amazon EC2 작업, 자동 크기 조정 작업 Amazon Simple Notification Service(Amazon SNS)에 전송되는 알림일 수 있다.

CloudWatch 경보로 인한 문제 예방 및 문제 해결

  • CloudWatch Logs는 지표 필터 사용하여 ➡️ 로그 데이터 그래프로 표시, 경보 설정할 수 있는 지표로 전환
직원 디렉터리 애플리케이션에서 500 오류 응답 코드에 대한 지표 필터를 설정한다고 가정해 보겠습니다.

그런 다음 500 오류 응답이 일정 기간 동안 일정량을 초과하면 ALARM 상태로 전환하는 해당 지표에 대한 경보를 정의합니다.
시간당 500개 이상의 오류 응답이 5회 이상인 경우 경보가 ALARM 상태로 들어가야 합니다.

다음으로 경보가 트리거될 때 수행할 작업을 정의합니다.
이 경우 웹 사이트 문제 해결을 시작할 수 있도록 이메일 또는 문자 알림을 보내면 더 큰 문제로 발전하기 전에 해결할 수 있습니다.
경보가 설정되면 오류가 다시 발생할 경우 즉시 알림을 받게 된다는 것을 알고 있으므로 안심할 수 있습니다.
여러 가지 이유로 서로 다른 경보를 설정하여 운영 문제를 예방하거나 해결할 수 있습니다.

방금 설명한 시나리오에서 경보는 문제를 수동으로 조사하는 사람에게 전달되는 Amazon SNS 알림을 트리거합니다.
또 다른 옵션은 경보가 기술 문제를 자동으로 해결하는 작업을 트리거하도록 하는 것입니다.

예를 들어
EC2 인스턴스 재부팅을 트리거하거나 서비스를 확장 또는 축소하도록 경보를 설정할 수 있습니다.
AWS Lambda 함수를 트리거하는 Amazon SNS 알림을 트리거하도록 경보를 설정할 수도 있습니다.
그런 다음 Lambda 함수가 모든 AWS API를 호출하여 리소스를 관리하고 운영 문제를 해결합니다.
이와 같이 AWS 서비스를 함께 사용하면 이벤트에 보다 신속하게 대응할 수 있습니다.

리소스

 

6-4) 솔루션 최적화

액세스 하는 인원이 많다면? ➡️ 가용성 높이려면 중복성 필요

  1. 인스턴스 수직 확장
    • 보유한 인스턴스 크기 늘리기
    • 해당 인스턴스의 확장성 상한 도달
  2. 인스턴스 수평 확장
    • 인스턴스 더 추가하여 인스턴스 플릿 생성
    • 제한 ❌ ➡ 플릿에 원하는 만큼 인스턴스 추가 가능
  3. 오토 스케일링
  4. 로드 밸런서

가용성

  • 시스템 가용성 표시 : 일반적으로 단일 연도의 가동 시간 백분율(또는 숫자 9의 개수)

연간 가동 중지 시간을 기준으로 한 가용성 백분율 목록 및 해당 표기법

 

  • 가용성을 높이려면 중복성이 필요 ➡️ 일반적으로 더 많은 인프라(데이터 센터, 서버, 데이터베이스, 데이터 복제 등)를 의미
  • 인프라 추가와 비용 증가는 비례
  • 고객에게 애플리케이션 항상 사용 + 비용 고려하여 중복성 추가 솔루션 제공해야함

애플리케이션 가용성 개선

현재 애플리케이션에서 EC2 인스턴스 하나가
애플리케이션을 호스팅하고,
사진이 Amazon Simple Storage Service(Amazon S3)에서 제공되고,
정형 데이터가 Amazon DynamoDB에 저장됩니다.

이 단일 EC2 인스턴스가 애플리케이션의 단일 장애 지점입니다.
  • 단일 인스턴스 사용할 수 ❌ → 고객도 연결 할 수 ❌
    • 데이터베이스, Amazon S3 고가용성임에도 불구하고,
  • 단일 장애 지점 문제 해결 유일한 방법 : 서버 하나 더 추가

두 번째 가용 영역

  • 서버 물리적 위치는 중요
    • 운영 체제, 애플리케이션 수준의 잠재적인 소프트웨어 문제 + 하드웨어 문제 고려해야함
    • 문제는 가용역영
    • 가용역역 : 물리적 서버, 랙, 데이터 센터 또는 가상 머신을 호스팅
  • 물리적 위치 문제 해결 방안 : 다른 가용 영역에 두 번째 EC2 인스턴스 배포
  • 새 인스턴스는 운영 체제, 애플리케이션 문제도 해결 가능 BUT 인스턴스 두 개 이상 보유 시 새로운 과제 생김

복제, 리디렉션 및 고가용성

복제 프로세스

EC2 인스턴스가 여러 개인 경우,

  • 첫 번째 과제 : 인스턴스 간 구성 파일, 소프트웨어 패치, 애플리케이션 복제 프로세스 생성 필요
  • 가장 좋은 방법 : 최대한 자동화

고객 리디렉션

  • 두 번째 과제 : 클라이언트(서버에 요청을 보내는 컴퓨터)가 다른 서버를 인지하도록 하는 방법 ➡️ 다양한 도구 사용 가능
  • 가장 일반적인 방법 : 도메인 이름 시스템(DNS) 사용
    • 클라이언트가 사용 가능한 모든 서버의 IP 주소를 가리키는 하나의 레코드를 사용
    • 이 방법 항상 사용 ❌ ➡️ IP 주소 목록을 업데이트하고 클라이언트가 이러한 변경 사항(전파라고도 함)을 인식하는 데 시간 소요됨
  • 또 다른 방법 : 부하 분산기 사용
    • 부하 분산기 : 상태 확인을 처리, 각 서버에 부하 분산
    • 클라이언트와 서버 사이에 위치하는 로드 밸런서 ➡️ 전파 시간 문제 방지

고가용성 유형

서버가 두 개 이상일 때 해결해야 할 마지막 과제
  • 마지막 과제 : 액티브-패시브 또는 액티브-액티브 등 필요한 가용성 유형
액티브-패시브 (active-passive)
액티브-패시브 시스템의 경우 한 번에 두 인스턴스 중 하나만 사용할 수 있습니다.
이 방법의 한 가지 장점 : 클라이언트의 세션에 대한 데이터가 서버에 저장되는 상태 유지 애플리케이션의 경우 고객이 항상 세션이 저장된 서버로 전송되기 때문에 문제가 발생하지 않는다는 것입니다.
단점 : 확장성 ❌

액티브-액티브 (active-active)
액티브-패시브의 단점이자, 액티브-액티브 시스템의 장점은 확장성입니다.
두 서버를 모두 사용할 수 있게 하면 두 번째 서버가 애플리케이션의 로드를 일부 처리하므로 전체 시스템이 더 많은 로드를 수행할 수 있습니다.
그러나 애플리케이션이 상태 유지인 경우 두 서버 모두에서 고객의 세션을 사용할 수 없는 경우 문제가 발생할 수 있습니다.
무상태 애플리케이션은 액티브-액티브 시스템에서 더 잘 작동합니다.

리소스

6-5) Amazon Elastic Load Balancing을 사용한 트래픽 라우팅

Amazon Elastic Load Balancing

  • 고가용성, 자동 확장 가능 서비스
  • 리전 서비스 ➡ 각 가용 영역에서 노드를 유지 관리하거나 고가용성을 직접 구상하지 않아도 됨
  • 추가 처리량 처리하도록 설계 ➡ 들어오는 트래픽 처리하도록 자동 확장

ELB 유형

 

  • Application Load Balancer : HTTP 및 HTTPS 트래픽 로드 밸런싱 (Layer 7 : HTTP, HTTPS)
  • Network Load Blancer : TCP, UDP, TLS 트래픽 로드 밸런싱 (Layer 4 : TCP, UDP, TLS)
  • Gateway Load Balancer : 주로 트래픽을 서드 파티 애플리케이션으로 라우팅 하기 위한 로드 밸런싱 (Layer 3+4 : IP)

로드 밸런서

  • 리소스 집합에 작업을 분산하는 프로세스
  • 로드 밸런서 사용 ➡️ 애플리케이션을 호스팅하는 모든 서버에 요청 분산 가능
직원 디렉터리 애플리케이션의 경우,
리소스 : 애플리케이션을 호스팅하는 EC2 인스턴스
작업 : 전송되는 요청
  • EC2 인스턴스에 자체 소프트웨어 로드 밸런싱 솔루션을 설치할 수도 있다.
  • BUT AWS는 Elastic Load Balancing 서비스 제공

모든 서버에 요청 분산 위해

  1. 로드 밸런서가 모든 트래픽 가져옴
  2. 알고리즘 기반으로 백엔드 서버로 리디렉션하도록 설정
  • 가장 많이 사용되는 알고리즘 : 라운드 로빈 ➡️ 트래픽을 각 서버에 하나씩 전송

로드밸런서 요청

  • 애플리케이션에 대한 일반적인 요청은 클라이언트의 브라우저에서 시작
  • 요청 ➡️ 로드 밸런서로 전송됨
  • 로드밸런서로 전송된 요청 ➡️ 전송애플리케이션을 호스팅하는 EC2 인스턴스 중 하나로 전송
  • 반환 트래픽 ➡️ 로드 밸런서를 통해 다시 클라이언트의 브라우저로 돌아감
  • 로드 밸런서는 트래픽 경로에 직접 위치

ELB 기능

  • ELB 서비스는 자체 솔루션 사용 ➡️ 로드 밸런싱을 수행하는 것보다 큰 이점 제공
  • 가본적으로 관리 또는 운영할 필요 ❌
  • 수신되는 애플리케이션 트래픽 ➡️ EC2 인스턴스, 컨테이너, IP 주소, AWS Lambda 함수 간 분산 가능

ELB 중요한 특징

  • ELB는 IP 주소로 로드 밸런싱할 수 있으므로 하이브리드 모드에서도 작동
    • 즉, 온프레미스 서버로도 로드 밸런싱됩니다.

 

  • ELB는 고가용성
    • 유일하게 확인해야 할 옵션 : 로드 밸런서가 여러 가용 영역에 배포되는지

 

  • 확장성 측면 ➡️ ELB는 수신 트래픽의 수요에 맞게 자동으로 확장
    • 수신 트래픽을 처리하여 백엔드 애플리케이션으로 전송

상태 확인

  • 적절한 상태 확인 정의는 매우 중요
  • 애플리케이션의 포트가 열려 있다 ➡️ 애플리케이션이 작동 중이라는 의미 ❌
  • 단순히 애플리케이션의 홈페이지 호출 ➡️ 올바른 방법이라는 의미 ❌
예를 들어
직원 디렉터리 애플리케이션은 데이터베이스와 Amazon S3에 종속됩니다.

상태 확인은 모든 요소의 유효성을 검사해야 합니다.
이를 위한 한 가지 방법은 ‘/monitor’와 같이 데이터베이스를 호출하여 데이터를 연결하고 가져와,
Amazon S3에 호출할 수 있도록 모니터링 웹 페이지를 만드는 것입니다.
그런 다음 로드 밸런서의 상태 확인을 ‘/monitor’ 페이지로 가리킵니다.

 

 

  • 새 EC2 인스턴스 가용성 확인 후, 로드 밸런서가 이 EC2 인스턴스로 트래픽 전송 시작
  • ELB에서 EC2 인스턴스가 더 이상 작동하지 않는다고 판단 시
    • EC2 인스턴스로의 트래픽 전송 중지
    • EC2 Auto Scaling에 알림
  • EC2 Auto Scaling 책임 : 그룹에서 이 EC2 인스턴스 제거 + 새 인스턴스로 교체
  • 새 인스턴스 상태 확인 통과 후 트래픽 전송
Connection Draining 기능

EC2 Auto Scaling은 크기 조정 정책에 따라 축소 작업을 수행해야 하는 경우, ELB에게 EC2 인스턴스가 종료될 것임을 알립니다.
ELB는 인스턴스에 대한 모든 연결이 끝날 때까지 EC2 Auto Scaling이 EC2 인스턴스를 종료하는 것을 금지하는 한편 새 연결을 차단할 수 있습니다.

ELB 구성 요소

ELB 서비스를 이루는 3가지 주요 구성 요소

  1. 규칙
  2. 리스너
  3. 대상 그룹

규칙 대상
그룹을 리스너에 연결하려면 규칙을 사용해야 합니다.
규칙 구성: 클라이언트 소스 IP 주소가 될 수 있는 조건 + 트래픽을 보낼 대상 그룹을 결정하는 조건

리스너
클라이언트가 리스너에 연결합니다. 이를 흔히 클라이언트 측이라고 합니다.
리스너를 정의하려면 로드 밸런서 유형에 따라 프로토콜 외에 포트가 제공되어야 합니다.
단일 로드 밸런서에 대해 여러 리스너가 있을 수 있습니다.

대상 그룹
백엔드 서버 또는 서버 측은 하나 이상의 대상 그룹으로 정의됩니다.
여기에서 EC2 인스턴스, AWS Lambda 함수, IP 주소와 같이 트래픽을 전송하려는 백엔드 유형을 정의합니다.
또한 각 대상 그룹에 대해 상태 확인을 정의해야 합니다.

Application Load Balancer

  • OSI 모델 7계층인 app 계층에서 작동 ➡ 트래픽 경로를 사용자가 지정 가능
  • 주로 HTTP, HTTPS 트래픽에 사용
    • 애플리케이션이 다른 프로토콜을 사용하는 경우 ➡️ 네트워크 로드 밸런서

ALB 생성시 주요 구성 요소 3가지

1. 리스너 (Listener)

리스너 목표 : 요청 확인
리스너 정의 위해 ➡ 포트, 프로토콜 제공

 

2. 대상 그룹 (Target group)

대상 그룹 : 트래픽을 전송하려는 백엔드 유형 (Ex. ec2, 람다, ip주소 등)
대상 그룹은 단순히 백엔드 리소스를 그룹화
각 대상 그룹에는 health check 필요 ➡ 로드밸런서가 대상이 정상인지 확인하여 트래픽 수락

 

3. 규칙 (Rules)

규칙 : 요청이 대상으로 라우팅되는 방식을 정의
각 리스너에는 기본 규칙 존재, 선택적으로 추가 규칙을 정의 가능

Application Load Balancer 중요한 특징

  • ALB는 요청 데이터를 기반으로 트래픽을 라우팅합니다.

ALB는 URL 경로(/upload) 및 호스트, HTTP 헤더 및 메서드, 클라이언트의 소스 IP 주소와 같은 HTTP 프로토콜을 기반으로 라우팅 결정을 내립니다. 그러면 대상 그룹으로 세분화된 라우팅이 가능합니다.

  • ALB는 클라이언트에 직접 응답을 보냅니다.

ALB는 사용자 지정 HTML 페이지와 같은 고정 응답을 사용하여 클라이언트에 직접 회신할 수 있습니다. 클라이언트로 리디렉션을 보낼 수도 있습니다. 이는 특정 웹 사이트로 리디렉션하거나 HTTP에서 HTTPS로 요청을 리디렉션하여 백엔드 서버에서 해당 작업을 경감해야 할 때 유용합니다.

  • ALB는 TLS 오프로딩을 사용합니다.

HTTPS 및 백엔드 서버의 작업 경감에 대해 부연하자면, ALB는 HTTPS 트래픽을 이해합니다. ALB를 통해 HTTPS 트래픽을 전달하기 위해 SSL 인증서가 IAM 또는 AWS Certificate Manager(ACM) 서비스를 통해 인증서를 가져오거나 ACM을 사용하여 인증서를 무료로 생성하여 제공됩니다. 그러면 클라이언트와 ALB 간의 트래픽이 암호화됩니다.

  • ALB는 사용자를 인증합니다.

보안 측면에서 ALB는 로드 밸런서를 통과하기 전에 사용자를 인증할 수 있습니다. ALB는 OpenID Connect 프로토콜을 사용하고 다른 AWS 서비스와 통합하여 SAML, LDAP, Microsoft Active Directory 등과 같은 프로토콜을 지원합니다.

  • ALB는 트래픽을 보호합니다.

트래픽이 로드 밸런서에 도달하지 못하도록 하려면 보안 그룹을 구성하여 지원되는 IP 주소 범위를 지정합니다.

  • ALB는 라운드 로빈 라우팅 알고리즘을 사용합니다.

ALB는 일반적으로 각 서버가 동일한 수의 요청을 수신하도록 합니다. 이 유형의 라우팅은 대부분의 애플리케이션에서 작동합니다.

  • ALB는 최소 미해결 요청 라우팅 알고리즘을 사용합니다.

백엔드에 대한 요청의 복잡성이 다르면 한 요청의 CPU 시간이 다른 요청보다 훨씬 더 많은 CPU 시간이 필요할 수 있으므로 최소 미해결 요청 알고리즘이 더 적합합니다. 또한 대상의 처리 용량에 편차가 있는 경우 사용할 수 있는 올바른 라우팅 알고리즘이기도 합니다. 미해결 요청은 요청이 백엔드 서버로 전송되고 응답이 아직 수신되지 않은 경우입니다.

예를 들어 대상 그룹의 EC2 인스턴스가 동일한 크기가 아닌 경우 라운드 로빈 라우팅 알고리즘을 사용하여 각 서버로 동일한 수의 요청이 전송되면 한 서버의 CPU 사용률이 다른 서버의 CPU 사용률보다 높아집니다. 그 서버에는 더 많은 미해결 요청이 있을 것입니다. 최소 미해결 요청 라우팅 알고리즘을 사용하면 대상 간에 동일한 사용량을 보장할 수 있습니다.

  • ALB는 스티키 세션을 사용합니다.

애플리케이션이 상태 유지이기 때문에 요청을 동일한 백엔드 서버로 보내야 하는 경우 스티키 세션 기능을 사용합니다. 이 기능은 HTTP 쿠키를 사용하여 트래픽을 보낼 서버 간 연결을 기억합니다.

네트워크 로드 밸런서 (Network Load Balancer)

네트워크 로드 밸런서 중요한 특징

네트워크 로드 밸런서는 TCP, UDP 및 TLS 프로토콜을 지원합니다.

HTTPS는 TCP 및 TLS를 프로토콜로 사용합니다. 그러나 NLB는 연결 계층에서 작동하므로 HTTPS 요청이 무엇인지 이해할 수 없습니다. 즉, 프로토콜, 인증 및 최소 미해결 요청 라우팅 알고리즘에 기반한 라우팅 규칙과 같이 HTTP 및 HTTPS 프로토콜을 이해하는 데 필요한 모든 기능을 NLB에서는 사용할 수 없습니다.

NLB는 흐름 해시 라우팅 알고리즘을 사용합니다.

이 알고리즘은 다음을 기반으로 합니다.

  • 프로토콜
  • 소스 IP 주소 및 소스 포트
  • 대상 IP 주소 및 대상 포트
  • TCP 시퀀스 번호

모든 파라미터가 동일하면 패킷이 동일한 대상으로 전송됩니다. 다음 패킷에 다른 패킷이 있는 경우 요청이 다른 대상으로 전송될 수 있습니다.

NLB에는 스티키 세션이 있습니다.

ALB와 달리 이러한 세션은 쿠키 대신 클라이언트의 소스 IP 주소를 기반으로 합니다.

NLB는 TLS 오프로딩을 지원합니다.

NLB는 TLS 프로토콜을 이해합니다. 또한 ALB 작동 방식과 유사하게 백엔드 서버에서 TLS를 오프로드할 수 있습니다.

NLB는 초당 수백만 건의 요청을 처리합니다.

ALB는 이 요청 수를 지원할 수도 있지만 해당 건수에 도달하도록 크기를 조정해야 합니다. 이 작업에는 시간이 걸립니다. NLB는 초당 수백만 건의 요청을 즉시 처리할 수 있습니다.

NLB는 고정 및 탄력적 IP 주소를 지원합니다.

경우에 따라 애플리케이션 클라이언트가 DNS를 사용하는 대신 로드 밸런서 IP 주소로 직접 요청을 보내야 합니다. 예를 들어 애플리케이션에서 DNS를 사용할 수 없거나 연결 클라이언트가 IP 주소를 기반으로 하는 방화벽 규칙을 요구하는 경우에 유용합니다. 이 경우 NLB가 사용할 올바른 유형의 로드 밸런서입니다

NLP는 소스 IP 주소를 보존합니다.

NLB는 트래픽을 백엔드로 보낼 때 클라이언트의 소스 IP 주소를 보존합니다. ALB에서는 요청의 소스 IP 주소를 보면 로드 밸런서의 IP 주소를 찾을 수 있습니다. NLB를 사용하는 동안 클라이언트의 실제 IP 주소를 볼 수 있습니다. 백엔드 애플리케이션에 이 주소가 필요한 경우도 있습니다.

ELB 유형 중에서 선택

  • ELB 서비스 유형 중에서 선택하는 것 ➡️ 애플리케이션에 필요한 기능을 결정하여 수행

로드 밸런서의 주요 특징 목록

리소스

6-6) Amazon EC2 Auto Scaling

인스턴스 수평 확장에서 수동이 아닌 자동화하는 오토 스케일링

Auto Scaling

  • 설정한 임계값에 따라 더 많은 용량을 프로비저닝 가능하게 함
  • 임계값 설정은 CloudWatch
오토 스케일링에 더 많은 EC2 인스턴스 프로비저닝 지시 ➡ 각 인스턴스 온라인 상태 ➡ ELB Health check ➡ 트래픽 수신 시작 ➡ 필요한 수평 확장 제공

용량 문제

  • 서버 하나 더 추가 ➡️ 가용성, 도달 가능성 향상
  • BUT 용량 문제가 있으면 ➡️ 전체 시스템을 다시 사용할 수 ❌
  • 두 가지 유형의 시스템에 대한 로드 문제 : 액티브-패시브, 액티브-액티브

수직 크기 조정

너무 많은 요청이 하나의 액티브-패시브 시스템으로 전송되면,
액티브 서버를 사용할 수 없게 되어 패시브 서버로 장애 조치될 수 있습니다.

하지만 이것은 아무 것도 해결하지 못합니다.
액티브-패시브 기능을 사용하려면 수직 크기 조정이 필요합니다. 이는 서버의 크기를 늘리는 것을 의미합니다.
EC2 인스턴스에서는 더 큰 유형 또는 다른 인스턴스 유형을 선택할 수 있습니다. 이 작업은 인스턴스가 중지 상태일 때만 수행할 수 있습니다.

 

이 시나리오에서는 다음 단계가 발생

  1. 패시브 인스턴스를 중지합니다. 트래픽이 발생하지 않기 때문에 애플리케이션에는 영향을 주지 않습니다.
  2. 인스턴스 크기 또는 유형을 변경한 다음 인스턴스를 다시 시작합니다.
  3. 트래픽을 패시브 인스턴스로 이동하여 활성 상태로 전환합니다.
  4. 두 인스턴스가 모두 일치해야 하므로 중지하고 크기를 변경하고 이전 활성 인스턴스를 시작합니다.

수직 크기 조정 단점

  • 요청 수가 줄어들면 동일한 작업 수행해야함
    • 그다지 많은 단계가 관련되어 있지는 않지만, 실제로 수작업이 많은 작업
  • 서버를 수직으로 확장하는 데 특정 제한 존재
    • 특정 제한 도달 시 유일한 옵션 ➡️ 다른 액티브-패시브 시스템을 만들고, 요청과 기능을 분할
    • 이를 위해서, 대규모 애플리케이션을 다시 작성해야 할 수 있다.

수직 크기 조정 단점 보완 방법

  • 액티브-액티브 시스템
  • 너무 많은 요청시 ➡️ 서버 추가, 시스템을 수평으로 확장 가능

수평 크기 조정

액티브-액티브 시스템 사용

액티브-패시브 시스템에 비해 더 많은 이점 존재
애플리케이션을 무상태가 되도록 수정하면 확장이 가능
  • 애플리케이션은 액티브-액티브 시스템에서 작동하도록 이미 무상태로 생성 ➡️ 서버에 클라이언트 세션 저장❌
    • 즉, 2대의 서버가 있거나 4대의 서버가 있으면 애플리케이션을 변경할 필요가 없습니다.
  • 애플리케이션 변경 필요한 경우 ➡️ 더 많은 인스턴스를 만들고
  • 트래픽이 감소하면 ➡️ 인스턴스를 종료하기만 하면 됨

Amazon EC2 Auto Scaling

  • Amazon CloudWatch 지표 기반으로, EC2 인스턴스를 자동으로 생성/제거하여 크기 조정 작업 처리 가능

EC2 Auto Scaling을 사용한 ELB

  • ELB 서비스 ➡️ EC2 Auto Scaling과 원활하게 통합
    • EC2 Auto Scaling 그룹에서 새 EC2 인스턴스 추가 / 제거 ➡️ 즉시 ELB 알림 전송 받음
  • 새로운 EC2 인스턴스로 트래픽 전송하려면 ➡️ EC2 인스턴스에서 실행 중인 애플리케이션 사용할 수 있는지 확인해야함
    • 이 유효성 검사는 ELB 상태 확인 기능을 통해 수행된다.
  • 모니터링은 로드 밸런서의 중요한 부분 ➡️ 트래픽을 정상 EC2 인스턴스로만 라우팅해야 함

ELB 지원하는 두 가지 유형의 상태 확인

  1. TCP를 사용하여 백엔드 EC2 인스턴스에 대한 연결을 설정하고 연결이 성공하면 인스턴스를 사용 가능으로 표시합니다.
  2. 지정한 웹 페이지에 대한 HTTP 또는 HTTPS 요청을 실행하고 HTTP 응답 코드가 반환되는지 확인합니다.

기존 크기 조정과 자동 크기 조정

기존 크기 조정 방식 ➡️ 트래픽을 처리하기에 충분한 서버를 구매 및 프로비저닝

예를 들어
야간에는 트래픽보다 용량이 많아 돈을 낭비한다는 의미이기도 합니다.
야간이나 트래픽이 낮은 시간에 서버를 끄면 전기가 절약됩니다.

 

클라우드 크기 조정 방식 ➡️ 종량 과금제 모델

사용하지 않는 서비스,특히 온디맨드 요금을 지불하는 EC2 인스턴스를 해제해야 합니다.
예상 시간에 서버를 수동으로 추가 및 제거할 수 있습니다.

그러나 트래픽이 비정상적으로 급증하는 경우 이 솔루션은 과잉 프로비저닝으로 인한 리소스 낭비 또는 프로비저닝 부족으로 인한 고객 상실로 이어집니다.
  • 정의한 조건에 따라 EC2 인스턴스 자동으로 추가, 제거하는 도구 필요 ➡️ EC2 Auto Scaling

Amazon EC2 Auto Scaling

  • 용량 추가/제거하여 가능한 최저 비용으로 안정적, 예측 가능한 성능 유지
  • 애플리케이션 사용량과 정확히 일치하게 용량 조정 ➡️ 애플리케이션에 필요한 만큼만 비용 지불 가능
  • 애플리케이션 사용량 꾸준한 경우 ➡️ 플릿 관리에 도움
  • EC2 인스턴스에 문제 발생한 경우 ➡️ 인스턴스 자동으로 교체
  • 즉, EC2 Auto Scaling은 인프라의 크기를 조정하고 고가용성을 보장하는 데 모두 도움이 됩니다.

EC2 Auto Scaling 구성 요소 구성

  1. 시작 템플릿 또는 구성: 자동으로 크기를 조정할 리소스는 무엇입니까?
  2. EC2 Auto Scaling 그룹: 리소스를 어디에 배포해야 합니까?
  3. 크기 조정 정책: 언제 리소스를 추가 또는 제거해야 합니까?

시작 템플릿

  • EC2 인스턴스 생성에 필요한 파라미터 : Amazon Machine Image(AMI) ID, 인스턴스 유형, 보안 그룹, 추가 Amazon Elastic Block Store(EBS) 볼륨 등
  • 크기 조정이 필요한 경우 ➡️ EC2 Auto Scaling이 사용자 대신 EC2 인스턴스 생성할 때 파라미터 정보 필요
  • 모든 정보는 시작 템플릿에 저장

시작 템플릿 사용 이점

  • EC2 인스턴스 수동으로 시작 가능
  • EC2 Auto Scaling과 함께 사용 가능
  • 버전 관리도 지원 ➡️ 문제가 있거나 기본 버전을 지정해야 할 경우 신속한 롤백 가능
  • 새 버전을 반복하면서 다른 사용자가 기본 버전을 사용하여 EC2 인스턴스 계속 시작하는 동안, 필요한 변경 수행 가능

 

시작 템플릿 생성 3가지 방법

  1. 템플릿을 만드는 가장 빠른 방법은 기존 EC2 인스턴스를 사용하는 것입니다. 모든 설정이 이미 정의되어 있습니다.
  2. 기존 템플릿 또는 이전 버전의 시작 템플릿에서 템플릿을 생성하는 것입니다.
  3. 템플릿을 처음부터 만드는 것입니다. AMI ID, 인스턴스 유형, 키 페어, 보안 그룹, 스토리지 및 리소스 태그 옵션을 정의해야 합니다.

EC2 Auto Scaling 그룹

  • EC2 Auto Scaling이 리소스를 배포하는 위치 정의 가능 ➡️ EC2 인스턴스를 시작해야 하는 Amazon VPC, 서브넷 지정
  • EC2 Auto Scaling은 서브넷에서 EC2 인스턴스를 생성 ➡️ 서로 다른 가용 영역에 있는 서브넷 두 개 이상 선택
  • EC2 인스턴스 구매 유형 지정 가능
    • 온디맨드 전용
    • 스팟 전용
    • 이 둘의 조합 사용 가능 ➡️ 관리 오버헤드 최소화 + 스팟 인스턴스 활용

3가지 용량 설정

EC2 Auto Scaling : 시작해야 하는 인스턴스 수 지정 위해 ➡️ 그룹 크기에 맞게 용량 설정 구성해야 함

  1. 최소: 인스턴스 수를 줄이는 임계값에 도달하더라도 Auto Scaling 그룹에서 실행되는 최소 인스턴스 수입니다.
  2. 최대: 새 인스턴스를 추가하기 위한 임계값에 도달하더라도 Auto Scaling 그룹에서 실행되는 최대 인스턴스 수입니다.
  3. 원하는 용량: Auto Scaling 그룹에 있어야 하는 인스턴스 수입니다. 이 값은 최솟값 또는 최댓값과 같거나 그 사이여야 합니다. EC2 Auto Scaling은 원하는 용량과 일치하도록 인스턴스를 자동으로 추가 또는 제거합니다.

  • 트래픽 최소화되어 EC2 인스턴스를 제거하는 경우 ➡️ 최소 용량에 도달할 때까지 EC2 인스턴스를 계속 제거
  • 트래픽 계속 감소하면
    • 고가용성 보장 위해 최소 2개 사용 권장
    • 애플리케이션에 항상 필요한 최소 EC2 인스턴스 수 알 수 있음
    • 이 한도에 도달하면 ➡️ EC2 Auto Scaling에서 인스턴스를 제거하라는 지시가 있더라도 최솟값이 유지
  • 반면 트래픽 계속 증가하면
    • EC2 Auto Scaling은 EC2 인스턴스 계속 추가
    • 애플리케이션 비용도 계속 증가 ➡️ 예산 초과하지 않도록 최대 금액 설정 필요
  • 원하는 용량 : 그룹 생성 시 EC2 Auto Scaling이 생성하는 EC2 인스턴스의 수
    • 이 수가 감소 ➡️ EC2 Auto Scaling은 기본값으로 가장 오래된 인스턴스 제거
    • 이 수가 증가 ➡️ EC2 Auto Scaling은 시작 템플릿 사용하여 새 인스턴스 생성

EC2 Auto Scaling을 사용한 가용성

  • 용량 동적으로 조정 ➡️ 최소, 최대, 원하는 용량에 다른 숫자 사용
  • 플릿 관리에 EC2 Auto Scaling 사용 위해서는 ➡️ 이미지에 표시된 것처럼 3가지 설정을 같은 숫자(예: 4개)로 구성
  • EC2 인스턴스 비정상인 경우,
    • EC2 인스턴스 대체하여 항상 4개의 EC2 인스턴스를 사용할 수 있도록 ➡️ 애플리케이션의 고가용성 보장

크기 조정 정책을 통한 자동화

기본값으로 Auto Scaling 그룹은 초기의 원하는 용량으로 유지됩니다.
원하는 용량을 수동으로 변경할 수도 있지만 크기 조정 정책을 사용할 수도 있습니다.

AWS 모니터링 모듈에서 Amazon CloudWatch 지표 및 경보에 대해 배웠습니다.

지표 사용 : CPU 사용률과 같은 EC2 인스턴스의 다양한 속성에 대한 정보를 유지
경보 사용 : 임계값에 도달했을 때의 작업을 지정
지표 및 경보는 크기 조정 정책이 언제 작업을 수행해야 하는지 알기 위해 사용하는 것입니다.

예를 들어
전체 EC2 인스턴스 플릿에서 CPU 사용률이 70% 이상일 때를 알리는 경보를 설정하고, 크기 조정 정책을 트리거하여, EC2 인스턴스를 추가할 수 있습니다.

3가지 유형의 크기 조정 정책 (단순, 단계, 대상 추적 크기 조정) 사용 가능

단순 크기 조정 정책

단순 크기 조정 정책을 사용하면 이 모듈에서 설명한 내용을 정확하게 수행할 수 있습니다.
CloudWatch 경보를 사용하고 트리거될 때 수행할 작업을 지정합니다.
이는 추가 또는 제거할 EC2 인스턴스 수 또는 원하는 용량을 설정할 특정 숫자일 수 있습니다.
EC2 인스턴스 수를 사용하는 대신 그룹의 백분율을 지정할 수 있으므로 그룹이 더 빠르게 확장 또는 축소됩니다.

크기 조정 정책이 트리거되면 휴지 기간 동안 기다렸다가 다른 작업을 수행합니다.
이는 EC2 인스턴스를 시작하는 데 시간이 걸리고 EC2 인스턴스가 부팅되는 동안 CloudWatch 경보가 계속 트리거될 수 있기 때문에 중요합니다.

예를 들어
모든 인스턴스의 CPU 사용률이 65%를 초과하는 경우 EC2 인스턴스를 추가할 수 있습니다.
새 EC2 인스턴스가 트래픽을 수락할 때까지 인스턴스를 더 추가하고 싶지 않습니다.
그러나 Auto Scaling 그룹에서 CPU 사용률이 85%를 초과하면 어떻게 될까요? 인스턴스 하나를 추가하는 것은 올바른 조치가 아닐 수 있습니다.
대신 크기 조정 정책에 다른 단계를 추가할 수 있습니다. 안타깝게도 간단한 크기 조정 정책으로는 도움이 되지 않습니다.

단계 크기 조정 정책

이때에는 단계 크기 조정 정책이 도움이 됩니다.

단계 크기 조정 정책은 크기 조정 활동 또는 상태 확인 교체가 진행 중에도 추가 경보에 응답합니다.
위의 예와 마찬가지로 CPU 사용률이 85%인 경우 인스턴스를 두 개 더 추가하고 95%인 경우 인스턴스 4개를 더 추가하기로 결정할 수 있습니다.

CloudWatch 경보를 기반으로 인스턴스를 추가 또는 제거할 시기를 결정하는 것은 어려운 작업처럼 보일 수 있습니다.
이것이 세 번째 유형인 대상 추적 크기 조정 정책이 존재하는 이유입니다.

대상 추적 크기 조정 정책

애플리케이션이 평균 CPU 사용률, 평균 네트워크 사용률(입력 또는 출력) 또는 요청 수에 따라 확장되는 경우,
이 유형의 크기 조정 정책을 사용할 수 있습니다.
추적해야 할 목표 값만 제공하면 필요한 CloudWatch 경보가 자동으로 생성됩니다.

리소스

6-7) 직원 디렉터리 애플리케이션 재설계

직원 디렉터리 app

  • 프라이빗 서브넷의 VPC 내에서 여러 EC2 인스턴스에 걸쳐 호스팅 중
  • EC2 인스턴스는 EC2 auto Scaling 그룹의 일부
  • ALB 사용하여 트래픽 분산
  • DB는 DynamoDB에서 호스팅
  • 이미지는 S3에 저장
  • 유지 관리 관점 ➡ 오토 스케일 정책이 기대에 부합하는지 확인

성공적 솔루션 설계

  • 솔루션 최적화에 도움이 되는 새로운 인스턴스 크기 및 유형 확인
  • 최적화하려는 대상과 수행하려는 작업에 따라 app을 설계하는 방법이 크게 좌우됨
  • 대체 아키텍처에 대한 아이디어 제공

3 tier application

Presentation Layer User-interface : HTML, CSS, JS
Application Layer Business/application logic
Data Layer Database

위에 직원 디렉터리 app에서 현재 EC2 인스턴스는 Presentation Layer 과 Application Layer 모두 호스팅하고 있다

  • EC2 인스턴스에 웹 사이트용 콘텐츠를 제공하는 웹 서버 실행되고 있기 때문
    • 웹 서버 ➡ 프레젠테이션 계층
  • app계층인 추가, 업데이트, 삭제를 위한 백엔드 로직에 대한 요청 처리

웹 사이트의 프론트 엔드가 백엔드 애플리케이션 로직과 별도로 호스팅 되도록 설계

여러 유형의 요청을 동시에 처리하여 인스턴스가 오버로드 되지 않도록 ➡️ 프레젠테이션 계층 / 애플리케이션 계층 분리하는것이 중요

 

 

프레젠테이션 계층은 S3에서 처리

  • S3는 정적 웹 사이트 호스트 지원 ➡ 웹사이트의 HTML, CSS, JavaScript 호스팅 가능

애플리케이션 계층은 Lambda 처리 가능 (EC2 호스팅 뿐 아니라)

  • 애플리케이션 코드가 프론트엔트 프레젠테이션 계층에 이벤트에 대한 응답으로서만 실행
  • 프론트엔트가 백엔트 코드와 직접 대화 ❌ ➡ API를 이용하여 백엔드 람다 함수 노출
    • 이러한 API 호스팅하기 위해 Amazon API Gateway 서비스 사용
    • Amazon API Gateway에서 호스팅되는 API는 백엔드 코드를 트리거하는 정문 역할
    • 이 코드는 EC2가 아니라 AWS Lambda에서 호스팅

Lambda 사용

  • 데이터에 대한 모든 요청을 처리하는 하나의 Lambda함수를 사용하거나
  • 수행할 수 있는 각 작업마다 하나의 Lambda 함수 사용 가능

스토리지를 위한 DB또는 Data Layer 계층의 경우

  • DynamoDB와 S3 유지

이러한 서비스 간의 모든 액세스는 IAM 역할을 사용하여

  • 역할 기반 액세스를 통해 처리

솔루션 구성 이점

  • 보다 모듈식 방식으로 솔루션을 구축했기 때문에  ➡ 데이터 계층을 그대로 두면서 Presentation Layer 과 Application Layer을 처리하는 방식을 바꿀 수 있음
  • 이는 유연성의 유형으로 신속하게 혁신하고, 변화에 적응하는 데 도움이 됨

완전성과 명확성을 위해 새로운 아키텍처에 초점을 맞추기 위해 다이어그램에 다른 aws서비스 추가

 

 

  • 웹 사이트의 도메인 이름 관리를 위해 ➡ Amazon Route 53 추가
  • AWS 글로벌 인프라의 AWS 엣지 로케이션을 활용하여 HTML, CSS, JavaScript와 같은 정적 자산을 최종 사용자와 더 가깝게 캐시하기 위한 ➡ CloudFront 추가

전체 플로우

  • 사용자가 웹 사이트의 도메인 입력
  • Amazon Route 53로 전송
  • Route 53가 S3에서 호스팅되는 정적 웹 사이트 주소를 클라이언트에 전송
  • S3가 브라우저에서 렌더링 할 콘텐츠 보냄
  • 웹 사이트에는 동적 콘텐츠를 로드하기 위해 백엔드로 API 호출을 전송하는 JavaScript 존재 (HTTPS calls from JS)
  • 모든 데이터를 로드하는 API 호출이 생성된 후 먼저 API Gateway에 도달
  • API Gateway가 요청 검증한 다음
  • 백엔드 Lambda 함수를 트리거
  • Lambda 함수가 DynamoDB에 API 호출을 전송하여 테이블에서 데이터을 쿼리
  • 해당 데이터를 API Gateway로 반환하면 다시 JavaScript로 반환
  • 최종적으로 페이지에서 렌더링

➡ 이 아키텍처는 확장성, 운영 오버헤드에 대해 최적화

➡ 사용량에 따라 비용에 대해 최적화 될 수 있음

➡ 이 아키텍처의 서버리스 측면 덕분에 EC2 기반 솔루션에 비해 지원 작업이 훨씬 적다

➡ AWS Lambda와 같은 서버리스 솔루션 사용하면 패치 작업 또는 AMI 관리 ❌

➡ 이 솔루션을 위해 VPC, 서브넷, 보안 그룹, 네트워크 액세스 제어 목록을 생성할 필요 ❌

➡ 이 아키텍처의 네트워킹 측면은 사용자가 관리 BUT 규정 준수 때문에 필요한 경우 서버리스 서비스를 VPC 와 통합 가능. 하지만 솔루션 가동에 필요한 것은 ❌

아키텍처 설계

  • app 설계할 때 선택할 수 있는 옵션은 많음

aws 컨테이너 서비스를 사용하여 호스팅하도록 시나리오를 생각한다면 ➡ 동일한 app을 재설계하는 전체 다이어그램이 바뀔 것

  • aws 기반으로 구축할 수 있는 다양한 방법이 있고 이것이 asw의 장점

aws 서비스가 릴리스 되거나 새 기능이 추가된다면 ➡ 솔루션의 특정 구성 요소를 교체 가능

  • aws 모든것이 api 호출이므로 그 과정에서 프로세스를 자동화 할 수 있음

모듈 6 지식 확인

#1 EC2 Auto Scaling의 3가지 구성 요소는 무엇입니까?

 

✅ 시작 템플릿, 크기 조정 정책, EC2 Auto Scaling 그룹

EC2 Auto Scaling에서는 EC2 인스턴스의 구성 템플릿으로
시작 템플릿 또는 시작 구성,
인스턴스의 최소,최대 및 원하는 용량을 지정할 수 있는 EC2 Auto Scaling 그룹,
지정한 조건의 발생 또는 일정에 따라 크기를 조정하도록 그룹을 구성할 수 있는 크기 조정 정책 등
3가지 주요 구성 요소를 지정해야 합니다.

 

#2 Elastic Load Balancing에는 어떤 특징이 있습니까? (2개 선택)

 

✅ Auto Scaling과의 통합

✅ 수신 트래픽을 인스턴스로 전달

ELB는 트래픽에 따라 자동으로 크기 조정됩니다.
수신 트래픽을 처리하여 백엔드 애플리케이션으로 전송합니다.

또한 ELB는 EC2 Auto Scaling과 원활하게 통합됩니다.
EC2 Auto Scaling 그룹에 새 EC2 인스턴스가 추가 또는 제거되는 즉시 ELB에 알림이 전달되고 트래픽을 새 인스턴스로 보내기 시작할 수 있습니다.

 

#3 지표 경보의 가능한 상태는 무엇입니까?

 

✅ OK, ALARM, INSUFFICIENT_DATA

지표 경보에는 다음과 같은 가능한 상태가 있습니다.

OK - 지표 또는 표현식이 정의된 임계값 내에 있습니다.
ALARM - 지표 또는 표현식이 정의된 임계값을 벗어납니다.
INSUFFICIENT_DATA - 경보가 방금 시작되었거나, 지표를 사용할 수 없거나, 지표에 대해 경보 상태를 확인할 수 있는 데이터가 충분하지 않습니다.