Cloud High Availability

 

국민대학교에서 "클라우드 컴퓨팅" 교과목을 진행하시는
이경용 교수님의 강의 교안을 이용하여 수업 내용을 정리하였습니다

 

 

 

AWS High Availability (고가용성)

 

Fault-tolerance와 Scalability 관점에서 살펴보자

 

 

고가용성 (High Availability)란?

 

서비스를 운용하는 사람이 관리를 하지 않아도 서비스가 동작하지 않는 시간을 최소화해서 사용자에게 예측된 성능을 제공해줄 수 있는 척도

 

고가용성의 구현 요소들

 

Fault tolerance

 

• 응용예제 자체에서 문제가 발생시에도 사용자에게 영향을 전파하지 않는 능력
  
  => fault가 failure가 되지 않게
  
  
• 백업 서버의 구동 등

 

Scalability

 

• 시스템의 디자인을 바꾸지 않고도 증가하는 요청을 처리할 수 있는 능력

 

사용자 보유 데이터 센터와 클라우드에서 가용성

 

사용자 보유 데이터센터

 

• 많은 경비 소요 (하드웨어 구매 등)
• 중요한 일부 서비스에 대해서만 고가용성 확보

 

클라우드 서버에서 고가용성 확보 방안

 

• 여러대의 서버
  
  
• Region 안에 여러 AZ를 활용
  
  
• 여러 Region을 활용
  
  => 관리가 너무 어려움
  
  
• 서비스 자체에 내재된 fault-tolerant 기능 활용 (fully-managed service)

 

반드시 여러 Region에서 서비스를 해야하는게 아니라면, 하나의 Region에서 서비스를 시작하고 최소한 여러 AZ 를 사용하는게 이상적임

=> 여러 Region을 활용하면 가용성이 높아지지만 더 많은 경비가 소요되고 시스템이 복잡해질 수 있음

 

 

AWS 제공 서비스들의 고가용성 특성

 

AWS가 고가용성을 제공 (Fully managed service)

 

=> 클라우드 벤더가 알아서 해줌

 

Amazon S3 and Amazon Glacier, Amazon DynamoDB, Amazon CloudFront, Amazon Route 53 등이 있음

 

사용자가 고가용성을 위해서 시스템 구축을 해야하는 서비스 (unmanaged service)

 

Amazon EC2, Amazon VPC, Amazon Redshift 등

 

(EC2 서버를 키기만 했다고 고가용성을 보장하지 않음)

 

AWS Managed 고가용성 서비스 - AWS Load Balancer

 

여러 AZ 사이에 배포된 EC2 인스턴스로 사용자 요청을 배포해주는 역할 담당

 

=> AWS EC2 인스턴스의 건강상태 (health check)를 주기적으로 체크하여 정상 동작하지 않는 인스턴스들의 부하 상태 및 동작 상태를 고려하여 요청 분배

 

(ping을 통해 health check)

 

하나의 AZ 또는 여러 AZ에 걸쳐서 요청의 전달이 가능하지만 여러 지역은 전달 불가능

 

=> DNS서비스인 Route 53을 이용하면 여러 지역으로 요청 분배 가능

 

LoadBalancer 종류

 

Application Load Balancer

 

• OSI 7계층에서 Application 단에서 동작함 (http, https 등)
  
  
• 컨텐츠 기반 라우팅을 가능하게 해줌
  
  ex. HTTP 경로에 따른 라우팅으로 다른 경로의 서비스들이 다른 서버 호스트에 의해서 제공될 수 있음

 

Network Load Balancer

 

• OSI 7 계층에서 Transport 단에서 동작
• TCP, UDP에 기반한 라우팅
  
  ex. 같은 응용 서비스를 제공하는 여러 인스턴스를 두고 이중 임의의 응용 서버에 요청 전달

 

Gateway Load Balancer

 

• Inbound traffic에 대한 단일 진입 점을 제공함으로 보안 서비스 (심층 패킷 검사 등)를 구축 가능하게 해줌
  
  (이를 이용해 외부 보안 솔루션을 붙여서 사용 가능함)

 

AWS Load Balancer Sticky Session

 

Sticky 세션 단점을 극복하기 위한 분산 캐쉬

 

 

Sticky 세션은 사용자의 요청 또는 세션이 특정 인스턴스에 바인드 되어 다른 인스턴스로 향하지 못하도록 해주는 기능을 제공

 

• Sticky 세션이 동작하지 않는 것이 기본이며, Sticky 세션이 동작하지 않을 경우 가장 작은 부하를 가지고 있는 서버로 요청을 전달 
• 세션 정보를 유지하고 있어야 하는 경우 사용하면 좋음 (stateful)
  
  
• 쿠키를 통해서 로드밸러서 서비스가 특정 인스턴스로 요청 전달

 

Sticky 세션의 단점

 

 

응용 프로그램의 확장성을 제한할 수 있음 (state를 지켜야 하는 제약 사양 존재)

불공평한 부하 처리 부담이 발생할 수 있음

 

나쁜 사용자 경험 (오랜 처리 시간) 발생 가능

 

Sticky 세션 단점을 극복하는 방안

 

 

세션 정보를 빠른 읽기를 지원하는 분산 저장소를 활용하는 것이 좋음

 

=> 분산 캐쉬, NoSQL 서비스 (AWS DynamoDB 등)

 

 

Elastic Load Balance를 활용한 시스템 안정성 발전 예

 

 

 

Load Balancer 와 TLS/SSL Termination

 

HTTP 규약을 활용하여 서버와 클라이언트간 통신 중 plain text로 전송되면 중요 정보가 유지 될 수 없는 정보들을 전송할 때 이를 클라이언트 단에서 암호화해서 송신하고 서버단에서 복호화 하여 처리하는 방법

=> http 통신은 패킷 까면 plain text가 다 보임 (id, pw 쓰면 안됨)

 

 

TLS / SSL Termination

 

클라이언트와 서버간의 통신 중에 암호화되어 도착한 사용자 데이터를 복호화 하여 plain text 형식의 데이터로 변환하는 과정

 

EC2 서버 환경에서 Termination 가능한 단계

 

Load Balancer : ELB가 복호화 한 후 VPC 내의 Private network를 통해서 EC2로 전달

EC2 : 데이터가 암호화 된 채로 ELB를 통해서 EC2로 전달 된 후 EC2에서 복호화

 

보안 요구 사항과 LoadBalancer 선택

 

ELB 단에서 termination

 

 

• EC2의 자원을 다른 용도로 활용 가능
  
  
• 효율적인 자원 활용
  
  
• EC2 서버가 많을 경우 관리 오버헤드가 줄어듬
  
  
• 요구하는 보안 조건이 end-to-end 암호화를 강제한다면 EC2에서 복호화 해야함
  (Load Balancer 에서 EC2로 가는 데이터는 암호화 되지 않기에)
  
  

Application load balancer 에서는 반드시 TLS/SSL termination 을 수행해야 함

 

=> Application load balancer는 복호화 후 header 정보를 확인 후 요청을 라우팅함

 

End-to-End encryption이 필수여서 EC2 단에서 복호화가 이루어져야 한다면 Network load balancer를 사용하고 TCP 프로토콜을 사용해야 함
(트래픽이 중간에서 해독되지 않아야함)

=> HTTPS 사용 불가 
(HTTPS는 ALB에서 해독되므로 End-to-End 암호화가 깨질 수 있으니 TCP 사용)

 

UDP는 연결을 추적하지 않기 때문에 TLS/SSL Termination을 당연히 수행할 수 없음

 

 

Azure Managed 고가용성 서비스 - Load Balancer

 

 

 

AWS Load Balancer와 대응 되는 서비스임

 

=> 백엔드 리소스 및 서버들에 트래픽을 고르게 분산시키는 서비스

 

Public, Private 2가지로 나뉨

 

 

GCP Managed 고가용성 서비스 - Load Balancing

 

AWS Load Balancer에 대응되는 서비스임

 

=> 트래픽을 여러 VM에 분산

 

AWS Elastic IP

 

고정 IP 주소로 사용자는 임의의 인스턴스에 IP를 할당해줄 수 있음

 

• 동작중이던 인스턴스가 문제가 발생하여 종료될 경우 Elastic IP를 활용하면 새로운 인스턴스를 시작 후 같은 IP를 할당해줄 수 있음
  
  => EC2의 기본동작은 새로운 인스턴스가 시작하면 새로운 IP를 할당 받게 됨

 

 

 

=> 동작중인 App 서버가 문제가 발생하더라도 Elastic IP를 새로운 인스턴스에 할당해 줌으로 인스턴스의 문제를 숨길 수 있음
(고가용성의 방법으로도 쓰임)

 

Azure Static Public IP

 

 

NIC에 고정 IP 주소를 할당해줄 수 있음

 

=> 서버가 문제가 발생해서 종료된다면 해당 NIC를 다른 서버로 할당해줄 수 있음

(새로운 서버는 할당 받은 NIC로 별도의 네트워크 설정 없이 사용 가능)

 

GCP Static Public IP

 

 

AWS Elastic IP와 같은 원리임

 

 

AWS에서 Region 사이에서의 고가용성 보장

 

Region 내의 여러 AZ에서의 부하 분산 : Load Balancer

 

Region 사이에서의 부하 분산 : Route53

 

 

=> Route53은 Fully-managed DNS 서비스임
(DNS query는 UDP port 53을 이용)

 

Amazon Route53

 

안정성 (reliable)

• 여러지역에 백업시스템 구동 중
• AWS 서비스중 가장 높은 가용성을 보장해줌

 

빠른 응답 속도

 

• 전세계에서 서비스가 배포되고 서비스 되고 있음
• 새로운 변화에 대한 빠른 배포

손쉬운 사용

 

• AWS 콘솔 및 프로그래밍  API를 활용한 레코드 등록 가능

다양한 Resolve 기법 지원

 

• Latency-based, geolocation, weighted round-robin

 

Route53 DNS Resolve 라우팅 기법

 

Simple routing

 

하나의 서버만 있을 경우 해당 서버의 IP 주소로만 resolve 

 

 

Weighted Round Robin

 

여러대의 서버가 있을 경우 각 서버에 가중치를 부여 후 가중치 값에 기반하여 IP resolve 작업이 실행됨

 

=> A/B 테스팅에도 활용될 수 있음 (새로운 binary의 테스트)

 

A/B 테스트는 두 가지 이상의 버전 (A 와 B) 중에서 어느 것이 더 나은 성과를 내는지 비교하는 실험 방식임

=> 일부 사용자에게 A버전 다른 사용자에게 B 버전을 보여주고 분석

새로운 binary 테스트란 업데이트된 실행 파일(바이너리)를 배포하고 그 성능이나 안정성을 검증하는 과정

=> 일부 서버에 먼저 새로운 버전을 배포하여 안정성 테스트

 

Latency-based routing

 

글로벌에 위치해 있는 사용자가 있을 경우 접근이 가장 빠른 서버로 resolve

 

Health checks and DNS Failover

 

마스터 서버에 문제가 발생시에 미리 등록되어 있는 백업 서버로 resolve

 

Geolocation routing

 

특정 나라, 대륙, 또는 지역의 서버만 resolve 되도록 하는 방법

 

=> 컨텐츠가 특정 지역에서만 제공됨을 강제해야할 때 사용됨

 

AWS Route53를 활용한 Multi-Region 배포

 

 

 

us-west-2로 가는 요청을 Latency-based Routing 을 통해 접근이 더 빠른 ap-southeast-2로 보냄

 

AWS Route53를 활용한 Primary-Secondary 배포 예제

 

 

 

Chaos Engineering : 클라우드 맹신하지 않고 일부러 실패 시나리오를 주입하여 대응하는 방식

 

 

Azure DNS

 

AWS Route53에 대응되는 서비스

 

=> Azure 인프라를 사용하여 DNS 호스팅 서비스 제공

(Route 53과 달리 도메인 이름을 구매 할 수는 없음)

 

Azure Multi-Region 배포

 

 

GCP Cloud DNS

 

AWS Route53에 대응하는 서비스로 도메인 및 DNS 레코드를 호스팅하고 관리함

 

 

시스템의 고가용성 확보 - Scalability

 

 

 

 

시스템의 확장성 확보 방안

 

Vertical Scaling

 

 

• Sacle up and down
  
  
• 인스턴스의 하드웨어 스펙 변경
  
  
• ex. 메모리 증가, 디스크 증가 등

 

Horizontal Sacling

 

• Sacle in and out
  
  
• 인스턴스의 개수 변화
  
  
• 인스턴스 개수 증가 또는 감소 시킴

 

시스템 확장이 필요한 시기의 판단

 

클라우드 자원이 어떻게 활용되고 있고, 사용자의 경험이 어떤지에 대한 데이터 필요

 

• 서비스의 컴퓨팅 자원 활용량 (CPU, 메모리 사용량)
  
  
• 사용자의 서비스 상태 (응답 시간, 400 번대 응답 비율, 500 번대 응답 비율)
  
  
• 사용자의 경험이 자원의 부족으로 인해서 영향을 받고 있는가?
  
  
• 추측에 의한 시스템 확장 자제

 

시스템의 동작 상태 모니터링 - Amazon CloudWatch

 

 

인스턴스의 상태를 관찰하여 실시간으로 정보 제공

 

=> 여러 클라우드 서비스들이 상태 정보를 보내줌

 

수집된 정보를 활용한 통계 및 알람 제공

 

=> AWS가 기본으로 제공해주는 통계 및 사용자 지정 통계 생성 가능
(다른 서비스와의 연동이 우수함)

 

설정된 기준에 따라서 Auto Scaling을 가능하게 해줌

=> 높은 CPU 사용량, 높은 응답시간, 에러 발생율등의 알람을 통해 AutoScaling에 이벤트를 등록해놓고 자동화

 

CloudWatch Logs를 활용한 응용 프로그램의 로그 수집

 

 

응용 프로그램의 로그 메시지를 CloudWatch에 저장

 

• AWS 콘솔을 통한 실시간 읽기 가능
  
  
• Batch Processing을 위해 S3에 추가 저장 가능
  
  
• 스트림 프로세싱 시스템 (Amazon Kinesis)을 활용한 실시간 처리 가능

 

자율적인 인스턴스 관리 - AutoScaling

 

 

 

amazon.com 웹페이지의 전형적인 요청 횟수 패턴

 

=> 낮에 사용량 많고 새벽에 적음

 

또한 11월에 BlackFriday나 Cyber Monday의 접속량을 보면 다른 날들에 비해 급등함

 

=> 특정 시기에 발생 가능한 사용량의 급속적인 증가를 예측하는 것은 어려움

 

AWS AutoScaling

 

CPU 활동량이 높아지는 특정 조건을 만족하는 경우 EC2 인스턴스를 자동으로 시작/종료하게 해줌

 

로드밸런서와의 연동성이 좋음

 

• AutoScaling에서 시작/정지된 인스턴스는 로드밸런서에 자동으로 반영됨
  
  
• 인스턴스 시작 후 사용자 요청은 자동으로 전달됨

 

여러 AZ에 걸쳐서 인스턴스를 시작할 수 있음 (고가용성 측면에서)

 

사용자 지정 메트릭을 활용한 scale-out 과 scale-in 여부 결정됨

 

=> ex. 평균 CPU 사용량이 80% 이상일 때 서버 추가, 주중 7시에 서버를 새롭게 추가

(CloudWatch 안쓰면 지표에 의한 이벤트는 사용 못함 시간이나 인스턴스 생존 상태 등을 통한 이벤트만 가능)

 

AWS EC2 Scaling 방법

 

 

 

 

Auto Scaling 그룹 : 자원의 스케일링을 자동으로 하고자 하는 인스턴스 그룹

 

=> Minimum, Maximum, Desired (default) 인스턴스 개수 설정 가능

 

 

AWS AutoScaling 사용 예제 및 동작 차례

 

 

 

 

CloudWatch, Elastic Load Balancing 과 AutoScaling

 

CloudWatch가 ELB의 성능지표를 모니터링하고 이벤트를 알람으로 설정 후 AutoScaling

 

 

AutoScaling 그룹에서 인스턴스 개수 확인

 

AutoScaling 그룹에서 설정 가능한 인스턴스 개수

 

• Maximum 개수
  
  
• Minimum 개수
  
  
• Desired 개수
  
  => 이상적으로 동작 되어야 하는 인스턴스 갯수
  (로드가 크지 않으면 최소 인스턴스 갯수만 동작)

 

이상적인 Minimum 개수는?

 

 

주 단위로 일어나는 작업 : 0으로 설정

 

=> 트래픽 패턴이 예측 가능하고 특정 시간대에만 활성화되는 경우, Minimum Capacity를 0으로 설정할 수 있음

 

각 AZ마다 하나의 인스턴스가 항상 동작해야 한다면 : 희망 AZ 개수로 설정

 

인스턴스를 시작하는데 시간이 소요됨을 유의해야함

 

=> warm-up period

(이 시간 동안은 EC2 생성/삭제가 일어나지 않음)

 

이상적인 Maximum 개수는?

 

 

트래픽 패턴이 급격히 변동하는 시스템이라면, maximum은 트래픽이 피크에 도달할 때 필요한 인스턴스 수를 고려하여 설정

 

 

=> 너무 많은면 비용적으로 부담이 될 수 있음

 

AutoScaling 동작의 또 다른 예

 

시나리오 예제

 

• Auto Scaling Group minimum = 2
  
  
• Auto Scaling Group maximum = 10
  
  
• Auto Scaling Policy: 인스턴스 평균 CPU 사용량이 60% 이상이면 현재 인스턴스 수의 100% 추가

평균 CPU 사용량이 60% 가 넘어간다면 인스턴스양을 2배씩 늘림 - 2, 4, 8, 10 (maximum)

 

=> 인스턴스들은 초기에 등록된 AZ 에 고루 분배됨

메트릭 값을 구간으로 분리 후 구간 값에 따라서 인스턴스 조절 가능
(커스터 마이즈 가능)

 

=> ex. 평균 CPU 사용량이 80% ~ 100% 라면 인스턴스 2대 추가, 60~ 80% 라면 1대 추가, 20%
미만이라면 1대 감소

Warm up period : 인스턴스 시작 후 준비되기까지 시간이 소요되기에, 새로운 알람이 발생하더라도
시작중인 인스턴스는 동작중인 것으로 판단 함

 

 

Azure Virtual Machine Scale Sets (VMSS)

 

 

AWS Auto Scaling에 대응되는 서비스임

 

GCP Instance Group AutoScaling

 

단일 항목으로 관리할 수 있는 VM 모음

 

관리형 인스턴스 그룹과 비관리형 인스턴스 그룹으로 나뉘는데

 

비관리형 인스턴스 그룹

 

• 인스턴스들의 논리적 묶음
  
  
• Load Balancer 연결 가능

(소규모 환경이나 특수한 요구 사항에 맞출 때)

 

관리형 인스턴스 그룹

 

• Failover 기능 제공
  
  
• 다양한 VM 배포 옵션 및 자동 확장 기능 제공

(고가용성이 필요할 때)

 

관리형 인스턴스 그룹(MIG)는 Stateless 와 Stateful로 나뉨

=> Stateful에서는 로드밸런싱, AutoScaling이 불가능함
(해당 노드로 가더라도 특정 정보가 없으면 처리를 못하니까)