AWS Lambda 란? (기능, 장점, 단점)

목차

개요

Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있는 컴퓨팅 서비스입니다.
Lambda는 고가용성 컴퓨팅 인프라에서 코드를 실행하고 서버 및 운영 체제 유지 관리, 용량 프로비저닝 및 자동 확장, 코드 모니터링 및 로깅을 비롯한 모든 컴퓨팅 리소스 관리를 수행합니다.
Lambda를 사용하면 거의 모든 유형의 애플리케이션 또는 백엔드 서비스에 대한 코드를 실행할 수 있습니다.
Lambda가 지원하는 언어 중 하나로 코드를 공급하기만 하면 됩니다.

Lambda는 필요할 때만 함수를 실행하고 하루에 몇 개의 요청에서 초당 수천 개까지 자동으로 확장합니다.
사용한 컴퓨팅 시간만큼만 비용을 지불하고, 코드가 실행되지 않을 때는 요금이 부과되지 않습니다.
Lambda API를 사용하여 Lambda 함수를 호출하거나 다른 AWS 서비스의 이벤트에 응답하여 Lambda 함수를 실행할 수 있습니다.

Lambda 기능

다음 주요 기능은 크기 조정 가능하고 안전하며 쉽게 확장할 수 있는 Lambda 애플리케이션 프로그램을 개발하는 데 도움이 됩니다.

• 동시성 및 크기 조정 컨트롤
  동시성 제한 및 프로비저닝된 동시성과 같은 동시성 및 크기 조정 제어를 사용하면 프로덕션 애플리케이션의 크기 조정 및 응답성을 세밀하게 제어할 수 있습니다.
• 비동기식 호출
  함수를 호출할 때 동기식으로 호출할 것인지 비동기식으로 호출할 것인지 선택할 수 있습니다. 동기식 호출의 경우 함수가 이벤트를 처리하여 응답을 반환하기를 기다립니다. 비동기식 호출의 경우, Lambda는 처리를 위해 이벤트를 대기열에 저장하고 즉시 응답을 반환합니다.
  비동기식 호출에서는 함수가 오류를 반환하거나 병목 중인 경우 Lambda이 재시도를 처리합니다. 이 동작을 사용자 지정하기 위해 함수, 버전 또는 별칭에 대한 오류 처리 설정을 구성할 수 있습니다. 처리에 실패한 이벤트를 배달 못한 편지 대기열로 보내거나, 호출 레코드를 대상에 보내도록 Lambda를 구성할 수도 있습니다
• 이벤트 소스 매핑
  스트림 또는 대기열에서 항목을 처리하려면 이벤트 소스 매핑을 생성하면 됩니다. 이벤트 소스 매핑은 Amazon Simple Queue Service(Amazon SQS) 대기열, Amazon Kinesis 스트림 또는 Amazon DynamoDB 스트림에서 항목을 읽어 배치로 함수에 전송하는 Lambda 내 리소스입니다. 함수가 처리하는 각 이벤트에는 수백 또는 수천 개의 항목이 포함될 수 있습니다.
  이벤트 소스 매핑은 처리되지 않은 항목의 로컬 대기열을 유지 관리하고, 함수가 오류를 반환하거나 병목 중인 경우 재시도를 처리합니다. 배치 처리 동작 및 오류 처리를 사용자 정의하거나 처리에 실패한 항목의 레코드를 대상으로 보내도록 이벤트 소스 매핑을 구성할 수 있습니다.
• Destination(대상)
  대상은 함수에 대한 호출 레코드를 수신하는 AWS 리소스입니다. 비동기 호출의 경우, 호출 레코드를 대기열, 주제, 함수 또는 이벤트 버스에 보내도록 Lambda를 구성할 수 있습니다. 성공적인 호출과 처리에 실패한 이벤트에 대해 별도의 대상을 구성할 수 있습니다. 호출 레코드에는 이벤트, 함수의 응답 및 레코드가 전송된 이유에 대한 세부 정보가 포함되어 있습니다.
  스트림에서 읽기를 수행하는 이벤트 소스 매핑의 경우, 처리에 실패한 배치 레코드를 대기열이나 주제로 보내도록 Lambda를 구성할 수 있습니다. 이벤트 소스 매핑에 대한 실패 레코드에는 배치에 대한 메타데이터가 포함되어 있으며 스트림의 항목을 가리킵니다.
• 컨테이너 이미지로 정의된 함수
  선호하는 컨테이너 이미지 도구, 워크플로 및 종속성을 사용하여 Lambda 함수를 빌드, 테스트 및 배포할 수 있습니다.
• 코드 서명
  Lambda에 대한코드 서명은 승인된 개발자가 게시한 변경되지 않은 코드만 Lambda 함수에 배포되었는지 확인할 수 있는 신뢰 및 무결성 제어 기능을 제공합니다.
• Lambda 익스텐션
  Lambda 익스텐션을 사용하여 Lambda 함수를 보강할 수 있습니다. 예를 들어 익스텐션 기능을 사용하면 Lambda를 모니터링, 가관측성, 보안 및 거버넌스를 위해 자주 사용하는 도구와 보다 쉽게 통합할 수 있습니다.
• 함수 블루프린트
  함수 블루프린트는 다른 AWS 서비스 또는 서드 파티 애플리케이션을 Lambda와 함께 사용하는 방법을 보여 주는 샘플 코드를 제공합니다. 블루프린트에는 Node.js 및 Python 런타임에 대한 샘플 코드 및 함수 구성 사전 설정이 포함되어 있습니다.
• 데이터베이스 액세스
  데이터베이스 프록시는 데이터베이스 연결 풀을 관리하고 함수에서 쿼리를 릴레이합니다. 이렇게 하면 함수는 데이터베이스 연결을 소모하지 않고 높은 동시성 레벨에 도달할 수 있습니다.
• 파일 시스템 액세스
  Amazon Elastic File System(Amazon EFS) 파일 시스템을 로컬 디렉터리에 마운트하도록 함수를 구성할 수 있습니다. Amazon EFS를 사용하면 함수 코드가 안전하고 높은 동시성으로 공유 리소스에 액세스하여 수정할 수 있습니다.
• 애플리케이션 템플릿
  Lambda 콘솔을 사용하여 지속적 전달 파이프라인에서 애플리케이션을 생성할 수 있습니다. Lambda 콘솔의 애플리케이션 템플릿에는 하나 이상의 함수에 대한 코드, 함수를 정의하고 AWS 리소스를 지원하는 애플리케이션 템플릿, AWS CodePipeline 파이프라인을 정의하는 인프라 템플릿이 포함되어 있습니다. 파이프라인에는 포함된 Git 리포지토리에 변경 사항을 푸시할 때마다 실행되는 빌드 및 배포 단계가 있습니다.

장점

1. 더 빠른 개발
   소프트웨어 개발 이미지
   서버리스 아키텍처가 시스템 엔지니어링의 문제를 완화함에 따라 제품 엔지니어는 빠르게 혁신할 수 있습니다. 따라서 이제 운영 문제에 더 적은 시간을 할애하여 DevOps의 삶을 더 쉽게 만들 수 있습니다.
   기술 스택은 유연하게 업데이트할 수 있습니다. ID 관리, 스토리지는 FaaS에 노출되거나 미들웨어에 의해 처리되는 인터넷 애플리케이션의 우려 사항의 일부 예입니다. 엔지니어는 애플리케이션의 실제 비즈니스 로직에 집중할 수 있습니다.
2. 간편한 운영 관리
   AWS Scaling 기능 이미지
   FaaS의 Automatic Scaling 기능은 계산 비용을 절감할 뿐만 아니라 운영 관리 오버헤드도 줄입니다.
   서버리스 아키텍처 기반 플랫폼은 인프라 서비스와 플랫폼 위에서 실행되는 애플리케이션을 명확하게 구분합니다.
   시스템 엔지니어는 데이터베이스 및 로드 밸런서와 같은 핵심 서비스 관리에 집중할 수 있고 제품 엔지니어는 플랫폼에서 실행되는 기능을 관리할 수 있습니다.
   FaaS 아키텍처를 번들화하고 배포하는 것은 전체 서버를 배포하는 것과 비교할 때 매우 간단합니다. 지속적인 통합, 지속적인 전달 또는 컨테이너화 도구가 필요하지 않습니다. 개발자는 공급업체 콘솔에서 직접 코드를 작성할 수 있습니다.
   따라서 AWS Lambda와 같은 완전한 서버리스 아키텍처 솔루션은 시스템 관리가 필요하지 않습니다.
3. FaaS의 확장성 이점
   이벤트가 유입되면 AWS는 Lambda 이벤트를 확장하여 들어오는 모든 트래픽을 처리합니다. 거꾸로, 그것은 훌륭한 cron 작업 서비스로 작동합니다.
   Lambda는 SQS 작업으로 배치를 확장하고 대기열에서 선택하고 프로세스가 작동한 다음 완료되면 다시 완전히 종료합니다. EC2 스핀업이 필요하지 않습니다.
   확장은 공급업체에서 처리하므로 FaaS 호스팅 앱을 사용하면 메모리가 부족해지기 전에 처리할 수 있는 동시 요청 수를 고려할 필요가 없습니다. 이것은 각 요청/이벤트에 대해 수행됩니다. 다운스트림 데이터베이스 및 비 FaaS 구성 요소의 로드가 크게 증가하면 처리해야 합니다.
4. 낮은 운영 비용
   이 서버리스 아키텍처 기반 기술의 기본 이점은 기능이 실행되는 시간과 실행에 필요한 리소스에 대해서만 비용을 지불한다는 것입니다.
   AWS Lambda는 FaaS 기능이 호출된 시간에 대해서만 요금을 청구합니다. 이는 한 달 동안 서버를 운영하는 것에 비해 비용이 95% 적게 청구됨을 의미합니다. 운영비 절감이 가능합니다.

단점

1. 상태 제한
   in-process 또는 host-created 상태는 후속 호출에 사용할 수 없습니다. FaaS 기능은 로컬 상태와 관련하여 상당한 제한이 있습니다. 상태 저장 지원 서비스, 일반적으로 데이터베이스(예: S3, Redis)는 지속해야 하는 데이터를 저장하는 데 필요합니다.
2. DoS(서비스 거부)
   현재 AWS Lambda는 모든 람다에서 실행할 수 있는 동시 실행을 1000개로 제한합니다. 전체 AWS 계정에는 이 제한이 있으며 프로덕션과 테스트 모두에 동일한 AWS 계정을 사용하면서 로드 테스트를 시도하면 프로덕션에서 실수로 DOS가 발생합니다.
3. 제한된 실행 기간
   AWS Lambda 함수는 5분 이상 실행되면 중단됩니다. 비디오 파일 형식 변환과 같은 일부 작업은 지정된 제한 이상으로 실행됩니다.
4. 시작 지연 문제
   FaaS 기능, 특히 AWS의 JVM 구현 기능이 응답하는 데 시간이 걸릴 수 있습니다. 시작하는 데 10초 이상 걸릴 수 있습니다. API/마이크로 서비스는 데이터베이스 및 기타 항목에 대한 연결을 개방 및 준비 상태로 유지할 수 있기 때문에 거의 항상 더 빠르게 응답할 수 있습니다.
5. 테스트 장애
   
   서버리스 앱의 단위 테스트는 여러 가지 이유로 간단합니다. 구현할 사용자 정의 라이브러리나 인터페이스가 많지 않습니다. 코딩만 하면 됩니다.
   서버리스 앱의 경우 통합 테스트가 다소 어렵습니다. 현재 대부분의 공급업체는 사용할 수 있는 로컬 구현을 제공하지 않으므로 일반 프로덕션 구현을 사용해야 합니다.
   이는 서버리스 아키텍처의 모든 통합/승인 테스트에 대해 원격으로 배포하고 원격 시스템을 사용하여 테스트한다는 것을 의미합니다. 구성이 적고 교차 계정 실행 제한은 테스트 방법에 영향을 줍니다.
6. 실행 과제
   현재, 기능 집합을 응용 프로그램에 번들로 묶는 기능이 부족합니다. 전체 논리 애플리케이션의 모든 기능에 대해 별도로 FaaS 아티팩트를 배포해야 하기 때문입니다. JVM에 20개의 FaaS 기능을 배포한다는 것은 JAR을 20번 배포하는 것을 의미합니다. 기능 그룹을 원자적으로 배포할 수 없습니다. 기능을 트리거하는 이벤트 소스를 끄고 전체 그룹을 배포한 다음 이벤트 소스를 다시 켜야 합니다.
   제로 다운타임 애플리케이션은 이를 감당할 수 없습니다. 버전이 지정되지 않은 응용 프로그램을 원자적으로 롤백할 수 있는 방법은 없습니다.
7. 모니터링 및 디버깅 제한 사항
   현재, 당신은 공급업체가 제공하는 무엇이든 모니터링 및 디버깅 측면에 갇혀 있습니다. AWS Lambda에서는 매우 기본적이며 일부 경우에 적합하지만 이 영역에서 정말 필요한 것은 개방형 API와 타사 서비스가 도움을 줄 수 있는 기능입니다.

 

 

Reference

https://hevodata.com/blog/serverless-architecture-aws-lambda/ 

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/welcome.html 

 

 

layers, runtime API

https://aws.amazon.com/ko/blogs/korea/new-for-aws-lambda-use-any-programming-language-and-share-common-components/

AWS Lambda 신규 기능 – Layers 기반 라이브러리 관리 및 Runtime API를 통한 모든 언어 지원 | Amazon Web Se

 

 

 

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/runtimes-extensions-api.html

Lambda 익스텐션 API - AWS Lambda