11주차 - AWS

기간	230717 - 230721
배운 내용	AWS

◎ AWS

서비스	리소스
ec2	ec2 instance
IAM	IAM user, Role, Policy, Group
S3	S3 bucket
vpc	vpc
Lambda	Lambda function

- 리소스 레벨
1) 글로벌 레벨 - IAM 관련 리소스
2) 리전 레벨 - VPC, S3, Lambda, DDB table

        리전 레벨 : 가용영역까지 선택할 필요 없고, 리전까지만 선택하면 됨

        S3, Lambda, DDB table 은 완전 관리형
3) 가용영역 레벨 - subnet, EC2 instance, RDS

1. AutoScaling

AutoScaling = 트래픽에 따라 자동으로 서버가 늘어났다가 줄어들었다가 함
(오토스케일링 아니면 예상한 것에 따라 낭비/품질 저하 발생)
=> 탄력성

EC2 auto scaling = ec2 instance 개수 자동으로 증가/감소
오토스케일링 그룹 만들어서 로드밸런서랑 연결
-> 인스턴스 개수 자동으로 증감시켜 줌

- Auto Scaling Group에서 정할 것
1) 최소 용량 : 사용량이 줄면 인스턴스 개수가 줄어들지만, 이 용량까지는 유지하도록 함

2) 최대 용량 : 자동으로 늘어나는 최대 인스턴스 개수

3) 원하는 용량 : 처음 start 되는 인스턴스 개수

 

- EC2 Auto Scaling 구성

1) Auto Scaling Group :희망 용량, 최소 용량, 최대 용량
2) 조정 정책 : 언제 instance 늘어나게 할 건지에 대한 규칙
예) cpu 60% 이상(단계별로 설정 가능 50% 이상일 땐 몇 개,, 70 이상일 땐 몇 개 등등

3) 시작 템플릿 : EC2 instance 추가 생성 시 어떻게 만들 것인지 정의

4) ELB 연결

2. EdgeService

edge = 사용자와 가깝게(사용자에게 빠른 서비스)

- Cloudfront

글로벌 콘텐츠 전송 네트워크 (Global CDN) 서비스.

정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스.

엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공

=> edge에서 리전까진 백본으로 연결. 인터넷이 아닌 aws 네트워크로

3. Amazon SNS, Amazon SQS

SNS, SQS : 메세징 서비스 => 약결합 통해 확장성 증가

클라이언트 -> 53->클라우드 프론트 ->로드밸런싱 ->오토스케일링->RDS
이 아키텍처의 문제 (SNS, SQS 없음)
1) 요청 늘면 오토스케일링 해주는데 시간이 걸림.
2) 처리 오류시 그 시간 동안 주문 없어질 수 있음

이를 해결하기 위한 아키텍처 : web 티어 app 티어 나누기

=> 요청을 메시지 큐에 쌓아두고 그걸 꺼내가서 처리함

 

위 아키텍처의 장점
1) 갑자기 요청 늘었을 때, 쌓이는 것만 많이 쌓이고 요청이 사라지진 않음
2) 오류가 나면 Dead Letter Queue(DLQ) 옮기는 시스템 있음.
요청이 제대로 처리하면 삭제, 처리 못하면 남겨둠
최대 시도 횟수만큼 시도해도 처리 못하면 DLQ로 옮김
여기 있는 오류들은 관리자가 분석 후 해결

 

- SQS

SQS 대기열
1) 표준 대기열 = 원래 1:1로 가져가야 하는데 보장하진 않음.(최선을 다함)
메시지 하나가 2번 이상 처리될 수도 있음. 순서도 다르게 전송될 수 있음
2) fifo 대기열 = 순서대로 한번 처리. 1:1 보장. 처리량은 떨어짐

배달 못한 편지 대기열(Dead Letter Queue. DLQ) - 에러 발생한 메시지는 여기로

가시성 제한시간 = 메시지 읽어가면 다른 곳에서 읽어가면 안 되니까 제한시간을 둠.

대기열에서 메시지 가져온 후 다른 애플리케이션에서는 해당 메시지가 보이지 않는 시간.

이 시간 안에 처리되면 삭제되고, 처리되지 않으면 다시 보임

 

- SNS
클라우드에서 손쉽게 알림 기능을 설정, 작동 및 전송할 수 있는 웹 서비스.

“게시-구독”(pub-sub) 메시징 패러다임을 따르며 “푸시” 메커니즘을 사용하여 클라이언트에 알림 전달

게시자는 자신이 생성한 주제(topic) 또는 게시할 권한이 있는 주제로 메시지 전송

SNS는 주제와 해당 주제를 구독하는 각각의 구독자에게 메시지 전송

- SQS / SNS 차이

Amazon SNS	Amazon SQS
topic에 메시지 담음	큐에 메시지 담음
일대다(메시지 하나를 여러 구독자가 구독 신청)	일대일(메시지 하나씩 한명이 가져감)
토픽에 메시지 있으면 전부 보내고 남지 않음	메시지를 제대로 처리했을 때만 삭제

4. AWS Lambda

- AWS 서비스 유형

1) 비관리형 
백업, 이중화, 확장성, db 설치, 패치 등등 직접 관리
ec2 인스턴스 위에 직접 플랫폼 설치, app올림 + 이중화 오토스케일링 다 고객이 해야 함

2) 관리형
백업, 이중화, 확장성, db 설치 등의 작업을 aws에서 대신 관리해 줌
대신 고객이 선택하고, 결정해 줘야 aws에서 관리해 줌

3) 완전관리형
서버리스
서버관리 필요 없고 보여주지 않음
고객이 전혀 신경 쓰지 않음

운영, 관리에 대한 노력은 줄지만 세세한 부분 확인 어렵고 설정 바꿀 수도 없음

- AWS Lambda

완전 관리형 컴퓨팅 서비스

Node.js, Java, Python 등 지원

상태 비저장 코드 실행

주로 이벤트에 대한 응답으로 코드 실행

- Lambda 작동 방식
1) event 등록
    a) push 방식(비동기)
        s3 버킷에 이미지 들어와서 put 발생하면 람다 호출 하도록 해줘
        s3에서 호출하니까 여기에 호출 권한 필요
    b) pull 방식
        ddb table에 변경 일어나면 자동 호출
        ddb table은 변경사항 큐에 보냄. 람다가 큐에 주기적으로 가서 끌고 옴.
        여기에 뭐 있으면 자기 자신 실행
        이벤트소스 쪽에서 호출 권한 필요 없음

2) 직접 호출(동기, 비동기도 가능)
invoke, cli, sdk로 호출
api gateway가 람다 호출
호출 권한 필요

3) 시간예약

- Lambda 관련 권한
1) 처리 권한 - Lambda 함수가 필요한 권한
2) 호출 권한  - 호출하는 쪽에서 필요한 권한

5. AWS API Gatway

- 주요 기능
1) 인증, 권한관리 : IAM, cognito 연결하면 로그인한 사용자만 api 요청할 수 있게 함
2) 보안 : 디도스 공격 방어 위한 쉴드
3) mock 통합 가능 : 백엔드가 구현되기 전에도 API만 생성 가능
4) 스로틀 제한 : API 요청 개수 제한 가능
5) SDK 생성 : API GW에서 생성한 API를 자바 등의 프로그램언어로 SDK로 생성 가능
6) API 키 구성 : API 키 만들어서 해당 키 있어야만 권한 주기 가능

 

6. AWS 데이터베이스 서비스

- Amazon 데이터베이스 옵션

1) 비관리형 데이터베이스

EC2 instance에 DB를 직접 설치해서, 직접 관리하는 형태

 

2) 관리형/완전관리형 데이터베이스

Amazon RDS , Amazon DynamoDB 등 관리형 서비스를 이용하는 형태

- Amazon RDS
"관리형" 관계형 데이터베이스 서비스
(관리형 = 고객이 책임지고 선택해야 함, 완전관리형 = aws가 알아서)

어떤 vpc, subnet, instance type, 멀티가용영역의 이중화, 스토리지 용량, DBMS 종류 등등을 고객이 선택해야 함.
자동으로 되는 건 설치, 마이너 패치, 백업, 이중화 시 자동 페일오버 등등
-> DBA가 해야 할 일 AWS가 대신해 줌

 

 

7. Cognito

웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리를 제공

- 사용자 풀

Cognito 쪽에 유저 테이블 만드는 것

사용자 풀이 있으면 사용자는 Amazon Cognito를 통해 웹 또는 모바일 앱에 로그인할 수 있음

Google, Facebook 등을 통하거나, SAML 자격 증명 공급자를 통해 로그인할 수도 있음

 

- 자격증명 풀 

자격 증명 풀을 사용하여 사용자를 위한 고유의 자격 증명을 생성하고 자격 증명 공급자를 통해 해당 자격 증명을 인증할 수 있음

자격 증명을 사용하면 다른 AWS 서비스에 액세스 하기 위해 권한이 제한된 임시 AWS 자격 증명을 얻을 수 있음

 

유저가 app에게 로그인 -> 유저풀에서 찾아 -> jwt 토큰 연결
app이 aws 서비스에 뭐 저장하려 한다 -> 권한 있어야 함->자격증명풀에 권한 입력
누구한테 롤 부여할 것인지 -> 유저풀에 로그인하면 준다고 연결 가능