2-모듈4 고가용성 설계

모듈 목표

가용성 내결함성 및 확장성의 의미 정의, 클라우드 아키텍처에서 어떻게 이 의미들이 사용되는지

단일 장애 지점 제거 방법

어느 서비스가 내결함성 기본 제공하는지 파악

어느 AWS 서비스에서 내결함성을 설계할 수 있는지 파악

로드 밸런싱이 핵심 아키텍처 구성 요소가 된 이유를 설명

 

1.확장성

확장성: 리소스 크기를 늘리거나 줄이는 능력

클라우드의 탄력성을 최대한 활용할 수 있어야 한다.

자동화된 인프라 조정이 AWS 클라우드에서 워크로드를 실행하는 가장 큰 이유이디.

클라우드 기반 아키텍처의 핵심 이점은 리소스의 수요 변화에 신속하게 대응할 수 있는 능력이다.

Amazon CloudWatch : 모니터링 솔루션 --> 로드 임계값에 도달했는지 탐지하여 경보 전송

사용자의 특정 애플리케이션을 기반으로 사용자 지정 지표를 설계할 수 있다.

경보가 트리거 되면 Auto scaling 이 즉시 새 인스턴스를 시작함

수직 확장 --> 더 강력한 하드웨어를 사용하는 것

인스턴스의 사양을 변경한다. 워크로드가 증가함에 다라 메모리 및 cpu 추가

제한 존재함

수평적 확장 --> 인스턴스 수를 변경하여 신속하게 확대 축소

제한이 존재하지 않으나 이를 최대한 활용할 수 있도록 설계하는 것이 중요하다

 

2. 조정이 필요한지 아는 방법

 

AWS를 효율적으로 사용하기 위해서 AWS 리소스에 대한 통찰력이 필요하다.

a. 인프라에서 실제로 사용되는 부분이 어느정도인지

b. 용량이 충분하지 않아서 애플리케이션 성능에 영향을 주지는 않는지

 

Amazon CloudWatch

--> 인프라를 모니터링 할 수 있다.

인스턴스를 모니터링하여 원시 데이터 수집하고 읽을 수 있음

지정한 지표보다 트래픽이 넘어가면 Auto scaling 작업을 trigger함

Elastic Load Balancing 로드 밸런서는 Amazon Ec2 인스턴스로 트래픽을 전송하고, CloudWatch에도 지표를 

전송하여 지표가 임계값을 넘는지 확인한다.

 

분산 통계 수집 시스템 --> 지표를 수집 및 추적

클라우드 리소스와 애플리케이션에 대한 모니터링 서비스

로그 파일을 수집 및 모니터링하여 경보 설정 가능

사용자 자체 애플리케이션 및 서비스에서 생성된 데이터 기반 사용자 지정 지표를 생성하고 사용한다.

CloudWatch로 시스템 전반 리소스 사용, 애플리케이션 성능, 운영 상태를 가시화할 수 있다.

 

CloudWatch는 IAM(Identity and Access Management)과 통합되어 있습니다.

ex) 조직의 특정 사용자에게만 GetMetricStatistics 작업 권한을 부여 가능, 이 작업을 통해

클라우드 리소스에 대한 데이터를 가져온다.

 

**IAM을 통해 부여된 권한은 CloudWatch와 함께 사용하는 모든 클라우드 리소스에 적용된다.

즉 특정 리소스의 CloudWatch 데이터에 대한 액세스 제어는 IAM을 사용할 수 없다.

 

통합 CloudWatch 에이전트는 클라우드 및 온프레미스에서 Linux 및 Windows 인스턴스/서버 상에서 실행됩니다. 또한 지표 및 로그 파일을 처리합니다. 이 에이전트는 AWS Systems Manager, Run Command, SSM State Manager 또는 CLI를 사용하여 배포할 수 있습니다.

 

경보가 발생하면 Auto Scaling 정책을 실행 --> 운영 팀에 알림 전송등등의 작업 시작

 

단일 지표 기반의 CloudWatch는 위와 같은 일을 할 수 있다.

SNS -- 관리자가 상황을 파악할 수 있도록

 

-클라우드 설계 패턴

시스템 운영하기 위해 모니터링은 필수이다

AWS 클라우드에서의 모니터링 서비스 --> 가상 서버의 내부 작업(운영체제, 미들웨어, 애플리케이션)을

모니터링할 수 없다. 따라서 독립적인 모니터링 시스템을 구축해야 한다.

 

모니터링 서비스를 구현

CloudWatch 모니터링 서비스로부터 모니터링 정보를 얻을 수 있도록

Amazon EC2 인스턴스에 모니터링 소프트웨어를 설치합니다.

 

• Nagios, Zabbix, Munin과 같은 모니터링 소프트웨어를 설치합니다.

• 플러그인을 사용하여 CloudWatch API를 통해 모니터링 정보를 가져오고,

해당 정보를 모니터링 소프트웨어에 씁니다.

• 그리고 이 플러그인을 사용하여 모니터링을 수행합니다(AWS의 정보 포함).

 

CloudWatch logs 사용

AWS CloudWatch Logs를 사용

-->데이터 처리를 위한 로그를 stream으로 보내기

-->내구성을 위한 로그를 S3 버킷으로 보내기

-->관리자 콘솔에서 직접 액세스 가능

위 기능들 사용 가능

 

로그는 Amazon Kinesis Streams 또는 AWS Lambda와 같은 데이터 처리 솔루션으로

실시간으로 스트리밍될 수 있다.

평소에는 24% 정도의 리소스만 필요해서 나머지 76%의 리소스는 사용되지 않는다.

그러나 아마존의 블랙 프라이데이 등의 행사때 엄청난 양의 트래픽이 몰린다.

따라서 AWS가 없을 때는 트래픽이 엄청나게 올라가는 경우를 대비하기 위해

평소에는 사용하지 않더라도 필요한 데이터 센터를 추가했다.

AWS에 Auto Scaling을 이용하여 위 같은 상황을 해결해보자

애플리케이션 수요가 증가하고 감소할 때 인스턴스를 시작 종료 가능하다.

위 설정을 해놨을 경우 새 인스턴스가 자동으로 Elastic Load Balancing 로드 밸런서에 등록된다.

이 서비스는 모든 가용 영역에서 사용 가능하다.

 

Auto scaling 은 Elastic Load Balancing과 통합된다. 따라서 하나 이상의 로드 밸런서를 기존

Auto scaling 그룹에 연결 가능하다. 

 

리소스 요구 사항을 추측하는 것은 옳지 않다. 예측 보다는 어떻게 대응해야 할지에 초점을 두어야 한다.

위 구조도에서 웹 서버 계층 구성을 살펴보자

데이터베이스 서버가 2개이다. 하나는 기본 서버이고 다른 하나는 대기 모드 서버이다.

CloudWatch가 경보를 트리거 하면 서버가 늘어난다. (늘어난 트래픽을 감당하기 위해)

 

Auto scaling: 제약을 걱정할 필요 없음

필요에 따라 새 리소스를 생성할 수 있는 기능을 제한하지 않도록 설정 가능하다.

방법: API 스크립트 및 Auto scaling을 사용하면 된다.

 

Auto scaling 작동 방식

1. 시작 구성 --> "무엇을" 자동 조정할지 설정

Amazon EC2 인스턴스를 시작하는 방법을 정의한다.

2. Auto scaling 그룹 --> "어디에서" 서버를 시작할지 결정

어느 가용 영역에서 시작할지, Auto sacling이 액세스해야 하는 서브넷, 시작 구성의 이름, 원하는 용량등을

결정

3.Auto scaling 정책 --> "언제" 서버를 시작할지 결정

어떠한 조건에 인스턴스가 시작하고 종료할지를 명시

단순 조정 정책 : 현재 용량을 단일 조정에 따라 늘리고 줄임

단계 조정 정책 : 단계에 따라 그룹의 용량을 조절

 

로드 밸런서에 Cloudwatch가 지정된다.

Cloudwatch가 지연 시간을 추적하고 경보를 트리거 한다.

그러면 알림을 전송하고 Auto scaling 정책을 실행한다.