Written by php-style
on 

[79일 차] 21.11.15 : AWS 공인 교육 5

[79일 차] 21.11.15 : AWS 공인 교육 5

CloudWatch + SNS

고가용성

CloudFormation

캐싱/세션 관리 with DynamoDB

1교시

저번에는 IAM을 배웠다. 인증과 권한을 제공하는 서비스

IAM 관리 사용자 생성 > 루트 사용자 자격 증명 잠금 > IAM 관리 사용자 사용

AWS Landing Zone

서비스는 아니고, 다중 계정 환경을 사용할 때 AWS 시작 환경을 빠르게 시작할 수 있는 솔루션

Control Tower 서비스에서 이것을 사용하는데, 컨트롤 타워 서비스는 서울 리전에서 제공하지 않는다.

AWS에서 권장하는 2가지 기본 아키텍처 패턴 - 다중 VPC, 다중 계정

1. 다중 계정

교차 계정 액세스는 기본적으로 활성화되어 있지 않다. 다른 계정의 리소스에 접근하려면 역할을 받아서 사용.

대부분의 경우에 다중 계정을 사용한다.

단점이라면 결제가 번거롭다는 점과 루트 계정을 다수 만들어 배포해야 한다는 것.

그래서 사용하는 서비스가 AWS Organizations.

루트 계정들의 루트 계정을 만든다(Organization을 만드는 계정이 루트 계정이 된다). 그리고 다른 계정을 초대해 조직에 속하게 할 수 있다.

통합 결제가 지원되며, 각 계정들이 얼마나 사용했는지도 알 수 있다.

그룹 기반 계정 관리가 가능하다(소속된 루트 계정의 권한 제한 가능).

SCP(Service Control Policy)를 조직에 적용할 수 있다. 루트 계정에 SCP를 적용하면 이 조직의 모든 계정에 적용될 것이고, 하위의 특정 OU(Organization Unit)에 적용된다면 개발 OU에만 적용된다.

AWS Organizations 서비스는 실제로도 많이 사용하는 서비스다.

2교시

모듈 8 - 탄력성, 고가용성 및 모니터링

조직에서 급격한 성장이 발생한다면 아키텍처에서 용량의 큰 변화를 처리해야 한다.

고가용성 요소

내결함성 : 결함이 생기더라도 전체 서비스에 영향을 주지 않게끔 하는 것. 결함이 생기는 부분을 중복으로 처리(이중화)복구성 : 장애 발생 후 데이터 손실 없이 서비스를 신속하게 복구

확장성 : 애플리케이션의 인프라가 증가된 용량 요구에 따라 신속하게 대응(성장 수용)할 수 있어야 한다.

확장성(탄력성) - Auto Scaling, Load Balancing, CloudWatch 사용

일단 온 프레미스 환경에서는 구현 불가. 일반적인 데이터 센터에서는 수요를 예상해서 인프라를 구축할 수 밖에 없다.

리소스가 남으면 비용 낭비.

트래픽 패턴이 일정하면 범위에 따라 프로비저닝하면 되겠지만, 트래픽이 기하급수적으로 폭증하는 기간이 있다면?

-> 온 프레미스라면 시기에 맞춰 장비 구입, 세팅해야 한다.

-> 나머지 기간에는 유지비만 들고 쓸 일이 없다.

탄력성 환경을 사용할 수 있다면 이러한 손실을 크게 줄일 수 있다.

-> 지능적으로 인프라를 확장 및 축소

탄력성의 유형 3종

시간 기반 : 리소스가 사용되지 않을 때 리소스 끄기. 개발/테스트 환경

볼륨 기반 : 수요 강도에 맞게 규모 조정. 충분한 컴퓨팅 파워가 있어야 한다.

예측 기반 : 일일 및 주간 추세를 기반으로 향후 트래픽 예측.

모니터링

탄력성에 필수적인 요소. 전체 운영 상태를 볼 수 있어야 하기 때문이다.

리소스 활용률, 애플리케이션 성능, 요청의 허용/거부(보안 감사)

어디에서 비용을 지출하고 있는지 알아야 한다

-> AWS Cost Explorer : 시간 흐름에 따른 리소스 소비 패턴 확인 가능

AWS CloudWatch

리소스에 대한 지표를 수집/추적

경보를 생성하고 알림 전송

설정한 규칙에 따라 리소스의 용량 변화 트리거 가능

-> 지표, 로그, 경보, 이벤트, 규칙, 대상

SNS에서 알림을 미리 만들고, CloudWatch에서 알림을 SNS로 보내도록 설정

SNS로 이동 > Topic 생성 > 타입은 Standard, 이름 작성 > 생성

생성한 Topic에서 Create subscription > Protocol은 Email(서울 리전은 SNS 알림이 지원 안됨), 엔드포인트에 이메일 주소 작성 > 생성

생성한 구독자는 해당 이메일에서 확인해줘야 생성 완료(Confirmed).

CloudWatch > Rules > Create rule > Event source는 Event Pattern, Service name은 EC2, Event type은 EC2 Instance State-change Notification(Specific State - running, stopped, terminated) > 우측의 Add Target은 SNS Topic으로 선택 후 아까 생성한 토픽 선택 > 다음으로 넘어가서 이름 작성 > 규칙 생성 완료

이제 인스턴스 하나를 켜보자. 그러면 작성했던 이메일로 알림이 온다.

-> 인스턴스 ID, 상태 등의 인스턴스 정보가 온다.

SNS는 요청이 없으면 비용이 발생하지 않지만, CloudWatch Rule은 삭제해놓자.

3교시

AWS CloudTrail

계정에서 이루어지는 모든 API 호출을 기록하고, 지정된 S3 버킷에 로그 저장

CloudTrail > Event history에 지금까지의 이벤트가 모두 남아있다.

이벤트 정보를 보면 관련된 모든 정보가 작성되어 있다.

VPC Flow Logs

VPC의 트래픽 흐름 세부 정보 캡처

허용/거부 또는 모든 트래픽

VPC, 서브넷, ENI에 대해 활성화할 수 있다.

탄력성 및 아키텍처 확장을 위한 도구 - AWS Auto Scaling

지정된 조건에 따라 인스턴스를 시작/종료. 새 인스턴스를 로드 밸런서에 자동으로 등록할 수 있다.

여러 가용 영역에 걸쳐 사용할 수 있다.

시작 구성/시작 템플릿 생성 > 오토 스케일링 그룹 생성

Auto Scaling 방법

1. 예약 : 특정 시간에 인스턴스를 축소/확장

2. 동적 : 대상을 추적/모니터링해서 지원

3. 예측 : 기계 학습 기반 조정. 규칙을 수동으로 조정할 필요 없음

추가 가능한 인스턴스 유형은 온디맨드/스팟

-> 보통은 온디맨드를 사용하지만, 단시간에만 필요하다면 스팟 유형도 좋은 선택이다.

-> 2가지 유형을 혼합해서 사용할 수도 있다.

Auto Scaling 그룹에서 원하는 용량/최소 용량/최대 용량을 지정할 수 있다.

-> 원하는 용량 : 현재 시점의 이상적인 인스턴스 용량

고려 사항

여러 유형의 오토 스케일링을 결합해야 할 수도 있다.

단계 조정을 상요하여 아키텍처를 조정할 수 있다.

둘 이상의 지표를 사용하여 조절할 수 있다.

빠르게 확장하고, 천천히 축소된다.

데이터베이스 조정

관계형 DB는 동적인 규모 조정을 할 수 없다.

AWS RDS

-> 수직적 조정. 컴퓨팅 및 메모리 리소스를 조정해 배포를 조정 가능.

-> 스토리지 조정은 다운타임 없음. 인스턴스 유형 조정은 다운타임 필요.

AWS Aurora 클러스터

-> 기본 인스턴스 이외에 최대 15개의 읽기 작업만 지원하는 복제본을 가질 수 있다.

Aurora Serverless

-> 온디맨드 오토 스케일링 구성 : 애플리케이션의 필요에 따라 자동으로 조정된다

DB 샤딩으로 RDS 조절

샤딩은 DB 서버를 여러 대 사용하여 쓰기 성능을 개선하는 기술

샤딩이 없으면 모든 데이터가 하나의 파티션에 상주한다. 샤딩은 데이터를 큰 청크로 분할

DynamoDB - 2가지 조정

신경써야 할 것은 별로 없다. 완전 관리형 서비스니까

-> Auto Scaling : 처리량의 상한, 하한을 정할 수 있다.

-> On-demand : 용량 계획 없이 요청이 들어오는 대로 전부 처리하고, 처리한 만큼 요금 청구

DynamoDB의 Auto Scaling 실행

1. DynamoDB 테이블의 애플리케이션 Auto Scaling 정책 생성

2. DynamoDB가 지표를 CloudWatch에 전달

3. 전달된 지표를 기준으로 CloudWatch가 경보 트리거 - SNS가 알람 수신

4. CloudWatch 경보가 Auto Scaling 호출 및 조정 정책 평가

5. 앱 AS가 요청을 생성하여 테이블의 처리량 조정

6. DynamoDB는 요청을 처리하고 테이블의 할당 처리 용량을 조정

4교시

실습 - 고가용성 환경 생성

VPC, ELB, EC2 Auto Scaling Group, RDS를 사용한 복원력이 뛰어난 인프라 구축

시작 구조는 퍼블릭 서브넷에 NAT 게이트웨이 하나, 프라이빗 서브넷에 RDS DB 인스턴스 하나 있는 구조

작업 1 : ALB 생성

-> Target groups 생성

-> Load Balancer 생성

-> 시작 템플릿 생성(Launch Templates)

-> Auto Scaling Group 생성

구성되어 있던 3티어 아키텍처에 체인 다이어그램 구축하기

-> 애플리케이션(EC2 인스턴스) 보안 그룹 HTTP 트래픽 규칙의 대상을 ALB의 보안 그룹으로 지정

-> DB 보안 그룹 MySQL 트래픽 규칙의 대상을 EC2 인스턴스 보안 그룹으로 지정

작업 2 : 고가용성 테스트

오토 스케일링에 의해 2개의 인스턴스가 작동 중인데 하나를 종료시켜도 잘 작동하는지 확인

작업 3 : DB를 고가용성으로 만들기

만들어져 있던 RDS DB 인스턴스의 용량과 인스턴스 클래스를 변경해 확장

Multi-AZ 옵션 활성화

작업 4 : NAT 게이트웨이를 고가용성으로 만들기

별 거 없다. 기존에는 퍼블릭 서브넷 하나에만 NAT 게이트웨이가 있었는데, NAT 게이트웨이/프라이빗 라우팅 테이블을 하나씩 더 추가해 NAT 게이트웨이를 이중화

5교시

모듈 9 - 자동화

조직에 있는 다양한 아키텍처를 일관되게 배포, 관리, 업데이트할 방법이 필요하다.

자동화가 없다면 관리 콘솔이나 CLI에서 수동으로 해야 한다.

개별 구성 요소를 수동으로 생성해 환경에 추가할 경우 확장이 불가능하다.

-> 버전 제어 불가

-> 환경을 수동으로 제어해야 한다

-> 일관성을 지키기 어렵다

AWS CloudFormation - 인프라 자동화

AWS 인프라를 설명하는 공통 언어 제공, 설명된 리소스를 자동화된 방식으로 생성/구축

JSON/YAML 리소스를 안전하고 반복 가능한 방식으로 프로비저닝한다.

-> 수동 작업을 수행하거나 사용자 지정 스크립트를 작성할 필요 없이 인프라와 앱을 구축/재구축 가능

코드형 인프라(IaC)

환경을 구축하면서 반복성과 재사용성의 이점을 활용할 수 있다.

템플릿 하나로 복잡한 동일 환경을 반복해서 구축할 수 있다.

CloudFormation 템플릿에서 Parameters 쓰는 이유?

-> 재사용성을 높이기 위해

Mapping은 정적 데이터 : 리전별로 달라지는 값 같은 것

AWS::CloudFormation::Init은 인스턴스 초기 설정 내용(= 사용자 데이터)

작업이 생성되는 순서는 DependsOn으로도 가능하지만, Ref로도 가능하다.

AWS Quick Start

AWS 클라우드에서의 모범 표준 배포

고객이 AWS에서 인기 있는 솔루션을 배포하는 데 활용할 수 있도록 보안 및 고가용성 관련 모범 사례를 기반으로 구축

6교시

CloudFormation으로 전체 인프라를 자동으로 구축한 후, 개별 요소의 업데이트는 어떻게 할 것인가?

직접 접속해서 명령 입력? 앱 다운로드?

오류 발생 시 롤백은 어떻게 하는가?

AWS System Manager

자동화된 구성 및 대규모 시스템의 지속적 관리가 가능한 기능의집합

-> 모든 Winodws/Linux 워크로드

-> EC2 인스턴스나 온프레미스에서 실행

System Manager Run Command를 사용하여 대규모 관리형 인스턴스의 구성을 원격으로 관리

인프라 및 배포 자동화를 위한 AWS OpsWorks

AWS Elastic Beanstalk

인프라 리소스를 프로비저닝/운영하고 사용자를 위해 애플리케이션 스택을 관리

생성되는 모든 것을 확인할 수 있으며, 애플리케이션의 크기를 자동으로 늘리거나 줄인다.

고유한 도메인 이름을 제공하며, 고객은 코드만 제어하면 된다.

Elastic Beanstalk > OpsWorks > CloudFormation > EC2

우측으로 갈수록 자유도는 올라가지만, 관리할 요소는 많아진다.

실습 - AWS CloudFormation을 사용한 인프라 배포 자동화

CloudFormation은 이전에도 많이 해봤으니 쉬운 실습이었다.

네트워크 부분과 애플리케이션 부분의 스택을 분리했다는 점이 달랐다.

7교시

모듈 10 - 캐싱

동일한 요청과 동일한 응답이 반복되면 인프라 용량이 지속적으로 부하가 걸린다. 이는 비효율적으로 비용 및 지연 시간을 늘린다.

장비가 필요하다고 집에서 철물점으로 계속 왔다갔다하면 상당한 노력이 든다.

-> 공구 창고가 가까운 곳에 있으면 굳이 멀리 갈 필요 없다

캐시 처리를 해야 할 데이터는 무엇일까?

-> 수집하려면 시간이 오래 걸리고, 무거운 쿼리가 필요한 데이터

-> 자주 액세스하고 정적인 데이터

-> 일정 시간 동안 변화가 없을 수 있는 정보

캐싱의 이점

-> 애플리케이션 속도 향상

-> 시간이 많이 걸리는 DB 쿼리의 부담 완화

-> 응답 시간 지연 감소

아키텍처의 캐싱 유형

웹 서버에서 클라이언트 측 브라우저의 요청에 따라 응답을 보내면,

브라우저는 이 응답을 역방향 프록시 캐시 서버에 저장.

AWS에서의 캐싱 : CDN

웹 컨텐츠의 캐시된 사본을 엣지 로케이션을 통해 제공

Amazon CloudFront

AWS의 글로벌 CDN.

1. 사용자가 컨텐츠를 요청 > 요청이 최적의 엣지 로케이션으로 라우팅됨 > CloudFront 엣지 로케이션 도달

2. 캐시되지 않은 컨텐츠가 오리진으로부터 검색됨 > 컨텐츠가 있는 S3 버킷 또는 고객 오리진

3. 오리진 > 오리진 컨텐츠가 캐싱을 위해 CloudFront 엣지 로케이션으로 전송됨

4. 캐시된 객체 복사본 > 데이터가 최종 사용자에게 전송됨

정적 컨텐츠 뿐만 아니라 동적 컨텐츠도 CloudFront를 사용하는 이유는?

-> 엣지 로케이션을 통한 빠른 응답을 위해

-> 동적 컨텐츠에도 보안 추가 가능 : 바로 얻어맞기보다는 한번 거르고 얻어맞기(DDoS)

웹 계층 캐싱 - 세션 관리

트래픽이 골고루 분산되는 환경이라면 정보가 오락가락할 수 있다.

-> 고정 세션 사용

이러면 비효율적 - 세션은 웹 서버에 저장되기 때문

그래서 세션 정보를 웹 서버에 저장하지 않고, 웹 서버들이 공유하는 서버에 모아서 저장

8교시

실습 - 세션 정보를 DynamoDB로 관리하기

애플리케이션이 DynamoDB 테이블에 요청을 보낼 수 있어야 한다

-> 요청을 보낼 수 있는 권한과 PHP용 SDK로 요청을 보낼 수 있게 코드 수정 필요

1. IAM에서 인스턴스용 역할을 하나 만들자.

IAM > Roles > Create role > use case는 EC2 > permission은 AmazonDynamoDBFullAccess > Role 이름 작성 > 생성

2. 인스턴스 2개 생성 : 역할을 지정해서 만들기

일단 DB 인스턴스는 켜두고

WebServerUserData_Session.txt 내용 중 DBURL을 DB 인스턴스의 사설 주소로 변경

(우분투 18.04)인스턴스 생성하며 위 파일의 내용을 사용자 데이터에 입력, 퍼블릭 서브넷 1에 생성, 위에서 생성한 역할 선택, 보안 그룹은 웹 서버 보안 그룹 선택

동일한 구성으로 인스턴스 하나 더 생성

3. 인스턴스에 원격 접속 후 PHP SDK가 실행될 수 있는 환경 세팅

각 인스턴스에 접속해서 AWS+PHP+SDK+installation(ubuntu18).txt에 있는 설치 내용 진행

/var/www/html/basic/index.php 파일에 보면 세션 정보를 어디서 처리하는지 볼 수 있다.

DynamoDB로 이동해서 테이블 생성 : 테이블명은 usersession, 파티션 키는 id

이후 ALB의 대상 그룹에 만든 인스턴스 2개를 추가 후 ALB를 통해 접속(Sticky Session 꺼두기)

-> 로그인 후 새로고침하며 웹 서버를 왔다갔다해도 로그인이 풀리지 않는다

DynamoDB로 가서 Items를 확인해 보면 세션 정보가 저장되어 있다

CloudWatch(412~418)

DB(433~436)

441~445는 신경 쓸 필요 없다

실습 4 따로 정리(그림들 사진 찍어놓기)

479~482

502~514

from http://ballenabox.tistory.com/130 by ccl(A) rewrite - 2021-11-16 00:27:03