[SAA] Lambda 개요

Why AWS Lambda

• EC2는 클라우드의 가상 서버라서 프로비저닝이 필요하며 따라서 프로비저닝할 메모리와 CPU 크키가 제한되며
  지속적으로 실행되어야 하기 때문에 최적화를 하려면 효율적으로 시작하고 중단해야 함
  이를 위해 오토 스케일링 그룹으로 자동으로 서버를 추가하고 제거하는 스케일링을 할 수 있음
  
  

  

• 위처럼 EC2를 사용해도 좋지만 AWS Lambda라는 것이 있음
  Lambda는 가상의 함수이며 서버 없이 코드를 프로비저닝하면 함수가 실행되는 것이며 제한 시간이 있어 실행 시간이 최대 15분
  이는 온디맨드로 실행되기 때문에 Lambda를 실행하지 않으면 람다 함수가 실행되지 않고 비용 또한 함수가 실행되는 동안 청구
  스케일링이 자동화되기 때문에 더 많은 람다 함수가 동시에 필요한 경우 AWS가 자동으로 프로비저닝해서 람다 함수를 늘려줌
  
  

  

Benefits of AWS Lambda

• Lambda가 수신하는 요청의 횟수(Lambda가 실행되는 시간만큼)에 따라 과금 되므로 가격 책정이 아주 쉬워짐
  또한 프리 티어에서도 Lambda를 요청 1백만건과 40만 GBs의 컴퓨팅 시간으로 넉넉하게 제공
• 다양한 AWS 서비스와 통합됨
• Lambda에 여러 가지 프로그래밍 언어를 사용할 수 있어서 상당히 자유로움
• CloudWatch와의 모니터링 통합을 할 수 있음
• 함수당 더 많은 리소스를 프로비저닝하려면 함수당 최대 10GB의 램을 프로비저닝할 수 있음
  만약 함수의 RAM을 증가시키면 CPU 및 네트워크의 품질가 성능도 함께 향상

AWS Lambda language support

• Lambda가 지원하는 언어
  Node.js (JavaScript)
  Python
  Java (Java 8 호환)
  C# (.NET Core)
  Golang
  C# / Powershell
  Ruby
  Custom Runtime API
  (커뮤니티가 지원하는 사용자 런타임 API 덕분에 웬만한 언어는 모두 Lambda에서 사용 가능, example Rust)
• Lambda 컨테이너 이미지를 지원
  컨테이너 이미지는 Lambda 런타임 API 구현 전제 조건(아무 컨테이너 이미지가 Lambda에서 실행되지 않음)이 필요하며,
  ECS와 Fargate는 임의의 도커 이미지를 실행하는데 더 많이 사용됨
  즉, Lambda에 컨테이너를 실행해야 할 경우 해당 컨테이너가 Lambda 런타임 API를 구현해야 하며
  만약 Lambda 런타임 API를 구현하지 않으면 ECS나 Fargate에서 컨테이너를 실행해야 함

AWS Lambda Integrations Main ones

• 다양한 AWS 서비스와 통합되는 Lambda
  API Gateway : REST API를 생성하고 람다 함수를 호출
  Kinesis : Lambda를 이용해 데이터를 변환
  DynamoDB : 데이터베이스에 어떤 일이 생기면 람다 함수가 작동하도록 트리거를 설정할 때 사용
  S3 : 파일이 생성되거나 할 때 언제든 람다 함수를 작동
  CloudFront : CloudFront용 람다인 Lamdba@Edge가 존재
  CloudWatch Events, EventBridge : AWS의 인프라에 어떤 일에 대응하고자 할 때 상황에 따라 자동화를 람다 함수로 실행
  CloudWatch Logs : 어디든 해당 로그를 스트리밍
  SNS : 알림과 SNS Topic에 대처
  SQS : SQS 대기열 메시지를 처리
  Cognito : 사용자가 데이터베이스에 로그인할 때마다 응답
  
  

  

Example : Serverless Thumbnail creation

• 예) 서버리스 썸네일 생성
  S3 버킷이 있을 때 바로 썸네일을 생성하고 싶다면
  S3에 새 이미지가 업로드되는 이벤트가 생기고 S3 이벤트 알림을 통해 람다 함수가 작동
  이 람다 함수에는 썸네일 생성 코드가 있으며 해당 썸네일은 다른 S3 버킷이나 같은 S3 버킷으로 작은 크기로 푸시 및 업로드됨
  또한 람다 함수는 몇몇 데이터(이미지 이름, 크기, 생성 날짜 등의 이미지의 메타 데이터)를 DynamoDB에 삽입할 수 있음
  이처럼 람다 덕분에 기능이 자동화되고 S3에 새 이미지와 앱이 생성되는 이벤트에 대한 반응형 아키텍처를 얻을 수 있음
  

  

Example: Serverless CRON Job

• 예) 서버리스 CRON 작업
  CRON이란 EC2 인스턴스에서 작업을 생성하는 방법이며 5분마다, 월요일 10시마다 등을 지정하여 예약
  CRON은 가상 서버에 실행되어야 하므로 인스턴스가 실행되지 않거나 CRON이 아무 일도 안 하면 인스턴스 시간이 낭비됨 
  그러므로 CloudWatch Events 규칙 또는 EventBridge 규칙을 만들고
  1시간마다 작동되게 해서 1시간 마다 람다 함수와 통합되면 테스크를 수행할 수 있음 
  
  

  

AWS Lambda Pricing : example

• 호출 당 청구
  처음 1백만 건의 요청은 무료이고 이 후 1백만 건 요청마다 20센트가 과금되며 1ms 단위로 요금이 부과되므로 매우 저렴
• 기간 당 청구
  한달 간 첫 40만 GBs 동안의 컴퓨팅 시간은 무료로 사용 가능
  GBs란 함수가 1GB RAM을 가질 때 실행 시간이 40만 초이며
  다시 말해 실행 시간이 8배 늘어나려면 함수의 RAM은 8배 작은 128MB RAM이 되어야 함
  즉, 1GB의 RAM을 가질 때의 실행 시간 400000초 == 128MB의 RAM을 가질 때의 실행 시간 3200000초이며
  이 후에는 600000초당 1달러가 과금됨
• 람다로 코드를 실행하면 정말 저렴하므로 애플리케이션을 만들 때 널리 사용됨

<Lambda 실습>

• 람다 서비스 소개
  람다는 서버를 생각하지 않고 코드를 실행할 수 있게 도와주며 진짜 서버리스 서비스를 만들 수 있음
  따라서 원하는 프로그래밍 언어를 전부 사용할 수 있음
  
  이렇게 작성되는 코드를 람다 콘솔에 업데이트하면 AWS 람다가 코드를 실행해 주고 "Hello from Lambda!"가 나옴
  즉, 우리가 여기에 제공한 코드를 람다 함수가 실행한 것
  람다 함수는 Run을 클릭하거나 Lambda responds to events 메뉴를 선택하여 호출
  
  이벤트는 다양한 소스에서 나옴
  예) 스트리밍 분석으로부터 전송된 이벤트가 람다 함수로 들어가고 람다 함수는 반환으로 "Hello from Lambda!"를 계속 표시
  스트리밍 분석 이외에도 휴대폰을 클릭하면 모바일/IoT 백엔드로 메시지를 전송하고 해당 IoT 백엔드는 다시 람다 함수를 호출
  사진을 클릭하면 S3 버킷에 업로드되어 데이터가 처리되고 람다 함수가 호출됨
  
  또한 흐름이 들어오고 람다에 대한 호출이 스케일링되면 람다 호출 횟수와 더불어 동시 실행 람다 함수의 횟수도 함께 스케일링됨
  그러므로 부하가 늘어날수록 람다가 자동으로 스케일링되어 컴퓨팅 플랫폼으로 람다를 사용할 때의 장점이 됨
  이를 위해 Scale seamessly를 누르면 람다 함수가 호출되고 시간이 지날수록 호출이 늘어나게 됨
  호출 횟수가 늘어날수록 요금이 늘어나지만 통제되는 수준의 가격이므로 람다는 대규모 작업에 적절한 비용 절감 매커니즘임

톱니바퀴 증가 (스케일링)

• 람다 함수 생성
  함수 생성에는 네 가지 옵션이 존재하며 그 중에서 Use a blueprint를 선택하고 hello-world-python 블루프린트를 사용
  함수 이름은 demo-lambda로 지정한 후 기본 Lambda 권한에 새 역할을 생성하기 위해 기본 설정으로 둠
  
  그리고 함수에 로그 값을 세 개 출력하고 반환하는 값은 하나인 lambda_handler 코드를 불러와서 람다 함수를 생성

• 람다 함수 생성 확인
  함수의 Code 탭에서 lambda_function.py를 클릭하면 앞서 사용했던 함수 코드가 코드 편집기에 불러와지게 됨
  이를 테스트하기 위해 Test 버튼을 클릭하고 새로운 함수 생성을 선택한 후 hello-world 이벤트를 클릭해 DemoEvent 구성
  
  테스트를 해보면 DemoEvent를 실행하고 Response와 Function Logs를 얻게 됨
  Function Logs를 통해 빌드에서 소요시간이 2.32ms, 과금된 실행 시간은 3ms, 프로비저닝한 메모리 크기는 128MB,
  사용된 메모리 양은 47MB, Init 소요시간은 135.61ms임을 알 수 있으며 이는 람다 함수를 처음 사용할 때 표시됨
  
  이를 다시 테스트해보면 람다 함수가 이미 사용 가능한 상태이므로 최초 소요 시간이 줄어들어 소요 시간이 1.33ms가 됨

• 람다 함수 구성 및 확인
  Configuration 탭의 General configuration에서의 Memory
  설정 가능한 메모리 크기는 128MB에서 10240MB이며 메모리가 커질수록 비용이 높아짐
  Timeout 항목은 시간 초과 기준을 3초에서 15분까지 선택할 수 있으며 실제로 필요한 시간 동안만 람다 함수를 사용하도록 함
  Execution role은 람다가 처음 생성한 기존의 역할을 사용하도록 설정
  
  Monitor 탭을 통해 람다 함수에서 어떤 생기는지 알 수 있음
  호출된 횟수는 한 번이고 소요 시간도 볼 수 있으며 오류가 있었는지, 성공했는지 등을 확인할 수 있음
  통합 기능은 CloudWatch 지표와 CloudWatch 로그이며 함수 실행 후에 볼 수 있고 현재 람다 함수의 모든 호출 기록 확인 가능
  가능한 이유로는 Configuration의 Permissions 탭을 보면 람다 콘솔에서 demo_lambda_role 역할을 생성하였기 때문에
  액세스 권한이 있어 CloudWatch 로그에 쓰기를 할 수 있는 것임
  로그 그룹 이름은 /aws/lambda/demo-lambda이며 로그 스트림은 하나이며 로그 전체를 람다로 가져오게 됨
  
  Code 탭을 통해 코드를 수정할 수 있으며 만약 수정을 한 후 오류가 발생하면
  람다는 모든 유형의 오류를 보고하므로 CloudWatch 로그를 통해 오류가 일어난 로그가 어디인지 알 수 있음

Configuration

Monitor

Code를 수정한 후 오류 발생

+) 이번 실습에서는 Runtime Settings가 Python 3.7로 실행되는데 업데이트 버전을 사용할 수 있음
+) 또한 핸들러로는 lambda_function.lambda.handler이기 때문에
     파일의 이름이 lambda_function.py이며 그 안에 있는 함수가 lambda_handler이기 때문에 특정 함수를 호출할 수 있었던 것

파일의 이름이 lambda_function.py

그 안에 있는 함수가 lambda_handler