AWS 서버리스

서버리스

• 서버가 없다는 것이 아니라 관리할 필요가 없다는 뜻이다
  • 코드를 배치, 함수를 배치하면 된다
• 기존 서버리스는 FaaS(Function As a Service)를 뜻했지만 지금은 더 많은 걸 의미한다
• AWS에서 서버리스가 처음 개발된건 AWS Lambda였는데 현재는 원격 관리되는 것을 모두 포함한다

서버리스 서비스

• AWS Lambda
• DynamoDB
• AWS Cognito
• AWS API Gateway
• Amazon S3
• AWS SNS & SQS
• AWS Kinesis Data Firehose
• Aurora Serverless
• Step Functions
• Fargate

AWS Lambda

• 람다는 가상의 함수로 관리할 서버 없이 코드를 프로비저닝하면 함수가 실행된다
• 최대 15분 제한시간이 있다
• 온디맨드로 실행된다
• 스케일링이 자동화된다 스케일링이 자동화된다
  

1. 장점

• 가격책정이 쉽다
  • 요청횟수와 컴퓨팅 시간, 즉 Lambda가 실행된 시간만큼 청구된다
• 다양한 AWS 서비스와 통합
  • CloudWatch와 모니터링 통합도 쉽다
  • 여러가지 프로그래밍언어를 쓸 수 있어서 자유롭다
• 함수당 더 많은 리소스를 프로비저닝하려면 함수당 최대 10GB의 램을 프로비저닝 할 수 있다

2. 한도

• 한도는 리전당 존재한다
• 실행 한도
  • 메모리 할당량은 128MB ~ 10GB이며 메모리는 1MB씩 증가한다
  • 메모리가 증가하면 vCPU도 더 많이 필요하다
  • 최대 실행시간은 15분이다
  • 환경변수는 크기는 4KB이고 큰 파일을 가져올 때 사용하는 임시공간은 /tmp 폴더에 최대 10GB이다
  • 최대 1,000개까지 동시 실행이 가능하며 동시성은 미리 예약해두는 것이 좋다
• 배포 한도
  • 압축 시 최대크기는 50MB, 압축하지 않았을 때는 250MB이다
  • 이 용량을 넘는 파일의 경우 /tmp에 저장해야 한다
  • 배포시에도 환경변수 크기는 4KB이다

3. SnapStart

• 람다함수의 성능을 높이기 위한 Lambda의 기능이다
• Java11 이상에서 실행되는 람다함수들을 추가 비용 없이 성능을 최대 10배 높여준다
• 기존에는 초기화를 해줬지만 SnapStart를 활성화하면 초기화를 이미 해놓기 때문에 바로 호출을 하고 종료를 해서 빠르다
  

4. Lambda VPC

• 기본적으로Lambda는 VPC 외부에서 제공하기 때문에 VPC내부에서 사용되는 서비스는 접근할 수 없다
  • 만약 RDS가 퍼블릭 API가 아닌 VPC로 연결만 허용한다면 람다는 연결할 수 없다
• 이를 해결하려면 VPC 내에서 람다함수를 실행하면 된다
  • 서브넷을 지정하고 람다함수에 보안그룹을 추가하면 된다
  • 람다가 서브넷에 ENI를 생성해 VPC에 실행되는 서비스에 액세스할 수 있게 된다
    

1). 사용처

• RDS와 람다가 연결되어 있을 때 람다가 너무 많이 생성되면 연결 초과, 성능저하로 이어진다
• 이럴때 RDS 프록시를 이용해서 연결을 한 곳으로 모으고 RDS 연결 수를 줄인다
• RDS Proxy는 퍼블릭이 아니기 때문에 VPC로 연결하면 유용하게 쓸 수 있다
  

DynamoDB

• 완전 관리형 서비스로 데이터가 다중 AZ간에 복제되므로 가용성이 높다
• 클라우드 네이티브이며, NoSQL 데이터베이스이다
• 트랜잭션 지원 기능이 있고, 내부에서 분산이 되기 때문에 확장이 가능하다
• 성능이 좋고 보안과 모든 기능은 IAM과 통합이 되어 있다
• 비용이 적게 들고 오토 스케일링 기능이 탑재되어있다
• 액세스가 빈번한 스탠다드와 액세스가 빈번하지 않은 IA 테이블 클래스에 저장한다

1. 기본

• 테이블로 구성되며 데이터베이스를 생성할 필요가 없다
  • 데이터베이스가 이미 존재하는 서비스이다
• 테이블을 생성하면 각 테이블에 기본키가 부여되는데 기본 키는 생성 시 결정된다
• 항목의 최대크기는 400KB로 크기가 큰 유형을 저장할 때는 적합하지 않다
• 데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야 할 때 유용하다
  

2. Read/Write 용량 모드

• 테이블 용량 관리 방식을 제어하는 데는 두 가지 모드가 있다
• 프로비저닝 모드
  • 미리 용량을 프로비저닝한다
  • 읽기, 쓰기를 계획해서 설정하면 그것이 테이블의 용량이 된다
  • 미리 계획한 경우에도 오토 스케일링이 되기 때문에 늘리거나 줄일 수 있다
• On-Demand Mode
  • 자동으로 확장되기 때문에 용량 계획을 하지 않는다
  • 정확히 사용한 만큼의 비용을 낸다
  • 워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용하다
  • 프로비저닝 모드보다 2~3배 더 비싸다

3. DynamoDB Accelerator (DAX)

• DynamoDB를 위한 고가용성의 완전 관리형 무결절 인메모리 캐시이다
• 읽기 작업이 많을 때 DAX 클러스터를 생성하고 데이터를 캐싱하여 읽기 작업을 해결한다
• 캐시데이터에 마이크로초 수준의 지연시간을 제공한다
• DAX 클러스터는 기존 DynamoAPI와 호환되기 때문에 수정할 필요가 없다
  

ElastiCache가 아닌 DAX를 쓰는 이유

• DAX는 DynamoDB앞에 있고 개별 객체 캐시와 쿼리와 스캔 캐시를 처리하는데 유용하다
• 집계 결과를 저장할 때는 엘라스틱캐시가 좋고 DynamoDB는 대용량 연산을 저장할 때 좋다

API Gateway

• 클라이언트도 람다함수를 지연 호출하게 하고 싶을 때 클라이언트도 IAM 권한이 있어야 한다
  • ALB을 앞에 둔다면 람다함수의 엔드포인트가 노출이 된다
• API Gateway는 서버리스로 REST API를 생성할 수 있다
• 클라이언트가 API Gateway와 통신하며 람다와 통신을 할 수 있다
• 인증, 사용량 계획, 개발 단계 등의 기능을 제공한다
  

1. 기능

• 람다와 통합하면 완전 서버리스 애플리케이션이 구축되므로 인프라 관리가 필요없다
• 웹소켓을 지원하므로 두 가지 방법의 실시간 스트리밍을 지원한다
• 인증, 권한부여 등 보안에도 활용할 수 있다
• Swagger / Opeen API등 정의된 API를 가져와 사용할 수 있다
• API 응답을 캐시할 수 있다
• ALB와 달리 다양한 기능이 있다

2. 배포방법 (엔드포인트 유형)

• 엣지 최적화
  • 글로벌 클라이언트 용
  • 전세계 누구나 API 게이트웨이에 접속할 수 있다
  • 모든 요청이 CloudFront 엣지 로케이션을 통해 라우팅되므로 지연시간이 개선된다
• Regional
  • CloudFront 엣지 로케이션을 사용하고 싶지 않을 때 사용한다
  • 모든 사용자는 API Gateway를 생성한 리전과 같은 리전에 있어야 한다
  • 자체 CLoudFront를 배포하여 엣지 최적화 배포와 캐시 전략, 더 많은 권한을 줄 수 있다
• Private
  • ENI같은 인터페이스를 이용하여 VPC 내에서만 액세스 할 수 있다

Step Functions

• 서버리스 워크플로우를 시각적으로 구성할 수 있는 기능으로 주로 람다 함수를 오케스트레이션하는 데 사용한다
• 시퀀싱, 병행 실행, 조건 설정, 타임아웃, 에러 처리등 다양한 기능을 제공한다
• ECS, EC2, API Gateway, SQS 등 다양한 서비스를 워크플로우에 넣을 수 있다
• 복잡한 워크플로우를 시각적으로 작성할 때 유용하다
  

Amazon Congnito

• 사용자에게 웹 및 모바일 앱과 상호작용할 수 있는 자격증명을 부여한다
• 사용자들을 AWS 계정 외부에 있고 모르는 사용자들에게 자격을 부여해 사용자를 인식한다
• 두 종류의 하위 서비스가 있다
  • Cognito User Pools
    • 앱 사용자에게 가입 기능을 제공한다
    • API Gteway 및 ALB와 원활히 통합된다
  • Congnito Identity Pools
    • 페더레이션 자격 증명이라 불린다
    • 앱에 등록된 사용자에게 임시 AWS 자격 증명을 제공해서 일부 AWS 리소스에 직접 액세스할 수 있도록 해준다
    • IAM과 달리 Congito는 외부 사용자에게 적합한 서비스이다

1. Cognito User Pools(CUP)

• 웹 및 모바일 앱을 대상으로 하는 서버리스 사용자 데이터베이스이다
• 사용자 이름 또는 이메일, 비밀번호 조합으로 간단한 로그인 절차를 진행할 수 있다
• 사용자 멀티팩터 인증이 가능하다
• OAuth2 소셜로그인이 가능하며 Gateway, ALB와 완전 통합이 가능하다
• ALB위에 배치하면 된다
• 사용자인증을 백엔드에서 API Gateway로 통합이 되도록 하는 것이다
  

2. Cognito Identity Pools(Federated Identities)

• 사용자에게 자격 증명을 제공하지만 API Gateway나 ALB로 액세스하지 않고 임시 AWS 자격 증명을 사용해 AWS 계쩡에 직접 액세스한다
• user_id를 기반으로 사용자를 정의하거나 IAM 역할을 정의하여 구분할 수 있다