Serverless Architectures with AWS Lambda(Overview and Best Practices) Kor 2/2
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Serverless Architectures with AWS Lambda(Overview and Best Practices)(November 2017, 영문) 내용에 기반하여 작성 되었습니다.
본 문서는 정보 제공 목적으로만 제공됩니다. 이 문서는 이 문서의 발행일 현재 AWS의 현재 제품 및 관행을 나타내며 예고 없이 변경될 수 있습니다. 고객은 본 문서의 정보 및 AWS의 제품 또는 서비스의 사용에 대한 자체적인 독립적 평가를 수행할 책임이 있으며, 각 정보는 명시적이든 묵시적이든 어떠한 종류의 보증도 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 계열사, 공급업체 또는 라이센스 제공자의 보증, 진술, 계약, 조건 또는 보증서를 작성하지 않습니다. 고객에 대한 AWS의 책임과 책임은 AWS 협약에 의해 관리되며, 이 문서는 AWS와 고객 간의 어떠한 합의에도 속하지 않으며 수정 하지도 않습니다.
© 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.
서버리스 모범 사례
Lambda 기반 서버리스 애플리케이션의 구성 요소를 다루었으므로 권장 모범 사례를 살펴 보겠습니다. 서버리스 아키텍처에도 적용되는 많은 SDLC 및 서버 기반 아키텍처 모범 사례(단일 장애 지점 제거, 배포 전 변경 테스트, 중요 데이터 암호화 등)가 있습니다.
그러나 서버리스 아키텍처에 대한 모범 사례를 달성하는 것은 운영 모델이 얼마나 다르기 때문에 다른 작업이 될 수 있습니다. 운영 체제나 인프라의 하위 레벨 구성 요소에 대한 액세스 권한이나 우려 사항이 없습니다. 이러한 이유로, 사용자는 자신의 애플리케이션 코드/아키텍처, 사용자가 따르는 개발 프로세스 및 모범 사례를 따를 수 있는 애플리케이션 활용 AWS 서비스의 기능에만 초점을 맞추고 있습니다.
먼저 AWS 잘 설계된 프레임워크에 따라 서버리스 아키텍처를 설계하기 위한 일련의 모범 사례를 검토합니다. 그런 다음 서버리스 애플리케이션을 구축할 때 개발 프로세스에 대한 몇 가지 모범 사례와 권장 사항을 다룹니다.
서버리스 아키텍처 모범사례
AWS Well-Architected Framework에는 워크로드를 모범 사례와 비교하고 안정적이고 효율적인 시스템을 생성하기위한 지침을 확보하여 기능 요구 사항에 집중할 수있는 전략이 포함되어 있습니다. 이 솔루션은 보안, 안정성, 성능 효율성, 비용 최적화, 운영 효율성 등 5가지 요소를 기반으로 합니다. 프레임워크의 많은 지침은 서버리스 애플리케이션에 적용됩니다. 그러나 서버리스 아키텍처에 고유한 특정 구현 단계 또는 패턴이 있습니다. 다음 섹션에서는 잘 설계된 각 기둥에 대해 서버리스 권장 사항을 설명합니다.
보안 모범 사례
애플리케이션에 대한 보안 설계 및 구현은 항상 최우선 사항이어야 합니다. 이는 서버리스 아키텍처에서 변하지 않는 사항입니다. 서버 호스팅된 애플리케이션과 비교하여 서버리스 애플리케이션을 보호하기 위한 주요 차이점은 분명합니다. 사용자가 보호할 서버가 없다는 것입니다. 그러나 애플리케이션의 보안에 대해서는 여전히 고려해야 합니다. 서버리스 보안에 대한 공유 책임 모델이 여전히 있습니다.
Lambda 및 서버리스 아키텍처에서는 바이러스 백신/맬웨어 소프트웨어, 파일 무결성 모니터링, 침입 탐지/예방 시스템, 방화벽 등을 통해 애플리케이션 보안을 구현하는 대신 안전한 애플리케이션 코드 작성, 소스 코드 변경에 대한 엄격한 액세스 제어 및 다음 작업을 통해 보안 모범 사례를 보장합니다. Lambda 기능이 통합되는 각 서비스에 대한 코드 변경 및 AWS 보안 모범 사례를 따르십시오.
다음은 많은 서버리스 사용 사례에 적용 할 수있는 서버리스 보안 모범 사례에 대한 간략한 목록입니다. 사용자 고유의 특정 보안 및 규정 준수 요구 사항을 이해하고 여기에 설명 된 것 이상을 포함 할 수 있습니다.
· One IAM Role per Function
AWS 계정의 각 Lambda 기능은 IAM 역할과 1:1 관계가 있어야 합니다. 여러 기능이 정확히 동일한 정책으로 시작되는 경우에도 IAM 역할을 항상 분리하여 기능의 미래에 대한 최소한의 권한 정책을 보장할 수 있도록 합니다.
예를 들어 여러 Lambda 기능에서 AWS KMS 키에 액세스해야 하는 Lambda 기능의 IAM 역할을 공유한 경우 이제 이러한 모든 기능이 동일한 암호화 키에 액세스할 수 있게 됩니다.
· Temporary AWS Credentials
Lambda 함수 코드 또는 구성에 장수 AWS 자격 증명이 포함되어 있지 않아야 합니다. 이 기능은 정적 코드 분석 도구를 사용하여 코드 기반에서 이러한 현상이 발생하지 않도록 하는 데 매우 유용합니다. 대부분의 경우 IAM 실행 역할은 다른 AWS 서비스와 통합하는 데 필요한 모든 것입니다. 자격 증명을 제공하지 않고 AWS SDK를 통해 코드 내에 AWS 서비스 클라이언트를 생성하기만 하면 됩니다. SDK는 역할에 대해 생성된 임시 자격 증명의 검색 및 회전을 자동으로 관리합니다. 다음은 Java를 사용하는 예입니다.
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.defaultClient(); Table myTable = new Table(client, "MyTable");이 코드 스니펫은 Java용 AWS SDK가 기능에 할당된 임시 IAM 자격 증명을 사용하여 DynamoDB API에 요청을 자동으로 서명하는 DynamoDB 테이블과 상호 작용하기 위한 개체를 생성하는 데 필요한 모든 것입니다.
그러나 실행 역할이 기능에 필요한 액세스 유형에 충분하지 않은 경우가 있을 수 있습니다. 이는 Lambda 기능이 수행할 수 있는 일부 교차 통합의 경우나 Amazon Cognito ID 역할과 DynamoDB 세분화된 액세스 제어를 결합하여 사용자별 액세스 제어 정책이 있는 경우에 해당할 수 있습니다. 교차 계정 사용 사례의 경우 AWS 보안 토큰 서비스 내의 AssumeRole API에 대한 액세스 권한을 부여하고 임시 액세스 자격 증명을 검색하기 위해 통합해야 합니다.
사용자별 액세스 제어 정책의 경우 해당 사용자 ID와 함께 기능이 제공된 다음 Amazon Cognito API GetCredentialsForIdentity와 통합되어야 합니다. 이 경우 Lambda 기능의 호출과 관련된 각 사용자에 대해 올바른 자격 증명을 활용하도록 코드에서 이러한 자격 증명을 적절하게 관리해야 합니다. 일반적으로 애플리케이션은 이러한 사용자별 자격 증명을 사용자 세션 데이터의 일부로 DynamoDB 또는 Amazon ElastiCache와 같은 위치에 암호화하여 저장하므로, 이러한 자격 증명을 나중에 반환되는 사용자에 대한 요청에 대해 재생성하는 것보다 지연 시간을 줄이고 확장성을 높여 검색할 수 있습니다.
· Persisting Secrets
Lambda 기능을 사용해야 하는 오래 지속되는 비밀(예: 데이터베이스 인증 정보, 종속 서비스 액세스 키, 암호화 키 등)이 있는 경우가 있습니다. 애플리케이션에서 보안 관리를 위한 몇 가지 옵션을 사용하는 것이 좋습니다.
o Lambda Environment Variables with Encryption Helpers
Advantages 함수 런타임 환경에 직접 제공되어 암호를 검색하는 데 필요한 대기 시간과 코드를 최소화합니다.
Disadvantages — 환경 변수는 함수 버전에 연결됩니다. 환경 변수를 업데이트하려면 새 함수 버전이 필요합니다(더 견고하지만 안정적인 버전 기록도 제공됨).
o Amazon EC2 Systems Manager Parameter Store
Advantages — 보안과 함수가 서로 관련되는 방식에 대한 최대 유연성을 제공하기 위해 Lambda 함수가 완전히 분리되었습니다.
Disadvantages — 매개 변수/보안을 검색하려면 매개 변수 저장소에 대한 요청이 필요합니다. 중요하지는 않지만 환경 변수에 대한 지연 시간뿐만 아니라 서비스 종속성도 추가되므로 코드를 조금 더 작성해야 합니다.
· Using Secrets
보안 내용은 항상 메모리에만 존재하며 디스크에 기록되거나 기록되지 않아야 합니다. 응용 프로그램이 실행 중인 동안 암호를 해지해야 하는 경우 암호 회전을 관리하는 코드를 작성합니다.
· API Authorization
API Gateway를 Lambda 기능의 이벤트 소스로 사용하는 것은 API 클라이언트에 대한 인증 및 권한 소유권이 있다는 점에서 다른 AWS 서비스 이벤트 소스 옵션과 다릅니다. API Gateway는 기본 AWS SigV4 인증, 생성된 클라이언트 SDK 및 사용자 지정 권한과 같은 기능을 제공함으로써 많은 작업을 수행할 수 있습니다. 그러나 API의 보안 상태가 설정한 막대와 일치하는지 확인해야 합니다. API 보안 모범 사례에 대한 자세한 내용은 이 설명서를 참조합니다.
· VPC Security
Lambda 함수가 VPC 내부에 배포 된 리소스에 액세스해야하는 경우 최소 권한 보안 그룹, Lambda 함수 관련 서브넷, 네트워크 ACL 및 Lambda 함수에서만 들어오는 트래픽을 허용하는 라우팅 테이블을 사용하여 네트워크 보안 모범 사례를 적용해야합니다.
이러한 사례와 정책은 Lambda 기능이 종속 항목에 연결되는 방식에 영향을 미칩니다. Lambda 함수 호출은 여전히 이벤트 소스와 호출 API를 통해 발생합니다 (VPC 구성의 영향을받지 않음).
· Deployment Access Control
UpdateFunctionCode API에 대한 호출은 코드 배포와 유사합니다. UpdateAlias API를 통해 해당 새 버전으로 별칭을 이동하는 것은 코드 릴리스와 유사합니다. 극도로 민감하게 기능 코드/별칭을 사용할 수 있는 Lambda API에 대한 액세스를 처리합니다. 따라서 모든 기능(최소한 생산 기능)에 대해 이러한 API에 대한 사용자 직접 액세스를 제거하여 사용자의 오류 가능성을 제거해야 합니다. 자동화를 통해 Lambda 함수의 코드를 변경해야 합니다. 이를 염두에 두고 Lambda로의 배포 시작 지점은 지속적인 통합/연속 제공(CI/CD) 파이프라인이 시작되는 곳이 됩니다. 이는 저장소의 릴리스 분기, AWS CodePipeline 파이프라인을 트리거하는 새 코드 패키지가 업로드되는 S3 버킷 또는 조직 및 프로세스와 관련된 다른 위치일 수 있습니다. 어디에 있든 팀 구조와 역할에 맞는 엄격한 액세스 제어 메커니즘을 적용해야 하는 새로운 장소가 됩니다.
안정성 모범 사례
서버리스 애플리케이션을 구축하여 미션 크리티컬한 사용 사례를 지원할 수 있습니다. 미션 크리티컬한 애플리케이션과 마찬가지로, W의 Werner Vogels, CTO, Amazon.com이 “모든 것은 항상 실패합니다.”라고 옹호하는 사고방식을 가지고 설계하는 것이 중요합니다. 서버리스 애플리케이션의 경우, 이는 코드에 논리 버그를 도입하고, 애플리케이션 의존성을 저하시키는 것을 의미할 수 있으며, 서버리스 애플리케이션에 여전히 적용되는 기존의 모범 사례를 사용하고 이를 방지하고 고려해야 하는 유사한 애플리케이션 레벨 문제를 의미할 수 있습니다. 서버리스 애플리케이션의 경우 이벤트로부터 추상화된 인프라 수준 서비스 이벤트의 경우 고가용성 및 내결함성을 달성하기 위해 애플리케이션을 설계한 방법을 이해해야 합니다.
고 가용성
고가용성(HA)은 운영 애플리케이션에 중요합니다. Lambda 함수의 가용성 상태는 실행할 수 있는 가용성 영역의 수에 따라 달라집니다. 함수가 기본 네트워크 환경을 사용하는 경우 해당 AWS 영역의 모든 가용성 영역 내에서 자동으로 실행할 수 있습니다. 기본 네트워크 환경에서 기능에 대한 고가용성을 구성하는 데 필요한 것은 없습니다. 함수가 VPC 내에 배포된 경우 서브넷(및 해당 가용성 영역)은 가용성 영역 운영 중단 시 함수가 계속 사용 가능한지 여부를 정의합니다.
따라서 VPC 설계에 여러 가용성 영역에 서브넷이 포함되어 있어야 합니다. 가용성 영역 운영 중단이 발생하는 경우, 필요한 동시 기능의 수를 지원하기 위해 나머지 서브넷에 적절한 IP 주소가 계속 있어야 합니다. 기능에 필요한 IP 주소 수를 계산하는 방법에 대한 자세한 내용은 이 설명서를 참조합니다.
결함 허용
애플리케이션 가용성을 위해 여러 AWS 영역을 활용해야 하는 경우 설계에서 이를 고려해야 합니다. 여러 AWS 리전에 람다 함수 코드 패키지를 복제하는 것은 복잡한 연습이 아닙니다. 대부분의 다중 리전 애플리케이션 설계와 같이 복잡할 수 있는 것은 애플리케이션 스택의 모든 계층에서 페일오버 결정을 조정하는 것입니다. 즉, Lambda 기능뿐 아니라 이벤트 소스(및 이벤트 소스 업스트림의 종속성)와 지속성 계층에 대해서도 다른 AWS 리전으로의 전환을 이해하고 조정해야 합니다. 결국, 다중 리전 아키텍처는 애플리케이션별로 매우 다릅니다. 다중 리전 설계를 실현하기 위해 가장 중요한 것은 설계의 맨 앞에 이를 설명하는 것입니다.
복구
함수를 실행할 수 없는 경우 서버리스 응용 프로그램의 작동 방식을 고려하십시오. API Gateway를 이벤트 소스로 사용하는 사용 사례의 경우 오류 메시지를 정상적으로 처리하고 성능이 저하될 경우 기능을 다시 실행할 수 있을 때까지 사용 가능한 사용자 환경을 제공하는 것만큼 간단할 수 있습니다.
비동기식 사용 사례의 경우 운영 중단 기간 동안 기능 호출이 손실되지 않도록 하는 것이 매우 중요합니다. 기능이 복구된 후 수신된 모든 이벤트가 처리되도록 하려면 비활성 문자 대기열을 활용하고 복구 후 해당 대기열에 있는 이벤트를 처리하는 방법을 구현해야 합니다.
성능 효율성 모범 사례
성능 모범 사례에 대해 자세히 살펴보기 전에 사용 사례를 비동기식으로 달성할 수 있는 경우, 비용 최적화를 제외하고는 기능 성능에 대해 신경 쓸 필요가 없습니다. 이벤트 호출을 사용할 이벤트 소스 중 하나를 활용할 수 있습니다.풀 기반 호출 모델을 입력하거나 사용합니다. 이러한 방법만으로도 Lambda가 이벤트를 별도로 처리하는 동안 애플리케이션 로직을 계속할 수 있습니다. Lambda 함수 실행 시간이 최적화하려는 경우, Lamda 함수의 실행 기간은 기본적으로 기능 구성에서 할당한 리소스, 선택한 언어 런타임 및 쓰는 코드의 세 가지 영향을 받습니다.
최적의 메모리 크기 선택
Lambda는 기능에 할당된 RAM의 양인 컴퓨팅 리소스의 양을 설정하거나 축소할 수 있는 단일 다이얼을 제공합니다. 할당된 RAM의 양은 또한 기능이 수신하는 CPU 시간 및 네트워크 대역폭 양에도 영향을 미칩니다. 단순히 기능을 적절하게 빠르게 실행하는 가장 작은 리소스 양을 선택하는 것은 반패턴입니다.
Lambda는 100ms 단위로 빌드되므로 이 전략은 애플리케이션에 지연 시간을 추가하는 것뿐만 아니라 추가된 지연 시간이 리소스 비용 절감 효과를 초과할 경우 전반적으로 더 많은 비용이 들 수 있습니다.
사용 가능한 각 리소스 수준에서 Lambda 기능을 테스트하여 애플리케이션에 적합한 가격/성능 수준을 결정하는 것이 좋습니다. 리소스 수준이 증가함에 따라 기능의 성능이 로그에서 개선되어야 합니다. 실행 중인 논리는 함수 실행 시간에 대한 하한을 정의합니다. 또한 기능에서 사용할 수 있는 추가 RAM/CPU/대역폭은 더 이상 상당한 성능 향상을 제공하지 않는 리소스 임계값이 있습니다. 그러나 Lambda의 리소스 수준이 증가함에 따라 가격이 선형적으로 높아집니다. 로그 기능이 구부러지는 위치를 검사하여 기능에 맞는 최적의 구성을 선택해야 합니다.
다음 그래프는 예제 기능에 이상적인 메모리를 할당하여 비용을 절감하고 지연 시간을 단축하는 방법을 보여줍니다. 여기서는 더 낮은 메모리 옵션에서 512MB를 사용하기 위한 100ms당 추가 컴퓨팅 비용이 더 많은 리소스를 할당하여 기능에서 지연 시간을 줄이는 것보다 큽니다. 그러나 512MB 이후에는 이 특정 기능의 논리에 대한 성능 향상 효과가 감소하므로 이제 100ms당 추가 비용이 증가하게 됩니다. 따라서 총 비용을 최소화하기 위한 최적의 선택으로 512MB가 남습니다.
기능에 대한 메모리 사용량은 호출당 결정되며 CloudWatch Logs에서 확인할 수 있습니다. 각 호출 시 다음과 같이 REPORT: 항목이 만들어집니다.
사용된 최대 메모리: 필드를 분석하여 기능에 더 많은 메모리가 필요한지 또는 기능의 메모리 크기를 과도하게 프로비저닝했는지 확인할 수 있습니다.
언어 런타임 성능
언어 런타임 성능을 선택하는 것은 지원되는 각 런타임의 편안함과 기술 수준에 따라 달라집니다. 그러나 성능이 응용 프로그램의 주요 고려 사항이라면 다른 런타임 환경에서와 같이 Lambda에서 각 언어의 성능 특성이 기대할 수 있습니다. 컴파일 된 언어 (Java 및 .NET)는 컨테이너의 초기 시작 비용이 가장 많이 듭니다 첫 번째 호출이지만 후속 호출에 대한 최상의 성능을 보여줍니다. 해석 된 언어 (Node.js 및 Python)는 컴파일 된 언어에 비해 초기 호출 시간이 매우 빠르지 만 컴파일 된 언어와 동일한 수준의 최대 성능에 도달할 수 없습니다.
애플리케이션 사용 사례가 매우 지연 시간에 민감하고 초기 호출 비용이 자주 발생하기 쉬운 경우(매우 빠른 트래픽 또는 매우 자주 사용) 해석 언어 중 하나를 사용하는 것이 좋습니다.
응용 프로그램에 트래픽 패턴 내에 큰 피크나 밸리이 없거나 Lamda 기능 응답 시간에 차단된 사용자 경험이 없는 경우, 이미 가장 익숙한 언어를 선택하는 것이 좋습니다.
코드 최적화
Lambda 함수의 성능의 대부분은 Lambda 함수를 실행하는 데 필요한 논리와 종속 관계에 따라 결정됩니다. 애플리케이션마다 다르기 때문에 이러한 모든 최적화는 다루지 않습니다. 하지만 Lambda에 맞게 코드를 최적화하는 몇 가지 일반적인 모범 사례가 있습니다. 이는 컨테이너 재사용(이전 개요에서 설명한 바와 같이)을 활용하고 콜드 스타트 초기 비용을 최소화하는 것과 관련이 있습니다.
다음은 Warm 컨테이너가 호출될 때 기능 코드의 성능을 향상시키는 몇 가지 예입니다.
· 초기 실행 후 코드가 로컬로 검색하는 외부 구성 또는 종속성을 저장하고 참조합니다.
· 모든 호출에 대해 변수/개체의 재초기화를 제한합니다(글로벌/정적 변수, 싱글릿 사용 등).
· 이전 호출 중에 설정된 연결(HTTP, 데이터베이스 등)을 활성화하고 재사용할 수 있습니다.
마지막으로 Lambda 함수에 콜드 스타트가 걸리는 시간을 제한하려면 다음을 수행해야합니다.
1. 프라이빗 IP를 통해 VPC 내의 리소스에 연결해야 하는 경우가 아니면 항상 기본 네트워크 환경을 사용하십시오. 이는 Lambda 함수의 VPC 구성 (VPC 내 ENI 생성과 관련)과 관련된 추가 콜드 스타트 시나리오가 있기 때문입니다.
2. 컴파일 된 언어보다 해석 된 언어를 선택하십시오.
3. 함수 코드 패키지를 런타임 요구 사항으로 만 정리하십시오. 이를 통해 호출 전에 Amazon S3에서 코드 패키지를 다운로드하는 데 걸리는 시간이 줄어 듭니다.
애플리케이션의 성능 이해
하나 이상의 Lambda 함수를 포함 할 수있는 애플리케이션 아키텍처의 다양한 구성 요소를 파악하려면 AWS X-Ray를 사용하는 것이 좋습니다. X-Ray를 사용하면 다음 그림과 같이 각 구성 요소 부분을 통해 애플리케이션 요청의 전체 수명주기를 추적하여 각 구성 요소의 대기 시간 및 기타 메트릭을 개별적으로 표시 할 수 있습니다.
X-Ray에 대한 자세한 내용은 이 설명서를 참조하십시오.
운영 우수성 모범 사례
서버리스 응용 프로그램을 만들면 기존 응용 프로그램에 수반되는 많은 운영 부담이 제거됩니다. 그렇다고 해서 운영 효율성에 대한 초점을 줄여야한다는 의미는 아닙니다. 즉, 운영 초점을 더 적은 수의 책임으로 좁히고 더 높은 수준의 운영 우수성을 달성 할 수 있습니다.
Logging
Lambda의 각 언어 런타임은 함수가 기록 된 명령문을 CloudWatch Logs로 전달하는 메커니즘을 제공합니다. 로그를 적절히 사용하는 것은 말할 것도 없고 Lambda 및 서버리스 아키텍처에는 새로운 것이 아닙니다. 오늘날 모범 사례로 고려되지는 않지만 많은 운영 팀은 응용 프로그램이 배포 된 서버에서 로그를 생성 할 때 로그를 보는 데 의존합니다. 서버가 없기 때문에 Lambda에서는 불가능합니다. 또한 현재 실행중인 Lambda 함수의 코드를 “스텝 스루”할 수는 없습니다 (배포 전에 AWS SAM 로컬에서이 작업을 수행 할 수는 있음). 배포 된 기능의 경우 기능 동작을 조사하기 위해 생성 한 로그에 크게 의존합니다. 따라서 생성하는 로그는 계산 시간을 너무 많이 요구하지 않고도 발생하는 문제를 추적 / 감사 할 수 있도록 정확한 상세 균형을 찾는 것이 중요합니다.
Lambda 환경 변수를 사용하여 함수가 참조 할 수있는 LogLevel 변수를 만들어 런타임 중에 만들 로그 문을 결정할 수 있도록 하는 것이 좋습니다. 적절한 로그 수준을 사용하면 운영 감사 중에만 추가 컴퓨팅 비용과 스토리지 비용을 선택적으로 발생시킬 수 있습니다.
지표 및 모니터링
Lambda는 다른 AWS 서비스와 마찬가지로 다양한 CloudWatch 메트릭을 즉시 제공합니다. 여기에는 함수가 받은 호출 횟수, 함수의 실행 기간 등과 관련된 메트릭이 포함됩니다. CloudWatch를 통해 제공된 모든 메트릭에 대해 각 Lambda 기능에 대한 경보 임계값(높음 및 낮음)을 생성하는 것이 좋습니다. 기능이 호출되는 방식이나 실행 시간이 크게 변경되면 아키텍처에서 문제를 가장 먼저 파악할 수 있습니다.
애플리케이션이 수집해야하는 추가 지표 (예 : 애플리케이션 오류 코드, 종속 성별 대기 시간 등)에는 CloudWatch 또는 선택한 모니터링 솔루션에 이러한 사용자 지정 지표를 저장하는 두 가지 옵션이 있습니다.
· 사용자 지정 메트릭을 생성하고 실행 중인 람다 기능에 필요한 API와 직접 통합할 수 있습니다. 종속성이 가장 적으며 메트릭을 가능한 빨리 기록합니다. 그러나 Lambda 실행 시간과 리소스를 다른 서비스 종속성과 통합하는 데 사용해야 합니다. 이 경로를 따라 측정지표를 캡처하기 위한 코드가 특정 Lambda 함수와 긴밀하게 결합되지 않고 모듈화되어 사용 가능한지 확인합니다.
· Lambda 함수 코드 내에서 메트릭을 캡처하고 제공된 로깅 메커니즘을 사용하여 로그에 기록합니다. 그런 다음 함수 스트림에 CloudWatch Logs 메트릭 필터를 생성하여 메트릭을 추출하여 CloudWatch에서 사용할 수 있도록 합니다. 또는 CloudWatch 로그 스트림에 구독 필터로 다른 Lamda 기능을 생성하여 필터링된 로그 문을 다른 메트릭 솔루션으로 푸시합니다. 이 경로는 더 복잡해지고 이전 메트릭스 캡처 솔루션만큼 실시간에 가깝지 않습니다. 그러나 이 기능을 사용하면 외부 서비스 요청 대신 로깅을 통해 메트릭을 보다 빠르게 생성할 수 있습니다.
배포
Lambda에서 배포를 수행하는 것은 새 기능 코드 패키지를 업로드하고 새 버전을 게시하며 별칭을 업데이트하는 것만 큼 간단합니다. 그러나 이러한 단계는 Lambda를 사용한 배포 프로세스의 일부일뿐입니다. 각 배포 프로세스는 응용 프로그램에 따라 다릅니다. 사용자 나 응용 프로그램 동작을 방해하지 않는 배포 프로세스를 디자인하려면 각 Lambda 함수와 해당 이벤트 소스 및 종속성 간의 관계를 이해해야 합니다. 고려해야 할 사항은 다음과 같습니다.
· 병렬 버전 호출 — 새 버전의 Lambda 함수를 가리키도록 별칭을 업데이트하면 서비스 측에서 비동기적으로 발생합니다. 이전 소스 코드 패키지를 포함하는 기존 함수 컨테이너가 별명이 업데이트 된 새 함수 버전과 함께 계속 호출되는 시간이 짧습니다. 이 과정에서 응용 프로그램이 계속 예상대로 작동하는 것이 중요합니다. 이 문제는 새로운 기능 버전을 대상으로 하는 모든 호출을 관찰 한 후에 배치 후 데이터베이스 종속성, 메시지 대기열 등과 같은 스택 종속성이 해제되지 않을 수 있습니다.
· 배포 일정 — 최대 트래픽 시간 동안 Lambda 기능 배포를 수행하면 시작보다 콜드 스타트 시간이 길어질 수 있습니다. Lambda 환경에서 프로비저닝되는 새 / 콜드 기능 컨테이너의 즉각적인 영향을 최소화하려면 트래픽이 적은 기간 동안 항상 기능 배치를 수행해야합니다.
· 롤백 — Lambda는 Lambda 함수 버전 (예 : 생성 시간, 증분 숫자 등)에 대한 세부 정보를 제공합니다. 그러나 애플리케이션 수명주기에서 해당 버전을 어떻게 사용하고 있는지 논리적으로 추적하지는 않습니다. Lambda 함수 코드를 롤백해야하는 경우 프로세스가 이전에 배포 된 함수 버전으로 롤백하는 것이 중요합니다.
로드 테스트
Lambda 함수를 로드 테스트하여 최적의 시간 초과 값을 결정하십시오. 함수 실행 시간을 분석하여 종속성 서비스의 예상 문제점 이상으로 기능의 동시성을 증가시킬 수 있는 문제점을 더 잘 판별 할 수 있도록 하는 것이 중요합니다. 이는 Lambda 함수가 Lambda의 스케일링을 처리하지 못할 수있는 리소스를 네트워크 호출 할 때 특히 중요합니다.
트리거 및 디버깅
조사를 가능하게 하는 로깅과 X-Ray를 사용하여 응용 프로그램을 프로파일링하는 것은 운영 심사에 유용합니다. 또한 통합 테스트, 성능 테스트, 디버깅 등과 같은 운영 활동을 나타내는 Lambda 함수 별칭을 만들어 보십시오. 팀이 운영 목적에 맞는 테스트 스위트 또는 세그먼트화 된 애플리케이션 스택을 구축하는 것이 일반적입니다. 이 운영 아티팩트를 빌드하여 별명을 통해 Lambda 함수와 통합해야합니다. 그러나 별칭은 완전히 별개의 Lambda 함수 컨테이너를 강제하지 않습니다. 따라서 기능 버전 번호 N을 가리키는 PerfTest와 같은 별명은 버전 N을 가리키는 다른 모든 별명과 동일한 기능 컨테이너를 사용합니다. 필요한 경우 별도의 컨테이너가 호출되도록 적절한 버전 관리 및 별명 업데이트 프로세스를 정의해야 합니다.
비용 최적화 모범 사례
Lambda 요금은 기능 실행 시간과 할당 된 리소스를 기준으로하므로 비용 최적화는이 두 가지 차원을 최적화하는 데 중점을 둡니다.
Right-Sizing
성능 효율성에 따라, 기능에 사용 가능한 가장 작은 리소스 크기가 가장 낮은 총 비용을 제공한다고 가정하는 것은 반패턴입니다. 기능의 리소스 크기가 너무 작으면 더 긴 실행 시간으로 인해 기능을 더 빨리 완료할 수 있는 리소스가 더 많은 경우보다 더 많은 비용을 지불할 수 있습니다.
자세한 내용은 최적 메모리 크기 선택 섹션을 참조합니다.
분산 및 비동기 아키텍처
일련의 차단/동기식 API 요청 및 응답을 통해 모든 사용 사례를 구현할 필요는 없습니다. 애플리케이션을 비동기식으로 설계할 수 있는 경우 아키텍처의 각 디커플링된 구성 요소는 동기식 요청에 대한 응답을 기다리는 CPU 주기를 사용하는 긴밀하게 연결된 구성 요소보다 작업을 수행하는 데 더 적은 컴퓨팅 시간이 소요될 수 있습니다. 대부분의 Lambda 이벤트 소스는 분산 시스템에 적합하며, 보다 비용 효율적인 방식으로 모듈식 및 디커플링 기능을 통합하는 데 사용할 수 있습니다.
배치 크기
일부 Lambda 이벤트 소스를 사용하여 각 기능 호출(예: Kinesis 및 DynamoDB)에 대해 제공되는 레코드 수에 대한 배치 크기를 정의할 수 있습니다. 각 이벤트 소스의 폴링 빈도가 기능이 작업을 얼마나 빨리 완료할 수 있는지 조정할 수 있도록 각 배치 크기에 대해 최적의 레코드의 수를 찾기 위해 테스트해야 합니다.
이벤트 소스 선택
Lambda와 통합할 수 있는 다양한 이벤트 소스는 요구 사항을 충족하는 다양한 솔루션 옵션을 제공하는 경우가 많다는 것을 의미합니다.
사용 사례 및 요구 사항(요청 확장, 데이터 볼륨, 대기 시간 필요 등)에 따라 Lamda 기능을 둘러싼 구성 요소로 선택한 AWS 서비스를 기반으로 하는 아키텍처의 총 비용에 차이가 있을 수 있습니다.
서버리스 개발 모범 사례
Lambda로 응용 프로그램을 만들면 이전에는 경험하지 못한 개발 속도를 실현할 수 있습니다. 작동하고 강력한 서버리스 응용 프로그램을 위해 작성해야 하는 코드의 양은 서버 기반 모델을 작성하는 데 필요한 코드 중 적은 비율일 것입니다. 그러나 서버리스 아키텍처를 가능하게 하는 새로운 애플리케이션 제공 모델을 사용하면 개발 프로세스가 결정해야 하는 새로운 차원과 구성이 있습니다.
Lambda 함수를 염두에 두고 코드 기반을 구성하고, 개발자 랩톱에서 프로덕션 서버리스 환경으로 코드 변경 사항을 옮기고, Lambda 런타임 환경 또는 AWS 외부의 이벤트 소스를 시뮬레이션 할 수는 없지만 테스트를 통해 코드 품질을 보장하는 것과 같은 것들. 다음은 서버리스 애플리케이션 소유의 이러한 측면을 통해 작업하는 데 도움이 되는 개발 중심의 모범 사례입니다.
코드 형태의 인프라 — AWS SAM (AWS Serverless Application Model)
인프라를 코드로 표시하면 인프라 생성 및 수정 관리의 감사 가능성, 자동화 가능성 및 반복성 측면에서 많은 이점이 있습니다. 서버리스 애플리케이션을 구축 할 때 인프라를 관리 할 필요는 없지만 IAM 역할, Lambda 기능 및 구성, 이벤트 소스 및 기타 종속성 등 많은 구성 요소가 아키텍처에서 역할을합니다. AWS CloudFormation에서 이러한 모든 것을 나타내려면 기본적으로 많은 양의 JSON 또는 YAML이 필요합니다. 대부분의 서버리스 응용 프로그램에서 다른 서버리스 응용 프로그램으로 거의 동일합니다.
AWS SAM (AWS Serverless Application Model)을 사용하면 서버리스 애플리케이션을 구축 할 때 더 간단한 환경을 경험할 수 있으며 인프라의 이점을 코드로 활용할 수 있습니다. AWS SAM은 AWS CloudFormation 기반의 개방형 사양 추상화 계층입니다. 몇 줄의 JSON 또는 YAML만으로 완전한 서버리스 애플리케이션 스택을 정의하고 Lambda 함수 코드를 해당 인프라 정의와 함께 패키지 한 다음 AWS에 함께 배포 할 수 있는 일련의 명령 줄 유틸리티를 제공합니다. 서버 없는 애플리케이션 환경을 정의하고 변경하려면 AWS SAM을 AWS CloudFormation과 함께 사용하는 것이 좋습니다.
그러나 인프라 / 환경 수준에서 발생하는 변경과 기존 Lambda 함수 내에서 발생하는 응용 프로그램 코드 변경 간에는 차이가 있습니다. Lambda 함수 코드 변경을위한 배포 파이프 라인을 구축하는 데 AWS CloudFormation 및 AWS SAM만이 필요한 툴은 아닙니다. Lambda 함수의 코드 변경 관리에 대한 자세한 내용은이 백서의 CI / CD 섹션을 참조하십시오.
Local Testing — AWS SAM Local
AWS SAM Local과 함께 AWS SAM Local은 서버리스 함수 및 애플리케이션을 AWS에 배포하기 전에 로컬로 테스트하기 위해 AWS SAM에 추가 할 수 있는 추가 명령 줄 도구를 제공합니다. AWS SAM Local은 Docker를 사용하여 인기있는 이벤트 소스 (예 : Amazon S3, DynamoDB 등)를 사용하여 개발 된 Lambda 함수를 빠르게 테스트 할 수 있습니다. SAM 템플릿에서 정의한 API를 API 게이트웨이에서 만들기 전에 로컬에서 테스트 할 수 있습니다. 생성한 AWS SAM 템플릿의 유효성을 검사 할 수도 있습니다. 개발자 워크스테이션 내에 여전히 존재하는 Lambda 함수에 대해 이러한 기능을 실행하면 로컬에서 로그 보기, 디버거에서 코드 단계별 실행 및 AWS에 새 코드 패키지를 배포하지 않고도 변경 사항을 신속하게 반복하는 등의 작업을 수행 할 수 있습니다.
코딩 및 코드 관리 모범 사례
Lambda 함수용 코드를 개발할 때 많은 Lambda 함수를 관리하는 것이 복잡한 작업이되지 않도록 코드를 작성하고 구성하는 방법에 대한 몇 가지 권장 사항이 있습니다.
코딩 모범 사례
빌드 한 Lambda 런타임 언어에 따라 해당 언어에 대해 이미 설정된 모범 사례를 계속 따르십시오. Lambda를 통해 코드 호출 방식을 둘러싼 환경이 변경되었지만 언어 런타임 환경은 다른 곳과 동일합니다. 코딩 표준 및 모범 사례가 여전히 적용됩니다. 다음 권장 사항은 선택한 언어에 대한 일반적인 모범 사례 이외의 Lambda 용 코드 작성에만 해당됩니다.
핸들러 외부의 비즈니스 로직
Lambda 함수는 코드 패키지 내에 정의한 핸들러 함수에서 실행을 시작합니다. 핸들러 함수 내에서 Lambda가 제공 한 매개 변수를 수신하고 해당 매개 변수를 다른 함수로 전달하여 애플리케이션에 컨텍스트 화 된 새 변수 / 객체로 구문 분석 한 다음 핸들러 함수 및 파일 외부에 있는 비즈니스 로직에 도달해야 합니다. 이를 통해 Lambda 런타임 환경에서 가능한 한 분리 된 코드 패키지를 만들 수 있습니다. 이렇게 하면 생성 한 객체 및 기능의 컨텍스트 내에서 코드를 테스트하고 Lambda 외부의 다른 환경에서 작성한 비즈니스 로직을 재사용 할 수 있습니다.
다음 예제 (Java로 작성 됨)는 애플리케이션의 핵심 비즈니스 로직이 Lambda에 밀접하게 결합되어 있는 불량 사례를 보여줍니다. 이 예제에서 비즈니스 로직은 핸들러 메소드 내에 작성되며 Lambda 이벤트 소스 오브젝트에 직접 의존합니다.
Warm Containers — Caching/Keep-Alive/Reuse
앞에서 언급했듯이 웜 함수 컨테이너를 이용하는 코드를 작성해야합니다. 이는 가능한 경우 후속 호출에서 변수 및 해당 내용을 재사용 할 수있는 방식으로 변수 범위를 지정하는 것을 의미합니다. 이는 부트 스트랩 구성, 외부 종속성 연결을 열린 상태로 유지 또는 한 호출에서 다음 호출까지 지속될 수있는 큰 개체의 일회성 초기화와 같은 작업에 특히 영향을줍니다.
컨트롤 의존성
Lambda 실행 환경에는 Node.js 용 AWS SDK 및 Python 런타임과 같은 많은 라이브러리가 포함되어 있습니다. (전체 목록은 Lambda 실행 환경 및 사용 가능한 라이브러리를 참조하십시오.) 최신 기능 및 보안 업데이트 세트를 활성화하려면 Lambda가 주기적으로 이러한 라이브러리를 업데이트합니다.
이 업데이트는 Lambda 함수의 동작에 미묘한 변화를 가져올 수 있습니다. 함수가 사용하는 종속성을 완전히 제어하려면 모든 종속성을 배포 패키지로 패키징하는 것이 좋습니다.
트림 종속성
Lambda 함수 코드 패키지는 압축 시 최대 50MB, 런타임 환경에서 추출 시 250MB까지 허용됩니다. 함수 코드에 큰 종속성 아티팩트를 포함하는 경우 런타임 필수 사항에 포함 된 종속성을 정리해야 할 수도 있습니다. 또한 콜드 스타트를 위해 Lambda 함수 코드를 런타임 환경에서 더 빨리 다운로드하여 설치할 수 있습니다.
Fail Fast
외부 종속성에 대해 상당히 짧은 시간 초과 및 전체 Lambda 함수 시간 초과를 짧게 구성하십시오. 의존성이 응답하기를 기다리는 동안 함수가 무력하게 회전하도록 허용하지 마십시오. Lambda는 함수 실행 기간에 따라 요금이 청구되므로 함수 종속성이 응답하지 않을 때 필요 이상으로 요금이 청구되는 것을 원하지 않습니다.
예외 처리
Lambda의 사용 사례에 따라 예외를 다르게 처리하고 처리하도록 결정할 수 있습니다. Lambda 함수 앞에 API 게이트웨이 API를 배치하는 경우 API 게이트웨이에 예외를 반환하여 해당 컨텐츠를 기반으로 해당 HTTP 상태 코드 및 오류 메시지로 변환 될 수 있습니다. 비동기 데이터 처리 시스템을 구축하는 경우 코드베이스 내의 일부 예외가 재처리를 위해 데드 레터 큐로 이동하는 호출과 동일해야 한다고 결정하는 반면, 다른 오류는 로깅 되어 데드 레터 큐에 놓을 수 없습니다 . 실패 동작 결정이 무엇인지 평가하고 해당 동작을 달성하기 위해 코드 내에서 올바른 유형의 예외를 생성하고 던지는지 확인해야 합니다. 예외 처리에 대한 자세한 내용은 각 언어 런타임 환경에서 예외가 정의되는 방법에 대한 자세한 내용은 다음을 참조하십시오.
· Java
· Node.js
· Python
· C#
코드 관리 모범 사례
Lambda 함수용으로 작성한 코드가 모범 사례를 따르므로 해당 코드를 어떻게 관리해야합니까? Lambda의 개발 속도를 통해 일반적인 프로세스에 익숙하지 않은 속도로 코드 변경을 완료 할 수 있습니다. 서버리스 아키텍처에 필요한 코드의 양이 줄어든다는 것은 Lambda 함수 코드가 전체 애플리케이션 스택 기능을 구성하는 것의 상당 부분을 나타냅니다. 따라서 Lambda 함수 코드의 소스 코드 관리가 우수하면 안전하고 효율적이며 원활한 변경 관리 프로세스를 보장 할 수 있습니다.
코드 리포지토리 조직
선택한 소스 코드 관리 솔루션 내에서 Lambda 함수 소스 코드를 매우 세분화 하도록 구성하는 것이 좋습니다. 이는 일반적으로 Lambda 함수와 코드 리포지토리 또는 리포지토리 프로젝트간에 1 : 1 관계가 있음을 의미합니다. (lexicon은 소스 코드 관리 도구 마다 다릅니다.) 그러나 동일한 논리 함수의 다른 라이프 사이클 단계에 대해 별도의 Lambda 함수를 작성하는 전략을 따르는 경우 (즉, MyLambdaFunction- DEV 및 MyLambdaFunction-PROD라고도하는 별도의 Lambda 함수가 코드 기반을 공유하도록하는 것이 합리적입니다 (아마도 개별 릴리스 브랜치에서 배포).
이러한 방식으로 코드를 구성하는 주요 목적은 특정 Lambda 함수의 코드 패키지에 기여하는 모든 코드가 독립적으로 버전이 지정되고 커밋 되고 자체 종속성 및 해당 종속성 버전을 정의하도록 하는 것입니다. 각 Lambda 함수는 배포 할 때와 마찬가지로 다른 Lambda 함수와 소스 코드 관점에서 완전히 분리되어야 합니다. 애플리케이션 아키텍처를 현대화하는 과정을 거치지 않고 모듈식이고 Lambda와 분리되어 모놀리식으로 단단히 결합된 코드 기반으로 남겨두기만 하면 됩니다.
출시 지점
Lambda 함수 배포를 릴리스 분기의 증분 커밋과 연관시킬 수 있는 리포지토리 또는 프로젝트 분기 전략을 만드는 것이 좋습니다. 리포지토리 내 소스 코드 변경 사항과 라이브 Lambda 함수에 배포 된 변경 사항을 자신 있게 연관시킬 수 있는 방법이 없다면 운영 조사는 항상 현재 코드베이스의 버전을 식별하려고 시도합니다. Lambda 코드 패키지 생성 및 배포 시간을 해당 Lambda 함수의 릴리스 분기에서 발생한 코드 변경 사항과 연관시킬 수 있는 CI / CD 파이프 라인 (나중에 권장 사항)을 작성해야 합니다.
테스트
서버리스 아키텍처 내에서 품질을 보장하는 가장 좋은 방법은 코드를 철저히 테스트하는 데 소요되는 시간입니다. 그러나 서버리스 아키텍처는 익숙한 것보다 적절한 단위 테스트 관행을 시행합니다. 많은 개발자들이 단위 테스트 도구와 프레임 워크를 사용하여 코드의 종속성을 테스트하는 테스트를 작성합니다. 이것은 단위 테스트와 통합 테스트를 결합한 단일 테스트이지만 성능이 좋지 않습니다.
모든 단위 테스트 사례를 단일 논리 함수 내에서 단일 코드 경로까지 범위를 정하여 업스트림의 모든 입력과 다운 스트림의 출력을 조종해야 합니다. 이를 통해 테스트 케이스를 소유한 코드로만 분리 할 수 있습니다. 단위 테스트를 작성할 때 코드와 API, 라이브러리 등의 계약을 기반으로 종속성이 올바르게 작동한다고 가정 할 수 있습니다.
실제 환경을 모방하는 환경에서 코드의 코드 통합을 테스트하는 것도 통합 테스트에서 중요합니다. 개발자 랩톱 또는 빌드 서버가 다운 스트림 종속성과 통합 될 수 있는지 테스트하는 것은 실제 환경에서 코드가 한 번 성공적으로 통합되는지 완전히 테스트하지는 않습니다. 이는 특히 코드 소스에 이벤트 소스가 전달할 이벤트의 소유권이 없고 Lambda 외부에서 Lambda 런타임 환경을 생성 할 수 없는 Lambda 환경에 해당됩니다.
단위 테스트
앞에서 말씀 드린대로 핸들러 함수 외부의 비즈니스 논리에 중점을 두어 Lambda 함수 코드를 철저히 테스트하는 것이 좋습니다. 또한 함수의 이벤트 소스에 대한 샘플 / 모의 객체를 구문 분석하는 기능을 단위 테스트해야 합니다. 그러나 대부분의 논리 및 테스트는 코드 기반 내에서 완벽하게 제어 할 수 있는 조종된 객체 및 함수에서 발생해야 합니다. 핸들러 함수 내에 단위 테스트가 필요한 중요한 것들이 있다고 생각되면 핸들러 함수의 로직을 캡슐화하고 외부화해야한다는 신호 일 수 있습니다. 또한 작성한 단위 테스트를 보완하려면 AWS SAM Local을 사용하여 기능 코드의 로컬 엔드 투 엔드 테스트 역할을 할 수 있는 로컬 테스트 자동화를 만들어야 합니다 (단위 테스트를 대체하지 않음).
통합 테스트
통합 테스트의 경우 CI / CD 파이프 라인이 결과를 트리거하고 검사 할 수 있는 샘플 이벤트를 통해 코드 패키지가 배포되고 호출되는 Lambda 함수의 수명 주기가 낮은 버전을 만드는 것이 좋습니다. 구현은 응용 프로그램 및 아키텍처에 따라 다릅니다.
지속적인 배포
CI / CD 파이프 라인을 통해 모든 서버리스 배포를 프로그래밍 방식으로 관리하는 것이 좋습니다. Lambda를 사용하여 새로운 기능을 개발하고 푸시 코드를 변경하는 속도가 훨씬 더 자주 배포 될 수 있기 때문입니다. 수동 배포는 더 자주 배포해야 할 필요성과 함께 수동 프로세스에 병목 현상이 발생하고 오류가 발생하기 쉽습니다.
AWS CodeCommit, AWS CodePipeline, AWS CodeBuild, AWS SAM 및 AWS CodeStar에서 제공하는 기능은 전체적이고 자동화 된 서버리스 CI / CD 파이프 라인 (파이프 라인 자체에 인프라가 없는 경우)과 기본적으로 결합 할 수 있는 일련의 기능을 제공합니다).
다음은 이러한 각 서비스가 잘 정의 된 지속적인 전달 전략에서 어떤 역할을 수행하는지 보여줍니다.
AWS CodeCommit– 서버리스 소스 코드를 호스팅하고, 권장 사항 (미세한 액세스 제어 포함)을 충족하는 분기 전략을 생성하고 AWS CodePipeline과 통합하여 새로운 커밋이 발생할 때 새로운 파이프 라인 실행을 트리거 할 수 있는 호스팅 된 프라이빗 Git 리포지토리를 제공합니다.
AWS CodePipeline — 파이프 라인의 단계를 정의합니다. 일반적으로 소스 코드 변경이 도착하면 AWS CodePipeline 파이프 라인이 시작됩니다. 그런 다음 빌드 단계를 실행하고 새 빌드에 대해 테스트를 실행하고 실제 환경에 빌드를 배포 및 릴리스합니다. AWS CodePipeline은 이러한 각 단계마다 다른 AWS 서비스와의 기본 통합 옵션을 제공합니다.
AWS CodeBuild — 파이프 라인의 빌드 상태에 사용할 수 있습니다. 이를 사용하여 코드를 작성하고, 단위 테스트를 실행하고, 새로운 Lambda 코드 패키지를 작성하십시오.
그런 다음 AWS SAM과 통합하여 코드 패키지를 Amazon S3로 푸시하고 AWS CloudFormation을 통해 새 패키지를 Lambda로 푸시 하십시오.
AWS CodeBuild를 통해 새 버전을 Lambda 함수에 게시 한 후 배포 중심 Lambda 함수를 생성하여 AWS CodePipeline 파이프 라인에서 후속 단계를 자동화 할 수 있습니다. 통합 테스트 수행, 함수 별명 업데이트, 즉각적인 롤백이 필요한지 여부 결정 및 애플리케이션 배치 중에 발생하는 기타 애플리케이션 중심 단계 (캐시 플러시, 알림 메시지 등)에 대한 로직을 소유합니다. 이러한 배포 중심 Lambda 함수는 Invoke 작업을 사용하여 AWS CodePipeline 파이프 라인 내에서 단계적으로 순차적으로 호출 할 수 있습니다. AWS CodePipeline에서 Lambda 사용에 대한 자세한 내용은 이 설명서를 참조하십시오.
결국 각 응용 프로그램과 조직에는 소스 코드를 리포지토리에서 프로덕션으로 이동하기위한 고유한 요구 사항이 있습니다. 이 프로세스에 더 많은 자동화를 도입할수록 Lambda를 사용하여 더 많은 민첩성을 얻을 수 있습니다.
AWS CodeStar — 처음부터 이러한 모범 사례를 따르는 데 도움이 되는 서버리스 응용 프로그램 (및 다른 유형의 응용 프로그램)을 만들기 위한 통합 된 사용자 인터페이스. AWS CodeStar에서 새 프로젝트를 생성하면 AWS CodeCommit, AWS CodePipeline 및 앞에서 언급 한 AWS CodeBuild 서비스를 사용하여 완전히 구현되고 통합 된 지속적 전달 툴체인으로 자동 시작됩니다. 또한 팀 구성원 관리, 문제 추적, 개발, 배포 및 운영을 포함하여 프로젝트에 대한 SDLC의 모든 측면을 관리 할 수 있는 장소가 있습니다. AWS CodeStar에 대한 자세한 내용은 여기를 참조하십시오.
서버리스 아키텍처 샘플
자체 AWS 계정에서 서버리스 아키텍처와 이를 재작성하기위한 지침이 많이 있습니다. GitHub에서 찾을 수 있습니다.
결론
AWS에서 서버리스 애플리케이션을 구축하면 서버가 도입하는 책임과 제약이 완화됩니다. AWS Lambda를 서버리스 로직 계층으로 사용하면 애플리케이션을 차별화하는 요소에보다 신속하게 구축하고 개발 노력에 집중할 수 있습니다. Lambda와 함께 AWS는 서버리스 기능을 추가로 제공하므로 강력하고 성능이 뛰어나고 이벤트 중심의 안정적이고 안전하며 비용 효율적인 애플리케이션을 구축 할 수 있습니다. 이 백서에 설명 된 기능과 권장 사항을 이해하면 자체 서버리스 응용 프로그램을 구축 할 때 성공할 수 있습니다. 관련 항목에 대한 자세한 내용은 서버리스 컴퓨팅 및 응용 프로그램을 참조하십시오.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
