인프런 AWS 입문자를 위한 강의-Lambda, CloudFront, DynamoDB, API Gateway, Code Commit, Code Deploy, Code pipeline (22.06.01)

# Lambda

- Serverless의 주축을 담당 (sever+less, 클라우드가 직접 자동으로 서버를 생성하고 자원 관리)

- Events를 통하여 Lambda를 실행시킴

- nodejs, python, java, go등 다양한 언어 지원

- Lambda Function (람다에서 짠 코드)

 

#Lambda비용

- Lambda Function이 실행될 때만 지불

- 매달 1,000,000 함수 호출시 무료 (그 이후는 유료)

 

#Lambda특징

- 최대 300초(5분) 런타임 시간 허용(대용량데이터 처리시 종종 타임아웃. 람다함수 5분이상 돌라갈 경우임.)

- 최대 512MB의 일시적인 디스크 공간 제공(/tmp)

- 최대 5MB Deployment Package허용. AWS콘솔에서 직접 코딩을 짤 수 있지만, Local에서 다수의 파일을 하나의 압축파일을 업로드하여 Deployment를 통하여 사용할 수 있다.

- 50MB초과시 S3버킷에 저장 후 Lambda에서 파일에 대한

 

#사용사례

사례1. S3 -> Lambda -> DB

1) S3에 파일 upload하려하면 PutObject 이벤트가 발생됨. 이 이벤트는 람다함수 실행시킴

2) Lambda : 데이터를 읽어보고 데이터 변환. 불필요한 데이터 삭제. 깨끗한 데이터 올림. 다리 역할

3) DB

 

사례2. IOT -> Lambda -> SNS

1) IOT  :  ex) 자동차 주행 데이터가 들어오는 경우. 갑자기 과속을 하여 예상치 못한 속도 측정되면 Topic으로 데이터를 보냄. 동시에 Lambda 호출함.

2) Lambda : km를  ㅡ> 미국 주행단위인  mileage로 변경해줄 수 있음.

3) SNS

 

# Lambda실습

- AWS Lambda 대시보드 : 함수개수, 코드 스토리지, 전체 계정 동시성, 예약되지 않은 계정 동시성(Concurrency)

- AWS Lambda 대시보드>함수생성>테스트 : 실행결과에 대한 상세 Log정보를 알 수 있음. 

 

#Lambda 실습

상황1. S3버킷에 PutObject 발생시, Lambda함수 실행시켜라

1) Temperature.json 데이터 'S3'로 실시간 업로드된다.(PutObject)

2) Lambda함수 실행: 특정 온도 넘으면 그 온도가 언제 측정됐는지 주의하라는 메시지를 출력 반대의 경우 출력X. 

 

#CloudFront

- 특정사용자가 요청하였을 때, Edge Location을 사용하여 정적, 동적, 실시간 웹사이트 컨텐츠를 유저들에게 전달

- 컨텐츠 딜리버리 네트워크 CDN(Content Delivery Network)

- 분산 네트워크 (Distributed Network)

- 웹페이지가 현재 어디에서 불려지는지, 해당 웹 페이지에 접속한 사용자가 어느 지역에 위치하는지 근거하여 Content에 Delivery 해줌. 

- 우리가 특정 홈페이지를 방문하면 홈페이지 내용이 불려짐. CDN을 통해 html, js, 이미지파일 등 가져오는 속도 비약적으로 상승시킬 수 있음

- 상세예시

Origin : 한국에서 현재 웹사이트를 호스팅하고 있다.

다른 나라에서 홈페이지 컨텐츠 열리는 속도 latency발생. 웹사이트 호스팅 주소와 멀어질수록 더 느려짐. 

중국보다 미국이 훨씬 느림. 지연시간 각각 다름. 

전세계 유저들이 접근하려함. 콘텐츠를 한국에서 직접 전달하는 것이  아니라 Edge Location을 통해 콘텐츠를 제공한다. ex) 은행(Origin) 직접 가지 않고 ATM(Edge Location)방문.

- Edge Location은 콘텐츠 정보를 캐시에 저장함. 처음 웹사이트 접속시 캐시에 정보가 없다면,  Edge Location과 Origin(웹사이트 호스팅) 대화를 주고 받은 후, 그 정보를 Edge Location 캐시에 넣고 유저들에게 콘텐츠를 뿌림. 

즉, 콘텐츠들은 EdgeLocation의 캐시에 들어있기 때문에 Latency 현저히 줄읆. 단, 캐시는 영구적이지 않다.

 

# CloudFront 용어정리

- Edge Location : 콘텐츠들이 캐시(Cache)에 보관되어지는 장소

- Origin : 원본 콘텐츠들이 들어있는 곳. 웹서버 호스팅이 되어지는 곳. S3, EC2인스턴스가 오리진이 될 수 있음

- Distribution(분산) : CDN에서 사용되어지며 전세계에 있는 Edge Location들을 하나로 묶어 통칭하는 것.

 

#CloudFront 실습

1. S3버킷 만들기 (모든 퍼블릭 액세스 차단 체크풀기:전세계에서 access가능한 public access를 만들것이기 때문) 

2. S3버킷에서 파일 올리기. (퍼블릭 권한관리 : 퍼블릭 읽기 액세스 권한 부여함)

3. CloudFront>create Distribute>web get started>

- origin domain name  : 생성한s3버킷 선택

- Restrict Bucket Acess : yes

- Origin Access Identity: create a new Identity

- Grant Read Permisions on Bucket : yes

- Default Cache Behavior Settings : Redirect HTTP to HTTPS / Get, Head/ use a cache policy / Restrict Viewer Access(승인받은 유저만 사용 가능.) : no, Distribution Settings price class (얼마나 많은 Edge Location사용할래?) / Alternate Domain Name(DNS) / SSL Certificate : Default / HTTP versions : HTTP/2, HTTP/1.1, HTTP/1.0 > create

 

 

#DynamoDB

- NOSQL (Not Only SQL) 데이터베이스

- 매우 빠른 쿼리 속도

- Auto-Scaling 기능 탑재.(처음 DB만들면 크기가 정해지는데, 어느정도 데이터 추가되면 알아서 크기 늘리고 사용안하면 줄여줌)

- key-value 데이터 모델 지원

- 테이블 생성시 스키마 생성 필요 없음

- 모바일, 웹, IOT데이터 사용시 추천됨

- SSD 스토리지 사용(읽고 쓰는 속도 매우 빠름)

 

#DynamoDB구성

- 테이블(Table)

- 아이템 (Items) : 행과 개념이 비슷함

- 특징(Attributes)-열(column)과 개념이 비슷함

- key-value (key: age, value:78) ex) json, xml

 

#DynamoDB PK(Primary Keys)

- PK를 사용하여 데이터 쿼리

- 2가지 PK 유형이 있음

  유형1) 파티션키 (Partition Key)

            - 파티션키:cust_id -> 해시함수(cust_id의 value) -> 94C -> 94C에 저장됨

            - 고유 특징 (Unique Attribute)

            - 실제 데이터가 들어가는 위치를 결정해줌

            - 파티션키 사용시 동일한 두개의 데이터가 같은 위치에 저장될 수 없음!

  유형2) 복합키

            - 파티션키 + 정렬키

            - 예시) 똑같은 고객이 다른 날짜에 다른 물건을 구매. 

            - 파티션키 : 고객아이디, 정렬키: 날짜

            - 같은 파티션키의 데이터들은 같은 장소에 보간, 그 다음 정렬키에 의해 데이터가 정렬됨.

 

#DynamoDB데이터 접근관리

- AWS IAM으로 관리할 수 있음

 - 테이블 생성과 접근권한 부여가능

 - 특정 테이블만, 특정 데이터만 접근 가능케해주는 특별한 IAM역할 존재

 

# DynamoDB Index 

- 특정 컬럼만을 사용하여 쿼리

- 테이블 전체가 아닌 기준점(pivot)을 사용해 쿼리가 이루어짐

- 매우 큰 쿼리 성능 효과

- 2가지 Index 유형

1) Local Secondary Index

2) Global Secondary Index

 

# Local Secondary Index(LSI)

- 테이블 생성시에만 정의해줄 수 있음

- 테이블 생성 후 변경, 삭제가 불가능

- 똑같은 파티션키 사용, 그러나 다른 정렬키 사용.  ex) 테이블 -> 파티션키 동일 뷰(x) 정렬키:2019, 뷰(x) 정렬키: 2020  

 

# Global Secondary Index(GSI)

- 테이블 생성 후에도 추가, 변경, 삭제 가능

- 다른 파티션키, 정렬키 사용

- ex) 테이블 파티션키:고객아이디 ->  뷰(x) 파티션키:카테고리 정렬키:구매날짜 , 뷰(x) 파티션키:브랜드 정렬키:구매날짜

 

# DynamoDB Query vs Scan

- Query 

  - Primary Key를 사용하여 데이터 검색

  - Query 사용시 모든 데이터(컬럼) 반환

  - ProjectionExpression  파라미터 : 원하는 컬럼만 가져올 수 있음 

- Scan

  - 모든 데이터를 불러옴 (primary key  사용x)

  - ProjectionExpression 파라미터

=> Query가 Scan보다 훨씬 효율적.

 

# DynamoDB DAX

- DAX? DynamoDB Accelerator

- 클러스터 In-memory 캐시 (인메모리? SSD, 하드디스크가 아닌 캐시로 속도 향상)

- 10배 이상의 속도 향상 > 읽기 요청만!  (쓰기요청X)

- ex) Black Friday날 쇼핑 웹사이트 운영(수많은 읽기 요청 예상)

- 원리

  - DAX 캐싱 시스템 : 테이블에 데이터 삽입 & 업데이트시 DAX에도 반영

  - 읽기 요청에 맞는 데이터가 DAX에 들어있을 시, DAX에서 데이터 즉시 반환 (Cache Hit) <-> (Cache Miss)

- 단점

  - 쓰기 요청이 많은 애플리케이션에는 부절절함

  - 읽기 요청이 많지 않은 애플리케이션에는 부절절함

  - 아직 모든 지역에서 제공되는 서비스는 아님.

 

# DynamoDB Stream

-  DynamoDB 테이블에서 일어나는 일들 (삽입, 수정, 삭제 등)이 일어날 시, 시간적 순서에 맞게 Streams 에 기록

- Log는 즉각 암호화가 일어나며 24시간 동안 보관됨

- 주로 이벤트를 기록하고 이벤트 발생을 외부로 알리는 용도(ex) Lambda Function)

- 이벤트 전&후에 대한 상황 보관

- ex) DynamoDB Streams <- Lambda Function -> SNS(Simple Notification Service) -> SQS (Simple Queue Service) <-> application

 

 

#API

특정물건 장바구니에 담는 것을 요청. 중간에서 복잡한 일 처리해줌. 요청받고 요청 해결해줌. 

#Restful API?

  - API 종류들 중 하나 

  - REpresentational State Transfer : 상태에 변화를 주기 위해 그 정보를 server와 client간에 공유하고 주고 받기 위해 사용하는 것. 

- CREATE(post), READ(get), UPDATE(put), DELETE(delete)

- JSON형태로 요청을 받고 해결함. 

 

#관리가 힘든 RESTful API

- Authentication & Authorization : 회원/비회원/등급별 혜택 달리, 보이는 페이지 달리

- API요청을 모니터링 해야함 : 재고가 5개인데 10개를 주문하려는 경우 경고창 제공 등. 모니터링 

- 더 나은 성능을 위해 API요청 캐시 시스템 필요. : 사람이 일일이 처리하기 어려움.

 

#API Gateway

- 뛰어난 확장성 제공 및 API를 만들고 운영하는 모니터링 가능

- 모니터링은 CloudWatch를 통해 확인가능

- 웨이터의 역할. 

- Back-end 서비스 (웹 애플리케이션, EC2)에 들어있는 데이터 접근 허용

- Pay As You Go. API를 호출할 때. 얼마나 오래 걸리는지. 얼마나 많은 데이터를 처리하는지에 따라 금액 달라짐.

 

#API Gateway실습

customers -> api gateway -> lambda function -> DynamoDB

 

# CI/CD

- CI : Continuous Integration 지속적인 통합

내 개발코드 중앙레파지토리에 올리고 테스트하여 다른 개발자와의 코드 충돌을 막아줌. 나는 내 것에만 최선을 다하면 된다.

- CD : Continuous Deployment 지속적인 배포

개발자는 지속적으로 서비스 수정 및 배포. 사용자가 사용시 전혀 불편함 못 느끼도록 서버다운, 프로그램 일시 중지 막아줌.

 

# CI/CD의 장점

- 자동화 시스템 (Automation) - 테스트

- Incremental Change

  ex) 가격에 대한 정보가 안보일 경우, 이를 수정하기 위해 관련 기능들 먼저 수정하고 최종적으로 가격 보이도록 수정. 

내가 작성한 프로그램이 오류날 경우 다시 돌아가고 싶은데 매번 백업 귀찮고, 매번 테스트도 귀찮음. 

 

# CI/CD - 중앙 리포지토리 (Repository)

- Github

 

#Code Comit

- 다양한 파일들(코드, 사진, 라이브러리, 등등)을 보관하는 저장소 (Repository) - Github와 매우 유사

- 동시에 많은 사람들이 저장 장소 접근 및 업데이트 가능

- 버전 컨트롤 기능 제공 ex) 언제 어떻게 누가 저장 내용을 변경하였는지

 

# Code Deploy

- Automated Deployment. 자동 배포

- 장점

  1) 새로운 기능들의 빠른 배포

  2) 소프트웨어 & 서버 다운타임 X

  3) Maual 에러 X

- 2가지 배포방법

  1) Rolling 배포

      현재 production에서 돌아가는 서버. 새기능25% 새로운 서버로 

  2) Blue/Green 배포

      Blue완전히 shut down, Green을 100% 활성화

 

 

# Code Pipeline

- 하는 일?

  1) 빌드, 테스트, 배포 과정을 관리 : 코드 변경시 Code Pipeline은 이를 감지할 수 있음

  2) 소프트웨어 및 애플리케이션 출시 자동화 가능 : 빠르고 쉬운 디버깅을 가능케 해줌. 배포(Deployment) VS 출시(Release)

- 작동방법?

  -  Workflow 정의 (Code pipeline) -> 코드 저장소에서 코드 변경 (Code Commit) -> 컴파일, 테스트, 패키지 생성(Code Build) -> staging or prodcution 배포 (Code Deploy)