AWS Serverless

서버리스는 서버가 없다는 뜻이 아니고 개발자가 서버에 관해서 생각하지 않아도 된다는 뜻이다. ( 서버를 프로 비저닝 하지 않아도 됨 )

서버리스가 처음 개발된 건 AWS Lambda에서였다. 이제는 대부분의 AWS서비스는 서버리스로작동이 된다.

Cognito

 

Lambda

서버를 관리할 필요가 없는 함수이다.

15분의 시간 제한이 있다.

온디맨드로 실행된다. 실행 되는 동안만 비용이 청구된다. 호출을 받으면 온디맨드로 실행된다.

스케일링이 자동화된다.

RAM의 성능을 최대 10기가 까지 올릴 수 있는데 이 때 cpu와 network성능도 같이 올라갈 것이다.

AWS cloudwatch와 같이 실행될 수 있다.

많은 프로그래밍언어를 지원한다. ( 노드제이에스 파이썬 자바 씨샵 고랭 루비 . . )

다른 aws서비스와 연결이 가능하다.

 

람다 컴테이너 이미지를 지원한다.

lambda에 컨테이너를 실행하야 할 경우 해당 컨테이너가 lambda 런타임 api를 구현하지 않으면 ecs나 fargate에서 컨테이너를 실행해야 한다.

 

서버리스 섬네일 생성

s3에 파일이 하나 업로드 되면 그 때 이벤트를 실행시켜 람다함수가 작동하도록 한다.

이 람다함수에는 s3로 작은 크기의 섬네일을 만들어 다시 업로드를 시키고, 또 dynamoDB를 실행시켜 img에 대한 정보등을 기록할 수 있다.

 

서버리스 CRON

cron이란 ec2에서 작업을 생성하는 방법이다. 5분 마다 월요일 10시마다 등등..

이건 가상서버에 실행해야 한다. 하지만 이걸 람다로도 할 수 있다.

 

cloudwatch events eventbridge를 통해서 1시간 마다 람다함수를 실행시키도록 한다,

 

Lambda한도

이 한도는 리전당 존재한다. 

시험에 잘나옴 

실행한도, 배포 한다.

실행시 메모리할당량 128 '~ 10기가

메모리는 1메가바이트씩 증가

메모르가 증가하면 더 많은 씨피유도 증가함

최대시간은 15분

환경변수는 4Kb까지 가능

임시디시크가 있다 512mb ~ 10gb

최대 1000개까지 동시 실행가능  더 증가할 숟 ㅗ있음

 

배포

환경변수는 4Kb까지 가능

압축시 최대 크기는 50 메가바이트 안하면 250 메가바이트

이 용량을 넘는 파일의 경우 /tmp 공간을 사용해야 한다.

시작할 때 크기가 큰 파일이 있으면 /tmp 디렉터리를 사용해야 한다.

 

lambda customziation at the edge

보통은 함수와 애플리케이션을 특정 리전에 배포하지만 

cloud front를 사용할 때는 엣지 로케이션을 통해 콘텐츠를 배포한다,

모던 애플리케이션에서는 애플리케이션에 도달하기 전에  엣지에서 로직을 실행하도록 요구한다.

이를 엣지 함수라고 하며 클라우드 프론트 배포에 연결하는 코드이다. 이 함수는 사용자 근처에서 실행하여 

지연 시간을 최소화 하는 것이 목적이다. 

cloudfront에는 두 종류의 함수가 있다. 

cloudfront함수와 lambda@edge이다.

 

cloudfront

자바스크립트로만이루어짐

cloudfront에 클라이언트가 요청을 보내는 것을 뷰어 요청이라고 한다.

그 다음 cloudfront가 오리진 요청을 오리진 서버에 전송한다, 

서버가 cloudfront에 오리진 리스폰을 보내면 cloudfront가 클라이언트에게 뷰어 응답을 전송한다.

확장성이 엄청 높음  초당 수백만의 요청을 처리

뷰어에만 영향을 미친다 ( 사용자 )

함수의 최대 실행시간은 1밀리초 미만이다 엄청짦음

 

사용사례 : 캐시키 생성 , 요청이나 응답에 http헤더 삽입 수정 삭제, url 다시쓰거나 리다이렉션

요청을 허용또는 거부하기 위해 jwt생성 검증.

lambda@edge

노드js python으로 이루어짐

초당 수천개의 요청을 처리

cloudfront는 오리진에게 요청을 보내거나 받아온 것을 수정하지 못했는데 이건 수정이 가능하다.

함수는 us-east-1리전에만 작성할 수 있다. 

뷰어와 오리진 모두에게 영향을 미친다. ( 사용자, 서버 )

함수의 최대실행시간은 5~10초

다른 서비스도 이 안에서 사용가능

커스터마이징이 가능

 

Lambda by default

by default , your lambda function is launched outside your own VPC ( in acn AWS owned VPC )

therefore it cannot access resources in your VPC ( rds, elasticache, internalELB ..)

하지만 인터넷의 퍼블릭 API에 액세스 하는 것은 가능하다. 

그리고 dynamoDB에도 액세스가 가능하다. dynamoDB가 AWS클라우드의 퍼블릭 리소스 이기때문이다.

 

말했듯이 프라이빗 리소스에는 접근할 수 없다. 따라서 접근하려면

우리의 VPC에서 람다 함수를 시작하면 된다. 람다에 ENI를 부착하여 VPC에 접속할 수 있다.

람다 함수에도 보안그룹을 지정해야함

 

VPC에서 lambda를 사용하는 대표적인 사용 사례는 RDS프록시이다. 

만약 람다가 직접적으로 rds에 접속을하면 커넥션이 많이생겨 쓸데없는 수평확장을 할 것이다.

이를 해결할 수 있는 방법이 RDS프록시이다.

 

람다의 연결을 이 곳으로 몰아서 rds 데이터 베이스 인스턴스의 연결을 줄인다.

프록시와 rds를 연결시킴으로써 이 커넥션 문제를 해결할 수 있다.

 

장애가 발생할 경우 장애조치 시간을 66퍼센트 줄여 가용성을 높인다. rds arura다 포함 

프록시 서버에 IAM을 강제하여 보안을 강화할 수 있다. 람다 함수가 rds프록시에 연결할 수 있으려면 

우리의 vpc안에서 람다를 실행시켜야 한다. rds프록시는 퍼블릭 액세스가 불가능하다.

람다를 퍼블릭으로 실행시키면 rds프록시에 네트워크 연결을 할 수가 없다.

 

DynamoDB

데이터가 다중 AZ간에 복제 되므로 가용성이 높다.

클라우드 네이티브이다. 독점 서비스, no sql

트랜잭션 기능이 있다.

방대한 워크로드로 확장이 가능

데이터베이스가 내부에서 분산이 된다.

iam과 통합되어 있다. 보안 권한부여 관리기능이 포함

오토스케일링 기능이 탑재되어있음

프로비저닝 할 필요 없다.

테이블 용량만 설정하면된다.

스탠다드 클래스와

ia테이블 클래스가 있다.

 

dynamodb는 테이블로 구성되며 데이터베이스를 생성할 필요가 없다.

행을 무한히 추가할 수 있다.

열을 나중에 쉽게 추가할 수 있다. null로 둘 수 있음

아이템 하나당 최대 400kb까지 밖에 저장을 못하므로 데이터가 큰 것은 저장할 수 없음

 

시험에 나오는 내용 : 스키마를 빠르게 전개해야할 때 dynamoDB를 사용하면 좋다.

 

데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야 할 때 rds나 aurora보다는 dynamoDB가 더 좋다.

테이블 하나가 존재하고 행마다 컬럼을 다르게 가질 수 있다.

 

provisioned mode (defauit)

미리 용량을 지정하고 그 지정한 만큼의 비용을 지불한다.

따라서 사전에 용량을 설정해햐 한다.

프로비저닝이라 할지라도 오토스캐일링을  통해 용량을 늘이거나 줄이거나 할 수 있다.

예상이 되는 워크로드에 적합하다.

 

on-demand

미리 용량을 계획하지 않으므로 용량을 지정하지 않는다

정확히 사용한 만큼만 지불

좀 더 비싸지만 워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용하다.

수천개의 트랜잭션, 수백만개의 트랜잭션을 1분내로 확장해야하는 애플리케이션에서는

빠르게 확장되지 않는 프로비저닝된 모드는 적합하지 않다. 온디멘드가 적당

 

트랜잭셔니없거나 많아야 4~5회인 경우에도 온디멘드가 적당하다.

 

dynamoDB Accelerator ( dax )

 

dynamodb를 위한 고가용성의 완전 무결절 인메모리 캐시로 읽기 작업이 많을 때 이 클러스터를 생성하고 데이터를 캐싱하여 읽기 혼잡을 해결한다. 마이크로초 수준의 짇연시간을 보장한다.

 

이 클러스터는 dynamodb api와 호환되므로 애플리케이션 로직을 변경할 필요가 없다.

 

다이나모 디비 앞단에서 몇몇 캐시 노드가 연결되어 있는 이 DAX클러스터를 생성하여 연결하는 것이다.

캐시의 기본 ttl은 5분이다. 

클라이언트에서 다이나모 디비로 들어올 때 사용하는 캐쉬라고 생각하자. 값이 있으면 바로 반환 없으면 다이나모디비에서 꺼내와서 저장후 반환

 

그럼 왜 elastic cache를 사용하지 않고 이걸 사용하나 ? < 이것도 비슷한 기능을 하잖아?

상황에 따라 다르게 쓸 수 있는데 집계 결과 저장같은건 엘라스틱 캐시가 더 좋고

다이나모 디비는 대용량의 연산을 저장할 때 좋다. 그래서 상호 보완적 성격을 띤다

 

다이나모 디비는 스트림 또한 처리가 가능하다.

테이블의 모든 수정 사항에 관한 스트림을 생성할 수 있다.

사용자 테이블에 새로운 사용자가 등록 됐을 때 환영 이메일을 보내는 등 dynamoDB 테이블의 변경사항에 실시간으로 반응하는데 활용할 수 있다. -> 테이블의 변경사항에 실시간으로 반응하는데 활용할 수있다.

 

실시간의 사용을 분석하거나

파생테이블을 삽입할 수도 있다.

리전 간 복제를 실행하거나

변경사항이 발생하면 람다를 실행할 수도 있다.

 

두가지 스트림 처리방법이 있다.

dynamoDB 스트림

보존기간이 24시간이고 소비자 수가 제한

람바 트리거와 함께하면 좋고

자체적으로 읽기를 실행하려면 dynamoDB stream kinesis 어탭터를 사용한다.

 

아니면 kinesis data streams에 변경사항을 바로 보내는 방법도 있다.

이 스트림은 보존기간 1년

더많은 소비자 수를 갖고

데티어 처리방법이 훨씬 많다.

다양한 API를 사용가능하다..

 

------스트림 과정------

예를들어 애플리 케이션이 다이나모디비 테이블에 작업을 생성, 업데이트, 삭제를 하면

이건 DynamoDB Stream이나, Kinesis Data Streams로 전송된다.

 

dynamoDB Stream을 사용하면 처리 계층을 둘 수 있다.

ec2인스턴스에서 애플리케이션을 실행하려면 KCL adapter나 람다함수를 사용한다.

그래서 이 결과를 SNS로 보내거나, dynamoDB테이블을 필터링하거나 변환할 수 있다.

또 amazon opensearch로 데이터를 전송할 수도 있다. 

 

 

kinesis data streams를 선택하면 kinesis data firehose를 사용할 수 있다.

그 다음 분석 목적으로 데이터를 amazon redshift로 전송하거나, 아카이빙하려면 s3, amazon opensearch로 보내면 인덱싱이나 검색을 할 수 있다.

 

DynamoDB global tables

글로벌테이블은 여러 리전간에 복제가 가능한 테이블이다.

두 테이블이 각각 다른 레전에 존재해도 두 테이블 간에는 양방향 복제가 가능하다.

어느 레전에 있는 테이블 둘 중 하나에 쓰기만 해도 다른 곳에 반영이 된다. 지연시간이 엄청 짧다.

 

글로벌 테이블을 활성화 하려면 dynamoDB스트림을 활성화해야한다. 리전 간 테이블을 복제할 수 있는 기본 인프라가 구축된다.

 

 

TTL

ttl이라는 기능은 만료 스탬프가 지나면 자동으로 항목을 삭제하는 기능이다. 

이 기능을 캐시에서 많이 봤을텐데 이건 테이블에서 사용하는 것이다.

 

테이블의컬럼에 TTL이 있고 그 시간이 지나면 그 로우가 자동으로 삭제되는 기능이다.

최근 항목만 저장하도록하거나 2년후 데이터를 삭제해야하는 규정이있다.

웹 세션 핸들링이라고. 시험에 자주나오는 개념인데 사용자가 웹사이트에 로그인 했을 때 해당 세션을 

중앙 저장소인 dynamodb에 두시간 저장하여 모든 애플리케이션이 액세스할 수 있고

두시간후에 세션이 갱신되지 않으면 만료되어 해당테이블에서 삭제될 것이다.

 

backups for disater recovery 

재해 복구에도 dynamoDB를 활용한다. 백업 옵션을 한번 보자

지정 시간 복구를 사용하여 지속적인 백업을 할 수 있다.

 

활성화를 선택하면 35일간 지속된다.

언제든 지정 시간 복구를 실행할 수 있다.

복구를 진행할 경우 새로운 테이블을 생성한다.

 

intergration with amazon s3

s3에 테이블을 내보낼 수가 있다. 이르 ㄹ위해선 지정 시간 복구 기능을 활성화 해야한다.

ㅔ이블을 s3로 보내고 여기서 쿼리를 수행하려면 athena로 보낸다.

지속적 백업을 활성화 한 상태이므로 최근 35일 이내면 어떤 시점으로든 보낼 수 있다.

 

 

API gate way

람다 함수에서 다이나모 디비로 읽기 쓰기 지우기 업데이트 등이 가능하다.

 

api gateway는 서버리스 서비스로 Rest api를 생성할 수 있으므로, 클라이언트가 퍼블릭 액세스 할 수 있다.

api gateway에 클라이언트가 직접 소통하며 다양한 작업을 할 수 있고 람다함수에 요청을 프록시한다.

이걸 사용하는 이유는 인증부터 계획 개발단계 등의 기능을 제공하기 때문이다.

 

만약 api gateway와 람다를 통합하면 완전 서버리스 애플리케이션이 되므로 인프라  관리가 필요없다.

웹소켓 프로토콜도 지원하므로 api gateway로 두가지 방법의 실시간 스트리밍이 가능하다.

버저닝이 가능하여 버전 1,2,3이 가능.

.

.

.

.