AWS 고가용성 구현 (Region, AZ, ELB, ASG)

가용성

• 서비스 가용성
• 워크로드를 사용할 수 있는 시간의 비율

고가용성

• 높은 가용성
• 지속적으로 구현한 시스템이 정상적으로 운영되는 성질
• 고장이 나더라도 복구를 해서 서비스를 지속할 수 있는 능력

(1) Region / Availability Zone

• AWS는 Region과 Availability Zone 으로 이루어짐

Region

• 전 세계에서 데이터 센터를 클러스터링(그룹화) 하는 물리적 위치
• 어떤 지역으로 서비스 하느냐에 따라 지리적으로 가까운 Region 선택

Region code

• Region Code로 구분 가능
• AWS는 Region 단위로 서비스 된다
• Resource는 Region 내 AZ 단위로 배포 됨

Availability Zone

• Region 내 물리적을 분리된 전력 네트워킹 장치가 분리된 영역
• 보통 AZ 별 데이터센터가 분리된 구조

AZ간 구성

• Region은 보통 2~3개 AZ로 구성
• 동일 Region 내 AZ는 전용 광 네트워크로 구성되어 매우 낮은 지연속도와 높은 처리량 보장
• Az 간 모든 데이터 트래픽은 기본 암호화

AZ 분산 배치

• 동일 AZ 내 모든 인스턴스를 배치하는 경우 AZ 장애 발생시, 본인이 구축한 서비스도 장애로 이어질 수 있음
• 동일 역할을 수행하는 인스턴스의 경우, AZ를 분산 배치하여 서비스 가요성을 높이는 것이 좋음

(2) AZ / VPC

• Region - VPC 와 맵핑
• AZ - Subnet 맵핑

VPC 구성

• Public Subnet: 외부 통신용
• Private Subnet: Public과 Private간 연동용

AZ별 Subnet 구성

• 각각의 Subnet을 AZ 수 만큼 생성
• Total Subnet 수 = AZ Count x 용도별 Subnet
• 인스턴스 생성시 각각에 맞는 Subnet 선택 후, AZ별로 분산 구성

AZ 장애 발생 시

• 동일 용도의 인스턴스 및 서비스 set가 다른 AZ에 구성되어 있으므로 가용성을 높일 수 있음

(3) Load Balancer

• 인입되는 트래픽을 특정 알고리즘 기반으로 다수의 서버로 분산 시켜주는 장비

(4) ELB

• Region 내 인스턴스 및 다양한 서비스로 트래픽 분배 서비스
• 다수의 AZ으로 트래픽 분배
• HTTP/S 웹 기반 트래픽, TCP/S 프로토콜 기반
• 고가용성 기반 L4 / L7 서비스
• AZ 분산 및 트래픽 증가 => 자동 Scale-out 기능 지원

Scale-out

• 트래픽 증가시 서비스에 투입되는 서버를 증설하여 각 서버가 처리하는 부하를 낮추는 방식
• Web based 서비스의 경우 많이 사용하는 구성으로 세션이나 Data 처리 영역 없이 Stateless(무상태) 한 서버에서 주로 사용

Scale-in

• 트래픽 감소시, 배포된 서버를 제거하는 방식
• 낭비되는 리소스를 줄임으로 비용 최적화가 목적임

ELB 알고리즘

• Roud Robin
• Hashing
• Weighted RR
• Least Connection
• Weighted LC

NLB, ALB

• Load Balancer : 인입되는 트래픽을 특정 알고리즘 기반으로 다수의 서버로 분산 시켜주는 장비
• NLB : L4 Load Balancer, TCP/UDP
• ALB : L7 Load Balancer, HTTP/HTTPS

ELB 헬스체크 기능

• 주기적으로 서버가 정상 상태인 확인함
• 서버가 정상 상태가 아니면 트래픽을 전달하지 않게 하는 기능
  • NLB: TCP/UDP Port Alive Check
  • ALB: URL 기반 응답체크

ELB AZ 분산배치

• 활성화된 AZ 에는 Load Balancer 노드가 자동으로 생성되어 배치
• 기본적으로 해당 AZ에 배치된 인스턴스는 해당 AZ의 Load Balancer 노드가 트래픽을 처리

Cross-Zone Load Balancing

• 교차 영역 로드 밸런싱이 활성화 되면, Load Balancer가 위치한 AZ와 상관없이 타겟 AZ에 있는 모든 인스턴스에 트래픽 라우팅 가능함
  • ALB는 Cross-Zone LB가 기본 활성화 상태
  • NLB는 기본 비활성 상태

Cross-Zone Load Balancing 비활성화

• 교차영역 로드 밸런싱이 비활성화 상태이면, 로드밸런서 노드가 위치한 AZ에 상주하는 타겟 인스턴에게만 라우팅 가능
• AZ에 위치한 인스턴스 마다 균일한 부하 분산이 어려움

(5) Auto Scaling Group

• 인스턴스 증가 작업을 자동으로 수행함
• Scaling을 자동으로

Lauch Template

• 인스턴스를 배포하기 위한 정보들의 묶음
• 기본정보를 보여줌
• 추가 정보를 미리 Template으로 정의 가능
• 사용자는 Template을 그대로 인스턴스로 배포하는데 사용
• Launch Template, ELB, Auto Scaling Group으로 구성

AWS 모니터링

모니터링

• 데이터를 수집, 분석, 사용하는 행위

• 모니터링 목적

  • IT 리소스 및 시스템에 대한 여러가지 질문의 답 산출 및 의사 결정
    • 매일 몇 명 사이트 방문?
    • 시간 경과에 따른 방문자 수 추적
    • 웹 사이트 성능, 가용성 문제가 있는지?
    • 인스턴스 용량이 부족한지?
    • 사이트가 정상 동작 하는지?
      => 리소스 과다 사용, 애플리케이션 결함, 리소스 구성 오류, 보안 이벤트로 운영 문제 감시 가능함

모니터링의 이점

1) 최종 사용자가 운영 문제를 인식하기 전에 사전에 대응할 수 있음

• 빠른 인식

2) 리소스의 성능 및 안정성을 개선할 수 있음

• 병목현상, 비효율적 아키텍처 확인 가능

3) 보안 위협 및 이벤트 인식

• 모니터링시 시간이 지남에 따라 기준선이 생겨 이상현상을 발견을 할 수 있음

4) 비즈니스를 위해 데이터 중심의 의사결정을 수립할 수 있음

5) 비용 효율적인 솔루션을 구축

• 사용량이 부족한 리소스 확인, 사용량에 맞게 조정하여 비용 최적화할 수 있음

메트릭(Metric)

• 리소스가 생성하는 다양한 형태의 데이터 중 모니터링을 통해 수집된 데이터 (지표)
  ex) 시간 경과에 따라 EC2 인스턴스에서 수집, 분석 되는 메트릭
  • 평균 CPU 사용률
  • 네트워크 사용률
  • 디스크 성능
  • 메모리 사용률
  • 각종 로그

메트릭의 다양성

• AWS 리소스 마다 다른 유형의 메트릭을 가짐

• 리소스, 목표, 상황에 따라 다양한 메트릭이 존재함

  • Amazon S3 버킷
    • CPU 사용률은 없음
    • 버킷에 저장된 객체와 관련된 메트릭 (버킷 내 객체 수, 용량)
    • 버킷에 대한 요쳥과 관련된 메트릭 (버킷을 읽기, 수정)
  • Amazon RDS
    • 데이터베이스 연결
    • CPU 사용률
    • 디스크 공간 소비

  Trobleshooting Process

• Detect => Identify => Fix => Verify

  MTTI: 문제를 인식하여 원인을 파악하기 까지의 시간 (Detect ~ Identify)

  모니터링 솔루션

• 리소스의 운영상태 및 사용량에 대한 데이터를 수집하고 분석하는 방법이 필요

• 중앙 집중식 모니터링 필요

• 데이터 가시성 확보 필요

• ex) AWS CloudWatch 등

AWS CloudWatch

• AWS 리소스 및 애플리케이션을 관측하고 모니터링 하는 도구
• 수행 작업
  • 환경에서 이상 동작 감지
  • 알림를 설정
  • 로그 및 메트릭을 시각화
  • 크기 조정같은 자동화 작업
  • 정상으로 유지하기 위한 인사이트

CloudWatch 구조

• CloudWatch Dashboard
  • 메트릭 정보를 그래프로 시각화
• CloudWatch 메트릭
  • 리소스 성능 확인
• CloudWatch Insight
  • 가시성 확보
• CloudWatch Log
  • 서비스 로그들을 수집, 저장, 탐색, 분석
• CloudWatch Alarm
  • 이벤트를 사용자에게 알림
• CloudWatch Event
  • 변경사항에 관한 기록
• CloudWatch Service Lens
• CloudWatch Synthetics

CloudWatch Dashboard

• 리소스와 애플리케이션의 메트릭 및 경보 시각화
• 원하는 메트릭 정보만 모아 대시보드를 생성할 수 있음
• AWS 계정에 공유되고 있는 애플리케이션을 모니터링하고 문제를 해결 가능
• 애니메이션 대시보드를 통해 메트릭 데이터를 재생하여 가시성 확보
• AWS 계정이 없어도 대시보드 공유 가능

CloudWatch Alarm

• 이벤트 및 메트릭 변경에 대한 경보 제공

• 3가지 알람 상태 (OK / ALARM / INSUFFICIENT_DATA)

• 경보 생성 가능 유형

  • 메트릭 경보: 정해진 기간 동안의 값을 계산하여 트리거
    ex) CPU 사용량이 5분 60% 초과시 경고 발생

  • 복합 경보: 다른경보 상태 확인 후 모든 조건 충족 시 트리거
    ex) CPU, 메모리, 스토리지 경보가 동시에 경고이면 경고 발생함
    => 경고 노이즈 감소 효과, EC2 작업이나 Auto Scaling 작업 트리거 불가함

CloudWatch Metric

• 리소스 성능 관련 메트릭 확인 가능
• 기본 5분 주기 메트릭 제공 (1분 주기는 유료)
• 메트릭 보존
  • 1분(15일), 5분(63일), 1시간(455일)
• 맞춤형 메트릭 수집 가능
• 운영상태, 메트릭 필터링, 수집, 시각화를 지원함
• 메트릭 값
• CloudWatch에서의 통계 값
  ex) Minnimun, Maximun, Sum, Average, SampleCount

CloudWatch Log

• AWS 로그 파일을 중앙 집중화 하여 저장 및 접근함
• 보관은 무기한함 (1일 ~ 10년 변경 가능)
• 이벤트 내 특정 메시지, 오류 검색 가능함

CloudWatch Insight

• 가시성으 확보해주는 서비스
  • Container Insights: 컨테이너 앱 모니터링
  • Lambda Insights: 서버리스 앱 모니터링
  • Contributor Insights: 영향을 미치는 사람이나 대상을 모니터링
  • Application Insights: 앱 모니터링 및 대시보드 제공

CloudWatch 기본 관리구조 용어

CloudWatch 에이전트

• AWS 내외 시스템의 정보를 수집하여 메트릭으로 보내기 위한 구성요소
• CloudWatch 에이전트를 사용하면 사용할 수 없는 추가 메트릭을 수집 가능함
  • Windosw 서버: 카운터와 연결된 메트릭을 수집 가능
  • Linux 서버: 메모리, CPU, 디스크 공간 등 메트릭을 수집 가능

CloudWatch Metric 네임스페이스

• CloudWatch 메트릭들의 묶음
• AWS 서비스 관련 네임 스페이스
• CloudWatch 에이전트가 수집한 데이터
  • 기본 네임스페이스는 "CWAgent"를 사용
• 사용자 지정 메트릭
  • 기본 네임스페이스가 없음

Metric Deimension(차원)

• 메트릭을 고유하게 식별할 수 있도록 하는 이름과 값의 페어
  • 메트릭들에 속한 여러 특성 중 일부
  • 메트릭에 최대 30개 차원 할당
  • 이름, 네임스페이스 및 여러 차원 등을 활용하여 식별 가능함

로그 이벤트

• 모니터링 중인 응용 프로그램 또는 리소스에 의해 기록되는 일부 활동의 기록
• 타임스탬프와 이벤트 메시지

로그 스트림

• 특정 소스의 로그 이벤트
• 인스턴스 또는 리소스와 관련한 이벤트

로그 그룹

• 동일한 보존, 모니터링 및 에세스 제어 설정을 공유하는 로그 스트림 그룹
• 로그 스트림은 로그 그룹에 속해야 함