서버리스

서버가 없다 X
서버를 관리할 필요가 없다. O

-> 코드 배치, 함수 배치하면된다.

Serverless == Faas(Function as a Service)

AWS Lambda로 서버리스를 처음 개발 -> 지금은 우너격 관리되는 것을 모두 포함
ex) DB, 메시징, 스토리지 등... 서버를 프롭지저닝 하지 않는 모든 것들을 포함

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

AWS Lambda

• 람다는 가상 함수
• 람다는 온디맨드로 실행된다.
• 제한시간이 있어 실행 시간이 짧다
• 함수가 실행되는 동안만 비용이 청구된다.
• 스케일링이 자동화된다.

Lambda의 장점

• 가격이 저렴
  • 람다가 실행되는 시간만큼 청구
    • 호출당 청구
      처음 백만 건의 요청은 무료
      이후 백만 건당 20센트
    • 기간당 청구
      한달간 40만 GB-초 동안의 컴퓨팅 시간은 무료(GB-s == 함수가 1GB 램을 가질 때 실행 시간이 40만 초)
      ex) 실행시간이 320만 GB-s이면 램은 128MB
      이후 60만 GB-s당 1달러
  • 프리 티어에서도 람다를 넉넉하게 제공
• 다양한 AWS 서비스와 통합
  • 람다와 다양한 AWS 서비스와 통합 되는 과정
    
    • API Gateway: REST API를 생성하고 람다 함수를 호출
    • Kinesis: 람다를 이용해 바로 데이터를 변환
    • DynamoDB: 트리거를 생성할떄 주로 사용(DB에 이벤트가 생기면 람다 함수 작동)
    • Amazon S3: S3에 파일이 생성되거나 삭제될때 등 언제나 람다 함수 작동
    • CloudFront
    • CloudWatch Evants & EventBridge: AWS의 인프라에 이벤트가 생겨 대응할 때 자동화 실행
      EX) 파이프라인이 끊기거나 상태가 바뀌는 경우
    • CloudWatch Logs: 어디든 해당 로그를 스트리밍
    • SNS: 알림과 SNS 토픽에 대처
    • SQS: SQS 대기열 메시지를 처리
    • Cognito: 예를들어 사용자가 DB에 로그인 할 때마다 응답
  • 서버리스 사용 예시
    • 서버리스 섬네일 생성
      
      S3에 새 이미지와 앱이 생성되는 이벤트에 대한 반응형 아키텍처를 얻을 수 있다.
    • 서버리스 CRON JOB
      
      CRON은 EC2같은 가상 서버에 실행되어야 하는데 인스턴스가 실행되지 않거나 CRON이 아무일 도 안하면 인스턴스 시간이 낭비됨.
      그래서 CloudWatch Evants나 EventBridge로 규칙을 만들고 1시간마다 동작되게 해 1시간마다 람다 함수와 통합되면 태스크를 실행할 수 있다.
• 람다에 여러가지 프로그래밍 언어를 사용할 수 있다.
  • 지원하는 언어
    Node.js(JavaScript)
    파이썬
    자바
    C#(.NET Core)
    Golang
    C# / Powershell
    Ruby
    사용자 지정 런타임API가 있는 다양한 언어(Rust같은 오픈소스 프로젝트가 있는 언어)
  • 람다 컨테이너 이미지를 지원한다.
    컨테이너 이미지 자체가 Lambda의 런타임 API를 구현해야 한다.
    즉, 아무 컨테이너 이미지가 실행되는 것이 아니라 컨테이너 이미지를 만들 때 조건이 필요하다
    ECS와 Fargate는 계속 임의의 도커 이미지를 실행할 때 더 많이 사용
    -> 람다에 컨테이너를 실행해야 하는 경우 해당 컨테이너가 람다 런타임 API를 구현하지 않았다면 ECS와 Fargate에서 컨테이너를 실행해야 한다.
• CloudWatch와의 모니터링 통합이 쉽다.
• 함수당 더 많은 리소스를 프로비저닝하려면 함수당 최대 10GB의 램을 프로비저닝 가능
  • 함수의 램을 증가시키면 CPU와 네트워크 품질과 성능도 같이 향상된다.

Lambda 한도

• 한도
  • 실행 한도
    - 실행 시 메모리 할당량: 128MB ~ 10GB(1MB씩 증가)
    - 최대 실행 시간: 15분
    - 환경 변수: 4KB
    - 함수 컨테이너 디스크 용량: 10GB (/tmp)폴더에 용량이 있음.
    - 동시 실행 한도: 최대 1,000개 (요청 시 더 증가 가능)
  • 배포 한도
    - 압축 시 최대 크기: 50MB
    - 압축하지 않은 크기: 250MB (이 용량을 넘는 경우 /tmp 공간을 사용해야 함)
    - 시작할 때 크기가 큰 파일이 있으면 /tmp 디렉토리 사용
    - 배포 시 환경변수 한도: 4KB

Lambda SnapStart

• 람다 함수의 성능을 높이기 위한 람다의 기능
  Java 11 이상에서 실행되는 람다 함수를 추가 비용 없이 성능 10배 향상
  

• SnapStart가 비활성화 시
  초기화 - 호출 - 종료

• SnapStart 활성화 시
  함수가 미리 초기화된 상태에서 호출
  즉, 호출 - 종료

• 새 람다 버전을 게시할 때

  • 람다가 함수를 초기화
    즉, 초기화 단계가 미리 진행되어 있다.
  • 그 이후에 메모리와 초기화된 함수의 디스크 상태의 스냅샷이 생성
  • 이 스냅샷이 저지연 액세스를 위해 캐시 된다.
    이는 함수가 SnapStart 즉, 빠른 시작을 할 수 있도록 한다.

Lambda@엣지 & CloudFront Functions

• 엣지에서의 사용자 지정
  • 보통의 경우 함수와 애플리케이션은 특정 리전에 배포
  • 그러나 CloudFront를 사용하면 엣지 로케이션을 통해 컨텐츠 배포
• 엣지 함수(Edge Function)
  • CloudFront 배포에 연결하는 코드
  • 모던 애플리케이션에서는 애플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요구
  • 엣지 함수는 사용자 근처에서 실행해 지연 시간을 최소화하는 것이 목적
  • 엣지 함수를 사용하면 서버를 관리할 필요가 없다. - 서버리스 (전역 배포되기 때문)
  • 사용한 만큼 비용 지불
  • 사용 사례:
    • CloudFront의 CDN 콘텐츠를 사용자 지정하는 경우
    • 웹 사이트 보안과 프라이버시
    • 엣지에서의 동적 웹 애플리케이션
    • 검색 엔진 최적화(SEO)
    • 오리진 및 데이터 센터 간 지능형 경로에 활용
    • 엣지에서의 봇 완화
    • 엣지에서의 실시간 이미지 변환
    • A/B 테스트
    • 사용자 인증 및 권한 부여
    • 사용자 우선순위 지정
    • 사용자 추적 및 분석
• CloudFront 종류
  • CloudFront 함수
    - CloudFront 함수는 JavaScript로 작성된 경량 함수로 뷰어 요청과 응답을 수정한다.
    - 확장성이 높다.
    - 지연 시간에 민감한 CDN 사용자 지정에 사용된다.
    - 시작 시간: 1ms 미만, 초당 백만개의 요청 처리
    • 뷰어 요청과 응답을 수정할때만 사용된다.
      - 뷰어 요청: CloudFront가 뷰어로부터 요청을 받은 다음 뷰어 요청을 수정
      - 뷰어 응답: CloudFront가 뷰어에게 응답을 보내기 전에 뷰어 응답을 수정
    • CloudFront의 기본 기능
      - 모든 코드가 CloudFront에서 직접 관리된다.
      - CloudFront함수는 고성능, 고확장성이 필요할 때 그리고 뷰어 요청과 뷰어 응답에만 사용
    • 요청 처리 과정
      
      - 먼저 뷰어 요청(CloudFront에 클라이언트가 요청을 보내는 것을 한다.
      - 그 다음 CloudFront가 오리진 요청을 오리진 서버에 전송
      - 서버가 CloudFront에 오리진 응답을 보내고
      - CloudFront가 클라이언트에세 뷰어 응답을 전송
  • Lambda@Edge
    - 함수는 us-east-1 리전에만 작성할 수 있음. -> CloudFront 배포를 관리하는 리전과 같은 리전
    --> 함수를 작성하면 CloudFront가 모든 로케이션에 해당 함수를 복제
    - 이 함수는 Node.js나 Python으로 작성된다.
    - 초당 수천 개의 요청을 처리
    - 모든 CloudFront 요청 및 응답을 수정 가능
    --> 뷰어 요청: CloudFront가 뷰어로부터 요청을 받은 다음 뷰어 요청을 수정
    --> 오리진 요청: CloudFront가 오리진에 요청을 전송하기 전에 수정
    --> 오리진 응답: CloudFront가 오리진에서 응답을 받은 후 수정
    --> 뷰어 응답: CloudFront가 뷰어에게 응답을 보내기 전에 수정
• Lambda@Edge vs CloudFront Functions
  (런타임 지원)
  CloudFront: JavaScript
  Lambda@Edge: Node.js, Python
  
  (요청 처리)
  CloudFront: 수백만 개 요청 처리(확장성 매우 높음)
  Lambda@Edge: 수천 개 요청 처리
  
  (트리거 발생 위치)
  CloudFront: 뷰어에만 영향을 준다.
  Lambda@Edge: 뷰어와 오리진 모두에게 영향을 준다.
  
  (최대 실행 시간)
  CloudFront: 1ms 미만
  Lambda@Edge: 5~10초 소요
  
  (사용 사례)
  * CloudFront:
  - 캐시 키 정규화: 요청 속성을 변환해 최적의 캐시 키를 생성
  - 헤더 조작: 요청이나 응답에 HTTP 헤더를 삽입/수정/삭제하도록 헤더 조작
  - URL 다시쓰기 또는 리디렉션
  - 요청 인증/승인:
  --> 요청을 허용 또는 거부하기 위해 JWT를 생성하거나
  --> 검증하는 요청 인증 및 권한 부여에 사용
  - 위 모든 작업이 1ms 내에 이뤄짐.
  
  * Lambda@Edge:
  - 긴 실행 시간
  - CPU, 메모리가 증가해 여러 라이브러리를 로드할 수 있다.
  - 타사 라이브러리에 코드를 의존시킬 수 있음.
  (SDK에서 다른 AWS 서비스에 액세스할 수 있도록)
  - 네트워크 액세스를 통해 외부 서비스에서 데이터를 처리할 수 있다. -> 대규모 데이터 통합 수행 가능
  - 파일 시스템이나 HTTP 요청 본문에도 바로 액세스 가능.(다양한 사용자 지정 가능)

Lambda 네트워킹

• 람다 함수는 기본적으로 VPC 외부에서 시작된다.
  그래서 VPC 내에서 리소스에 액세스할 권한이 없다.
  예를들어 RDS, ElastiCache 캐시 내부 로드 밸런서 등..
  그러나 인터넷의 퍼블릭 API에 액세스는 가능하다.
  예를들어 DynamoDB에 액세스할 수 있는 이유는 DynamoDB가 AWS의 퍼블릭 리소스이기 떄문이다.
• 그렇다면 어떻게 RDS와 같은 리소스에 액세스할 수 있을까
  
  • 람다 함수를 VPC에서 시작하면 된다.(Lambda 함수를 프라이빗 서브넷에 시작하기)
    이를 위해..
    1) Lambda 함수를 시작하려는 서브넷을 지정 한다.
    2) Lambda 함수에 보안 그룹을 추가해야 한다.
    3) 그러면 Lambda가 서브넷에 ENI(Elastic Network Interface)를 생성한다.
    4) 그럼 사용자의 VPC에서 실행되는 RDS등의 리소스에 접근 가능하다.

사용 사례

• VPC에서 람다를 사용하는 대표적인 사용 사례
  • RDS 프록시
    
    RDS DB가 프라이빗 서브넷에 있어도 람다 함수로 직접 해당 DB에 액세스 가능
    -> 그러나 직접 DB에 접근하는것은 문제가 발생할 수 있다.
    --> 함수가 너무 많이 생성됬다 사라지길 반복하면 개방된 연결이 너무 많아져 RDS DB의 로드가 상승해 시간 초과등의 문제 발생
  • 해결 방법(RDS 프록시 사용)
    RDS 프록시가 연결을 한곳으로 모으고 RDS DB 인스턴스 연결의 수를 줄인다.
• RDS 프록시의 장점
  1) DB 연결의 풀링과 공유를 통한 확장성 향상
  2) 장애 발생 시 장애 조치 시간 66% 감소해 가용성 향상시키고 연결 보존
  3) RDS 프록시 수준에서 IAM 인증을 강제해 보안을 높임
  자격 증명은 Secrets Manager에 저장됨.

* 람다 함수가 RDS 프록시에 연결할 수 있으려면 본인의 VPC에서 람다 함수를 시작해야 한다.

RDS - 람다 호출 및 이벤트 알림

• DB 인스턴스 내에서 람다 함수 호출
  DB 안에서 일어나는 데이터 이벤트를 처리할 수 있음.
  RDS for PostgreSQL, Aurora MySQL에서 지원.

• 개념
  
  - 사용자가 이벤트 데이터를 나의 등록 테이블에 삽입
  - 그리고 RDS는 나의 람다 함수를 직접 호출하도록 설정된다.
  - 람다 함수는 사용자에게 환영 이메일을 보낼 수 있고, 사용자는 이메일을 받게된다.
  => 이것이 DB에 접속하고 그 안에서 설정해야 하는 부분이다.(AWS 콘솔에서 설정 하는게 아님)
  => RDS DB 인스턴스로부터 람다 함수로 오는 인바운트 트래픽을 허용해줘야 한다.
  => 람다 함수에 대한 아웃바운드 트래픽을 허용해야 한다.
  왜냐하면 람다가 퍼블릭 인터넷에 있는 경우에도 허용해야 하기 때문(NAT Gateway, VPC 엔드포인트 등을 사용할 수 있음)
  => DB 인스턴스에는 Lambda 함수를 호출하는 데 필요한 권한(Lambda 리소스 기반 정책& IAM 정책)이 있어야 합니다.
  DB 인스턴스가 적절한 IAM 정책을 갖고 있는가 확인

• RDS 이벤트 알림
  
  - DB 인스턴스 자체에 대한 정보를 알려주는 알림들은 AWS 내부에서 이뤄진다.
  ex) 생성된 시각, 정지된 시각, 시작된 시각 등..
  - 데이터 자체에 대한 정보는 없다.(유의하자)
  - DB 인스턴스, DB 스냅샷, 파라미터 그룹, 보안 그룹, 프록시, 커스텀 엔진 버전에 관한 이벤트를 구독할 수 있다.
  - 실시간에 가까운 이벤트를 받게된다.(최대 5분)
  - 그 이벤트를 SNS에 전송하거나 EventBridge를 사용해 구독할 수 있다.
  --> 그럼 SNS에서 SQS 대기열이나 람다 함수로 이벤트를 전송할 수 있고
  --> EventBridge에는 람다 함수 같은 아주 많은 다양한 전송 대상이 있다.
  --> 데이터 이벤트 자체에 관한 정보는 받지 못하기 때문에 이전 방법을 사용해야 한다...?