RESOURCES

잘 설계된 서버리스 응용 프로그램은 일반적으로 사용자 지정 비즈니스 논리로 연결된 관리 서비스로 구성되어 있습니다.  Amazon S3 와 AWS Lambda 또한 엔터프라이즈 애플리케이션 개발을 위한 훌륭한 구성 중 하나입니다. S3는 스토리지 요구 사항에 맞게 확장 가능한 내구성이 뛰어나고 가용성이 높은 객체 스토리지입니다. Lambda는 이벤트에 대한 응답으로 사용자 지정 코드를 실행하여 워크로드 규모에 따라 자동으로 조정됩니다. 두 서비스를 함께 사용하면 서버리스 솔루션을 위한 확장 가능한 코어를 사용 가능합니다.

 

오늘은 블로그 포스팅으론 S3 이벤트를 중심으로 설계된 서버리스 응용 프로그램을 디자인하고 배포하는 방법을 보여드립니다. 해당 솔루션은 AWS 서비스를 사용하여 최소한의 사용자 지정 코드를 사용하여 확장 가능한 서버리스 아키텍처를 만듭니다. 이것은 S3-to-Lambda 패턴이 다음과 같은 비즈니스 솔루션을 구현하는 방법을 보여주는 시리즈의 마지막 편입니다.

 

• S3 이벤트에 대한 응답으로 Amazon Translate 를 사용한 대규모 문서 번역
• S3 버킷에 저장된 객체를 사용하여 DynamoDB테이블로 데이터 가져 오기 자동화
• S3 및 Amazon ML 서비스를 사용하여 검색 가능한 엔터프라이즈 문서 리포지토리 생성
• 확장 가능한 비즈니스 워크 플로우를 자동화, S3와 AWS 스텝 기능 연동
• Amazon Transcribe 와 S3를 사용하여 콜 센터 기록을 분석에 유용한 데이터로 변환

 

 

컴퓨팅 계층을 데이터로 가져오기

대다수의 전통적인 소프트웨어는 데이터를 컴퓨팅 계층으로 가져 와서 작동합니다. 이는 프로세스가 파일, 데이터베이스 및 기타 소스의 데이터 배치에서 실행됨을 의미합니다. 데이터 볼륨이 증가함에 따라 본질적으로 확장하기가 어려우며, 피크 타임에 서버를 확장해야 하는 경우가 생깁니다. 개발자에게는 컴퓨팅 용량을 데이터 볼륨과 맞추기 위해 운영 오버 헤드가 발생합니다.

 

S3-to-Lambda 서버리스 패턴은 대신 컴퓨팅 계층을 데이터로 가져옵니다. 데이터가 도착하면 컴퓨팅 프로세스가 수요에 맞게 자동으로 확장 및 축소됩니다. 이를 통해 개발자는 단일 데이터 항목에 대한 비즈니스 로직을 구축하는 데 집중할 수 있으며 규모에 따른 실행은 Lambda 서비스에 의해 처리됩니다.

 

이미지 최적화 응용 프로그램은 전통적인 접근 방식과 서버리스 접근 방식 비교에 좋은 예시입니다. 방문이 많은 미디어 사이트의 경우 S3 버킷에서 분당 수백 개의 이미지를 캡처하면 작업 오버 헤드가 더 명확해집니다. 서버에서 실행되는 스크립트는 이 수준의 트래픽에 맞추기 위해 여러 인스턴스에서 확장되어야 합니다.  요청 시 확장되는 Lambda 기반 접근 방식과 비교해보십시오. 단일 이미지에 사용되든 수천 개의 이미지에 사용되든 코드 자체는 변경되지 않습니다.

 

 

사용자 정의 코드로 S3에서 이벤트 수신 및 처리

S3는 객체를 버킷에 넣거나 복사하거나 삭제할 때 이벤트를 발생시킵니다. 또한 수명주기 이벤트가 발생할 때와 같은 많은 알림을 발생시킵니다. S3 콘솔, Lambda 콘솔, AWS CLI 또는 AWS SAMS (Serverless Application Model) 템플릿을 사용하여 이러한 이벤트에서 Lambda를 호출하도록 S3을 구성할 수 있습니다.

 

S3는 객체 자체가 아닌 이벤트 세부 정보를 JSON 객체의 Lambda 함수에 전달합니다. 이 객체에는 레코드 배열이 포함되어 있으므로 호출 당 하나 이상의 S3 이벤트를 수신할 수 있습니다.

 

 

Lambda 핸들러는 둘 이상의 레코드를 수신할 수 있으므로 레코드 콜렉션을 반복해야 합니다. 핸들러를 작고 포괄적인 상태로 유지하여 별도의 함수 또는 파일에서 비즈니스 로직을 호출하는 것이 가장 좋습니다.

const processEvent = require(‘my–custom–logic’) // A Node.js Lambda handlerexports.handler = async (event) => {   // Capture event – can be used to create mock events  console.log (JSON.stringify(event, null, 2))     // Handle each incoming S3 object in the event  await Promise.all(    event.Records.map(async (event) => {      try {         // Pass each event to the business logic handler        await processEvent(event)      } catch (err) {        console.error(‘Handler error: ‘, err)      }    })  )} 

이 코드 예제는 Node.js에서 사용 가능한 concurrent asynchoronous executions을 활용하지만 다른 언어로도 유사한 구문을 사용할 수 있습니다. 이는 전체 기능 실행 시간을 최소화하기 위해 여러 객체가 병렬로 처리됨을 의미합니다.

 

함수 코드 내에서 오류를 처리하고 기록하는 대신 destinations for asynchoronous invocations 을 사용할 수도 있습니다. On failure조건을 사용하여 다른 Lambda 함수 또는 다른 AWS 서비스를 포함하여 다양한 잠재적 대상으로 오류를 라우팅합니다. 복잡한 애플리케이션이나 대용량을 처리하는 애플리케이션의 경우 처리에 실패한 이벤트를 보다 효과적으로 제어할 수 있습니다.

 

개발 프로세스 동안 S3-to-Lambda 연동을 로컬로 디버그하고 테스트할 수 있습니다. 먼저 개발 동안 샘플 이벤트를 캡처하여 로컬 테스트를 위한 모의 이벤트를 만듭니다. 이 시리즈의 샘플 애플리케이션은 각각 테스트 하네스를 사용하므로 개발자는 로컬 시스템에서 핸들러를 테스트할 수 있습니다. 테스트 하네스는 핸들러를 로컬로 호출하여 모의 환경 변수를 제공합니다.

 

// Mock eventconst event = require(‘./localTestEvent’) // Mock environment variablesprocess.env.AWS_REGION = ‘us-east-1’process.env.localTest = trueprocess.env.language = ‘en’ // Lambda handlerconst { handler } = require(‘./app’) const main = async () => {  console.time(‘localTest’)  await handler(event)  console.timeEnd(‘localTest’)} main().catch(error => console.error(error))  

 

더 많은 데이터에 맞게 확장

S3가 여러 이벤트를 동시에 보내면 Lambda 서비스가 확장됩니다. 이것이 작동하는 방법은 여러 가지 요인에 따라 다릅니다. 대상 Lambda 함수에 사용 가능한 동시성이 충분하고 함수의 활성 인스턴스가 이미 이벤트를 처리 중인 경우 Lambda 서비스가 확장됩니다.

 

예약된 동시성 이 1로 설정되어 있거나 계정의 리전에 대한 확장 용량이 완전히 소비된 경우 이 기능이 확장되지 않습니다. 이 경우 S3의 이벤트는 Lambda 인스턴스를 처리 할 수 있을 때까지 내부적으로 대기합니다. 지원 센터 콘솔에서 요청을 제출하여 지역 동시성 한계를 늘리도록 요청할 수 있습니다. 예약된 동시성을 1로 설정하여 한 번에 하나씩 처리를 수행할 수도 있습니다.

일반적으로 S3가 여러 객체를 수신하면 이벤트를 가능한 빨리 처리하기 위해 함수의 여러 인스턴스가 동시에 호출됩니다. S3와 Lambda에서 이 빠른 확장 및 병렬화는 이 패턴을 많은 애플리케이션에 대한 강력한 핵심 아키텍처로 만듭니다.

 

 

Amazon SNS 및 Amazon SQS 연동

기본 S3 와 Lambda 연동은 접두사 당 하나의 함수 또는 버킷 당 접미사 패턴을 호출하는 안정적인 방법을 제공합니다. 예를 들어, 단일 버킷에서 객체 키가 .pdf 로 끝나는 경우 함수를 호출합니다. 이는 대부분 사용사례에서 잘 작동하지만 S3 이벤트당 여러 Lambda 함수 호출이 필요할 때도 있습니다.

 

이 경우 S3는 이벤트를 다양한 대상에 전달하는 SNS에 알림을 게시할 수 있습니다. 여기에는 Lambda 함수, SQS 대기열, HTTP 끝점, 전자 메일, 문자 메시지 및 푸시 알림이 포함됩니다. SNS는 팬 아웃 기능을 제공하여 하나의 이벤트를 Lambda 기능 또는 웹 후크와 같은 여러 대상으로 전달할 수 있습니다.

 

사용량이 많은 응용 프로그램에서 서버가 없는 서비스와 같은 다운 스트림 시스템에는 S3 이벤트의 볼륨이 너무 클 수 있습니다. 이 경우 SQS 대기열을 알림 대상으로 사용할 수도 있습니다. 이벤트가 큐에 게시된 후 Lambda 함수 및 기타 서비스에서 사용할 수 있습니다. 큐는 버퍼 역할을 하며 이러한 이벤트를 소비하는 시스템의 트래픽을 부드럽게 처리할 수 ​​있습니다. 예제는 DynamoDB 임포터 리포지터리를 참조하세요.

 

 

업스트림 애플리케이션에서 S3에 데이터 업로드

S3에 저장된 데이터를 생성하는 업스트림 서비스가 아키텍처에 있을 수 있습니다. 일부 업스트림 워크로드에는 웹 또는 모바일 애플리케이션과 같이 급격한 사용 패턴과 많은 사용자가 있습니다. S3에 직접 업로드하여 이러한 워크로드의 성능 및 처리량을 증가시킬 수 있습니다. 이는 API Gateway 엔드 포인트 또는 웹 서버를 통한 이진 데이터 프록시를 방지합니다.

예를 들어, 사용자 사진을 업로드하는 모바일 애플리케이션의 경우 S3 및 Lambda는 많은 수의 사용자에 대한 업로드 프로세스를 처리할 수 ​​있습니다.

 

 

1. 업스트림 프로세스 (이 경우 모바일 클라이언트)는 API Gateway 엔드 포인트에서 사전 서명된 URL을 요청합니다.
2. S3 버킷에 대해 미리 서명 된 URL 을 요청하는 Lambda 함수를 호출하고 API 호출을 통해 이를 다시 반환합니다.
3. 모바일 클라이언트는 HTTPS POST를 사용하여 미리 서명된 S3 URL로 데이터를 직접 보냅니다. 업로드는 S3에서 직접 관리합니다.

 

이 간단한 패턴은 확장 가능하고 비용 효율적인 방법으로 큰 이진 데이터를 응용 프로그램에 업로드할 수 있습니다. 오브젝트가 성공적으로 업로드 된 후 S3 put 이벤트는 다운 스트림 워크 플로우를 비동기적으로 호출할 수 있습니다.

서버리스 S3 업 로더 애플리케이션의 예제를 보려면 이 리포지터리를 방문하세요. 이 YouTube 비디오에서 이 프로세스의 연습을 볼 수도 있습니다.

 

 

더 큰 응용 프로그램 개발

더 큰 서버리스 응용 프로그램을 개발할 때 별도의 팀을 위해 여러 서비스와 리포지토리로 응용 프로그램을 분할하는 것이 종종 실용화됩니다. 종종 개별 서비스는 기존 S3 버킷과 통합되어야하며 애플리케이션 템플릿에서 생성하지 않아야 합니다. 단일 서비스를 여러 S3 버킷과 통합해야 할 수도 있습니다.

 

Amazon EventBridge를 사용하여 더 큰 애플리케이션을 분리할 때 이벤트 버스를 사용하여 애플리케이션 내에서 서비스를 분리하는 방법을 보여줍니다. 이 패턴은 워크로드에서 이벤트 생산자와 소비자를 분리하는 데 도움이 됩니다. 이를 통해 각 서비스가 전체 애플리케이션의 변화에 보다 독립적이고 탄력적으로 변할 수 있습니다.

 

이 예제는 문서 리포지터리 솔루션 이 이벤트를 사용하여 통신하는 여러 개의 작은 애플리케이션으로 리팩터링되는 방법을 보여줍니다. 흐름을 조정하는 이벤트 라우터로 Amazon EventBridge 를 사용합니다. 각 응용 프로그램에는 이벤트를 필터링하기 위해 EventBridge 규칙을 정의하고 처리가 완료된 후 데이터를 다시 이벤트 버스에 게시하는 SAM 템플릿이 있습니다.

 

이벤트 기반 아키텍처를 사용하면 얻을 수 있는 주요 이점 중 하나는 개발팀이 애플리케이션이 커져도 유연성을 유지한다는 것입니다. 개발자는 S3 버킷 및 DynamoDB 테이블과 같은 AWS 리소스를 Lambda 함수와 같은 컴퓨팅 리소스와 분리할 수 ​​있습니다. 이 디커플링은 배포 프로세스를 단순화하고 모놀리스 구축을 방지하며 대규모 응용 프로그램 개발 인지 부하를 줄일 수 있습니다.

 

 

결론

S3와 Lambda는 확장성이 뛰어난 두 개의 AWS 서비스로서 서버리스 애플리케이션과 결합할 때 강력해집니다. 이 게시물에서는 이 시리즈에서 보여드린 많은 패턴을 요약해드렸습니다. 통합 패턴과 스케일링 동작 및 로컬 테스트 및 개발에 모의 이벤트를 사용하는 방법에 대해 설명합니다. 일부 응용 프로그램에서 SNS 및 SQS를 사용하여 이벤트 팬 아웃 및 버퍼링을 수행할 수도 있습니다.

 

업스트림 애플리케이션은 데이터를 S3에 직접 업로드하여 프록시를 피함으로써 더 큰 확장성을 달성 할 수 있습니다. 더 큰 응용 프로그램의 경우 EventBridge를 중심으로 모델링 된 이벤트 기반 아키텍처를 사용하여 응용 프로그램 서비스를 분리하는 방법을 보여줍니다. 이를 통해 서비스 독립성을 촉진하고 응용 프로그램이 증가함에 따라 유연성을 유지할 수 있습니다.

 

S3에서 Lambda 아키텍처 패턴에 대해 자세히 알아보려면 YouTube 비디오 시리즈를 확인하시거나 이 게시물의 맨 위에 나열된 기사를 참고하세요.

 

 

 

 

원문URL : https://aws.amazon.com/ko/blogs/compute/building-scalable-serverless-applications-with-amazon-s3-and-aws-lambda/

** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.