[SAA] 서버리스

서버리스

• 서버 관리를 거의 하지 않는 패러다임
• 함수 배포만 하면 됨
• FaaS
• 서버를 관리하지 않고 프로비저닝하지 않아도 됨
• 람다, DynamoDB, Cognito, API Gateway, S3, SNS, SQS, Kinesis, Aurora Serverless, Step functions, Fargate 등등의 서비스

---

Lambda

• 가상 함수
• 서버 관리 불필요
• 사용할 때만 사용됨
• 확장이 자동화됨
• 수행 시간 짧다.
• 과금 체계가 간단하다.
• 다른 모든 서비스와 연동됨
• 다양한 언어 지원
• CloudWatch로 모니터링 가능
• 함수 당 쉽게 리소스 할당 가능 (최대 10GB ram)
• ram을 늘리면 CPU와 네트워크도 추가 할당됨
• EventBridge에 크론잡을 설정하여 특정 시간마다 람다의 이벤트 트리거 역할 가능
• 시작 시점에 /tmp 디렉토리를 사용해서 다른 파일 로드 가능 (임시 스토리지로도 사용 가능)

제약 조건

• 메모리는 128MB ~ 10GB
• 실행 시간은 최대 15분
• 환경 변수 크기는 4KB
• container의 disk 용량은 512MB ~ 10GB
• 동시성은 1000
• 배포 최대 사이즈는 -zip 기준 50MB
• 압축되지 않은 배포 크기는 250MB (소스코드 + 라이브러리 포함)

스냅 스타트

• Java 11 이상의 Lambda 함수의 성능을 최대 10배까지 늘릴 수 있다.
• 초기화가 진행된 상태로 대기하므로 JVM 로드 시간 단축으로 시간적 이득
• 신규 버전을 배포하는 경우, 함수 초기화
• 초기화가 진행된 상태의 메모리와 디스크 스냅샷을 진행
• 해당 스냅샷을 캐싱해서 성능 향상을 도모

---

Edge 커스터마이징

• Edge Function
• Edge에서 로직을 실행
• CloudFront 배포에 함수를 붙이는 기능
• 역시 서버리스로 구동
• CloudFront function
  • js 기반의 가벼운 함수 실행
  • 높은 확장성, 낮은 지연시간
  • ms 이하의 시작 시간, 초당 100만 단위의 요청 처리
  • CloudFront에 내장된 기능
  • CloudFront의 Viewer 요청 및 응답을 변경하기 위해 사용
    • CloudFront가 요청받은 이후에 동작함.
    • CloudFront가 응답하기 전에 동작함.
• Lambda@Edge
  • Python3, NodeJS 기반의 람다 함수
  • 다소 무거움
  • 초당 천단위의 요청 처리
  • us-east-1 리전에서만 함수 작성
  • 작성된 함수는 각 CloudFront로 복사해서 전파
  • CloudFront의 요청 및 응답을 변경하기 위해 사용
    • CloudFront가 요청받은 이후에 동작
    • CloudFront가 Origin에 요청하기 이전에 동작
    • CloudFront가 오리진에게 응답받은 이후에 동작
    • CloudFront가 응답하기 이전에 동작

Edge 기능 예시

• 웹사이트 보안에서도 사용
• 동적 웹사이트를 엣지에서 운영
• 검색 최적화를 사용
• Origin들과 데이터 센터간의 라우팅을 위해 사용
• Bot 마이그레이션을 진행
• 실시간 이미지 변형
• A/B 테스트
• 사용자 인증 
• 등등

---

VPC 내부에서 사용

• VPC 밖에서 동작하므로 VPC 내부의 다른 서비스에 접근 불가
• VPC, subnet, SG를 지정해야 함.
• 별도의 ENI를 부착하여 VPC 내부에서 사용 가능.

RDS Proxy와 사용

• RDS에 직접 접근해야 하는 경우
• 람다 실행마다 DB Connection을 생성하는 경우 커넥션 고갈 일어남.
• RDS Proxy가 DB 커넥션을 Pooling하고, 공유하여 확장성 증가
• 커넥션을 보관하면서 실패 재시도를 줄이고 가용성 증가
• IAM 인증을 강제하여 보안성을 올림
• RDS Proxy는 절대 public으로 열리지 않음. 그러므로 람다가 VPC 내부에 배포되어야 함.

DB에서 람다 호출하기

• DB에서 발생하는 Data Event를 처리할 수 있도록 함.
• PostrgeSQL RDS, Aurora Mysql에서 지원함
• DB의 Outbound traffic이 람다로 전송될 수 있어야 함.
• Public, NAT Gateway, VPC Endpoint 등이 설정되어야 함.
• 또한 DB가 람다를 호출할 수 있는 권한 필요

RDS 이벤트 알림

• DB 인스턴스의 상태에 대한 이벤트 알림 처리
• DB 인스턴스, 스냅샷, 파라미터 그룹, 보안 그룹, RDS 프록시, 커스텀 엔진 버전에 대한 이벤트 구독 가능
• 5분 정도의 지연시간 존재
• SNS, EventBridge를 통해 전달되고, 람다를 후방에 붙여서 해결

---

DynamoDB

• 완전 관리형 서비스
• 멀티AZ 지원하는 고가용성
• NoSQL DB
• 트랜잭션 지원
• 대용량, 분산 워크로드 지원
• 초당 100만 단위의 요청 처리, 조단위 row, 백단위 TB 스토리지 지원
• 빠르고 안정적인 성능 (10ms 미만)
• 보안, 인증, 인가는 IAM을 통해 핸들링 가능
• 낮은 비용과 오토스케일링을 지원
• 항상 가동 가능한 상태
• DynamoDB는 테이블로 구성됨

테이블

• 테이블은 생성시점에 지정되는 PK를 가짐
• PK는 Partition Key와 Sort Key로 구분
• 테이블은 무제한으로 아이템(row를 가질 수 있음)
• 각 아이템은 속성을 갖는다.(null 가능, 추가 가능)
• 아이템의 최대 사이즈는 400KB
• Scalar type(String, Number 등), Document type(List, Map), Set type(String set, Number set 등) 지원
• 매우 빠르게 스키마를 늘릴 수 있다.
• 테이블 타입은 스탠다드와 Infrequent Access(자주 접근하지 않는 경우)로 나뉨.

읽기 쓰기 용량 모드

• 각 테이블의 읽기 쓰기 크기를 조절할 수 있다.
• Provisioned Mode (기본)
  • 초당 읽기/쓰기 수를 지정
  • 용량을 사전에 지정해야 함.
  • 지정된 읽기 용량 단위와 쓰기 용량 단위로 비용을 지불
  • 읽기/쓰기 용량에 오토스케일링 모드를 지정 가능
• On-Demand Mode
  • 읽기/쓰기 용량의 확장/축소가 자동으로 진행
  • 사전 계획 불필요
  • 사용한만큼 비용이 발생하지만 더 비싸다.
  • 그러나 예측이 어렵거나, 급작스럽게 트래픽이 증가하는 서비스에 유용하다.

---

DAX

• DynamoDB 전용 완전 관리, 고가용성 메모리 캐시
• 읽기 부하를 줄이기 위해 사용
• ms 수준의 지연율
• 애플리케이션 로직 변경은 불필요 (DynamoDB와 같은 SDK 사용.)
• TTL은 기본 5분. (최신화가 필요하다면 안 쓰거나 TTL을 조정할 것)
• Elasticahe에 비해 장점이 많음
• 개별 오브젝트 캐싱 가능
• 쿼리, 스캔에 대한 캐싱 지원

DynamoDB Stream

• 테이블 내부의 아이템 단위의 변경이 일어나면, 정렬된 순서가 있는 스트리밍 지원
• 24시간 동안 데이터 저장
• 소비자 수에 제한
• 데이터 변경에 대한 실시간 처리 (회원 가입하면 이메일 보내기)
• 실시간 사용 분석
• 관련 있는 테이블에 신규 데이터를 추가
• 리전 간 복제
• 테이블 변경 이벤트에 맞춰서 추가적인 액션이 필요한 경우에 사용.
• 추가적인 변경이 필요하면 Lambda 혹은 Kinesis Adapter를 사용.
• Kinesis Data Streams와의 비교
  • 데이터 저장 기간 1년
  • 소비자 더 많이 등록 가능
  • 다양한 서비스와 연동 가능
  • 복잡하고 많은 스트림이거나, 다양한 서비스와 연동해야 하는 경우 Kinesis가 압승

Global Table

• DynamoDB의 테이블이 낮은 지연율로 여러 리전에서 접근하도록 설정
• 모든 테이블이 two-way replication으로 이루어짐.
• 즉, 모든 리전의 테이블에 대해 읽고 쓰기가 가능하다는 것.
• 또한, DynamoDB 스트림이 반드시 켜져 있어야 한다.

---

TTL

• DB에 값을 저장한 시점부터 데이터의 유효 시간을 설정 가능
• 애플리케이션 로직, 별도 크론잡 스케줄링이 필요 없이 자체적으로 처리 가능
• 현재 데이터만을 보관, 웹세션을 핸들링 등 데이터가 일시적으로만 남고 삭제되어야 하는 경우 설정

재해복구 백업

• 지속적 백업
  • 시점 기반 복구를 위해 지속적으로 백업함.
  • 최근 35일간 데이터를 선택적으로 설정
  • 백업 기간 내의 어느 시점이든 백업 가능
  • 복구 처리를 위해 새로운 테이블을 생성
• On-Demand 백업
  • 상대적으로 긴 기간동안 백업 보관 (비용 청구됨)
  • 명시적으로 삭제 필요
  • 필요할 때 백업 가능
  • 성능이나 지연시간에 영향을 미치지 않음
  • AWS backup을 통해 정의 및 관리 가능
  • 리전간 백업 설정 가능
  • 복구 처리를 위해 새로운 테이블 생성

S3 Export

• S3로 데이터 보내기 가능
• PITR과 같이 사용
• 테이블의 읽기 성능에 영향을 받지 않음
• DynamoDB에 직접 접근하지 않고 데이터 분석 가능
• 이력 관리(Audit)를 위해 스냅샷을 남기는 경우에 사용
• DynamoDB를 다시 데이터를 넣기 전에 ETL 진행 가능
• DynamoDB JSON, ION 형식으로 데이터를 내보낼 수 있다.

S3 Import

• S3로부터 데이터 가져오기 가능
• 읽기 용량 소비 X
• 신규 테이블 생성
• 가져오기 과정에서 발생하는 에러들은 CloudWatch에서 확인 가능
• CSV, DynamoDB JSON, ION 형식으로 가져올 수 있다.

---

API Gateway

• 인프라 관리 필요 없음
• Websocket 프로토콜 지원
• API Versioning 지원
• 람다에 붙여서 람다를 Web으로 띄울 수 있음.
• 여러개의 환경 지원 (개발, 테스트, 상용 등등)
• 요청에 대한 쓰로틀링 설정 가능
• Swagger / OpenAPI로부터 빠르게 API Gateway를 구성할 수도 있다.
• 요청 / 응답 변형 및 검증 가능
• SDK와 API 정의 작성 가능
• 응답 캐싱함

타 서비스와 사용하기

• 람다: 람다의 REST API 공개 가능
• HTTP: 백엔드의 HTTP 엔드포인트 외부 노출(API 통신 관리를 인프라 단에서 처리한다는 장점)
• AWS Service: 모든 AWS 서비스 API를 API Gateway를 통해 공개 가능

엔드포인트 종류

• 엣지 최적화 (기본값)
  • 글로벌 사용자 대상
  • CloudFront Edge Location으로 라우팅
  • 지연시간 감소
  • API Gateway 자체는 한개 리전에만 있게 된다.
• 지역별
  • 같은 리전 내부의 사용자 대상
  • 직접 CloudFront와 연결 가능
  • 캐싱 전략, CloudFront 배포에 대한 관리 직접 해야 함.
  • 대신 불필요한 엣지 최적화로 발생하는 비용 감소
• Private
  • VPC 내부에서만 접근 가능
  • ENI 세팅 필요
  • 접근 제어를 위해 IAM 정책 사용

---

보안

• 사용자 권한
  • IAM Role (내부 서비스)
  • Cognito (외부 사용자 인증)
  • 별도의 인증 로직 (자사에서 사용하는 로직이 있는 경우)
• 사용자 정의 도메인 이름 HTTPS
  • AWS Certificate Manager(ACM)과 연동해서 사용
  • 엣지 최적화를 사용하는 경우 인증은 us-east-1에서
  • 지역별을 사용하는 경우 API Gateway가 있는 리전에서 인증
  • CNAME or A 레코드가 Route53에 정의돼 있어야 함.

---

AWS Step Function

• 람다 수행 workflow를 구성 가능
• 시각적으로 구성 가능
• 순차, 병렬, 조건, 시간제한, 에러 핸들링 등 가능
• EC2, ECS, 온프레미스, API Gateway, SQS 등과 사용 가능
• 사람과 상호작용하는 요소도 넣을 수 있음

---

Amazon Cognito

• 웹, 앱에서 사용하는 인증을 유저에게 제공
• Cognito User Pool과 Identity Pool로 나뉨

Cognito User Pool

• 앱 사용자에게 로그인 기능 제공
• API Gateway 또는 Application Load Balancer와 연동해서 사용 가능
• 사용자 정보를 저장하기 위해 자체적으로 서버리스 DB 생성
• email + pw로 간단한 로그인
• 비밀번호 초기화 제공
• 이메일 또는 핸드폰 번호 인증 제공
• MFA 제공
• 외부 서비스 인증과 연동 가능

Cognito Identity Pool

• 유저의 정보를 가져와서 직접 AWS 리소스에 접근할 수 있는 AWS 인증을 임시적으로 유저에게 제공
• 유저의 정보는 User Pool, 외부 서비스 등 다양한 곳에서 가져올 수 있음.
• 유저는 AWS 서비스에 바로 접근하거나 API Gateway를 통해 접근 가능
• IAM 정책은 Cognito에 미리 정의된 내용이 사용됨
• user_id를 기반으로 세밀하게 권한 조정 가능
• 기본 IAM Role은 인증된 유저에게만 제공

---

• PITR: Point In Time Recovery. 특정 시점에 대한 복구
• ETL: 데이터 추출, 변환, 전달하는 과정
• 쓰로틀링: 제한