

 이 백서는 기록 참조용입니다. 일부 콘텐츠는 오래되어 일부 링크를 사용하지 못할 수 있습니다.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 샘플 아키텍처 패턴
<a name="sample-architecture-patterns"></a>

 API Gateway 및를 로직 계층 AWS Lambda 으로 사용하여 널리 사용되는 아키텍처 패턴을 구현할 수 있습니다. 이 백서에는 AWS Lambda기반 로직 티어를 활용하는 가장 인기 있는 아키텍처 패턴이 포함되어 있습니다.
+  **모바일 백엔드 -** 모바일 애플리케이션은 API Gateway 및 Lambda와 통신하여 애플리케이션 데이터에 액세스합니다. 이 패턴은 서버리스 AWS 리소스를 사용하지 않는 일반 HTTPS 클라이언트로 확장하여 프레젠테이션 계층 리소스(예: 데스크톱 클라이언트, EC2에서 실행되는 웹 서버 등)를 호스팅할 수 있습니다.
+  **단일 페이지 애플리케이션 **- Amazon S3 및 CloudFront에서 호스팅되는 단일 페이지 애플리케이션은 API Gateway 및와 통신 AWS Lambda 하여 애플리케이션 데이터에 액세스합니다.
+  **웹 애플리케이션 ** - 웹 애플리케이션은 비즈니스 로직을 위해 API Gateway와 AWS Lambda 함께를 사용하는 범용 이벤트 기반 웹 애플리케이션 백엔드입니다. 또한 DynamoDB를 데이터베이스로 사용하고 Amazon Cognito를 사용자 관리에 사용합니다. 모든 정적 콘텐츠는 Amplify를 사용하여 호스팅됩니다.

 이 백서에서는 이러한 두 패턴 외에도 Lambda 및 API Gateway를 일반 마이크로서비스 아키텍처에 적용하는 방법에 대해 설명합니다. 마이크로서비스 아키텍처는 널리 사용되는 패턴으로, 표준 3계층 아키텍처는 아니지만 애플리케이션 구성 요소를 분리하여 서로 통신하는 상태 비저장 개별 기능 단위로 배포해야 합니다.

# 모바일 백엔드
<a name="mobile-backend"></a>

![\[서버리스 모바일 백엔드의 아키텍처 패턴\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)


* 서버리스 모바일 백엔드의 아키텍처 패턴 *

* 표 1 - 모바일 백엔드 계층 구성 요소 *


|  티어  |  Components  | 
| --- | --- | 
|  프레젠테이션  |  사용자 디바이스에서 실행되는 모바일 애플리케이션입니다. | 
|  로직  |   를 사용하는 Amazon API Gateway AWS Lambda.  이 아키텍처는 세 가지 노출된 서비스(`/tickets`, `/shows`및 `/info`)를 보여줍니다. API Gateway 엔드포인트는 [Amazon Cognito 사용자 풀](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)에 의해 보호됩니다.이 방법을 사용하면 사용자는 Amazon Cognito 사용자 풀에 로그인하고(필요한 경우 페더레이션 타사 사용) API Gateway 호출을 승인하는 데 사용되는 액세스 및 ID 토큰을 수신합니다.  각 Lambda 함수에는 적절한 데이터 소스에 대한 액세스를 제공하기 위해 자체 Identity and Access Management(IAM) 역할이 할당됩니다.  | 
|  데이터  |   DynamoDB는 `/tickets` 및 `/shows` 서비스에 사용됩니다.  Amazon RDS는 `/info` 서비스에 사용됩니다. 이 Lambda 함수는 AWS Secrets Manager에서 Amazon RDS 자격 증명을 검색하고 탄력적 네트워크 인터페이스를 사용하여 프라이빗 서브넷에 액세스합니다.  | 

# 단일 페이지 애플리케이션
<a name="single-page-application"></a>

![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)


* 서버리스 단일 페이지 애플리케이션을 위한 아키텍처 패턴 *

* 표 2 - 단일 페이지 애플리케이션 구성 요소 *


|  티어  |  Components  | 
| --- | --- | 
|  프레젠테이션  |   CloudFront에서 배포한 Amazon S3에서 호스팅되는 정적 웹 사이트 콘텐츠입니다.  AWS Certificate Manager를 사용하면 사용자 지정 SSL/TLS 인증서를 사용할 수 있습니다.  | 
|  로직  |   를 사용하는 API Gateway AWS Lambda.  이 아키텍처는 세 가지 노출된 서비스(`/tickets`, `/shows`및 `/info`)를 보여줍니다. API Gateway 엔드포인트는 Lambda 권한 부여자에 의해 보호됩니다. 이 방법에서 사용자는 타사 자격 증명 공급자를 통해 로그인하고 액세스 및 ID 토큰을 얻습니다. 이러한 토큰은 API Gateway 호출에 포함되며 Lambda 권한 부여자는 이러한 토큰을 검증하고 API 시작 권한이 포함된 IAM 정책을 생성합니다.  각 Lambda 함수에는 적절한 데이터 소스에 대한 액세스를 제공하기 위한 자체 IAM 역할이 할당됩니다.  | 
|  데이터  |   Amazon DynamoDB는 `/tickets` 및 `/shows` 서비스에 사용됩니다.  Amazon ElastiCache는 `/shows` 서비스에서 데이터베이스 성능을 개선하는 데 사용됩니다. 캐시 누락은 DynamoDB로 전송됩니다.  Amazon S3는에서 사용하는 정적 콘텐츠를 호스팅하는 데 사용됩니다`/info service`.  | 

# 웹 애플리케이션
<a name="web-application"></a>

![\[AWS 클라우드 architecture diagram showing client interaction with various AWS 서비스.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)


* 웹 애플리케이션의 아키텍처 패턴 *

* 표 3 - 웹 애플리케이션 구성 요소 *


|  티어  |  Components  | 
| --- | --- | 
|  프레젠테이션  |   프런트 엔드 애플리케이션은 모두 create-react-app과 같은 React 유틸리티에서 생성되는 정적 콘텐츠(HTML, CSS, JavaScript 및 이미지)입니다. Amazon CloudFront는 이러한 모든 객체를 호스팅합니다. 웹 애플리케이션을 사용하면 모든 리소스가 브라우저에 다운로드되고 여기에서 실행되기 시작합니다. 웹 애플리케이션은 APIs를 호출하는 백엔드에 연결됩니다.  | 
|  로직  |   로직 계층은 API Gateway REST APIs.  이 아키텍처는 여러 노출된 서비스를 보여줍니다. 애플리케이션의 다양한 측면을 처리하는 Lambda 함수는 여러 개 있습니다. Lambda 함수는 API Gateway 뒤에 있으며 API URL 경로를 사용하여 액세스할 수 있습니다. 사용자 인증은 Amazon Cognito 사용자 풀 또는 페더레이션 사용자 공급자를 사용하여 처리됩니다. API Gateway는 Amazon Cognito와의 즉시 통합을 사용합니다. 사용자가 인증된 후에만 클라이언트는 API 호출 시 사용해야 하는 JSON 웹 토큰(JWT) 토큰을 받습니다. 각 Lambda 함수에는 적절한 데이터 소스에 대한 액세스를 제공하기 위한 자체 IAM 역할이 할당됩니다.  | 
|  데이터  |   이 특정 예제에서는 DynamoDB가 데이터 스토리지에 사용되지만 사용 사례 및 사용 시나리오에 따라 다른 목적별 Amazon 데이터베이스 또는 스토리지 서비스를 사용할 수 있습니다.  | 

# Lambda를 사용하는 마이크로서비스
<a name="microservices-with-lambda"></a>

![\[AWS 클라우드 architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)


* Lambda를 사용하는 마이크로서비스의 아키텍처 패턴 *

 마이크로서비스 아키텍처 패턴은 일반적인 3계층 아키텍처에 바인딩되지 않지만,이 인기 패턴은 서버리스 리소스 사용으로 상당한 이점을 실현할 수 있습니다.

 이 아키텍처에서는 각 애플리케이션 구성 요소가 분리되고 독립적으로 배포 및 운영됩니다. Amazon API Gateway로 생성된 API와 이후에에서 시작된 함수 AWS Lambda만 있으면 마이크로서비스를 빌드할 수 있습니다. 팀은 이러한 서비스를 사용하여 환경을 원하는 수준으로 분리하고 세분화할 수 있습니다.

 일반적으로 마이크로서비스 환경에서는 각 새 마이크로서비스를 생성하기 위한 반복적인 오버헤드, 서버 밀도 및 사용률 최적화 문제, 여러 마이크로서비스의 여러 버전을 동시에 실행하는 복잡성, 여러 개별 서비스와 통합하기 위한 클라이언트 측 코드 요구 사항의 확산과 같은 문제가 발생할 수 있습니다.

 서버리스 리소스를 사용하여 마이크로서비스를 생성하면 이러한 문제를 해결하기가 어려워지고 경우에 따라 단순히 사라집니다. 서버리스 마이크로서비스 패턴은 각 후속 마이크로서비스의 생성에 대한 장벽을 낮춥니다(API Gateway는 기존 APIs를 복제하고 다른 계정에서 Lambda 함수를 사용할 수도 있음). 서버 사용률 최적화는 더 이상이 패턴과 관련이 없습니다. 마지막으로 Amazon API Gateway는 많은 인기 언어로 프로그래밍 방식으로 생성된 클라이언트 SDKs를 제공하여 통합 오버헤드를 줄입니다.