[PNU - AWS 세미나 ] AWS 클라우드로 디지털 혁신하기 A to Z

2019년 12월 4일 예비창업자를 위한 AWS 101 강의 내용을 정리한 것입니다.

Cloud Computing 이란
발전기 설치 —> 많은 초기비용 --> 용량의 한계 —> 많은 노력
필요할 땐 언제나 

클라우드 이전 : 데이터 센터 구축, 하드웨어 구매, 높은 초기 투자비용, 한정된 용량, 많은 공수/ 소요시간
클라우드 이후 : 필요할땐 언제나 사용한 만큼 지불, 유연한 용량, 적은 노력/소요 시간
1. 초기 투나자나 장기계약 없이
2. 인터넷을 통해 it 리소스와 앱을 
3.  원할때 언제든지
4. 사용한 만큼만 돈냄

메인프래임(1980) —> 클라이언트 서버(2000) —> 클라우드(today)

에어비앤비, 넷플릭스 슈퍼셀 배민, 슬랙 —> 클라우드 기반, 태생 기업 : 새로운 시도, 민첩성
Airbnb 사례 : 누적 숙박 1500만명 EC2인스턴스 1300대 운영팀 5명에서 관리
성장요소 : it 인력이 본질에더 집중(개발과 배포) 

왜 AWS 인가?
리프트, 넷플릭스, 옐프 등등 직방, 우형 비트윈 공통점 —> Build On AWS

기존 : 높은 선납금 유지보수 경직성 늦은 배포 매뉴얼 작엄 낮은 확장성
이후 : 운영비용(가변비용으로) 낮은 TCO(Total cost of offeset?)  유연성 빠른 배포, 핵심 역량 집중, 글로벌 시장

가용영역(서울 원래 2개 에서 올해 3개로 바뀜) : 하나는 데이터 센터의 묶음, 배포를 할때 고가용성을 생각하게 된다. 고가용성 걍 가능함
 —> 리전

- 빠른 혁신의 속도(feed back 을 통한 신규 기능 개발

스타트업 3가지 고려사항
1, 시간 - 불필요한 일은 AWS 에게(개발인력을 인프라 관리로? —> 유지관리가 아닌 비즈니스 가치를 전달하는데 집중, 
2, 돈 - 지속적인 노력과 관심이 필요하다. —> trusted adviser 비용 최적화, 예약 인스턴스 (약정) 추천, 인스턴스 최적화 등등의 알림 제시
3, 안정성/보안 - 더 안정적이 서비스를 위해 - 취약성 보고 모니터링 및 암호화 자동화 및 감사

 

Section 3 주요 AWS 서비스 소개

 

AWS 서비스 포트폴리오 : 필요한 만큼 원하는 서비스를 사용 

레고 블록에 비유 , 본인들만의 서비스를 만드는 경험을 할 수 있다. 

 

컴퓨팅 서비스 

Amazon EC2 ( Elastic Compute Cloud )

* Virtual Machine

* 재구성이 가능한 컴퓨팅 리소스 

* 쉽게 확장/축소되는 컴퓨팅 용량

* '고객 업무' 영역에 따른 다양한 인스턴스 타입 제공

* 사용한 만큼만 과금 (pay-as-you-go)

* Window나 Linux OS도 제공

 

다양한 인스턴스 타입이 있음.

(T2, T2 Unlimited , M4, M5 등)

인스턴스 사이즈는 커질 때마다 용량 및 가격이 2배 씩 증가

(small, medium, large, 등)

 

다양한 요금 옵션이 있음. 

 

On-Demand : 약정없이 쓴 만큼만 지불

Reserved : 1년 혹은 3년 약정 40~70% 할인 (예약 instance)

정기적으로 사용할 계획이 있다면 선택

Spot : 남은 자원에 대한 경매 방식으로 더 높은 가격으로 입찰할 경우 바로 양도 될 수 있으나 80~90% 저렴

(단기 컴퓨팅 리소스가 필요한 경우 - 데이터 학습 등 )

 

 

Auto Scaling : 자동 서버 확장/축소

블랙 프라이데이 같이 갑자기 트래픽이 집중된 경우 과부하가 발생할 수 있음. 과부하가 발생하면 서비스 신뢰도를 잃어버릴 수 있는데 서버의 최대 용량에 맞춰 서버 인프라를 구축하게 되면 낭비가 발생할 수 있음. 그래서 Auto Scaling을 이용해 서버가 필요할 때는 확장하고 필요가 없을 때는 수축시키는 기능. 

 

데이터베이스 

Amazon RDS(관리형 관계형 DB 서비스) - Relational Dababase Service

* DB 이중화 (Multi-AZ)

* Read Replica : DB의 사이즈를 늘려도 쿼리 속도가 낮으면 workload에 대한 분석이 필요함. read가 많을 경우가 마스터에서 read replica를 제공함. 최대한으로 인스턴스를 확장하지 않는 선에서 이런 기능을 처리할 수 있다.

* 인스턴스 확장

Amazon DynamoDB(관리형 NoSQL 서비스 )

Amazon ElastiCache

 

스토리지 

Amazon S3 ( Simple Storage Service) - 객체 스토리지 (이미지, 비디오, 파일, 스냅샷 등)

* 객체 기반의 무제한 파일 저장 스토리지

* URL을 통해 손쉽게 파일 공유 가능

* 99.999999999%의 내구성 : 데이터 유실 가능성은 거의 없다 ! 

* 사용한 만큼만 지불 (GB 당 과금)

* 정적 웹 사이트 호스팅 가능

소프트 리밋이 있어서 요청을 해야 그런 리밋을 풀 수 있는 것을 유념 

"다양한 AWS 서비스들과의 간편한 통합/연계 지원"

 

standard class - default 셋팅 , 자주 접근하는 데이터 스토리지 

infrequent Access Storage class - 자주 접근하지 않는 데이터를 저렴하게 보관, 자주 조회하는 데이터에는 부적합

Glacier - 데이터 백업용, 아카이빙, 장기간 백업 및 오래된 로그 데이터

정책을 통해 일정 기간 후에 standard에서 infrequent로 옮겨라 등의 규칙을 설정할 수 있다.

 

데이터 액세스 패턴에 대해서 잘 모를 경우 내부적으로 머신러닝이 돌아가서 패턴에 따라 자동으로 S3 intelligent-Tiering 기능을 통해 class를 설정해준다.

 

Amazon EBS (Elastic Block Store) - 블록 스토리지 : EC2에 attach 해서 쓸 수 있는 블록 스토리지 

 

Amazon CloudFront : 콘텐츠 전송 네트워크(CDN)

* 컨텐츠 (이미지, HTML 등)를 캐싱하여 성능 가속

* 전 세계 187개 엣지 로케이션: 글로벌 서비스

* AWS 서비스 -> CloudFront 간 데이터 전송 무료

: S3에서 edge로 보낼 때 ( 내부 네트워크 비용)은 무료라는 의미 (enduser가 edge로 접근할 때는 요금이 나옴)

* 글로벌 고속 백본 네트워크 확보

* DDoS 방어 무료 제공 (AWS Shield Standard)

 

Section 4 

AWS 고객 사례

Part 1. Ausoscaling : 여러분의 서비스는 충분히 탄력적인가요?

1. 디스패치 

기존 IDC 인프라의 한계점

* 특종 기사가 올라왔을 때 트래픽 처리가 어려움

* 기존 데이터센터 (IDC)에서는 트래픽 최고치 기준으로 요금이 책정되어 불합리

* 안정적이고 효율적인 인프라 운영이 중요 

 

=> AWS 서비스를 통해 

* 서버 부하 문제 해결 및 확장성 확보 (Auto Scaling 활용)

* 

 

Part2. Data Lake : 여러분의 데이터는 어떻게 관리되고 있나요?

 

Data Lake : 다양한 유형의 정형, 비정형 데이터 저장 

여러분의 데이터 홍수를 만들어서 이런 데이터로 머신러닝을 할 것인가, 하둡, 스파크를 사용하여 insight를 얻을 것인가를 결정할 수 있다. 

 

Part 3 . AI & IoT

AWS IoT 기반의 다양한 솔루션들

예지정비/ 건강 및 의료 솔루션 /생산성 및 프로세스 최적화 / 스마트 빌딩 및 스마트 시티

디바이스 플릿 관리 / 에너지 효율 모니터링 / 지불, 보험, 스마트 커머스 / 제조 시설 보호 

 

ML : 클라우드 기반 트레이닝, 엣지에서 추론

 

---

 

AWS 101 Hands-on Lab

기본 서비스 중심

 

AWS 시작하기 워밍업

22개 region으로 구성

 

지역적인 거점을 어떻게 선택할 것인가? 

(내 사용자가 가장 많이 사용하는 region을 선택하는 것이 제일 좋다 - 네트워크 문제 )

 

AWS 요금은 수요와 공급에 따라 달라질 수 있다. ( 같은 서비스라도 지역에 따라 달라질 수 있다. )

 

AWS region은 시작 초기에 반드시 2개 이상의 가용 영역으로 구성

데이터센터는 추상화 되어 있다. 

가용 영역은 특정한 거리만큼 떨어져있음. 천재지변에 영향을 받지 않기 위한 방안

 

비즈니스 요구 사항에 맞는 130여개 이상의 서비스 조립을 통해 유연한 활용이 가능하다.

 

서울 리전을 셋팅하고 EC2를 만들면 default로 서울 리전 근처에 VM이 생성된다. 

 

 

 

 

하나 가용 영역에 웹서버를 두고, 다른 가용 영역에도 웹 서버를 둔다. 로드 밸런서가 상태를 보고 두 가용 영역에 나눠서 준다. 보통 50/50으로 라운드 로빈으로 트래픽 조절을 하다가 하나가 죽으면 다른 가용 영역에 100% 트래픽 전달을 해준다. 

 

가용 영역을 서브넷이라는 단위로 쪼개놓음. 

모든 서비스는 오류가 날 수 있다는 것을 내재하고 설계해야함.

각 가용 영역은 1ms ~ 2ms latency 존재 (지리적으로는 격리되어 있지만 네트워크적으로는 거의 연결된 상태)

 

VPC 를 만든다. 하나의 리전 안에 가용 영역이 많은데 모든 가용 영역에 걸쳐서 가상의 데이터 센터를 만드는 것을 의미한다. 

 

AWS 사용하는 방법

1) AWS 콘솔

2) AWS CLI

3) AWS SDK/API

 

CIDR이란? (Classless Inter-Domain Routing)

네트워크의 주소와 크기를 표현하는 방식

 

10. 0. 0. 0 / 16 => 2^16 = 65000개의 EC2 인스턴스를 집어넣을 수 있다.

0000 1010. 0000 0000 . 0000 0000. 0000 0000

처음 16개 ( 고정 범위) , 뒤 16개 (가변 범위)

 

리전 당 5개의 VPC가 소프트웨어 리밋으로 설정되어 있다. 

VPC : 사설 네트워크 ( 인터넷으로 나가지 못하는 네트워크를 의미 )

10. 0. 0 . 0 / 8

172. 16. 0. 0 / 12

192. 168. 0. 0 / 16

 

서브넷 비트 별로 호스트의 수가 다름 ( 가급적 크게 만드는 게 좋음 가격 차이는 없기 때문에 )

 

서브넷을 늘릴 때 , region을 늘릴 때 어떻게 디자인을 설계할지 고민해봐야함.

 

VPC를 만들고 가용 영역을 구분하기 위해 서브넷을 구성 ( 서브넷은 특정 가용 영역에 매핑해야함 ) 

내부에 로직한 라우터가 있음. 내부 네트워킹을 가능하게 해줌

 

VPC는 의도하지 않으면 외부와 통신하지 않음. 외부와 연결하기 위해 필요한 것이 바로 인터넷 게이트웨이(IGW) ,생성 및 연결을 해야함.

 

10점 대 IP는 사설 IP임. 따라서 외부로 나가기 위해서는 라우팅 테이블을 수정해야함.

VPC 안에 라우팅 테이블이 이미 만들어져 있긴 함.

다수의 라우팅 테이블을 만들 수 있다. (어떤 서브넷은 외부와 연결하고 싶지 않을 때 서로 다른 라우팅 테이블을 가져야함. )

 

라우팅 테이블로 0.0.0.0/0 Internet gateway로 형성해도 못나감 public IP가 없기 때문에

 

보안 그룹은 모든 가용영역에 걸쳐서 작동함. 

방화벽은

1) Stateful : incoming만 정의하면 된다.

2) Stateless : 들어오는 것 , 응답으로 나가는 것도 따라 열어줘야함

보안 그룹은 Stateful 형식의 방화벽임

 

보안

화이트 리스트(AWS 방식) :  다 안되고 얘얘얘만 돼  

다크 리스트 : 다 되는데 얘만 안돼

 

따라서 인바운드 규칙을 통해 특정 트래픽에 대한 허용을 해줘야함.

 

네트워크 설정 끝 - 

---

컴퓨팅 리소스 설정 (EC2 인스턴스 생성)

EC2 디스크는 네트워크로 연결된 디스크임.

 

IAM 설정을 먼저 해야함 

minimum priviliage ( 가장 최소한의 권한만 줘라 )

 

AWS 거의 모든 리소스에는 태그가 존재 ( 자원이 적을 때는 보고 관리 가능하지만 자원이 많아지면 그것이 어떤 역할을 하는지, 어떤 부서의 리소스인지 알 수 없기 때문에 ! )

Key - value로 구성

 

CLI를 통해 태그 별로 관리 가능함. 

 

EC2로 돌아가 키페어를 생성해야함. (최초 1회에서만 생성 가능, 퍼블릭 키는 AWS가 가지고 있음)

키페어를 잃어버리면 로그인을 못함. (AWS는 프라이빗 키를 가지고 있지 않음!)

 

EC2 내에서 퍼블릭 IP 자동 할당을 통해 퍼블릭 IP 획득 가능

 

인스턴스를 중지했다가 다시 시작하면 퍼블릭 IP가 변경된다. 클라우드 상에서는 보통 IP보다는 DNS를 쓰라고 권고한다. 탄력적 IP ( elastic IP ) : 계정에 등록되는 IP - 고정된 IP를 할당 

 

EBS : block disk 서비스 (하드 디스크처럼 서버에 직접 붙은 디스크)

 

EC2 인스턴스에 접속하는 방법 : 1) SSH (private key 이용 ) , 2 ) AWS 관리 콘솔에서 AWS Systems Manager에 붙으면 서버로 연결 해줌 

---

커스텀 AMI 활용 (template)

기존에 만든 것을 복사해서 공장에서 찍어내듯이 설정 가능!

 

Elastic Load Balancer 

Listener : Port, HTTP/HTTPS , Routing Rules, Forward , Redirect, Authentication 설정

 

뒷단의 Health Check를 함. ping만 응답 받는다고 트래픽을 넘겨주면 안된다. 특정한 웹 페이지에 request를 했는데 응답을 안한다? 안된다. return 200이면 정상