[사내교육] AWS 클라우드 교육 2일차

AWS 강의 04/04 2일차

 

0. 목표

무엇을 구글링해야할지 알려줄것임.AWS 강의 04/04 1일차

 

0. 목표

무엇을 구글링해야할지 알려줄것임.

이론-> DEMO순서로 진행

유튜브에 강의있음

 

1. 클라우드컴퓨팅이란?

 

인터넷에서 종량요금제 방식으로 클라우드 서비스 플랫폼을 통해 컴퓨팅 파워, 데이터베이스 스토리지, 애플리케이션, 기타 IT리소스를 ~

IT리소스를 인터넷을 통해 온디맨드로 제공하고 사용한 만큼만 비용을 지불하는 것

필요한 만큼 계속쓰는 것이 온디맨드임.

 

 

2. 서버-클라이언트 아키텍처

 

스킬사전정보를 주고

이중에 하나라도 제대로 전달이 안되면 전체상태가 어그러진다.

스킬시전한 정보를 유저가 서버한테 보내준다.

중앙 서버에서 모두 관리하기 때문에 괜찮은

 

 

3. 데이터 센터: 어플리케이션의 서버룰 호스팅하는 실제 시설

데이터센터 운영에 필요한 인프라: 컴퓨터시스템을 위한 하드웨어,네으퉈킹장비,전원 공급장치,전기시스템,백업 발전기,환경제어장치(에어컨, 냉각기,팬),운영인력

 

- 데이터센터의 문제점

운영 비용이 많이 소요됨.

 

> 데이터센터운영과 AWS 비교

- 집을 직접 짓는 경우 (데이터센터 운영)

내가 원하는대로 커스터마이징 가능

단점 : 투자비용많이듬, 기간오래걸림, 상황변경에 쉽게 대처하기 힘들다, 유지보수를 직접 해야함.

 

- 호텔에 머무는 경우 (AWS 사용)

사용한만큼 돈을 지불: OnDemend 온디맨드

유지보수 필요없음, 유연한 사용가능, 투자비용 적음,

단점 : 내껏이 아님. 빌려쓰기 = 클라우드

다쓰면 반납함.

 

4. 클라우드 컴퓨팅의 장점

 

- 자본비용을 가변비용으로 대체,

막대한 초기비용을 쓰는 대신 쓰는 만큼만 비용지불

 

- 규모의 경제

한 개를 사는거보다 백개를 사는게 단가가 낮음.

AWS는 제일큰 서버기 때문에 AWS를 같이 이용하는 모든 고객과 공동구매를 하는 효과.

 

- 용량추정 불필요

시스템이 안정적으로 돌아가려면 최대 사용량에 맞춰야한다.

데이터센터는 피크를 최대 사용량으로 설치해놓으니 사용량 중 잉여 자원이 남게된다.

그런데 클라우드 컴퓨팅을 사용하면 딱 쓴 만큼만 내기 때문에 최대 용량을 추정할 필요가 없다.

불확실한 수요 예측에서 오는 손해가 적음.

 

- 속도 및 민첩성 개선

몇 번의 클릭으로 바로 리소스 확보 가능

개발비용 절감.

 

- 데이터센터보다 인프라 관리비용보다 비즈니스 자원(마케팅, 인건비 등)에 집중할 수 있다.

- 빠른 확장성.

- 온디맨드: 공급중심이 아닌 수요에 반응해서 서비스를 제공하는 것

 

- 유지보수가 쉬움

장애가 발생하면 그냥 시스템끄고 다른 시스템빌리면됨.

 

 

5. 클라우드 컴퓨팅의 유형

 

6. 클라우드 컴퓨팅의 모델

 

아래부터 네트워크., 00, 저장공간, 컴퓨팅, OS, APP

인프라만 제공.

IaaS: 주방만 빌리기 (인프라만 제공)

PaaS: 레시피, 주방기기만 공유주방으로 가져가서 쓰는 것

인프라+OS+ 런타임 제공

SaaS: 라면 자판기임 모두 제공해줌(전부다 빌리기)

 

> 배포모델

공개형: 모든 부분이 클라우드에서 실행

폐쇄형:

혼합형(공개+폐쇄) : 대규모면 대규모일수록 폐쇄형에서 공개형으로 바뀔 때 그 과도기에서 이횽

대부분 폐쇄형이지만, 공개형으로 백업을 진행.

 

7. 고가용성과 장애내구성

- 고가용성

장애상황을 해결하고 서비스를 지속할 수 있는 능력

장애상황의 준비가 되어있는 아키텍쳐가 필요

- 장애 내구성, 내결함성 : 장애상황에 구애를 받지 않는 능력, 장애가 발생하더라도 바로 대응할 수 있게, 비용많이 듬

 

타이어하나가 터지면 운전불가능 : 고가용성은 갖췄지만 장애내구성은 갖추지못함

엔진하나가 고장나더라도 계속 운행가능: 고가용성과 장애내구성 둘다 갖춤.

심정지 환자

 

- 재해복구: 장애상황 복구하기

- 확장성: 서버를 늘릴수있는거

- 탄력성: 수요에따라 능력과 용량을 줄였다 늘였다하는거 (elastic)

쿠키런이 오후 네시에 서버 잔뜩늘렸다가 새벽두시되면 서비 용량을 줄임.

 

8. 긴밀한 결합과 느슨한 결합

중요한 개념!!!

긴밀한 결합: 다른 주체에 대해 단단하게 얽혀있음 예) 우리몸

상태변경 어려움, 하나바꾸면 다른것도 다바꿔야함

느슨한 결합: 다른 요소에 얽히지 않고 연결되어있음. 독립적

주체끼리 낮은 의존성을 갖고있어서 쉽게 변경할 수있고 유연함.

한 개만 뺐다가 그거만 다른거로 교체가능.

예) 로봇. 뺐다꼈다 할수있음,

-> 느슨한 결합을 지향하자! (AWS 프레임워크 아키텍쳐의 원칙은 아님)

 

9. 가상화

하나의 어플리캐이션에 하나의 OS 필요

근데 하나에 서버에 다양한 OS를 운영할 수 있음.

물리적인게아니고 가상화된 서버를 제공받을 수있다.

 

10. 기타용어

- 온프레미스: 자체적으로 데이터센터 운영. 클라우드와 완전 반대.

- 프로비전 : AWS사용하기위한 준비

 

11. AWS의 구조

- AWS클라우드 하나에 다양한 전세계의 리전이 있음

 

1) 리전region? AWS의 서비스가 제공되는 서버의 물리적 위치.

각 리전에는 고유 코드가 부여됨

ap(아시아퍼시픽)

리전별로 가능한 AWS서비스가 다름

리전 선택시 고려할 것: 지연속도(범위가 너무크면), 법률적 문제(나무위키 저작권), 사용가능한 AWS서비스

 

- US-East-1 리전이 가장 중요!

가장 글로벌 서비스의 리전

 

2) 가용영역 (AZ)

리전의 하부단위. 하나이상의 데이터센터로 구성.

물리적으로 일정거리 이상 떨어져 있음.(재해 때문에, 느슨한 결합을 위해,

장애가 격리될 수 있도록)

- 가용영역의 위치 : 하나의 리전안에 두 개이상의 가용영역이 있으며 하나이상의 데이터센터로 구성

 

 

3) CDN/엣지로케이션?

 

4) 숫자별 비교

리전이 더많으냐 AZ가 많으냐

당연히 리전> 엣지 로케이션>

 

5) 글로벌 서비스

하나는 글로벌 서비스, 하나는 리전서비스임.

 

6) ARN : AWS의 리소스에 부여되는 고유아이디

형식을 외울 필요는 없음.

 

 

12. IAM 구성

아이패드에 필기 97page~

 

콘솔 엑세스 자격증명방식

MFA: 다른 자격증명에 보안을 강화하기위한 임시 비밀번호.

 

13. AWS 인증/이용방법

1) AWS 웹콘솔

2) 프로그래밍 엑세스: CLI(커맨드), SDK, 프로그램방식 엑세스 자격증명

 

 

 

> 실습(DEMO)

 

AWS 콘솔 접속

AWS 계정 새로 만들기

MFA코드 입력하기

리전이 제일 중요 : 서울리전 사용, 북미리전은 느림

스토리지추가. 태그 추가

IAM 글로벌 서비스고 여기에 사용자 추가

AWS자격유형방식은 두가지!

1) 엑세스키

2) 암호

 

권한 부여

기존정책 직접 연결 (액션과 권한 부여) 문서로되어있음

 

인스턴스에 연결

새로운 서버가 마련됨.

AWS CLI 여러 어플리케이션과 소통할 수 있는 방법

 

$ aws iam list-users

권한 없다고 나옴

$ aws configure

access key 입력하기

시크릿키 입력하기

포맷입력하기

$ aws iam list-users

하면 권한들 좍나옴

 

user한테 정책을 부여해서 권한을 없애면 안보임

 

보안자격증명을 비활성화

: 토큰자체가 없다고나옴.

IAM을 통해서 유저를 관리하고 정책을 부여할 수있음.

팀에 따라서 권한을 다르게 부여해주고 이런 시나리오를 제어.

14. EC2: 컴퓨팅을 빌려쓰는 서비스

AWS에서 가장 중요한 개념!!!!

- 하나의 EC2 인스턴스는 여러 보안그룹과 연동할 수 있다.

 

 

 

<EBS>

가상의 하드드라이브.

- 스냅샷? 증분식 방식: 바뀐 부분만 저장. 1메가만 바뀌면 1메가만 변환

- AMI: 한시간에 한번씩 AMI를 올려놓으면 그걸 받아서 사용가능

 

 

<실습>

새로운 인스턴스 실행

AMI선택 (레드햇, 윈도우,맥 ...)

우리는 아마존에서 만든 OS를 가지고 씀. 다 설치되어있어서 편리.

인스턴스 유형선택: 유형은 프리티어 무료 사용. 맥은 약정이 굉장히 큼.

인스턴스세부정보 구성하기(네트워크, 한번에 몇 개를 할지, 태넌시 구성 가능, 스팟인스턴스도 설정가능.)

스토리지추가 (EBS추가하기. 몇기가 천기가. 볼륨 암호화도 가능.)

크기, 볼륨유형 저장. 잘모르면 범용 사용, 종료시 삭제에 체크하면

태크추가 (인스턴스별로 태그 지정 가능. 팀1이 사용하는 AWS인스턴스 요금도 다르게 설정가능. EC2 인스턴스만 사용가능하게 권한 설정가능. 모든 이름은 대문자.)

보안그룹구성: 가상의 방화벽, TCP

기존 키페어 설정

인스턴스 시작

인스턴스가 프로비전 가상의 환경에서 인스턴스를 연결하기 때문에 시간이 좀 걸림

테스트 페이지

$ service http start

$ index.html 생성

테스트페이지에서 생성한 페이지 바로 확인가능

웹서버를 프로비저닝해서 웹서빙을 했다.

이미지생성 등.

마지막은 EC2 정리하기 : 종료 인스턴스

모니터링을 통해서 CPU사용량 등 확인 가능.

 

EC2 에 붙어있는 EBS를 생성해서(OS,파일,시작권한)을 EBS의 상태를 AMI에 저장해둠

이행동을 다 스냅샷에 저장해서 공유할 수 있음.

 

데이터베이스 설정하고 중요한 설정작업을 하고 AMI를 만들어놓으면 그다음부터 이어 실행 가능.

 

$ sudo -s

 

AMI를 만들어놓으면 공유, 백업 가능 최대한 자주써주는게 좋음

일정 기간마다 백업을 주는 서비스도 따로 있음

효율적으로 관리 가능.

 

15. EC2의 생명주기

모든 AMI는 EC2에서 시작한다.

 

16. EC2인스턴스

러닝상태일때만 청구됨

 

<실습>

EC2인스턴스 중지상태로 바꾸면 생성되어있던 EC2인시던스의 ip가 사라짐.

중지시키고 재시작하면 퍼블릭ip가 바뀜.

 

17.보안그룹

VPC의 소속이라서 내일 자세히 알아봄,

원하는 게이트만 허용 allow할 수가 있다.

외부 트래픽에 대해 Deny는 불가.

Statefule한 방화벽 서비스.

EC2인스턴스는 여러 보안그룹과 연동할 수 있다.

 

 

 

<실습>

80만 허용해주면 포트를 80으로만 접속할 수 있다.

모든 TCP포트를 허용하는게 default

 

EC2인시턴스 인바운드 규칙을 적용시킴.

보안그룹은 EC2의 네트워크를 차단은 못하지만 특정 포트만 허용을 가능하다.

 

18.EC2연결방법

1) SSH키로 연결하기

키페어를 사용해서 로그인을 한다.

SSH로 로그인하려면 SSH키페어를 무조건 사용해야함.

 

2) RDP연결

윈도우즈는 이거사용.

 

3) EC2인시턴스 연결

인턴은 접속못하게 막기. 9시에서 6시까지만 허용하기

IAM인증. 권한 조절 가능.

 

이렇게하면 수많은 권한들이 있을텐데 중앙서비스 관리 ROLE에서 효율적으로 관리가 가능하다.

 

<실습>

IAM사용자 권한 생성후, EC2에 IAM 역할 등록.

IAM과 관련된 모든 엑션을 와일드카드로 붙여서 모든 액션 가능하게도 가능.

기존키페어 설정.

IAM역할 선택 가능.

여러 IAM 역할 중에 내가 고른 역할을 EC2에 부여 가능.

$sudo -s

$ aws iam list-users

 

기존에 있는 EC2인시턴스 삭제하기.

계속 만들었다 삭제했다 가능

aws configure하지 않아도 바로 확인가능.

별도의 엑세스키와 시크릿엑세스키를 사용하지 않더라도 확인가능.

이 롤과 바로바로 연결되어있기 때문에.

권한을 부여하기위한 좋은 방법은 IAM역할을 사용하는것!

 

18. ENI와 elastic ip

내 엑세스키와 시크릿 엑세스키가 유출되면 알림이 온다.

ENI: 탄력적 네트워크 인터페이스

가상의 랜카드를 나타냄.

elastic ip: 확보해놓고 사용안하면 비용부과. 사용하면 무료.

중지 해놓고 재시작해도 고정 퍼블릭ip를 사용가능.

 

<실습>

내가 갖고 있는 아이피를 옮길 수 있다.

고객사 ip는 고정되어있을것이니,

인시턴스가 바뀔예정이다? 그러면 엘라스틱 ip를 사용해서

기존에 있는 ip를 그대로 사용할 수 잇음.

EC2인시턴스는 그대로 놓고

고객사에 지연없이 연동 시킬 수 있음.

$httpd start

elastic ip가 연결해놨다가 유저의 서비스 중단없이 ip동일하게 배포 가능.

퍼블릭 ip가 인시턴스가 중지된 상태에서도 유지가 되어있는 걸 볼 수가 있다.

안쓸땐 타임아웃 ip도 꼭 종료를 시켜놔야 요금이 안나감.

 

 

 

- 수직확장 (온프레미스 환경)

같은공간에 더 많은 인스턴스를 쓰려고 할 때

성능은 16배확장되지만 비용은 30배 이상 들어간다.

성능은 백만배의 성능을 가진 인스턴스를 만드려고하면 수직확장의 한계점이 명확하다

- 수평확장 (클라우드 환경) >> Autoscaling의 특징

성능을 늘린 만큼에 비례하여 비용증가. (쓰려는 만큼만 늘릴 수 있음)

다수의 인시턴스를 확보할 필요는 없고 필요한 만큼쓰고 다시 다 돌려주면됨.

클라우드적 환경에 적용할 수 있는가.

 

20. AWS의 EC2 Autoscaling

특징>

- 인스턴스 개수 보장.

미리 개수 정해놔서 얼마 이하나 얼마 이상 늘어나지 않도록 유지시킨다.

그 정해논 숫자만큼 인스턴스를 추가하거나, 삭제함

- 다양한 스케일링 정책적용가능

user가 늘어나면 서버가 두 대로 바뀌었다가 user가 줄어들면 줄였다가 할 수 있음.

네트워크 패킷이 늘어나면 또 인스턴스 개수를 바꿨다가 할 수 있음.

하나의 가용영역에 몰리지 않도록. 자동으로 여러 인스턴스 영역에 분산되도록 정책적용 가능.

여러 가용영역에 EC2인스턴스를 고르게 분산시킬 수 있다.

- 인스턴스 비용 이외에 별도 사용비용 발생함.

 

구성>

시작구성: 무엇을실행시킬지

모니터링: 정책부합하는지

설정: 얼마나실행시킬지

EC2인시턴스 개수조정가능!!

 

<실습>

.시작구성 생성하기

AMI선택 AMI id로 복사하기 인시턴스 유형을 t2로 실행

EBS볼륨

.auto스켈링 생성하기.

애는 앞으로 미리정해준 시작구성을 가지고 EC2인시턴스를 알아서 생성할것임

.그룹크기 및 조직 정책 구성

인시턴스 개수 지정해줌.(실제사용시 몇백개도 설정가능)

CPU상태나 등등 모니터링 결과를 sns로 알람을 받을 수 있다.

실행했을 때 인스턴스가 현재 0개다. 라고 원인을 말해주고 알아서 1개로 올림.

.자동조정 정책(시나리오)

평균 CPU가 50%보다 낮으면 인스턴스를 내리고, ...

시간단위로 CPU사용량을 볼 수 있다.

AWS에서는 모두 지표로 확인한다. 왜 인스턴스가 조절되었는지 원인도 기록해줌.

.를라우드 와치 -> 3일차에 봄

CPU기반으로 경고를 만듬. 알람에 따라서 인스턴스를 조정

임계값은 3분동안 3개의 데이터가 변경된 경우

 

 

21. ELB (Elastic Load Balancer)

자동으로 트래픽을 분산한다. 상태가 양호한

오토 스켈링 그룹이 있을 때 인시턴스들을 분산처리를 해주려면 각 ip주소를 알고있어야하잖아

근데 인시턴스가 추가 삭제되면서 ip주소가 바뀐다. 이걸 관리하기위해 로드밸런싱이 필요하다.

로드 밸런서가 트래픽을 분산해주는 것이다.

파일이 보이는지 체크를 계속 해줌.

EC2인스턴스는 정상적이지만 어플리케이션이 정상적이지 않은 상황에서 트래픽을 수신할 수 있다고 생각할 때 auto스켈링과 연동이 가능하다.

그래서 로드벨런서는 아이피가 아니라 도메인기반으로 쓴다

 

> ELB의 종류

1) Application Load Balancer (ALB)

트래픽을 읽어서 똑똑하게 라우팅한다.

도메인을 가지고 라우팅가능.

도메인 주소를 보고 라우팅할 대상(target)그룹을 설정한다.

(대상그룹: Lambda, ...)

OSI 7계층에 위치한다.

 

2) Network Load Balancer (NLB)

빠름. 도메인 주소를 못 읽음(http프로토콜 미지원)

elastic IP를 할당가능하다. 고정 아이피 유지.

 

3) 게이트웨이 로드밸런서(GLB)

4) 클래식 로드밸런서(안씀)

 

 

<실습>

오토스켈링그룹에 ALB를 생성.

인스턴스셋업.

스토리지 추가. 태그추가.

인스턴스 시작검토 시작구성 생성.

인간이 하다보면 인스턴스 생성할때도 실수가 있을수있음. 이때를 위해서 오토스켈링 필요

2) EC2인스턴스로 대상그룹을 설정해보기.

test.html로 하면 그 파일이 있어야지만 상태가 온전하다고 판단한다.

웹서버 두 개를 성성.

로드밸런서 생성.

활성화 상태가 되었음. ip주소없이 모든 dns기반!

두 인시턴스를 로드밸런싱했음 그래서 2개의 창으로 보임

health check을 했을 때 비정상인 인스턴스는 보이지 않음

웹서버 아까 만들어놓은 것은 서비스를 등록안해놨기 때문에 인스턴스가 올라가자마자

사용자데이터: EC2인스턴스가 취할 액션을 정의해놓음.index.html에 인스턴스 ID기재하기

보안그룹, 키페어 설정 하고

오토 스켈링 그룹을 새로 만든다.

시작구성은 템플릿으로 설정.

고급옵션 설정에서 기존 로드 밸런서에 연결한다.

기존에는 EC2만 살아있으면 되는데 ELB에 체크하면

index.html이 없다(오류발생)할 때 EC2인시턴스를 새걸로 바꿔버림.

그래서 유저가 볼때는 에러가 난지모름.

AMI에 서비스 httpd를 쓰지 않았는데도 아까정의해둔 사용자데이터 시나리오로 실행됨.

index.html에 인스턴스 ID기재하기.

한쪽으로 인스턴스가 몰리지 않도록 로드밸런서가 두 인스턴스를 번갈아 보여준다.

오토스켈링 단위로 인스턴스를 묶어놓으면 관리하기가 편하다

(가끔 날리면 안되는 인스턴스를 날리거나 하는일이 없음!)

 

 

22. 아마존 엘라스틱 파일시스템

읽후쓰(Read after Write)일관성

 

<실습>

시작구성 생성

아마존 엘라스틱 파일시스템 생성

인스턴스 유형 t2.micro 무료기 때문에 씀.

NFS

사용자에 액션주기: 디렉토리랑 파일하나 생성하고. 테스트페이지에서 확인

오토스캘링 그룹생성

가용영역 모두 선택

로드밸런서를 이번엔 안씀

용량은 두 개 설정

자동으로 인스턴스가 올라간다.

다른 인스턴스 사용했는지는 테스트페이지에 인스턴스 id를 찍어서 확인

서로다른 ip주소를 사용

하나의 EFS안에 두 개의 인스턴스를 놔서 EC2인스턴스 하나 날라가면 다른 인스턴스를 바라보게.

 

 

다음중 올바른 솔루션을 고르세요.

AWS에서 문제를 해결하는 방법은 다 제각각임.

아키텍쳐 어떤 목적에 따라 집을 짓는지

EFS는 빅데이터를 사용할 때 엄청큰 데이터를 다수가 사용할 때

스팟인스턴스와도 관련. 스팟은 올라갔다 내려갔다를 반복함

EFS는 용량을 따로 정해주지 않아요

EBS는 용량을 설정해줘야함.

 

 

23. AWS의 컨테이너 서비스

 

24. AWS의 라우트53 서비스

가용성과 확장성 뛰어남.

DNS포트명이 53번임!

문자열검색 가능

특정문자열이 있는지 없는지 판단

데이터 센터 운영하다가 클라우드로 옮길 수 있다.

 

TTL: 얼마나 오랫동안 인스턴스가 살아있느냐

application loadbalancer로 호스팅하는 경우 느낌이 다르다

 

 

25. 인증서 없이 https를 호스팅하기

https에다가 인증서깔고, 돈내고 해야하는데,

인증서 없이하려면 세가지 필요

 

<실습>

https가 없는 상태

ACM이라는 서비스: 보유하고 있는 도메인에 무료로 https를 사용할 수있어요.

도메인에 와일드카드를 쓴다.

DNS검증 라우트53이 검증해주는게 편리

새로 발급받은 인증서확인

라우트 53에서 자동으로 레코드 생성.

AWS서비스들만 쓸 수 있는 인증서.

리스너 추가하기

아까는 80번으로 들어오는 거에 대해서 반응했고

https는 443으로 들어오는 포트에 대해 반응 하도록 설정한다.

보안리스너 설정

80으로 들어오던, 443으로 들어오던 유저한텐 80으로 보임

라우트 53을 설정하면 빠르게 디커플링이 되어있어서 빠르게 변환가능

라우트 53을 통해 필요한 어플리케이션만을 따로 만듬.

ACM에서 만든 인증서를 활용한다.

헬스체크를 각각 하게 함.

https로 요청했으나 받는 입장에서는 http로 보임

ALB가 중간에서 트래픽을 받아다가 EC2에 전달한다.

그러기 때문에 https로 요청해도 받는 입장에서는 http로 받음

25. 아마존 클라우드 프론트

요청하고자하는 서버의 거리가 먼경우에는 엣지로케이션을통해 데이터 캐싱

정적동적 컨텐츠 모두 호스팅 가능.

 

<실습>

원본 도메인은 퍼블릭 아이피 사용.

객체 캐싱의 TTL(Time to Live)

얼마나 살건지. 86400초 = 하루동안 산다.

원본서버가 아무리 바뀌어도 TTL을 지정해둔 시간이 있다면

유저가 보기에는 TTL만큼 같은 화면만 보인다.(캐싱때문)

완료후 기다리기.

전세계 모든 엣지로케이션에 배포가 되어야해서 오래걸린다.

지리적제한 어떤 지역 (일본)에는 접속을 막아놓을 수 있다.

무효화 : 특정 캐싱을 날려버림.

변경된 사항을 그때그때 반영하려면 무효화 필요.

개발할때는 TTL을 짧게, 운영중일때는 TTL을 길게가 일반적임.

클라우드 프론트를 계속 새로고침해도 캐싱이 남아있어서 처음것만 계속보임.

(엑세스 로그도 안남음)

원본컨텐츠의 부하 줄여주는게 가장큰 목적.

클라우드 프론트 사용시 전세계에 저비용으로 빠른 호스팅가능.

원본서버 수정 후 TTL이 지나면 적용됨.

만약 무효화를 생성하면 캐싱없이 변경될 때마다 보임. 캐싱날라감.

 

당연히 라우트 53으로 호스팅이 가능함.

클라우드 프론트 배포할때는 별칭을 꼭 입력

오류페이지 설정하기 : http오류코드에 따라 보여줄 페이지를 설정할 수있음.

 

클라우드프론트는 전세계 서비스다.

클라우드 프론트를 통해 라우트53과 연결해 볼 수도있음

serveless 서버없이 -> 3일차에 알아봄.

클라우드프론트 서비스를 사용하면 수월하게 배포가능

 

 

시나리오1

가장 효율적인 아키텍쳐

답: AWS클라우드 프론트 서비스를 활용할 것이다.

시나리오 설정해놓는거 그거 활용해서 50%미만인거

라우트53으로도 호스팅이 가능하고

캐싱을 유지할 TTL을 설정할 수 있기 때문에

 

시나리오2

가장 효율적인 배포방법

비용걱정없이 지불하겠다?

답:

 

 

 

AWS, EC2를 비롯한 다양한 활용방법

엄청많은 기능들이있지만

AWS의 기능, 활용법 제시한 강의였다.

AWS의 주요서비스 알려주고,

S3를 비롯한 다양한 스토리지 서비스, VPC, AWS의 서블레스(서버없는 아키텍쳐)

 

AWS의 S3서비스를 통해서 파일을 공유드리겠다.

버킷: 파일을 공유, 저장하는 서비스

 

 

*****************

AMI (Amazon Machine Image)

인스턴스를 시작하는데 필요한 정보 제공.

인스턴스를 시작할 때 AMI를 지정.

하나의 AMI에서 여러 인스턴스 시작 가능.

- 1개 이상의 EBS(Elastic Block Store) 스냅샷 또는 인스턴스 스토어 기반 AMI의 경우 인스턴스 루트 볼륨에 대한 템플릿(OS, app server, application...)

- AMI를 사용하여 인스턴스를 시작할 수 있는 AWS 계정을 제어하는 시작권한

- 시작될 때 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스 매핑

 

04/05

AWS강의 2일차

 

> 1일차 리뷰

시나리오1)

유저가 몰린다 -> 트래픽분산. ALB(Application Load Balancer)사용하기

장애 발생시 알람줘야한다 -> health check 후 alarm 생성

 

고가용성: 장애를 극복하고 서비스를 지속할 수 있는거

장애 내구성: 장애 발생 시 서비스 중단없이 진행하는거

 

Autoscaling 입장에서는 장애 내구성있게

 

EC2 권한부여: 엑세스키와 시크릿엑세스키를 넣을 수도 있지만 역할을 부여할 수있다.

 

 

> public subnet

우리가 어제 웹서버 만들어서 외부에 존재했잖아요

퍼블릭 서브넷 이라서.

 

> CIDR (Classless Inter Domain Routing)

class 없이 여러 개의 사설망을 구축하기 위해 망을 나누는 방법.

 

> VPC (Virtual Private Cloud)

AWS 계정 전용 가상 네트워크. 가상으로 존재하는 데이터 센터.

AWS 계정 생성시 기본으로 모든리전에 VPC가 기본으로 1개씩 생성되어있음

EC2 인스턴스처럼 AWS Resource들을 VPC에서 실행 가능.

다양한 서브넷 구성(네트워크 분리)

- IP주소 범위와 VPC범위를 설정, 서브넷 추가, 보안그룹 연결, 라우팅 테이블 구성.

 

> 서브넷

리전마다 둘이상의 기본 서브넷과 가용영역 생성.

하나의 가용영역에는 하나의 서브넷 존재.

하나의 서브넷에는 하나의 가용영역(AZ) 안에 존재.

 

> 라우팅테이블

서브넷 안에 라우팅테이블이 존재.

172.31.0.0/16

라우트 테이블은 위에서부터 아래로

트래픽이 날라왔을 때 이 서브넷 안에 있다면 local로 보냄.

그 외 나머지는 모두 인터넷으로 보낸다.

 

> nat gateway는 대변인 역할을 한다.

인터넷으로 나갈때는 nat gateway를 통해서 나간다.

 

> 베이스쳔 호스트 (Bastion Host)

public EC2에 접속할 수 있는 방법은 베이스쳔 호스트를 사용할 수 있다.

외부에서 내부 서브넷으로 가는거에 대해 통제를 한다.

nat gateway은 외부로 나가는 트래픽에 대해 통제를 한다.

 

> 보안그룹 (SG, Sercurity Group)

보안그룹에서 허용할 포트들을 적용해놓고,

허용목록에 없으면 포트가 못들어온다.

stateful하다? inbound로 들어온 ip와 달라도 응답이 가능하다.

포트를 80번으로 보낼 때 우리가 응답은 에페메럴 포트(달라지는 임시포트)로 받음.

보안그룹은 똑똑하다.

아웃바운드 할 때 ip가 달라져도 보안그룹은 stateful하게 기억하기 때문에 전달한다.

 

> NACL

NACL은 stateless 해서 별도의 트래픽이 필요하다.

NACL은 서브넷 앞에 위치.

보안그룹과 차이는 서브넷 단위.

port의 허용도 가능하지만 Deny도 가능

 

<실습>

기존 보안그룹 사용

모든 TCP에 대해 allow 함.

아웃바운드 규칙 날리기

들어오는 포트에 대해서 모두 허용

$ sudo -s

$ yum install httpd 하면 에러남

why? stateful하기 때문에 들어오는것에 대해선 그냥 내보내지만,

외부로 나가는 것은 제한한다. 아웃바운드 룰에 영향받는다.

 

아웃바운드 규칙: 좀비피시가 되거나 그럴 때 아웃바운드가 안나갈 수 있다.

인바운드 규칙과 차이 이해안됨.

 

NACL 모든 트래픽 허용 했다가

$ service httpd start

인바운드 규칙 편집 - 포트의 80번 Deny해서 80번으로 요청하면 안보임

 

클라이언트가 접속할때마다 에페메럴 포트(Aphemetal Port, 임시포트)는 계속 변하기 때문에

보안그룹은 그걸 인지하고 있음. -> stateful

 

> S3 (Simple Storage Service)

AWS의 꽃. 고가용성(99.9%), 장애 내구성(99.999999999%). 무제한 용량.

파일 보관만 가능한 객체 스토리지 서비스. 어플리케이션은 설치 불가함.

(<-> Block Storage Service (EBS,EFS)와 차이)

글로벌 서비스. 전 세계 배포. (단, 데이터는 리전에 저장)

- MFA(멀티팩터인증, 보안강화)를 통해 객체 삭제 방지 가능.

- versioning 형상관리 가능. 특정시점으로 복구.

- 엑세스 로그 생성 및 전송 가능.

 

>버킷 : S3의 저장공간을 구분하는 단위

버킷이름은 전 세계에서 고유함.

새로 생성시 기본적으로 private.

 

 

<실습>

버킷생성. 버킷이름은 전세계 고유해야함.

EC2를 위한 IAM 생성.

EC2에 권한부여하려면 역할 부여.

EC2 인스턴스 생성.

사용자 데이터에 액션 작성.

요금 정책 이따가.

S3는 어플리케이션같은걸 설치할 수없는게 큰 차이다.

NFS는 EC2에서 주로 사용한다.

중요한 이미지, 모델링.

용량이 큰 파일들.

AMI에 고정된게 최신 이미지 파일, 최신 소스코드 가져오려면 S3에 저장된 파일들

 

 

> S3의 클래스들 (요금 정책)

- S3 스탠다드

- S3 Intelligent Tiering

데이터 사용 빈도(패턴)을 분석하다가 자동으로 다른 클래스들로 변경해 줌.

- S3 스탠다드 IA (Infrequently Accessed, 자주 사용안하는)

자주 쓰지 않는 데이터를 불러 올 때마다만 비용지불. 저렴.

- S3 one Zone-IA

저렴한 대신 저내구성

- S3 glacier Instanat Retrieval (빙하지만, 급할 땐 즉시 Access)

아카이브(유물)용 저장소.

 

 

<S3스토리지 실습>

스토리지 클래스를 직접 변경할 수는 있다.

intelijent class 에 넣어두면 사용주기 패턴을 파악해서 자동으로 클래스를 바꿔준다.

 

모든 퍼블릭 엑세스 차단/ 해제 가능

차단해 둔 경우 Access Denied 메시지가 뜸.

Principal에 특정시간, 특정사람 등 접속하여 액션을 할 수 있는 객체 조건을 넣을 수 있음.

객체 잠금: 지정된 기간 혹은 무제한으로 절대 삭제하지 않게 만들어 둘 수 있다. 풀 수 있는 권한을 줄 수 있다.

 

버킷에 버전 관리.

버킷삭제는 버킷이 비어있어야 만 가능.

버킷 정책 수정

 

> 파일 공유하는 방법

원하는 유저에게만 권한을 줘야한다.

수동 파일공유 시 인증방법

: IAM 유저, Access Key ID/ Secret Access Key

IAM 유저는 5천개까지만의 제한이 있다. 만료기간 설정 및 권한 관리 어려움.

 

> S3 (presigned URL)

미리 서명된 임시 URL로 파일을 공유.

마패를 가진 사람이 왕의 권한을 대리한다.: 암행어사

생성자가 가진 권한 중 일부/전체를 사용.

 

 

<실습 presigned URL>

이미지를 url에 올려놓고 접근제한 시켜보기.

$ sudo -s

$ aws s3 presign {http://~} --region ap-northest-2

이렇게 해서 생성된 url을 통해서만 이미지를 볼 수 있다.

--expires-in 파라미터를 url에 부여

정해진 기간동안만 url에 접속할 수 있다. (만료기간 지정가능)

 

AWS의 IAM을 통해서 권한을 확보한 다음 부여 가능.

 

S3 full access를 날리면 credential

권한이 있을 때 권한을 삭제하게되면 ??무슨말??

 

presigned url test 이후 리소스 정리.

정리안하면 인스턴스 비용 발생하니깐.

 

 

> S3의 호스팅

정적 컨텐츠 호스팅: 서버없이 웹호스팅 가능. 고가용성, 장애 내구성

동적 컨텐츠 호스팅: 서버필요.

 

<실습 정적호스팅>

버킷만들기

웹사이트니까 퍼블릭 엑세스 차단해제.

모든 사람이 볼 수 있게 버킷 정책 설정.

정적 웹사이트 호스팅

자기가 만든 정적파일들을 업로드한다.

장점: 무료. 서버를 24시간 돌릴 필요가 없어요.

개인 포트폴리오 만들땐 정적 호스팅 해버려라.

rubywave.io -> 본인이 리액트로 만든 포폴사이트

 

동적주소는 어떻게 만드나?

route53에서 S3 웹사이트 엔드포인트에 대한 별칭.

라우트53은 전세계 배포기 때문에 기다림.

S3에서 라우트53 으로 호스팅 할 때 버킷이름과 내가 호스팅할 주소가 이름이 똑같아야함.

도메인과 비슷하게 고유한 도메인 설정

asianaidt.com

 

어제배운 Cloud Front

https가 아닐 때 클라우드 프론트로 해결!

커스터마이징

http로 들어와도 리다이렉트 https로 되게 설정.

https 어제 배운 AWS거 인증서 넣기

클라우드 프론트를 사용하면 다양한 리다이렉션 가능.

대체 url설정할 수가 있다.

static 사이트를 사용하면 비용절약가능

serverless로 구성 -> 3일차

배포과정도 빠르고 서버가 내려가지 않기때문에 주말에 전화받을 일도 없음.

 

 

> S3 기능

- 이벤트, 다른 서비스들(SNQ, SQS, Lambda) 호출 가능.

- 버전 관리

- 복제

- 역추적(backtrack)

 

 

--- 점심 이후

 

<실습: 아테나를 통한로그분석>

버킷 생성

glue 크롤러를 추가하고 데이터 스토어에 저장하도록 EC2 역할 부여

DB추가 table 추가

크롤러: 데이터가 여러 가지 있을 때 엄청난 데이터를 정형화시키고 샘플링하는 작업을 해서 테이블에 스키마로 넣는다.

크롤러는 ETL 이다.

크롤러가 다 돌고나면 테이블이 생성된다.

테이블은 또 편집도 가능.

아테나에서 진짜 DB처럼 쿼리로 데이터 조회도 가능.

user가 어떤 메뉴에서 어떤 작업을 했는지 유저의 행동을 로그로 분석할 수 있다.

다른 테이블과 조인하려면 elastic 오픈 서비스? 를 활용할 수 있다.

S3에서 호스팅하는게 AWS에서 호스팅하는게 비용최적화 할 수 있다.

 

아키텍쳐에서보면 로그를 그냥 계쏙 버킷에 쌓는다.

이걸 크롤러가 수집해주면 아테네에서 분석한다.

 

 

> AWS의 RDS

- 관계형 DB를 제공하는 AWS의 서비스

- 가상 머신 위에서 동작

- 암호화 지원(프로그램 내부에서 암호화가 되는건 아님)

- 자동 백업 지원 (일정 주기마다 스냅샷 제공, 다시 그 시점으로 롤백 가능)

cf) 오로라는 이걸 더 극적으로 바꿈

- 내부에서는 EC2 활용(EBS설정)

- 인증방법: IAM DB인증 가능

- 클라우드 인프라 차원의 관리는 AWS에서 다 해주기 때문에 Auto

DBA입장에서 인프라차원의 관리는 AWS,

프로그래밍은 직접 해야한다.

- RDS의 DB엔진

 

 

> Multi AZ(멀티가용영역)

퍼포먼스 성능향상이 아니라 안정성을 위함.

스탠바이DB가 항상대기하고 있는데 접근은 불가하다.

장애가 났을 때 자동으로 경로를 만들어준다.

장애복구를 위한 서비스

성능에 도움이 되느냐? 안됨.

그냥 장애났을때만 복구를 하는 애기 때문에.

그러나 비용청구도됨.

무조건 고가용성과 장애내구성이 중요한건아니다.

저런 스탠바이(엑스트라 리소스)를 사용하면 고가용성과 장애내구성이 좋아지겠지만 비용이 두배가 든다.

 

<-> 읽기전용 복제본

이거는 안정성이아니라 성능(퍼포먼스) 향상을 위한 서비스

RDS가 페일이 났을 때 수동으로 복제함.

 

 

> RDS 멀티리전

DR: 디제스션 리코버리 (장애복구)

한 리전에서 장애난 경우 다른 리전에서 가능하도록 시나리오를 짬

 

> 오로라(Aurora)

관계형 DB엔진.

RDS에서 제공하는 DB엔진 이기도함.

RDS보다 5배 빠른데 10분의 1의 비용임.

오직 AWS에서만 사용가능.

serverless 서비스.

데이터 분산저장기능

데이터가 없어지면 자동으로 혼자 치유가 됨.

 

RDS는 읽기 쓰기 레이어가 같이 있었음.

오로라는 따로 있어서 읽기 역할이었던 애가 바로 쓰기 역할로 변환 가능

멀티 마스터모드 중요!!

읽기쓰기가 둘다 가능함.

하나가 터지더라도 시스템 장애가 발생하지 않음.

읽기였던 레이어가 쓰기였던레이어로, 그 반대로도 가능하기때문.

 

> Aurora Global Data base

RPO 장애났을 때 얼마나 백업되느냐

RTO는 얼마나 빨리 복구되느냐.

전세계에 일초만에 복제가능

 

> Aurora 클로닝

기존 클러스터를 삭제해도 제대로 동작.

객체를 클로닝할 때 스토리지 노드와 컴퓨팅노드가 분리되어

다른 write가 오면 연결을 끊고 새로 카피 write를 생성시킴.

버그가 났을 때 바로 복제 가능. 효율적.

 

> Aurora 역추적

어느시점만큼 DB를 되돌릴지 미리 지정

디비 생성할 때 미리 활성화 시켜놔야함.비용도 지불

오로라는 MySql만 지원

 

> Aurora 다중마스터

각 노드는 독립적.

고가용성과 달리 지속적인 가용성 제공.

 

<실습 오로라 역추적>

Aurora DB엔진 생성

serverless: 유저들이 사용하지 않을때는 돈이 안나감.사용할때마다 돈나감.

DB클러스터 식별자

EC2 인스턴스 생성

퍼블릭 엑세스 허용

역추적 활성화 체크 - 대상 역추적 기간 설정(24입력): 최대 24시간까지 되돌릴 수 있게 지정

DB클러스터 역추적을 하면 지정해준 시간으로 되돌아감.

ex. 1분에 한번씩 데이터 넣었다가 2시 25분시점의 DB로 역추적해서 되돌리기.

25분시점의 DB로 돌렸다가 27분 시점의 DB로 또 돌릴 수도 있음. (쿼리문없이!)

 

클론해서 미리 떠놓고 다시 돌릴 수도 있음.

자동 백업보다 backtrak이 초단위로 더 정밀하다

자동 백업은 시간단위, 최대 35일.

 

클라우드 와치로 관리를 할 수 있다.

개발적 비용 절감 가능

Aurora 디버깅

마이크로 튜닝, 파라미터 튜닝 쉽게 가능.

 

참고) AWS 아키텍쳐 다이어그램 아이콘이 제공이 됨.

아키텍쳐 다이어그램 만들 때 Draw.id 사용도 좋음.

 

 

<실습: 3Tier 어플리케이션 아키텍쳐>

RDS를 생성.

EFS(파일 시스템) 생성 - EC2 인스턴스 생성

보안그룹 구성 default

 

워드프레스를 셋업을 하고 이걸 AMI로 만든 다음,

 

$ chkconfig httpd on <- 서비스에 등록함.

 

$chown -R ec2-user: ec2user /var/www/html

EC2그룹에 권한주기

 

워드프레스 디렉토리 만들기

mount 포인트 설정하기

$ mount -a

워드프레스를 다운받아서 ESF에 넣는다.

워드프레스를 폴더에다가 복사를 함

권한을 확장해서 또 넣는다.

이제 워드 프레스에 권한을 부여한다.

ftp에 넣는다.

로드밸런서 생성

Auto scaling 그룹 생성

워드프레스를 접속했을 때 이미지가 보이는데,

이 이미지를 어떻게 불러오는지 보면 ip가 다른 곳에서 불러오고 있다.

EC2의 ip주소는 변할 수 있기 때문에 이런 것.

만약 이미지를 불러오던 ip주소를 가진 EC2인스턴스가 죽어버리면 갑자기 이미지가 안보이게 될 수 있다는 문제가 있다!

해결법

1) Route53에서 호스팅영역에 레코드를 생성하고 어플리케이션 로드밸런서(ALB)를 생성한다.

그래서 IP주소가 아닌 도메인으로 호출했을 때 살아있는 EC2 인스턴스만을 바라보게 하면 된다.

2) elastic ip를 사용해서 실행중인 인스턴스를 바라보게 한다. - 이건 로드밸런서를 사용하지 않아서 방화벽 문제가 있을 수 있음.

실습 다하고 리소스정리 (ALB는 상당히 비싸기 때문에 꼭 정리)

 

 

> 그 외 AWS가 제공하는 Database 서비스

- 넵튠 : 관계중심

- 오픈서치서비스: 원하는 데이터 찾도록 커스터마이징.elastic서비스

- QLDB: 원장(장부) 서비스. 데이터의 무결성 중요.

- 아마존 타임스트림: 많은 IO발생 할 때 시간단위로(나노세컨드까지지원) 저장하는 DB

ex. 벚꽃축제 팔찌있으면 주변 상점 할인. 유저의 소비패턴 데이터를 모을 수 있음.

 

--교재에 없는 내용

> Amazon Redshift

클라우드에서 완벽히 관리되는 페타바이트급 데이터베이스

data warehouse 서비스 = OLAP 데이터베이스

OLAP에 최적화됨.

병렬처리에 탁월한 성능. 컴퓨팅노드의 증감이 쉽고 빠름.

엄청 많은 디비가 병렬적으로 연결되어있는 경우.

테러바이트 용량의 디비 처리일 때

 

OLAP: 데이터 분석위주. 총판매금액, 어느주소에서 판매가 많았나? 열(col)에 관심.어떤 타입의 상품이 가장 많이 판매되었나?

OLTP: 일반적 RDS. 행에 관심. 주문번호 1번이 무슨 내용인가?

-> 서로다른 아키텍쳐 및 시스템 구조를 요구함.

--교재에 없는 내용 end

 

> AWS System Manager

일반적으로 EC2클러스터 관리하려면 user가 직접 로그인해서 만들기.

AWS 시스템매니져로 관리하면: 어느날 갑자기 취약점이 발견된 경우. 모든 인시던트에 한꺼번에 명령 때릴 수 있음. 비용 필요.

명령을 또 문서로 관리 가능. 형상관리됨. versioning.

언제 어디서 실수를 하더라도 결과는 같이 보장되는 장점.

기능

- 온프레임에서도 설치 가능.

- EC2의 인벤토리 조회. 수백개의 인스턴스의 상태 확인가능.

ex.몇 백대의 OS현황 조회,

 

> parameter store

디비 암호를 여기에 저장할 수있고 이걸 볼 수 있는 사람은 따로 지정가능.

ex. rest api 주소를 동적으로 저장가능

- 암호화해서 저장 가능

KMS(key management service)를 통한 암호화

무료임. <->system manager와 차이

 

> 명령실행

여러 인스턴스에 지정된 명령을 실행해줌

 

<실습 Run commend>

EC2 fullAccess 권한 주기.

SSM은 시스템스 매니져의 약자.

미리 명령을 문서화 해두고 EC2에 대한 설정들을 일괄 변경시킨다.

시스템스 매니저를 사용해서 명령쳐보는 실습.

대상: 인스턴스 태그 지정

클라우드 워치한테 너 메모리를 수집해서 지표로 알려줘.

 

> Cloud Watch

측정을 해야만 아키텍쳐 평가가 가능하므로 사용.

AWS 서비스 전반에 대한 모니터링. 쿼리로 분석 가능.

 

<실습>

에러코드에따라 가중치를 달리 부여할 수 있음.

경보생성

지표선택 이걸 기반으로 알람(경보)을 만들거야.

지표또는 표현식이 정의된 임계값을 벗어나면 알람을 울림.

(이메일로 전송, slack, jira등으로 받아볼 수 있음.)

테스트할 때 계속 404 error를 생성한다.

임계값을 1분보다 넓게 만들면 너무 예민해진다.

구독 생성하면 느슨한 결합의 예제.

실제 row data를 기반으로 처리.

 

알람에서 여러 가지 지표를 생성할 수 있다.

cpu, 다른 액션 기반 등등

지표(metric)들의 합이 어떤 특정 상황일 때 알람을 받는다.

통계적 수치를 정해서 알람 설정.

 

이상탐지: 대역을 임계값으로 사용

평소와 다른 패턴으로 움직였을 경우 알람 울리게 설정.

 

 

*********

04/06 3일차

2일차 리뷰

3tier application: 3개의 등급이 있는 어플리케이션

 

> AWS Cloud Watch Dashboard

여러 지표를 기반으로 대쉬보드 생성 및 커스터 마이징

 

<실습 Cloud Watch Dashboard>

쿼리를 생성하고 그걸 시각화 할 수 있음

EC2 인스턴스와 관련한 지표로 저장.

대쉬보드를 공유 가능. (presigned url, 암호인증)

지표에 따라 알람 생성도 가능.

 

 

> Amazon QuickSight

다양한 AWS서비스, 외부소스와 결합가능

모니터링용

 

 

> Infrastructure as a Code (IaaC)

클라우드에서 인프라를 코드로 문서화하여 관리.

안정성(human error X), 재사용성, 형상관리.

 

> AWS CloudFormation

AWS 인프라를 form을 통해서 관리.

IaaC를 실행할 수 있게 함. 재사용, 공유, 여러 리전에 동시 배포

json보다 yaml을 많이 씀.

업데이트하다가 에러나면 자동으로 롤백.

온프레미스에 있는 data도 제어 가능.

 

<실습 클라우드 폼 생성>

yml 파일 작성. 어떤 액션을 할지 작성.

액션: IAM ROLE만듬. EC2인스턴스 만들기

AWS에 템플릿 파일로 업로드.

파라미터 형식으로 나중을 위해서 인스턴스 생성 가능

autoscaling 의 사이즈라던지, 등등 미리 해두면 편리.

스택이름 작성.

스택실패 옵션: 모든 스택 리소스 롤백, 성공적으로 프로비저닝된 리소스 보존.

알림 옵션 - 알림에서는 SNS 항상 나옴.

이렇게 실행하면 몇십개 몇백개의 인스턴스를 찍어낼 수 있음.

무엇이 변경될 예정인지도 미리 알려줌.

리소스정리도 이걸로 해노면 알아서 해줌

 

serverless 환경의 Lambda(작게 쪼갬) : 단위별, 기능별로 올라감.

 

> 비동기화

독립적 Decoupling = 확장성, 안정성. 느슨한 결합.

다른 어플리케이션을 바라보기만 함.

하나를 없애도 유저한테 안정적인 서비스

 

> 이벤트 기반 아키텍쳐

온프레미스와 차이.

명령이 아니라 관찰한 내용이다! 명령과 이벤트의 차이.

불변성. - 모든 아키텍쳐 처리가 온전함.

 

> Amazon EventBridge

SaaS 이거 알아야 함!

이벤트 기반 아키텍쳐에서 이벤트 버스.(온프레미스의 이벤트 포함 가능)

내가 원하는 이벤트만 필터링 가능.

이벤트 브릿지 규칙에서 받아다가 다양한 방식의 처리 가능.

유저 행동반경의 지표를 인식해서 어떻게 반응할지 미리 규칙을 정의해놓으면 자동으로 처리.

 

> AWS API Call via CloudTrail

CloudTrail: AWS의 CCTV.

미리 지정된 이벤트 이외의 상황 처리.

CloudTrail 의 로그를 통해 이벤트를 발생시키는 방법.

 

> Amazon SQS(Simple Queue Service)

AWS의 디커플링 서비스. 큐 서비스

하나의 메시지를 단 한 번만 처리. (1:1)

어미새가 애기새한테 모이줄때는 한명한테만 모이를 몰아 주는거.

- 유저가 영상 업로드 하고 Queue 에 쌓음

온전히 Decoupling 되어있어서 인스턴스가 죽던말던 메시지를 저장중.

특징: 안정성, 확장성, 디커플링 (느슨한 결합)

 

> Amazon SNS(Simple Notification Service)

완전 관리형 메시징 서비스

하나의 메시지를 여러 서비스에서 처리. (1:N) -> Fan-out 아키택쳐

안정성 확보는 없음. SQS와 보완적 서비스.

다양한 프로토콜로 메시지 전달 가능.

 

> Fan-out 아키텍쳐

이벤트 기반 아키텍쳐. 하나의 메시지를 다양한 서비스에서 처리

SQS, SNS 혼용가능.

 

 

> Amazon Kinesis

지속적으로 들어오는 스트리밍 데이터를 수집, 분석 처리하는 서비스.

- kinesis Data Firehose: 데이터를 수집후 변환하여 공급자에게 전달.

전달하는데에 중점. 공급자: S3, Redshift, HTTP...

 

아키택쳐의 방향: 효율성. 비용최적화. AWS서비스끼리 결합하어 리스크 줄이기

 

 

> Serverless

가장 클라우드 친화적인 방법.

서버의 관리와 프로비전없이 코드 실행가능.

물리적 서버가 없는 건 아님! 사용자입장에서만 서버를 상관할 필요가 없음의 의미.

장점: 빠른 배포, OnDemand(사용한(트래픽 발생 횟수) 만큼만 비용지불).

이벤트 기반의 아키택쳐, 병렬처리 등의 아키텍쳐의 환경에서 사용하기 좋음.

 

> AWS Lambda

이벤트 중심의 Serverless 컴퓨팅 서비스. 톱니바퀴 역할.

SaaS (서비스형 소프트웨어) 어플리케이션에서 Lambda를 트리거.

마이크로서비스 아키텍쳐. 수많은 람다들이 호출되었다가 소실되고 반복.

저렴한 가격 100만건 당 2백원 (0.2불)

호출방식 2가지

1) 이벤트에 반응하여 호출. 2) API gateway를 통해서 호출.

Lambda 의 최대 제한시간은 15분! (절대불변) 오래 걸리는 로직에는 부적합.

특징

: 동시성, 비동기식 호출(SQS와 비슷. 실패했을 때 최대 2번까지 재호출 가능.)

실패시 SQS나 SNS로 전달해서 다시 처리.

- versioning 가능. 원하는 시점으로 복구 가능.

- Lambda 의 임시 스토리지: 파일 저장할 때

수많은 람다에 EFS(Elastic File System)를 붙여 구성하여 EFS에서 data를 가져올 수 있다.

유저의 실시간 스트리밍중에도 로직 처리 가능.

 

> DB Proxies 데이터베이스 프록시

RDS 프록시가 알아서 Lambda 커넥션 관리.

커넥션 이미지 증가하는 숫자보다 error발생이 증가하면

RDS 프록시가 디커플링하게 존재하여 처리해줌.

 

> VPC

Lambda가 vpc 내부에 위치하면 실행 가능.

(Lambda는 외부에서도 사용가능한데, 인터넷 사용하려면 NAT GW등의 리소스가 필요함.)

 

<실습 Lambda 사용해보기>

AWS에서 제일 많이 쓰이는 엔티티가 EC2와 Lambda.

버킷 생성. 이벤트 알림 생성.

이미지 리사이징 예제

객체에 대한 여러 가지 이벤트가 발생할 경우 Lambda를 호출하여 트리거.

 

권한부여: IAM 역할.

환경변수: Lambda코드 내에서 변수로 생성하여 분기처리 가능.

코드 서명: 권한없으면 아예 못바꾸게.

람다는 코드(로직)만 올리는 거기 때문에 코드만 수정가능함.

EC2보다는 코드 바꾸기가 쉬움.

Lambda 의 아웃풋 내용을 json기반으로도 생성 가능

 

 

점심이후에는

severless 기반의 ~

 

 

> Amazon DynamoDB

관계형 DB가 아님. NoSql에 가까움. 다큐먼트 DB

덜 효율적인 구조. 단순함. 검색이 빈약한 편. 다른 DB와 병행사용 추천.

serverless NoSQL DB

스키마가 존재하지 않아서 type에 제한이 없음.

특징

- key를 사용해서만 쿼리 가능.

- serveerless 서비스. 순간적으로 많은 트래픽이 발생해도 잘 처리됨.

- stateless(람다도 동일) 상태가 저장이 안됨. 다른 DB나 파일 시스템을 병행사용 필요.

구성

- 파티션키: 일반적으로는 고유키. 하나의 속성으로 구성되는 기본키

- 정렬키: 파티션키+복합키. 기록들이 어떻게 정렬될지.

 

> Amazon API Gateway

Lambda를 호출하는 방법 중 하나. (ex. 프론트에서 백을 호출하게 가능)

외부 서비스도 생성/관리 가능한게 특징. 다양한 서비스와 연동.

API Key를 가진 사람들만 사용가능하게 보안관리

사용량 추적도 가능. Http 프로토콜(REST API) 지원.

 

 

<실습 Serverless 기반 채팅 어플리케이션>

user가 웹소켓 접속후 유저 목록에 추가, 유저접속끝나면 유저접속 제거

API호출시 채팅목록을 기록. 채팅방에 있는 유저 목록 기록

Dynamo DB Access 권한 생성.

Cloud Watch full Access 생성

하나하나씩 함수 만들기 노가다

 

같은 zip파일로 백엔드 소스 돌림

네 개의 함수 생성. 동일한 역할 부여.

zip파일로 업로드 하면 됨.

chat_get: 채팅을 가져오는 함수

그냥 zip파일로 코드 업로드 하면됨.

스테이지 생성, 웹소켓 API로 설정.

 

S3웹사이트로 생성

Aurora

RDBMS는 사람들이 사용할 때마다 비용지불

어마무시한 리소스들이 포함되어 있을텐데

 

고가용성: 장애가 발생하면 서버가 죽었다가 해결

장애내구성은 장애가 발생하더라도 그냥 서비스가 계속 지속됨

 

> EC2를 자동으로 시작 종료하기

 

> AWS Step Fuctions

워크플로우를 관리.

시작이후에 여러 상태(state)를 거쳐서 종료까지 도달하는데 여기서 상태를 구현.

제작하는 상태-> 포장하는 상태-> 배송하는 상태->...

15분이상 장시간이 걸리는 상태를 람다 말고 어떻게 관리할까? 스텝펑션스!

Event Bridge 등 다양한 서비스가 워크플로우를 실행하게 관리함.

Event Bridge : event에 반응하여 state 제공

 

 

>AWS의 캐싱서비스

Redis는 멀티쓰레드가 안되지만 스냅샷이 됨.

Memcached는 멀티스레드 가능.

 

> AWS의 Artifact는 서비스는 아니고 일종의 저장장소이다.

 

> 유의할점

Penetration Test: 보안취약점 점검

 

> 클라우드 트레일: 감사를 위함. cctv.단순한 AWS사용로그들 전부 저장.

클라우드 워치 : 퍼포먼스(성능) 체크, 서비스가 잘돌아갔는지만 필요.

 

 

***** 물어볼거

혹시 EC2의 사이즈에 따라서 CPU의 메모리 숫자도 달라질까요? O

특정한 VPC를 다른 리전에다가 확장도 가능할까요? X

그럼 VPC를 타 AWS계정이랑 공유는 가능하겠죠??

 

> AWS 비용 원칙

미리 내지 않고, 사용한 만큼만내고,

많이 많이 쓰게되면 더 할인이 커지고 예약할수록 더 적게된다.

데이터통신은 AWS의 바깥으로 나간 데이터에 대해서만 요금발생!

S3 파일 다운로드 하는 경우 비용 발생.

외부에서 들어온 데이터에 대해서는 부과되지 않음.

AWS 내부 서비스 간에(EC2-RDS) 통신할때는 요금발생 없음.

정한 이상은 비용이 나가지 않게 예산설정이 가능.

 

 

> CICD

자주 빌드하고 자주배포하여 유저에게 빠르게 제품을 전달하자.

버그 없이 안정적으로.

파이프라인 구축

깃헙, 젠킨스와 연결하면 굉장히 편리.

 

> AWS　code service

AWS CodeCommit: AWS버전의 Github

AWS CodeBuild: CI/CD중에 CD를 담당.

 

 

API gateway를 통해서 API를 호출

AWS를 효율적으로 사용하려면 다양한 서비스를 함께 사용해야 좋음.

 

 

> Well-Architected Framwork

아키택쳐 컴퓨팅 사례 ex. 코트파이프라인이 있고 코드 커밋을 사용해서 스텝펑션스를 사용하고

원칙 >

운영우수성

보안성

안정성

성능효율성(serverless 아키택쳐의 우선 적용을 항상 고려. Lambda로 해결)

비용최적화

지속가능성

느슨한 결합(X)

 

람다와 EC2가 함께 혼용될 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

끝나면

그 서버리스 기반 채팅 어플리케이션 돌리셨던

Demo-serverless-chat-backend 소스코드 패키지 받을 수 있는지 문의

상업적 사용없이 개인학습용으로만 사용하고 싶습니당!

이론-> DEMO순서로 진행

유튜브에 강의있음

 

1. 클라우드컴퓨팅이란?

 

인터넷에서 종량요금제 방식으로 클라우드 서비스 플랫폼을 통해 컴퓨팅 파워, 데이터베이스 스토리지, 애플리케이션, 기타 IT리소스를 ~

IT리소스를 인터넷을 통해 온디맨드로 제공하고 사용한 만큼만 비용을 지불하는 것

필요한 만큼 계속쓰는 것이 온디맨드임.

 

 

2. 서버-클라이언트 아키텍처

 

스킬사전정보를 주고

이중에 하나라도 제대로 전달이 안되면 전체상태가 어그러진다.

스킬시전한 정보를 유저가 서버한테 보내준다.

중앙 서버에서 모두 관리하기 때문에 괜찮은

 

 

3. 데이터 센터: 어플리케이션의 서버룰 호스팅하는 실제 시설

데이터센터 운영에 필요한 인프라: 컴퓨터시스템을 위한 하드웨어,네으퉈킹장비,전원 공급장치,전기시스템,백업 발전기,환경제어장치(에어컨, 냉각기,팬),운영인력

 

- 데이터센터의 문제점

운영 비용이 많이 소요됨.

 

> 데이터센터운영과 AWS 비교

- 집을 직접 짓는 경우 (데이터센터 운영)

내가 원하는대로 커스터마이징 가능

단점 : 투자비용많이듬, 기간오래걸림, 상황변경에 쉽게 대처하기 힘들다, 유지보수를 직접 해야함.

 

- 호텔에 머무는 경우 (AWS 사용)

사용한만큼 돈을 지불: OnDemend 온디맨드

유지보수 필요없음, 유연한 사용가능, 투자비용 적음,

단점 : 내껏이 아님. 빌려쓰기 = 클라우드

다쓰면 반납함.

 

4. 클라우드 컴퓨팅의 장점

 

- 자본비용을 가변비용으로 대체,

막대한 초기비용을 쓰는 대신 쓰는 만큼만 비용지불

 

- 규모의 경제

한 개를 사는거보다 백개를 사는게 단가가 낮음.

AWS는 제일큰 서버기 때문에 AWS를 같이 이용하는 모든 고객과 공동구매를 하는 효과.

 

- 용량추정 불필요

시스템이 안정적으로 돌아가려면 최대 사용량에 맞춰야한다.

데이터센터는 피크를 최대 사용량으로 설치해놓으니 사용량 중 잉여 자원이 남게된다.

그런데 클라우드 컴퓨팅을 사용하면 딱 쓴 만큼만 내기 때문에 최대 용량을 추정할 필요가 없다.

불확실한 수요 예측에서 오는 손해가 적음.

 

- 속도 및 민첩성 개선

몇 번의 클릭으로 바로 리소스 확보 가능

개발비용 절감.

 

- 데이터센터보다 인프라 관리비용보다 비즈니스 자원(마케팅, 인건비 등)에 집중할 수 있다.

- 빠른 확장성.

- 온디맨드: 공급중심이 아닌 수요에 반응해서 서비스를 제공하는 것

 

- 유지보수가 쉬움

장애가 발생하면 그냥 시스템끄고 다른 시스템빌리면됨.

 

 

5. 클라우드 컴퓨팅의 유형

 

6. 클라우드 컴퓨팅의 모델

 

아래부터 네트워크., 00, 저장공간, 컴퓨팅, OS, APP

인프라만 제공.

IaaS: 주방만 빌리기 (인프라만 제공)

PaaS: 레시피, 주방기기만 공유주방으로 가져가서 쓰는 것

인프라+OS+ 런타임 제공

SaaS: 라면 자판기임 모두 제공해줌(전부다 빌리기)

 

> 배포모델

공개형: 모든 부분이 클라우드에서 실행

폐쇄형:

혼합형(공개+폐쇄) : 대규모면 대규모일수록 폐쇄형에서 공개형으로 바뀔 때 그 과도기에서 이횽

대부분 폐쇄형이지만, 공개형으로 백업을 진행.

 

7. 고가용성과 장애내구성

- 고가용성

장애상황을 해결하고 서비스를 지속할 수 있는 능력

장애상황의 준비가 되어있는 아키텍쳐가 필요

- 장애 내구성, 내결함성 : 장애상황에 구애를 받지 않는 능력, 장애가 발생하더라도 바로 대응할 수 있게, 비용많이 듬

 

타이어하나가 터지면 운전불가능 : 고가용성은 갖췄지만 장애내구성은 갖추지못함

엔진하나가 고장나더라도 계속 운행가능: 고가용성과 장애내구성 둘다 갖춤.

심정지 환자

 

- 재해복구: 장애상황 복구하기

- 확장성: 서버를 늘릴수있는거

- 탄력성: 수요에따라 능력과 용량을 줄였다 늘였다하는거 (elastic)

쿠키런이 오후 네시에 서버 잔뜩늘렸다가 새벽두시되면 서비 용량을 줄임.

 

8. 긴밀한 결합과 느슨한 결합

중요한 개념!!!

긴밀한 결합: 다른 주체에 대해 단단하게 얽혀있음 예) 우리몸

상태변경 어려움, 하나바꾸면 다른것도 다바꿔야함

느슨한 결합: 다른 요소에 얽히지 않고 연결되어있음. 독립적

주체끼리 낮은 의존성을 갖고있어서 쉽게 변경할 수있고 유연함.

한 개만 뺐다가 그거만 다른거로 교체가능.

예) 로봇. 뺐다꼈다 할수있음,

-> 느슨한 결합을 지향하자! (AWS 프레임워크 아키텍쳐의 원칙은 아님)

 

9. 가상화

하나의 어플리캐이션에 하나의 OS 필요

근데 하나에 서버에 다양한 OS를 운영할 수 있음.

물리적인게아니고 가상화된 서버를 제공받을 수있다.

 

10. 기타용어

- 온프레미스: 자체적으로 데이터센터 운영. 클라우드와 완전 반대.

- 프로비전 : AWS사용하기위한 준비

 

11. AWS의 구조

- AWS클라우드 하나에 다양한 전세계의 리전이 있음

 

1) 리전region? AWS의 서비스가 제공되는 서버의 물리적 위치.

각 리전에는 고유 코드가 부여됨

ap(아시아퍼시픽)

리전별로 가능한 AWS서비스가 다름

리전 선택시 고려할 것: 지연속도(범위가 너무크면), 법률적 문제(나무위키 저작권), 사용가능한 AWS서비스

 

- US-East-1 리전이 가장 중요!

가장 글로벌 서비스의 리전

 

2) 가용영역 (AZ)

리전의 하부단위. 하나이상의 데이터센터로 구성.

물리적으로 일정거리 이상 떨어져 있음.(재해 때문에, 느슨한 결합을 위해,

장애가 격리될 수 있도록)

- 가용영역의 위치 : 하나의 리전안에 두 개이상의 가용영역이 있으며 하나이상의 데이터센터로 구성

 

 

3) CDN/엣지로케이션?

 

4) 숫자별 비교

리전이 더많으냐 AZ가 많으냐

당연히 리전> 엣지 로케이션>

 

5) 글로벌 서비스

하나는 글로벌 서비스, 하나는 리전서비스임.

 

6) ARN : AWS의 리소스에 부여되는 고유아이디

형식을 외울 필요는 없음.

 

 

12. IAM 구성

아이패드에 필기 97page~

 

콘솔 엑세스 자격증명방식

MFA: 다른 자격증명에 보안을 강화하기위한 임시 비밀번호.

 

13. AWS 인증/이용방법

1) AWS 웹콘솔

2) 프로그래밍 엑세스: CLI(커맨드), SDK, 프로그램방식 엑세스 자격증명

 

 

 

> 실습(DEMO)

 

AWS 콘솔 접속

AWS 계정 새로 만들기

MFA코드 입력하기

리전이 제일 중요 : 서울리전 사용, 북미리전은 느림

스토리지추가. 태그 추가

IAM 글로벌 서비스고 여기에 사용자 추가

AWS자격유형방식은 두가지!

1) 엑세스키

2) 암호

 

권한 부여

기존정책 직접 연결 (액션과 권한 부여) 문서로되어있음

 

인스턴스에 연결

새로운 서버가 마련됨.

AWS CLI 여러 어플리케이션과 소통할 수 있는 방법

 

$ aws iam list-users

권한 없다고 나옴

$ aws configure

access key 입력하기

시크릿키 입력하기

포맷입력하기

$ aws iam list-users

하면 권한들 좍나옴

 

user한테 정책을 부여해서 권한을 없애면 안보임

 

보안자격증명을 비활성화

: 토큰자체가 없다고나옴.

IAM을 통해서 유저를 관리하고 정책을 부여할 수있음.

팀에 따라서 권한을 다르게 부여해주고 이런 시나리오를 제어.

14. EC2: 컴퓨팅을 빌려쓰는 서비스

AWS에서 가장 중요한 개념!!!!

- 하나의 EC2 인스턴스는 여러 보안그룹과 연동할 수 있다.

 

 

 

<EBS>

가상의 하드드라이브.

- 스냅샷? 증분식 방식: 바뀐 부분만 저장. 1메가만 바뀌면 1메가만 변환

- AMI: 한시간에 한번씩 AMI를 올려놓으면 그걸 받아서 사용가능

 

 

<실습>

새로운 인스턴스 실행

AMI선택 (레드햇, 윈도우,맥 ...)

우리는 아마존에서 만든 OS를 가지고 씀. 다 설치되어있어서 편리.

인스턴스 유형선택: 유형은 프리티어 무료 사용. 맥은 약정이 굉장히 큼.

인스턴스세부정보 구성하기(네트워크, 한번에 몇 개를 할지, 태넌시 구성 가능, 스팟인스턴스도 설정가능.)

스토리지추가 (EBS추가하기. 몇기가 천기가. 볼륨 암호화도 가능.)

크기, 볼륨유형 저장. 잘모르면 범용 사용, 종료시 삭제에 체크하면

태크추가 (인스턴스별로 태그 지정 가능. 팀1이 사용하는 AWS인스턴스 요금도 다르게 설정가능. EC2 인스턴스만 사용가능하게 권한 설정가능. 모든 이름은 대문자.)

보안그룹구성: 가상의 방화벽, TCP

기존 키페어 설정

인스턴스 시작

인스턴스가 프로비전 가상의 환경에서 인스턴스를 연결하기 때문에 시간이 좀 걸림

테스트 페이지

$ service http start

$ index.html 생성

테스트페이지에서 생성한 페이지 바로 확인가능

웹서버를 프로비저닝해서 웹서빙을 했다.

이미지생성 등.

마지막은 EC2 정리하기 : 종료 인스턴스

모니터링을 통해서 CPU사용량 등 확인 가능.

 

EC2 에 붙어있는 EBS를 생성해서(OS,파일,시작권한)을 EBS의 상태를 AMI에 저장해둠

이행동을 다 스냅샷에 저장해서 공유할 수 있음.

 

데이터베이스 설정하고 중요한 설정작업을 하고 AMI를 만들어놓으면 그다음부터 이어 실행 가능.

 

$ sudo -s

 

AMI를 만들어놓으면 공유, 백업 가능 최대한 자주써주는게 좋음

일정 기간마다 백업을 주는 서비스도 따로 있음

효율적으로 관리 가능.

 

15. EC2의 생명주기

모든 AMI는 EC2에서 시작한다.

 

16. EC2인스턴스

러닝상태일때만 청구됨

 

<실습>

EC2인스턴스 중지상태로 바꾸면 생성되어있던 EC2인시던스의 ip가 사라짐.

중지시키고 재시작하면 퍼블릭ip가 바뀜.

 

17.보안그룹

VPC의 소속이라서 내일 자세히 알아봄,

원하는 게이트만 허용 allow할 수가 있다.

외부 트래픽에 대해 Deny는 불가.

Statefule한 방화벽 서비스.

EC2인스턴스는 여러 보안그룹과 연동할 수 있다.

 

 

 

<실습>

80만 허용해주면 포트를 80으로만 접속할 수 있다.

모든 TCP포트를 허용하는게 default

 

EC2인시턴스 인바운드 규칙을 적용시킴.

보안그룹은 EC2의 네트워크를 차단은 못하지만 특정 포트만 허용을 가능하다.

 

18.EC2연결방법

1) SSH키로 연결하기

키페어를 사용해서 로그인을 한다.

SSH로 로그인하려면 SSH키페어를 무조건 사용해야함.

 

2) RDP연결

윈도우즈는 이거사용.

 

3) EC2인시턴스 연결

인턴은 접속못하게 막기. 9시에서 6시까지만 허용하기

IAM인증. 권한 조절 가능.

 

이렇게하면 수많은 권한들이 있을텐데 중앙서비스 관리 ROLE에서 효율적으로 관리가 가능하다.

 

<실습>

IAM사용자 권한 생성후, EC2에 IAM 역할 등록.

IAM과 관련된 모든 엑션을 와일드카드로 붙여서 모든 액션 가능하게도 가능.

기존키페어 설정.

IAM역할 선택 가능.

여러 IAM 역할 중에 내가 고른 역할을 EC2에 부여 가능.

$sudo -s

$ aws iam list-users

 

기존에 있는 EC2인시턴스 삭제하기.

계속 만들었다 삭제했다 가능

aws configure하지 않아도 바로 확인가능.

별도의 엑세스키와 시크릿엑세스키를 사용하지 않더라도 확인가능.

이 롤과 바로바로 연결되어있기 때문에.

권한을 부여하기위한 좋은 방법은 IAM역할을 사용하는것!

 

18. ENI와 elastic ip

내 엑세스키와 시크릿 엑세스키가 유출되면 알림이 온다.

ENI: 탄력적 네트워크 인터페이스

가상의 랜카드를 나타냄.

elastic ip: 확보해놓고 사용안하면 비용부과. 사용하면 무료.

중지 해놓고 재시작해도 고정 퍼블릭ip를 사용가능.

 

<실습>

내가 갖고 있는 아이피를 옮길 수 있다.

고객사 ip는 고정되어있을것이니,

인시턴스가 바뀔예정이다? 그러면 엘라스틱 ip를 사용해서

기존에 있는 ip를 그대로 사용할 수 잇음.

EC2인시턴스는 그대로 놓고

고객사에 지연없이 연동 시킬 수 있음.

$httpd start

elastic ip가 연결해놨다가 유저의 서비스 중단없이 ip동일하게 배포 가능.

퍼블릭 ip가 인시턴스가 중지된 상태에서도 유지가 되어있는 걸 볼 수가 있다.

안쓸땐 타임아웃 ip도 꼭 종료를 시켜놔야 요금이 안나감.

 

 

 

- 수직확장 (온프레미스 환경)

같은공간에 더 많은 인스턴스를 쓰려고 할 때

성능은 16배확장되지만 비용은 30배 이상 들어간다.

성능은 백만배의 성능을 가진 인스턴스를 만드려고하면 수직확장의 한계점이 명확하다

- 수평확장 (클라우드 환경) >> Autoscaling의 특징

성능을 늘린 만큼에 비례하여 비용증가. (쓰려는 만큼만 늘릴 수 있음)

다수의 인시턴스를 확보할 필요는 없고 필요한 만큼쓰고 다시 다 돌려주면됨.

클라우드적 환경에 적용할 수 있는가.

 

20. AWS의 EC2 Autoscaling

특징>

- 인스턴스 개수 보장.

미리 개수 정해놔서 얼마 이하나 얼마 이상 늘어나지 않도록 유지시킨다.

그 정해논 숫자만큼 인스턴스를 추가하거나, 삭제함

- 다양한 스케일링 정책적용가능

user가 늘어나면 서버가 두 대로 바뀌었다가 user가 줄어들면 줄였다가 할 수 있음.

네트워크 패킷이 늘어나면 또 인스턴스 개수를 바꿨다가 할 수 있음.

하나의 가용영역에 몰리지 않도록. 자동으로 여러 인스턴스 영역에 분산되도록 정책적용 가능.

여러 가용영역에 EC2인스턴스를 고르게 분산시킬 수 있다.

- 인스턴스 비용 이외에 별도 사용비용 발생함.

 

구성>

시작구성: 무엇을실행시킬지

모니터링: 정책부합하는지

설정: 얼마나실행시킬지

EC2인시턴스 개수조정가능!!

 

<실습>

.시작구성 생성하기

AMI선택 AMI id로 복사하기 인시턴스 유형을 t2로 실행

EBS볼륨

.auto스켈링 생성하기.

애는 앞으로 미리정해준 시작구성을 가지고 EC2인시턴스를 알아서 생성할것임

.그룹크기 및 조직 정책 구성

인시턴스 개수 지정해줌.(실제사용시 몇백개도 설정가능)

CPU상태나 등등 모니터링 결과를 sns로 알람을 받을 수 있다.

실행했을 때 인스턴스가 현재 0개다. 라고 원인을 말해주고 알아서 1개로 올림.

.자동조정 정책(시나리오)

평균 CPU가 50%보다 낮으면 인스턴스를 내리고, ...

시간단위로 CPU사용량을 볼 수 있다.

AWS에서는 모두 지표로 확인한다. 왜 인스턴스가 조절되었는지 원인도 기록해줌.

.를라우드 와치 -> 3일차에 봄

CPU기반으로 경고를 만듬. 알람에 따라서 인스턴스를 조정

임계값은 3분동안 3개의 데이터가 변경된 경우

 

 

21. ELB (Elastic Load Balancer)

자동으로 트래픽을 분산한다. 상태가 양호한

오토 스켈링 그룹이 있을 때 인시턴스들을 분산처리를 해주려면 각 ip주소를 알고있어야하잖아

근데 인시턴스가 추가 삭제되면서 ip주소가 바뀐다. 이걸 관리하기위해 로드밸런싱이 필요하다.

로드 밸런서가 트래픽을 분산해주는 것이다.

파일이 보이는지 체크를 계속 해줌.

EC2인스턴스는 정상적이지만 어플리케이션이 정상적이지 않은 상황에서 트래픽을 수신할 수 있다고 생각할 때 auto스켈링과 연동이 가능하다.

그래서 로드벨런서는 아이피가 아니라 도메인기반으로 쓴다

 

> ELB의 종류

1) Application Load Balancer (ALB)

트래픽을 읽어서 똑똑하게 라우팅한다.

도메인을 가지고 라우팅가능.

도메인 주소를 보고 라우팅할 대상(target)그룹을 설정한다.

(대상그룹: Lambda, ...)

OSI 7계층에 위치한다.

 

2) Network Load Balancer (NLB)

빠름. 도메인 주소를 못 읽음(http프로토콜 미지원)

elastic IP를 할당가능하다. 고정 아이피 유지.

 

3) 게이트웨이 로드밸런서(GLB)

4) 클래식 로드밸런서(안씀)

 

 

<실습>

오토스켈링그룹에 ALB를 생성.

인스턴스셋업.

스토리지 추가. 태그추가.

인스턴스 시작검토 시작구성 생성.

인간이 하다보면 인스턴스 생성할때도 실수가 있을수있음. 이때를 위해서 오토스켈링 필요

2) EC2인스턴스로 대상그룹을 설정해보기.

test.html로 하면 그 파일이 있어야지만 상태가 온전하다고 판단한다.

웹서버 두 개를 성성.

로드밸런서 생성.

활성화 상태가 되었음. ip주소없이 모든 dns기반!

두 인시턴스를 로드밸런싱했음 그래서 2개의 창으로 보임

health check을 했을 때 비정상인 인스턴스는 보이지 않음

웹서버 아까 만들어놓은 것은 서비스를 등록안해놨기 때문에 인스턴스가 올라가자마자

사용자데이터: EC2인스턴스가 취할 액션을 정의해놓음.index.html에 인스턴스 ID기재하기

보안그룹, 키페어 설정 하고

오토 스켈링 그룹을 새로 만든다.

시작구성은 템플릿으로 설정.

고급옵션 설정에서 기존 로드 밸런서에 연결한다.

기존에는 EC2만 살아있으면 되는데 ELB에 체크하면

index.html이 없다(오류발생)할 때 EC2인시턴스를 새걸로 바꿔버림.

그래서 유저가 볼때는 에러가 난지모름.

AMI에 서비스 httpd를 쓰지 않았는데도 아까정의해둔 사용자데이터 시나리오로 실행됨.

index.html에 인스턴스 ID기재하기.

한쪽으로 인스턴스가 몰리지 않도록 로드밸런서가 두 인스턴스를 번갈아 보여준다.

오토스켈링 단위로 인스턴스를 묶어놓으면 관리하기가 편하다

(가끔 날리면 안되는 인스턴스를 날리거나 하는일이 없음!)

 

 

22. 아마존 엘라스틱 파일시스템

읽후쓰(Read after Write)일관성

 

<실습>

시작구성 생성

아마존 엘라스틱 파일시스템 생성

인스턴스 유형 t2.micro 무료기 때문에 씀.

NFS

사용자에 액션주기: 디렉토리랑 파일하나 생성하고. 테스트페이지에서 확인

오토스캘링 그룹생성

가용영역 모두 선택

로드밸런서를 이번엔 안씀

용량은 두 개 설정

자동으로 인스턴스가 올라간다.

다른 인스턴스 사용했는지는 테스트페이지에 인스턴스 id를 찍어서 확인

서로다른 ip주소를 사용

하나의 EFS안에 두 개의 인스턴스를 놔서 EC2인스턴스 하나 날라가면 다른 인스턴스를 바라보게.

 

 

다음중 올바른 솔루션을 고르세요.

AWS에서 문제를 해결하는 방법은 다 제각각임.

아키텍쳐 어떤 목적에 따라 집을 짓는지

EFS는 빅데이터를 사용할 때 엄청큰 데이터를 다수가 사용할 때

스팟인스턴스와도 관련. 스팟은 올라갔다 내려갔다를 반복함

EFS는 용량을 따로 정해주지 않아요

EBS는 용량을 설정해줘야함.

 

 

23. AWS의 컨테이너 서비스

 

24. AWS의 라우트53 서비스

가용성과 확장성 뛰어남.

DNS포트명이 53번임!

문자열검색 가능

특정문자열이 있는지 없는지 판단

데이터 센터 운영하다가 클라우드로 옮길 수 있다.

 

TTL: 얼마나 오랫동안 인스턴스가 살아있느냐

application loadbalancer로 호스팅하는 경우 느낌이 다르다

 

 

25. 인증서 없이 https를 호스팅하기

https에다가 인증서깔고, 돈내고 해야하는데,

인증서 없이하려면 세가지 필요

 

<실습>

https가 없는 상태

ACM이라는 서비스: 보유하고 있는 도메인에 무료로 https를 사용할 수있어요.

도메인에 와일드카드를 쓴다.

DNS검증 라우트53이 검증해주는게 편리

새로 발급받은 인증서확인

라우트 53에서 자동으로 레코드 생성.

AWS서비스들만 쓸 수 있는 인증서.

리스너 추가하기

아까는 80번으로 들어오는 거에 대해서 반응했고

https는 443으로 들어오는 포트에 대해 반응 하도록 설정한다.

보안리스너 설정

80으로 들어오던, 443으로 들어오던 유저한텐 80으로 보임

라우트 53을 설정하면 빠르게 디커플링이 되어있어서 빠르게 변환가능

라우트 53을 통해 필요한 어플리케이션만을 따로 만듬.

ACM에서 만든 인증서를 활용한다.

헬스체크를 각각 하게 함.

https로 요청했으나 받는 입장에서는 http로 보임

ALB가 중간에서 트래픽을 받아다가 EC2에 전달한다.

그러기 때문에 https로 요청해도 받는 입장에서는 http로 받음

25. 아마존 클라우드 프론트

요청하고자하는 서버의 거리가 먼경우에는 엣지로케이션을통해 데이터 캐싱

정적동적 컨텐츠 모두 호스팅 가능.

 

<실습>

원본 도메인은 퍼블릭 아이피 사용.

객체 캐싱의 TTL(Time to Live)

얼마나 살건지. 86400초 = 하루동안 산다.

원본서버가 아무리 바뀌어도 TTL을 지정해둔 시간이 있다면

유저가 보기에는 TTL만큼 같은 화면만 보인다.(캐싱때문)

완료후 기다리기.

전세계 모든 엣지로케이션에 배포가 되어야해서 오래걸린다.

지리적제한 어떤 지역 (일본)에는 접속을 막아놓을 수 있다.

무효화 : 특정 캐싱을 날려버림.

변경된 사항을 그때그때 반영하려면 무효화 필요.

개발할때는 TTL을 짧게, 운영중일때는 TTL을 길게가 일반적임.

클라우드 프론트를 계속 새로고침해도 캐싱이 남아있어서 처음것만 계속보임.

(엑세스 로그도 안남음)

원본컨텐츠의 부하 줄여주는게 가장큰 목적.

클라우드 프론트 사용시 전세계에 저비용으로 빠른 호스팅가능.

원본서버 수정 후 TTL이 지나면 적용됨.

만약 무효화를 생성하면 캐싱없이 변경될 때마다 보임. 캐싱날라감.

 

당연히 라우트 53으로 호스팅이 가능함.

클라우드 프론트 배포할때는 별칭을 꼭 입력

오류페이지 설정하기 : http오류코드에 따라 보여줄 페이지를 설정할 수있음.

 

클라우드프론트는 전세계 서비스다.

클라우드 프론트를 통해 라우트53과 연결해 볼 수도있음

serveless 서버없이 -> 3일차에 알아봄.

클라우드프론트 서비스를 사용하면 수월하게 배포가능

 

 

시나리오1

가장 효율적인 아키텍쳐

답: AWS클라우드 프론트 서비스를 활용할 것이다.

시나리오 설정해놓는거 그거 활용해서 50%미만인거

라우트53으로도 호스팅이 가능하고

캐싱을 유지할 TTL을 설정할 수 있기 때문에

 

시나리오2

가장 효율적인 배포방법

비용걱정없이 지불하겠다?

답:

 

 

 

AWS, EC2를 비롯한 다양한 활용방법

엄청많은 기능들이있지만

AWS의 기능, 활용법 제시한 강의였다.

AWS의 주요서비스 알려주고,

S3를 비롯한 다양한 스토리지 서비스, VPC, AWS의 서블레스(서버없는 아키텍쳐)

 

AWS의 S3서비스를 통해서 파일을 공유드리겠다.

버킷: 파일을 공유, 저장하는 서비스

 

 

*****************

AMI (Amazon Machine Image)

인스턴스를 시작하는데 필요한 정보 제공.

인스턴스를 시작할 때 AMI를 지정.

하나의 AMI에서 여러 인스턴스 시작 가능.

- 1개 이상의 EBS(Elastic Block Store) 스냅샷 또는 인스턴스 스토어 기반 AMI의 경우 인스턴스 루트 볼륨에 대한 템플릿(OS, app server, application...)

- AMI를 사용하여 인스턴스를 시작할 수 있는 AWS 계정을 제어하는 시작권한

- 시작될 때 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스 매핑

 

04/05

AWS강의 2일차

 

> 1일차 리뷰

시나리오1)

유저가 몰린다 -> 트래픽분산. ALB(Application Load Balancer)사용하기

장애 발생시 알람줘야한다 -> health check 후 alarm 생성

 

고가용성: 장애를 극복하고 서비스를 지속할 수 있는거

장애 내구성: 장애 발생 시 서비스 중단없이 진행하는거

 

Autoscaling 입장에서는 장애 내구성있게

 

EC2 권한부여: 엑세스키와 시크릿엑세스키를 넣을 수도 있지만 역할을 부여할 수있다.

 

 

> public subnet

우리가 어제 웹서버 만들어서 외부에 존재했잖아요

퍼블릭 서브넷 이라서.

 

> CIDR (Classless Inter Domain Routing)

class 없이 여러 개의 사설망을 구축하기 위해 망을 나누는 방법.

 

> VPC (Virtual Private Cloud)

AWS 계정 전용 가상 네트워크. 가상으로 존재하는 데이터 센터.

AWS 계정 생성시 기본으로 모든리전에 VPC가 기본으로 1개씩 생성되어있음

EC2 인스턴스처럼 AWS Resource들을 VPC에서 실행 가능.

다양한 서브넷 구성(네트워크 분리)

- IP주소 범위와 VPC범위를 설정, 서브넷 추가, 보안그룹 연결, 라우팅 테이블 구성.

 

> 서브넷

리전마다 둘이상의 기본 서브넷과 가용영역 생성.

하나의 가용영역에는 하나의 서브넷 존재.

하나의 서브넷에는 하나의 가용영역(AZ) 안에 존재.

 

> 라우팅테이블

서브넷 안에 라우팅테이블이 존재.

172.31.0.0/16

라우트 테이블은 위에서부터 아래로

트래픽이 날라왔을 때 이 서브넷 안에 있다면 local로 보냄.

그 외 나머지는 모두 인터넷으로 보낸다.

 

> nat gateway는 대변인 역할을 한다.

인터넷으로 나갈때는 nat gateway를 통해서 나간다.

 

> 베이스쳔 호스트 (Bastion Host)

public EC2에 접속할 수 있는 방법은 베이스쳔 호스트를 사용할 수 있다.

외부에서 내부 서브넷으로 가는거에 대해 통제를 한다.

nat gateway은 외부로 나가는 트래픽에 대해 통제를 한다.

 

> 보안그룹 (SG, Sercurity Group)

보안그룹에서 허용할 포트들을 적용해놓고,

허용목록에 없으면 포트가 못들어온다.

stateful하다? inbound로 들어온 ip와 달라도 응답이 가능하다.

포트를 80번으로 보낼 때 우리가 응답은 에페메럴 포트(달라지는 임시포트)로 받음.

보안그룹은 똑똑하다.

아웃바운드 할 때 ip가 달라져도 보안그룹은 stateful하게 기억하기 때문에 전달한다.

 

> NACL

NACL은 stateless 해서 별도의 트래픽이 필요하다.

NACL은 서브넷 앞에 위치.

보안그룹과 차이는 서브넷 단위.

port의 허용도 가능하지만 Deny도 가능

 

<실습>

기존 보안그룹 사용

모든 TCP에 대해 allow 함.

아웃바운드 규칙 날리기

들어오는 포트에 대해서 모두 허용

$ sudo -s

$ yum install httpd 하면 에러남

why? stateful하기 때문에 들어오는것에 대해선 그냥 내보내지만,

외부로 나가는 것은 제한한다. 아웃바운드 룰에 영향받는다.

 

아웃바운드 규칙: 좀비피시가 되거나 그럴 때 아웃바운드가 안나갈 수 있다.

인바운드 규칙과 차이 이해안됨.

 

NACL 모든 트래픽 허용 했다가

$ service httpd start

인바운드 규칙 편집 - 포트의 80번 Deny해서 80번으로 요청하면 안보임

 

클라이언트가 접속할때마다 에페메럴 포트(Aphemetal Port, 임시포트)는 계속 변하기 때문에

보안그룹은 그걸 인지하고 있음. -> stateful

 

> S3 (Simple Storage Service)

AWS의 꽃. 고가용성(99.9%), 장애 내구성(99.999999999%). 무제한 용량.

파일 보관만 가능한 객체 스토리지 서비스. 어플리케이션은 설치 불가함.

(<-> Block Storage Service (EBS,EFS)와 차이)

글로벌 서비스. 전 세계 배포. (단, 데이터는 리전에 저장)

- MFA(멀티팩터인증, 보안강화)를 통해 객체 삭제 방지 가능.

- versioning 형상관리 가능. 특정시점으로 복구.

- 엑세스 로그 생성 및 전송 가능.

 

>버킷 : S3의 저장공간을 구분하는 단위

버킷이름은 전 세계에서 고유함.

새로 생성시 기본적으로 private.

 

 

<실습>

버킷생성. 버킷이름은 전세계 고유해야함.

EC2를 위한 IAM 생성.

EC2에 권한부여하려면 역할 부여.

EC2 인스턴스 생성.

사용자 데이터에 액션 작성.

요금 정책 이따가.

S3는 어플리케이션같은걸 설치할 수없는게 큰 차이다.

NFS는 EC2에서 주로 사용한다.

중요한 이미지, 모델링.

용량이 큰 파일들.

AMI에 고정된게 최신 이미지 파일, 최신 소스코드 가져오려면 S3에 저장된 파일들

 

 

> S3의 클래스들 (요금 정책)

- S3 스탠다드

- S3 Intelligent Tiering

데이터 사용 빈도(패턴)을 분석하다가 자동으로 다른 클래스들로 변경해 줌.

- S3 스탠다드 IA (Infrequently Accessed, 자주 사용안하는)

자주 쓰지 않는 데이터를 불러 올 때마다만 비용지불. 저렴.

- S3 one Zone-IA

저렴한 대신 저내구성

- S3 glacier Instanat Retrieval (빙하지만, 급할 땐 즉시 Access)

아카이브(유물)용 저장소.

 

 

<S3스토리지 실습>

스토리지 클래스를 직접 변경할 수는 있다.

intelijent class 에 넣어두면 사용주기 패턴을 파악해서 자동으로 클래스를 바꿔준다.

 

모든 퍼블릭 엑세스 차단/ 해제 가능

차단해 둔 경우 Access Denied 메시지가 뜸.

Principal에 특정시간, 특정사람 등 접속하여 액션을 할 수 있는 객체 조건을 넣을 수 있음.

객체 잠금: 지정된 기간 혹은 무제한으로 절대 삭제하지 않게 만들어 둘 수 있다. 풀 수 있는 권한을 줄 수 있다.

 

버킷에 버전 관리.

버킷삭제는 버킷이 비어있어야 만 가능.

버킷 정책 수정

 

> 파일 공유하는 방법

원하는 유저에게만 권한을 줘야한다.

수동 파일공유 시 인증방법

: IAM 유저, Access Key ID/ Secret Access Key

IAM 유저는 5천개까지만의 제한이 있다. 만료기간 설정 및 권한 관리 어려움.

 

> S3 (presigned URL)

미리 서명된 임시 URL로 파일을 공유.

마패를 가진 사람이 왕의 권한을 대리한다.: 암행어사

생성자가 가진 권한 중 일부/전체를 사용.

 

 

<실습 presigned URL>

이미지를 url에 올려놓고 접근제한 시켜보기.

$ sudo -s

$ aws s3 presign {http://~} --region ap-northest-2

이렇게 해서 생성된 url을 통해서만 이미지를 볼 수 있다.

--expires-in 파라미터를 url에 부여

정해진 기간동안만 url에 접속할 수 있다. (만료기간 지정가능)

 

AWS의 IAM을 통해서 권한을 확보한 다음 부여 가능.

 

S3 full access를 날리면 credential

권한이 있을 때 권한을 삭제하게되면 ??무슨말??

 

presigned url test 이후 리소스 정리.

정리안하면 인스턴스 비용 발생하니깐.

 

 

> S3의 호스팅

정적 컨텐츠 호스팅: 서버없이 웹호스팅 가능. 고가용성, 장애 내구성

동적 컨텐츠 호스팅: 서버필요.

 

<실습 정적호스팅>

버킷만들기

웹사이트니까 퍼블릭 엑세스 차단해제.

모든 사람이 볼 수 있게 버킷 정책 설정.

정적 웹사이트 호스팅

자기가 만든 정적파일들을 업로드한다.

장점: 무료. 서버를 24시간 돌릴 필요가 없어요.

개인 포트폴리오 만들땐 정적 호스팅 해버려라.

rubywave.io -> 본인이 리액트로 만든 포폴사이트

 

동적주소는 어떻게 만드나?

route53에서 S3 웹사이트 엔드포인트에 대한 별칭.

라우트53은 전세계 배포기 때문에 기다림.

S3에서 라우트53 으로 호스팅 할 때 버킷이름과 내가 호스팅할 주소가 이름이 똑같아야함.

도메인과 비슷하게 고유한 도메인 설정

asianaidt.com

 

어제배운 Cloud Front

https가 아닐 때 클라우드 프론트로 해결!

커스터마이징

http로 들어와도 리다이렉트 https로 되게 설정.

https 어제 배운 AWS거 인증서 넣기

클라우드 프론트를 사용하면 다양한 리다이렉션 가능.

대체 url설정할 수가 있다.

static 사이트를 사용하면 비용절약가능

serverless로 구성 -> 3일차

배포과정도 빠르고 서버가 내려가지 않기때문에 주말에 전화받을 일도 없음.

 

 

> S3 기능

- 이벤트, 다른 서비스들(SNQ, SQS, Lambda) 호출 가능.

- 버전 관리

- 복제

- 역추적(backtrack)

 

 

--- 점심 이후

 

<실습: 아테나를 통한로그분석>

버킷 생성

glue 크롤러를 추가하고 데이터 스토어에 저장하도록 EC2 역할 부여

DB추가 table 추가

크롤러: 데이터가 여러 가지 있을 때 엄청난 데이터를 정형화시키고 샘플링하는 작업을 해서 테이블에 스키마로 넣는다.

크롤러는 ETL 이다.

크롤러가 다 돌고나면 테이블이 생성된다.

테이블은 또 편집도 가능.

아테나에서 진짜 DB처럼 쿼리로 데이터 조회도 가능.

user가 어떤 메뉴에서 어떤 작업을 했는지 유저의 행동을 로그로 분석할 수 있다.

다른 테이블과 조인하려면 elastic 오픈 서비스? 를 활용할 수 있다.

S3에서 호스팅하는게 AWS에서 호스팅하는게 비용최적화 할 수 있다.

 

아키텍쳐에서보면 로그를 그냥 계쏙 버킷에 쌓는다.

이걸 크롤러가 수집해주면 아테네에서 분석한다.

 

 

> AWS의 RDS

- 관계형 DB를 제공하는 AWS의 서비스

- 가상 머신 위에서 동작

- 암호화 지원(프로그램 내부에서 암호화가 되는건 아님)

- 자동 백업 지원 (일정 주기마다 스냅샷 제공, 다시 그 시점으로 롤백 가능)

cf) 오로라는 이걸 더 극적으로 바꿈

- 내부에서는 EC2 활용(EBS설정)

- 인증방법: IAM DB인증 가능

- 클라우드 인프라 차원의 관리는 AWS에서 다 해주기 때문에 Auto

DBA입장에서 인프라차원의 관리는 AWS,

프로그래밍은 직접 해야한다.

- RDS의 DB엔진

 

 

> Multi AZ(멀티가용영역)

퍼포먼스 성능향상이 아니라 안정성을 위함.

스탠바이DB가 항상대기하고 있는데 접근은 불가하다.

장애가 났을 때 자동으로 경로를 만들어준다.

장애복구를 위한 서비스

성능에 도움이 되느냐? 안됨.

그냥 장애났을때만 복구를 하는 애기 때문에.

그러나 비용청구도됨.

무조건 고가용성과 장애내구성이 중요한건아니다.

저런 스탠바이(엑스트라 리소스)를 사용하면 고가용성과 장애내구성이 좋아지겠지만 비용이 두배가 든다.

 

<-> 읽기전용 복제본

이거는 안정성이아니라 성능(퍼포먼스) 향상을 위한 서비스

RDS가 페일이 났을 때 수동으로 복제함.

 

 

> RDS 멀티리전

DR: 디제스션 리코버리 (장애복구)

한 리전에서 장애난 경우 다른 리전에서 가능하도록 시나리오를 짬

 

> 오로라(Aurora)

관계형 DB엔진.

RDS에서 제공하는 DB엔진 이기도함.

RDS보다 5배 빠른데 10분의 1의 비용임.

오직 AWS에서만 사용가능.

serverless 서비스.

데이터 분산저장기능

데이터가 없어지면 자동으로 혼자 치유가 됨.

 

RDS는 읽기 쓰기 레이어가 같이 있었음.

오로라는 따로 있어서 읽기 역할이었던 애가 바로 쓰기 역할로 변환 가능

멀티 마스터모드 중요!!

읽기쓰기가 둘다 가능함.

하나가 터지더라도 시스템 장애가 발생하지 않음.

읽기였던 레이어가 쓰기였던레이어로, 그 반대로도 가능하기때문.

 

> Aurora Global Data base

RPO 장애났을 때 얼마나 백업되느냐

RTO는 얼마나 빨리 복구되느냐.

전세계에 일초만에 복제가능

 

> Aurora 클로닝

기존 클러스터를 삭제해도 제대로 동작.

객체를 클로닝할 때 스토리지 노드와 컴퓨팅노드가 분리되어

다른 write가 오면 연결을 끊고 새로 카피 write를 생성시킴.

버그가 났을 때 바로 복제 가능. 효율적.

 

> Aurora 역추적

어느시점만큼 DB를 되돌릴지 미리 지정

디비 생성할 때 미리 활성화 시켜놔야함.비용도 지불

오로라는 MySql만 지원

 

> Aurora 다중마스터

각 노드는 독립적.

고가용성과 달리 지속적인 가용성 제공.

 

<실습 오로라 역추적>

Aurora DB엔진 생성

serverless: 유저들이 사용하지 않을때는 돈이 안나감.사용할때마다 돈나감.

DB클러스터 식별자

EC2 인스턴스 생성

퍼블릭 엑세스 허용

역추적 활성화 체크 - 대상 역추적 기간 설정(24입력): 최대 24시간까지 되돌릴 수 있게 지정

DB클러스터 역추적을 하면 지정해준 시간으로 되돌아감.

ex. 1분에 한번씩 데이터 넣었다가 2시 25분시점의 DB로 역추적해서 되돌리기.

25분시점의 DB로 돌렸다가 27분 시점의 DB로 또 돌릴 수도 있음. (쿼리문없이!)

 

클론해서 미리 떠놓고 다시 돌릴 수도 있음.

자동 백업보다 backtrak이 초단위로 더 정밀하다

자동 백업은 시간단위, 최대 35일.

 

클라우드 와치로 관리를 할 수 있다.

개발적 비용 절감 가능

Aurora 디버깅

마이크로 튜닝, 파라미터 튜닝 쉽게 가능.

 

참고) AWS 아키텍쳐 다이어그램 아이콘이 제공이 됨.

아키텍쳐 다이어그램 만들 때 Draw.id 사용도 좋음.

 

 

<실습: 3Tier 어플리케이션 아키텍쳐>

RDS를 생성.

EFS(파일 시스템) 생성 - EC2 인스턴스 생성

보안그룹 구성 default

 

워드프레스를 셋업을 하고 이걸 AMI로 만든 다음,

 

$ chkconfig httpd on <- 서비스에 등록함.

 

$chown -R ec2-user: ec2user /var/www/html

EC2그룹에 권한주기

 

워드프레스 디렉토리 만들기

mount 포인트 설정하기

$ mount -a

워드프레스를 다운받아서 ESF에 넣는다.

워드프레스를 폴더에다가 복사를 함

권한을 확장해서 또 넣는다.

이제 워드 프레스에 권한을 부여한다.

ftp에 넣는다.

로드밸런서 생성

Auto scaling 그룹 생성

워드프레스를 접속했을 때 이미지가 보이는데,

이 이미지를 어떻게 불러오는지 보면 ip가 다른 곳에서 불러오고 있다.

EC2의 ip주소는 변할 수 있기 때문에 이런 것.

만약 이미지를 불러오던 ip주소를 가진 EC2인스턴스가 죽어버리면 갑자기 이미지가 안보이게 될 수 있다는 문제가 있다!

해결법

1) Route53에서 호스팅영역에 레코드를 생성하고 어플리케이션 로드밸런서(ALB)를 생성한다.

그래서 IP주소가 아닌 도메인으로 호출했을 때 살아있는 EC2 인스턴스만을 바라보게 하면 된다.

2) elastic ip를 사용해서 실행중인 인스턴스를 바라보게 한다. - 이건 로드밸런서를 사용하지 않아서 방화벽 문제가 있을 수 있음.

실습 다하고 리소스정리 (ALB는 상당히 비싸기 때문에 꼭 정리)

 

 

> 그 외 AWS가 제공하는 Database 서비스

- 넵튠 : 관계중심

- 오픈서치서비스: 원하는 데이터 찾도록 커스터마이징.elastic서비스

- QLDB: 원장(장부) 서비스. 데이터의 무결성 중요.

- 아마존 타임스트림: 많은 IO발생 할 때 시간단위로(나노세컨드까지지원) 저장하는 DB

ex. 벚꽃축제 팔찌있으면 주변 상점 할인. 유저의 소비패턴 데이터를 모을 수 있음.

 

--교재에 없는 내용

> Amazon Redshift

클라우드에서 완벽히 관리되는 페타바이트급 데이터베이스

data warehouse 서비스 = OLAP 데이터베이스

OLAP에 최적화됨.

병렬처리에 탁월한 성능. 컴퓨팅노드의 증감이 쉽고 빠름.

엄청 많은 디비가 병렬적으로 연결되어있는 경우.

테러바이트 용량의 디비 처리일 때

 

OLAP: 데이터 분석위주. 총판매금액, 어느주소에서 판매가 많았나? 열(col)에 관심.어떤 타입의 상품이 가장 많이 판매되었나?

OLTP: 일반적 RDS. 행에 관심. 주문번호 1번이 무슨 내용인가?

-> 서로다른 아키텍쳐 및 시스템 구조를 요구함.

--교재에 없는 내용 end

 

> AWS System Manager

일반적으로 EC2클러스터 관리하려면 user가 직접 로그인해서 만들기.

AWS 시스템매니져로 관리하면: 어느날 갑자기 취약점이 발견된 경우. 모든 인시던트에 한꺼번에 명령 때릴 수 있음. 비용 필요.

명령을 또 문서로 관리 가능. 형상관리됨. versioning.

언제 어디서 실수를 하더라도 결과는 같이 보장되는 장점.

기능

- 온프레임에서도 설치 가능.

- EC2의 인벤토리 조회. 수백개의 인스턴스의 상태 확인가능.

ex.몇 백대의 OS현황 조회,

 

> parameter store

디비 암호를 여기에 저장할 수있고 이걸 볼 수 있는 사람은 따로 지정가능.

ex. rest api 주소를 동적으로 저장가능

- 암호화해서 저장 가능

KMS(key management service)를 통한 암호화

무료임. <->system manager와 차이

 

> 명령실행

여러 인스턴스에 지정된 명령을 실행해줌

 

<실습 Run commend>

EC2 fullAccess 권한 주기.

SSM은 시스템스 매니져의 약자.

미리 명령을 문서화 해두고 EC2에 대한 설정들을 일괄 변경시킨다.

시스템스 매니저를 사용해서 명령쳐보는 실습.

대상: 인스턴스 태그 지정

클라우드 워치한테 너 메모리를 수집해서 지표로 알려줘.

 

> Cloud Watch

측정을 해야만 아키텍쳐 평가가 가능하므로 사용.

AWS 서비스 전반에 대한 모니터링. 쿼리로 분석 가능.

 

<실습>

에러코드에따라 가중치를 달리 부여할 수 있음.

경보생성

지표선택 이걸 기반으로 알람(경보)을 만들거야.

지표또는 표현식이 정의된 임계값을 벗어나면 알람을 울림.

(이메일로 전송, slack, jira등으로 받아볼 수 있음.)

테스트할 때 계속 404 error를 생성한다.

임계값을 1분보다 넓게 만들면 너무 예민해진다.

구독 생성하면 느슨한 결합의 예제.

실제 row data를 기반으로 처리.

 

알람에서 여러 가지 지표를 생성할 수 있다.

cpu, 다른 액션 기반 등등

지표(metric)들의 합이 어떤 특정 상황일 때 알람을 받는다.

통계적 수치를 정해서 알람 설정.

 

이상탐지: 대역을 임계값으로 사용

평소와 다른 패턴으로 움직였을 경우 알람 울리게 설정.

 

 

*********

04/06 3일차

2일차 리뷰

3tier application: 3개의 등급이 있는 어플리케이션

 

> AWS Cloud Watch Dashboard

여러 지표를 기반으로 대쉬보드 생성 및 커스터 마이징

 

<실습 Cloud Watch Dashboard>

쿼리를 생성하고 그걸 시각화 할 수 있음

EC2 인스턴스와 관련한 지표로 저장.

대쉬보드를 공유 가능. (presigned url, 암호인증)

지표에 따라 알람 생성도 가능.

 

 

> Amazon QuickSight

다양한 AWS서비스, 외부소스와 결합가능

모니터링용

 

 

> Infrastructure as a Code (IaaC)

클라우드에서 인프라를 코드로 문서화하여 관리.

안정성(human error X), 재사용성, 형상관리.

 

> AWS CloudFormation

AWS 인프라를 form을 통해서 관리.

IaaC를 실행할 수 있게 함. 재사용, 공유, 여러 리전에 동시 배포

json보다 yaml을 많이 씀.

업데이트하다가 에러나면 자동으로 롤백.

온프레미스에 있는 data도 제어 가능.

 

<실습 클라우드 폼 생성>

yml 파일 작성. 어떤 액션을 할지 작성.

액션: IAM ROLE만듬. EC2인스턴스 만들기

AWS에 템플릿 파일로 업로드.

파라미터 형식으로 나중을 위해서 인스턴스 생성 가능

autoscaling 의 사이즈라던지, 등등 미리 해두면 편리.

스택이름 작성.

스택실패 옵션: 모든 스택 리소스 롤백, 성공적으로 프로비저닝된 리소스 보존.

알림 옵션 - 알림에서는 SNS 항상 나옴.

이렇게 실행하면 몇십개 몇백개의 인스턴스를 찍어낼 수 있음.

무엇이 변경될 예정인지도 미리 알려줌.

리소스정리도 이걸로 해노면 알아서 해줌

 

serverless 환경의 Lambda(작게 쪼갬) : 단위별, 기능별로 올라감.

 

> 비동기화

독립적 Decoupling = 확장성, 안정성. 느슨한 결합.

다른 어플리케이션을 바라보기만 함.

하나를 없애도 유저한테 안정적인 서비스

 

> 이벤트 기반 아키텍쳐

온프레미스와 차이.

명령이 아니라 관찰한 내용이다! 명령과 이벤트의 차이.

불변성. - 모든 아키텍쳐 처리가 온전함.

 

> Amazon EventBridge

SaaS 이거 알아야 함!

이벤트 기반 아키텍쳐에서 이벤트 버스.(온프레미스의 이벤트 포함 가능)

내가 원하는 이벤트만 필터링 가능.

이벤트 브릿지 규칙에서 받아다가 다양한 방식의 처리 가능.

유저 행동반경의 지표를 인식해서 어떻게 반응할지 미리 규칙을 정의해놓으면 자동으로 처리.

 

> AWS API Call via CloudTrail

CloudTrail: AWS의 CCTV.

미리 지정된 이벤트 이외의 상황 처리.

CloudTrail 의 로그를 통해 이벤트를 발생시키는 방법.

 

> Amazon SQS(Simple Queue Service)

AWS의 디커플링 서비스. 큐 서비스

하나의 메시지를 단 한 번만 처리. (1:1)

어미새가 애기새한테 모이줄때는 한명한테만 모이를 몰아 주는거.

- 유저가 영상 업로드 하고 Queue 에 쌓음

온전히 Decoupling 되어있어서 인스턴스가 죽던말던 메시지를 저장중.

특징: 안정성, 확장성, 디커플링 (느슨한 결합)

 

> Amazon SNS(Simple Notification Service)

완전 관리형 메시징 서비스

하나의 메시지를 여러 서비스에서 처리. (1:N) -> Fan-out 아키택쳐

안정성 확보는 없음. SQS와 보완적 서비스.

다양한 프로토콜로 메시지 전달 가능.

 

> Fan-out 아키텍쳐

이벤트 기반 아키텍쳐. 하나의 메시지를 다양한 서비스에서 처리

SQS, SNS 혼용가능.

 

 

> Amazon Kinesis

지속적으로 들어오는 스트리밍 데이터를 수집, 분석 처리하는 서비스.

- kinesis Data Firehose: 데이터를 수집후 변환하여 공급자에게 전달.

전달하는데에 중점. 공급자: S3, Redshift, HTTP...

 

아키택쳐의 방향: 효율성. 비용최적화. AWS서비스끼리 결합하어 리스크 줄이기

 

 

> Serverless

가장 클라우드 친화적인 방법.

서버의 관리와 프로비전없이 코드 실행가능.

물리적 서버가 없는 건 아님! 사용자입장에서만 서버를 상관할 필요가 없음의 의미.

장점: 빠른 배포, OnDemand(사용한(트래픽 발생 횟수) 만큼만 비용지불).

이벤트 기반의 아키택쳐, 병렬처리 등의 아키텍쳐의 환경에서 사용하기 좋음.

 

> AWS Lambda

이벤트 중심의 Serverless 컴퓨팅 서비스. 톱니바퀴 역할.

SaaS (서비스형 소프트웨어) 어플리케이션에서 Lambda를 트리거.

마이크로서비스 아키텍쳐. 수많은 람다들이 호출되었다가 소실되고 반복.

저렴한 가격 100만건 당 2백원 (0.2불)

호출방식 2가지

1) 이벤트에 반응하여 호출. 2) API gateway를 통해서 호출.

Lambda 의 최대 제한시간은 15분! (절대불변) 오래 걸리는 로직에는 부적합.

특징

: 동시성, 비동기식 호출(SQS와 비슷. 실패했을 때 최대 2번까지 재호출 가능.)

실패시 SQS나 SNS로 전달해서 다시 처리.

- versioning 가능. 원하는 시점으로 복구 가능.

- Lambda 의 임시 스토리지: 파일 저장할 때

수많은 람다에 EFS(Elastic File System)를 붙여 구성하여 EFS에서 data를 가져올 수 있다.

유저의 실시간 스트리밍중에도 로직 처리 가능.

 

> DB Proxies 데이터베이스 프록시

RDS 프록시가 알아서 Lambda 커넥션 관리.

커넥션 이미지 증가하는 숫자보다 error발생이 증가하면

RDS 프록시가 디커플링하게 존재하여 처리해줌.

 

> VPC

Lambda가 vpc 내부에 위치하면 실행 가능.

(Lambda는 외부에서도 사용가능한데, 인터넷 사용하려면 NAT GW등의 리소스가 필요함.)

 

<실습 Lambda 사용해보기>

AWS에서 제일 많이 쓰이는 엔티티가 EC2와 Lambda.

버킷 생성. 이벤트 알림 생성.

이미지 리사이징 예제

객체에 대한 여러 가지 이벤트가 발생할 경우 Lambda를 호출하여 트리거.

 

권한부여: IAM 역할.

환경변수: Lambda코드 내에서 변수로 생성하여 분기처리 가능.

코드 서명: 권한없으면 아예 못바꾸게.

람다는 코드(로직)만 올리는 거기 때문에 코드만 수정가능함.

EC2보다는 코드 바꾸기가 쉬움.

Lambda 의 아웃풋 내용을 json기반으로도 생성 가능

 

 

점심이후에는

severless 기반의 ~

 

 

> Amazon DynamoDB

관계형 DB가 아님. NoSql에 가까움. 다큐먼트 DB

덜 효율적인 구조. 단순함. 검색이 빈약한 편. 다른 DB와 병행사용 추천.

serverless NoSQL DB

스키마가 존재하지 않아서 type에 제한이 없음.

특징

- key를 사용해서만 쿼리 가능.

- serveerless 서비스. 순간적으로 많은 트래픽이 발생해도 잘 처리됨.

- stateless(람다도 동일) 상태가 저장이 안됨. 다른 DB나 파일 시스템을 병행사용 필요.

구성

- 파티션키: 일반적으로는 고유키. 하나의 속성으로 구성되는 기본키

- 정렬키: 파티션키+복합키. 기록들이 어떻게 정렬될지.

 

> Amazon API Gateway

Lambda를 호출하는 방법 중 하나. (ex. 프론트에서 백을 호출하게 가능)

외부 서비스도 생성/관리 가능한게 특징. 다양한 서비스와 연동.

API Key를 가진 사람들만 사용가능하게 보안관리

사용량 추적도 가능. Http 프로토콜(REST API) 지원.

 

 

<실습 Serverless 기반 채팅 어플리케이션>

user가 웹소켓 접속후 유저 목록에 추가, 유저접속끝나면 유저접속 제거

API호출시 채팅목록을 기록. 채팅방에 있는 유저 목록 기록

Dynamo DB Access 권한 생성.

Cloud Watch full Access 생성

하나하나씩 함수 만들기 노가다

 

같은 zip파일로 백엔드 소스 돌림

네 개의 함수 생성. 동일한 역할 부여.

zip파일로 업로드 하면 됨.

chat_get: 채팅을 가져오는 함수

그냥 zip파일로 코드 업로드 하면됨.

스테이지 생성, 웹소켓 API로 설정.

 

S3웹사이트로 생성

Aurora

RDBMS는 사람들이 사용할 때마다 비용지불

어마무시한 리소스들이 포함되어 있을텐데

 

고가용성: 장애가 발생하면 서버가 죽었다가 해결

장애내구성은 장애가 발생하더라도 그냥 서비스가 계속 지속됨

 

> EC2를 자동으로 시작 종료하기

 

> AWS Step Fuctions

워크플로우를 관리.

시작이후에 여러 상태(state)를 거쳐서 종료까지 도달하는데 여기서 상태를 구현.

제작하는 상태-> 포장하는 상태-> 배송하는 상태->...

15분이상 장시간이 걸리는 상태를 람다 말고 어떻게 관리할까? 스텝펑션스!

Event Bridge 등 다양한 서비스가 워크플로우를 실행하게 관리함.

Event Bridge : event에 반응하여 state 제공

 

 

>AWS의 캐싱서비스

Redis는 멀티쓰레드가 안되지만 스냅샷이 됨.

Memcached는 멀티스레드 가능.

 

> AWS의 Artifact는 서비스는 아니고 일종의 저장장소이다.

 

> 유의할점

Penetration Test: 보안취약점 점검

 

> 클라우드 트레일: 감사를 위함. cctv.단순한 AWS사용로그들 전부 저장.

클라우드 워치 : 퍼포먼스(성능) 체크, 서비스가 잘돌아갔는지만 필요.

 

 

***** 물어볼거

혹시 EC2의 사이즈에 따라서 CPU의 메모리 숫자도 달라질까요? O

특정한 VPC를 다른 리전에다가 확장도 가능할까요? X

그럼 VPC를 타 AWS계정이랑 공유는 가능하겠죠??

 

> AWS 비용 원칙

미리 내지 않고, 사용한 만큼만내고,

많이 많이 쓰게되면 더 할인이 커지고 예약할수록 더 적게된다.

데이터통신은 AWS의 바깥으로 나간 데이터에 대해서만 요금발생!

S3 파일 다운로드 하는 경우 비용 발생.

외부에서 들어온 데이터에 대해서는 부과되지 않음.

AWS 내부 서비스 간에(EC2-RDS) 통신할때는 요금발생 없음.

정한 이상은 비용이 나가지 않게 예산설정이 가능.

 

 

> CICD

자주 빌드하고 자주배포하여 유저에게 빠르게 제품을 전달하자.

버그 없이 안정적으로.

파이프라인 구축

깃헙, 젠킨스와 연결하면 굉장히 편리.

 

> AWS　code service

AWS CodeCommit: AWS버전의 Github

AWS CodeBuild: CI/CD중에 CD를 담당.

 

 

API gateway를 통해서 API를 호출

AWS를 효율적으로 사용하려면 다양한 서비스를 함께 사용해야 좋음.

 

 

> Well-Architected Framwork

아키택쳐 컴퓨팅 사례 ex. 코트파이프라인이 있고 코드 커밋을 사용해서 스텝펑션스를 사용하고

원칙 >

운영우수성

보안성

안정성

성능효율성(serverless 아키택쳐의 우선 적용을 항상 고려. Lambda로 해결)

비용최적화

지속가능성

느슨한 결합(X)

 

람다와 EC2가 함께 혼용될 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

끝나면

그 서버리스 기반 채팅 어플리케이션 돌리셨던

Demo-serverless-chat-backend 소스코드 패키지 받을 수 있는지 문의

상업적 사용없이 개인학습용으로만 사용하고 싶습니당!