6. AWS 고가용성 환경

1. 확장 대응

 

1.1. 아키텍처 확장

 

-  아키텍처는 변화하는 수요를 처리할 수 있어야 함

 ㅁ  위 안티패턴(설계가 적절하지 못한 시스템의 예)에서는 조정이 수동적 및 반응적으로 수행

 ㅁ  애플리케이션 서버는 최대 용량에 도달

 ㅁ  여유 용량이 없으므로 사용자는 애플리케이션에 액세스하지 못하고 있음

 ㅁ  관리자는 서버가 완전 가동중인 것을 발견하고 로드를 분담하기 위해 새 인스턴스 시작

 ㅁ  신규 인스턴스를 시작한 후 사용할 수 있게 될 때까지 몇 분 정도가 걸리므로, 그 시간 동안 사용자가 애플리케이션에 액세스 하지 못함.

 

1.2. 아키텍처 확장- 모범 사례

 

-  모니터링 솔루션(Cloud Watch 등)은 서버 집합 전체의 총 로드가 지정된 로드 임계값에 도달했는지 탐지

-  정보가 트리거 되면, Amazon EC2 Auto Scaling이 즉시 새 인스턴스를 시작

-  최대 용량에 도달하기 전 이 인스턴스가 준비되어 사용자에게 원할 한 경험 제공

 

1.3 Scale-Up & Scale-Out

 

-  수직적 조정(Scale-Up)

 ㅁ  워크로드가 증가함에 따라 메모리와 CPU 추가

 ㅁ  Java 애플리케이션 실행 시 메모리 추가(Java 힙 증가)는 가비지 컬렉션이 실행되는 시간이 길어진다는 의미

 

-  수평적 조정

 ㅁ  제한은 없으나 수평적 조정에 의존할 계획이라면 애플리케이션이 이를 충분히 활용할 수 있도록 설계하는 것이 중요

 

2 Amazon CloudWatch

 

-  인스턴스를 모니터링하고 원시 데이터를 거의 실시간 지표로 읽을 수 있도록 수집하고 처리합니다.

 

-  지정한 지표를 기준으로 알림을 전송하고 Auto Scaling 작업을 트리거합니다.

 

-  Amazon CloudWatch 제공 내용

 ㅁ  분산 통계 수집 시스템: 지표를 수집 및 추적

 ㅁ  기본적으로 하이퍼바이저 수준에서 원활하게 수집되는 지표 (CPU, I/O, Network)

 ㅁ  자체 애플리케이션 및 시스템에서 생성한 데이터에 대한 사용자 정의 지표를 생성 및 사용하는 기능

 

-  Amazon CloudWatch 사용자 정의 지표

 ㅁ  https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html

Publishing Custom Metrics - Amazon CloudWatch

-  Amazon EC2 인스턴스 용 모니터링 스크립트

 ㅁ  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html

Monitor memory and disk metrics for Amazon EC2 Linux instances - Amazon Elastic Compute Cloud

2.1 CloudWatch 경보 예

 

 

2.2. CloudWatch 경보 및 작업

 

 

2.3. CloudWatch 설계 패턴: 모니터링 통합 패턴

 

-  해결할 문제

 ㅁ  시스템 운영에서는 모니터링 필요

 ㅁ  Amazon 클라우드의 모니터링 서비스가 가상 서버의 내부 작업(운영 체제, 미들웨어, 애플리케이션 등)을 모니터링할 수 없으므로 독립적 모니터링 시스템 구축 필요

 

-  클라우드 패턴 설명

 ㅁ  가상 서버 등은 AWS 클라우드 모니터링 서버에서 모니터링

 ㅁ  고객은 별도의 시스템을 사용하여 운영 체제, 미들웨어, 애플리케이션 등을 모니터링해야 함

 

-  구현

 ㅁ  Amazon EC2 인스턴스에 모니터링 소프트웨어를 설치하여 CloudWatch 모니터링 서비스에서 모니터링 정보를 가져오도록 함.

 ㅁ  모니터링 소프트웨어 설치 (Nagios, Zabbix, Munin등)

 ㅁ  플러그인을 사용하여 CloudWatch API를 통해 모니터링 정보를 가져오고, 해당 정보를 모니터링 소프트웨어에 사용

 ㅁ  이 플러그인을 사용하여 모니터링 수행

 

-  클라우드 모니터링 설계 패턴 정보

 ㅁ  http://en.clouddesignpattern.org/index.php/CDP:Monitoring_Integration_Pattern

CDP:Monitoring Integration Pattern - AWS-CloudDesignPattern

2.4. CloudWatch Logs를 통한 애플리케이션 로그 파일 저장 및 모니터링

 

                             

-  지표는 CloudWatch에 CloudWatch Logs로 안정적으로 저장

 ㅁ  관리자 및 기타 관계자는 AWS Management Console에서 직접 CloudWatch 로그 확인 가능

 ㅁ  로그는 Amazon S3에 저장되어 다른 서비스 및 다른 사용자가 액세스 할 수 있음

 ㅁ  로그는 Amazon Kinesis Streams 또는 AWS lambda와 같은 데이터 처리 솔루션으로 실시간 스트리밍 가능

 

-  CloudWatch Logs 자세한 내용

ㅁ  https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html

What Is Amazon CloudWatch Logs? - Amazon CloudWatch Logs

3. Auto Scaling

 

-  지정된 조건에 따라 인스턴스를 시작 또는 종료

-  지정된 경우, 새 인스턴스를 로드 밸

-  밸런서에 자동으로 등록

-  여러 가용 영역에 걸쳐 시작 가능

 

3.1. Auto Scaling 기본 아키텍처

 

-  작업 수행 방법

 ㅁ  API

 ㅁ  스크립트

 ㅁ  Auto Scaling

 

3.2. Auto Scaling 작동 방식

 

- 시작 구성

 ㅁ  Auto Scaling에서 Amazon EC2 인스턴스를 시작하는 방법 정의

 ㅁ  기존 Amazon EC2 인스턴스 속성을 사용하여 새 시작 구성을 생성할 수 있는 옵션 제공

 ㅁ  이 옵션 사용 시 Auto Scaling이 속성을 지정된 인스턴스에서 사용자가 하나 이상의 Auto Scaling 그룹을 시작할 수 있는 템플릿으로 복사

 

-  Auto Scaling 그룹

 ㅁ  Auto Scaling 그룹은 시작 구성을 사용하여 Amazon EC2 인스턴스를 시작

 ㅁ  Auto Scaling이 Amazon EC2 인스턴스를 시작 시 사용할 이미지에 대한 정보를 제공하는 방식으로 시작 구성 생성

 ㅁ  이러한 정보는 이미지 ID, 인스턴스 유형, 키 페어, 보안 그룹, 블록 디바이스 매핑 등이 될 수 있음.

 

-  Auto Scaling 정책

 ㅁ  Auto Scaling 그룹은 정책과 경보의 조합을 사용하여 어떤 조건에 부합하면 인스턴스가 시작되고 종료되도록 할지 결정

 ㅁ  경보는 사용자가 지정한 일정 시간 동안 단일 지표를 주시하는 객체

 ㅁ  지표값이 사용자가 정의한 임계값을 지정된 횟수 이상 초과하는 경우, 경보가 하나 이상의 작업을 수행

 ㅁ  Auto Scaling 지원 정책

    >  단순 조정(Simple Scaling) – 그룹의 현재 용량을 단일 조정 조절에 따라 늘리거나 줄임

    >  단계 조정(Step Scaling) 그룹의 현재 용량을 일련의 조정 조절(단계 조절)에 따라 늘리거나 줄이며 이는 경보 위반의 크기에 따라 달라짐

 

-  예약된 작업

 ㅁ  일정을 기준으로 조정 수행 시 예측 가능한 로드 변화에 대응하여 애플리케이션 조정 가능

 ㅁ  Auto Scaling 그룹이 일정을 기준으로 조정 수행하도록 구성하려면, 예약된 작업을 생성해야 함.

 

3.3 Auto Scaling 정책과 예약된 작업 비교

구분	Auto Scaling 정책	예약된 작업
개요	조정 활동을 수동으로 개시 지표를 기준으로 조정 활동을 개시하도록 CloudWatch를 사용해 동적 조정	미리 조치를 취할 수 있는 사전 지식 (예측 가능한 일정)
파라미터 예시	파라미터 예시 AutoScalingGroupName HonorCoolDown PolicyName	파라미터 예시 ScheduledActionNAme AutoScalingGroupName DesiredCapacity
사용량 시나리오	CPU 사용률이 70%에 도달하면 인스턴스를 추가 반대로 CPU 사용률이 낮으면, 인스턴스를 제거하여	매주 수요일 웹 애플리케이션에 대한 트래픽이 증가하고 목요일까지 높은 상태로 유지되다가, 금요일에 줄어들기 시작

 3.4. Elstic Load Balacing CloudWatch 및 Auto Scaling 통합 아키텍처

Auto Scaling 구성	Auto Scaling 작동

①.    이 시나리오에서는 로드 밸런서가 지정된 CloudWatch 경보가 지연 시간을 계속 추적

②.    경보가 트리거 되면, Amazon CloudWatch에 알림 전송

③.    알림은 CloudWatch가 Auto Scaling 정책을 실행하도록 트리거

④.    AutoScaling은 지정된 Auto Scaling 그룹을 스케일아웃하여 다른 인스턴스를 추가

 

3.5. 최소 용량 크기 결정 방법

 

-  Auto Scaling 그룹에서 다음을 정의

 ㅁ  원하는 용량

 ㅁ  최소 용량

 ㅁ  최대 용량

-  설정하기에 적절한 최소 용량은?

AZ별로 최소한 1개의 인스턴스로 시작해야 하는 경우, 최소 용량 크기는 AZ의 수로 설정

-  설정하기에 적절한 최대 용량은?

-  시나리오: 적절한 최대 용량은 애플리케이션과 예산에 따라 달라짐.

 ㅁ  Auto Scaling 그룹

    최소 = 2, 최대 = 12

 ㅁ  Auto Scaling 정책

    CPU 사용률이 60% 이상이면

    그룹의 100% 추가 = 용량을 두배로

 

3.6. Auto Scaling 단계별 시나리오

 

I.  기본 구성

II.  사용량 증가 시 1

III.  사용량 증가 시 2

IV. 사용량 증가 시 3

V. 사용량 회복

VI. 사용량 감소 1

VII.사용량 감소 2

VIII.사용량 안정

3.7. Auto Scaling 고려 사항

 

-  Auto Scaling 스레싱을 방지

 ㅁ  Scale in 할 때 좀더 주의를 기울이고 공격적인 인스턴스 종료는 피함

 ㅁ  미리 확장하고, 천천히 축소

 

-  최소 및 최대 용량 파라미터 값은 신중하게 설정

 

-  수명 주기 후크를 사용

 ㅁ  Auto Scaling이 인스턴스를 시작 또는 종료함에 따라 사용자 정의 작업을 수행

 

-  상태 저장 애플리케이션의 경우 Auto Scaling 그룹에서 시작되는 인스턴스에 대한 추가 자동 구성이 필요

-  Auto Scaling 수명 주기 후크에 대한 정보

 

 ㅁ  https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html

Amazon EC2 Auto Scaling lifecycle hooks - Amazon EC2 Auto Scaling

 

Auto Scaling을 통한 아키텍처 개선

AS-IS	TO-BE

 

-  Amazon CloudWatch

 ㅁ  ELB 및/또는 인스턴스의 상태를 모니터링하고 적절하게 작업을 시작

 

-  Auto Scaling

 ㅁ  Amazon CloudWatch로부터 요청을 수신

 ㅁ  인스턴스를 추가 또는 삭제

 

4. EC2 자동 복구

 

Amazon EC2 자동 복구 기능을 사용해 손상된 Amazon EC2 인스턴스를 자동으로 교체

 

-  인스턴스 손상의 원인이 되는 조건 (CloudWatch에서 탐지)

 ㅁ  네트워크 연결성 손실

 ㅁ  시스템 전원 손실

 ㅁ  호스트의 소프트웨어/하드웨어 문제

 

-  교체 인스턴스

 ㅁ  동일한 인스턴스 ID/메타데이터, IP 주소 유지

 ㅁ  손상된 인스턴스의 인 메모리 데이터를 사용할 수 없음.

 

-  지원 인스턴스 유형

 ㅁ  C3, C4, C6, M3, M4, M%, R3, R4, T2 및 X1

 ㅁ  모든 AWS 리전에서 사용 가능

 ㅁ  인스턴스는 VPC에 있고 공유 테넌시 사용 필요

 ㅁ  인스턴스 스토리지는 사용할 수 없으며 EBS 지원 스토리지만 사용해야 함

 ㅁ  작업에서 동일한 인스턴스 메타 데이터 또는 스토리지 볼륨을 유지해야 하는 경우 Auto Scaling 대신 사용

 

5. 데이터 스토어 조정

 

5.1. Amazon RDS 규모 조정

 

Amazon RDS 조정을 통해 다음을 수행

-  크기 조정 가능한 인스턴스 유형으로 확장 또는 축소

 

-  클릭 몇 번 또는 API를 통해 스토리지 확장

 ㅁ  스탠다드에서 프로비저닝된 IOPS 스토리지로 쉽게 전환

 

-  읽기 트래픽을 읽기 전용 복제본으로 오프로드

 

-  성능 향상을 위해 다음과 같이 Amazon RDS 앞에 캐시를 배치

 ㅁ  Memcached 또는 Redis용 Amazon ElastiCache

 ㅁ  선호하는 Amazon EC2 기반 자체 관리형 캐시 솔루션

 

5.2. 데이터베이스 샤딩으로 Amazon RDS 쓰기 조정

 

                             

-  샤딩이 없으면 모든 데이터가 하나의 파티션에 상주

 ㅁ  예: 사용자를 성에 따라 A에서 Z까지 하나의 데이터베이스에 구성

 

-  샤딩은 데이터를 큰 청크(샤드)로 분할

 ㅁ  예: 사용자를 성에 따라 A에서 M까지 하나의 데이터 베이스에, N에서 Z까지 다른 데이터베이스 구성

 

-  대부분의 경우에 샤딩은 뛰어난 성능과 높은 운영 효율성을 제공함

 

-  클라우드 설계 패턴: 샤딩 쓰기 패턴

 ㅁ  http://en.clouddesignpattern.org/index.php/CDP:Sharding_Write_Pattern

CDP:Sharding Write Pattern - AWS-CloudDesignPattern

5.3. 읽기 전용 복제본으로 수평적 조정: Amazon RDS

 

-  읽기 전용 복제본 추가

 ㅁ  읽기 중심의 워크로드 처리를 위해 수평적으로 확장

 ㅁ  보고서 오프로드

 

-  주의점

 ㅁ  복제는 비동기식

 ㅁ  현재 Amazon Aurora, MySQL, MariaDB 및 PostgreSQL(9.3.5 이상)에서 사용 가능

 

5.4. Amazon RDS 조정: 버튼 클릭으로 조정

 

-  노드를 수직적으로 확장 또는 축소

 ㅁ  마이크로에서 8xlarge까지 그리고 그 사이의 모든 크기 지원

 

-  읽기 전용 복제본으로 수평적 조정

 ㅁ  읽기가 많은 워크로드

 

-  중단 시간 없이 수직으로 확장

 

-  Amazon RDS API 또는 AWS Management Console을 통해 조정 가능

 

-  RDS의 PIOPS 사용 시 IOPS 속도를 1,000 IOPS 단위로 30,000 IOPS까지 조정 가능

 

-  스토리지 100GB에서 6TB까지 지정하여 DB 인스턴스 처리량 확장 가능 (SQL Server 제외)

-  DB 인스턴스 변경 방법

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html#USER_ModifyInstance.Settings

Amazon RDS DB 인스턴스 수정 - Amazon Relational Database Service

5.5 Dynamic DynamoDB용 Auto Scaling

                             

-  테이블 및 글로벌 보조 색인을 위해 용량 관리 자동화

-  원하는 대상 활용률을 지정하고 읽기 및 쓰기 용량에 대한 상한 및 하한 제공

-  DynamoDB는 Amazon CloudWatch 경보를 사용하여 처리량 소비를 모니터링

-  모든 새 테이블 및 색인에 대한 기본값 정의

-  중단 시간 없이 자동으로 읽기 및 쓰기 처리 용량 조정

-  DynamoDB Auto Scaling을 사용할 때 원하는 처리량 활용률 목표, 최소 및 최대 제한만 설정하면 나머지는 Auto Scaling이 알아서 처리

 

6. AWS LAmbda

 

-  이벤트 또는 시간 기반 간격에 대한 응답으로 상태 비저장 코드(Node.js, Java, Python 및 C#)를 실행하는 완전 관리형 컴퓨팅 서비스

-  Amazon EC2 인스턴스 및 Auto Scaling 그룹과 같은 인프라를 관리하지 않고도 코드를 실행할 수 있음

 

6.1. AWS LAmbda가 처리하는 작업

 

-  서버

-  용량 요구

-  배포

-  조정 및 내결함성

-  OS 또는 언어 업데이트

-  지표 및 로깅

 

6.2. AWS Lambda를 사용하면 할 수 있는 작업

 

-  자체 코드 사용 가능(네이티브 라이브러리 포함)

-  코드를 병렬로 실행

-  백엔드, 이벤트 핸들러 및 데이터 처리 시스템 생성

-  유휴 리소스에 대해 비용을 지불할 필요가 없음

 

6.3. AWS Lambda 기본 조정 방법

 

                             

-  조정 이벤트가 AWS Lambda 함수를 트리거 할 수 있음

 

-  AWS Lambda에서 실행되는 코드는 AWS API에 액세스 할 수 있고, AWS IAM 역할을 통해 권한 부여

 

-  Lambda 함수를 사용하면 조정 발생 시, 다른 AWS 서비스에 대한 API 호출을 자동으로 수행 가능

 

-  조정 관련 작업 예

 ㅁ  컨테이너 기반 인스턴스 조정(Docker, Amazon Elastic Container Service 등)

 ㅁ  함수를 사용해 더욱 지능적으로 조정(예: 단지 이벤트가 아니라 패턴을 차도록 성능 데이터 스트림 분석)

 ㅁ  AWS Lambda는 자동으로 조정할 수 있으므로, 적합한 경우 일부 Amazon EC2 인스턴스를 Lambda 함수로 대체하는 것을 고려