기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
AWS AppSync에서 데이터 소스 연결데이터 원본은 GraphQL API가 상호작용할 수 있는 AWS 계정의 리소스입니다. AWS AppSync는 AWS Lambda, Amazon DynamoDB, 관계형 데이터베이스(Amazon Aurora Serverless), Amazon OpenSearch Service, HTTP 엔드포인트와 같은 다양한 데이터 원본을 지원합니다. AWS AppSync API는 단일 위치에서 데이터를 집계할 수 있도록 여러 데이터 원본과 상호 작용하도록 구성할 수 있습니다. AWS AppSync는 사용자 계정의 기존 AWS 리소스를 사용하거나 스키마 정의에서 사용자를 대신하여 DynamoDB 테이블을 프로비저닝할 수 있습니다.
다음 섹션에서는 GraphQL API에 데이터 원본을 연결하는 방법을 알아봅니다.
데이터 원본 유형
AWS AppSync 콘솔에서 스키마를 생성했으므로 이제 여기에 데이터 원본을 연결할 수 있습니다. API를 처음으로 만들 때 사전 정의된 스키마를 생성하는 동안 Amazon DynamoDB 테이블을 프로비저닝하는 옵션이 있습니다. 그러나 이 섹션에서는 이 옵션에 대해 다루지 않습니다. 이에 대한 예는 스키마 시작 섹션에서 확인할 수 있습니다.
대신 AWS AppSync가 지원하는 모든 데이터 원본을 살펴보겠습니다. 애플리케이션에 적합한 솔루션을 선택할 때는 여러 가지 요소를 고려하게 됩니다. 아래 섹션에서는 각 데이터 원본에 대한 몇 가지 추가 컨텍스트를 제공합니다. 데이터 원본에 대한 일반 정보는 데이터 원본을 참조하세요.
Amazon DynamoDB
Amazon DynamoDB는 확장 가능한 애플리케이션을 위한 AWS의 주요 스토리지 솔루션 중 하나입니다. DynamoDB의 핵심 구성 요소는 단순한 데이터 모음인 테이블입니다. 일반적으로 Book 또는 Author 등의 엔터티를 기반으로 테이블을 만들게 됩니다. 테이블 엔트리 정보는 각 엔트리에 고유한 필드 그룹인 항목으로 저장됩니다. 전체 항목은 데이터베이스의 행 및 레코드를 나타냅니다. 예를 들어, Book 엔트리의 항목에는 해당 값과 함께 title 및 author이(가) 포함될 수 있습니다. title 및 author 등의 개별 필드를 특성이라고 하며, 이는 관계형 데이터베이스의 열 값과 유사합니다.
짐작할 수 있듯이 테이블은 애플리케이션의 데이터를 저장하는 데 사용됩니다. AWS AppSync를 사용하면 DynamoDB 테이블을 GraphQL API에 연결하여 데이터를 조작할 수 있습니다. 프런트엔드 웹 및 모바일 블로그에서 이 사용 사례를 확인하세요. 이 애플리케이션을 통해 사용자는 소셜 미디어 앱에 가입할 수 있습니다. 사용자는 그룹에 가입하고 그룹에 가입한 다른 사용자에게 브로드캐스트되는 게시물을 업로드할 수 있습니다. 해당 애플리케이션은 사용자, 게시물 및 사용자 그룹 정보를 DynamoDB에 저장합니다. GraphQL API(AWS AppSync에서 관리)는 DynamoDB 테이블과 상호 작용합니다. 사용자가 시스템에서 변경하는 내용이 프런트엔드에 반영되면 GraphQL API는 이러한 변경 사항을 검색하여 다른 사용자에게 실시간으로 브로드캐스트합니다.
AWS Lambda
Lambda는 이벤트에 대한 응답으로 코드를 실행하는 데 필요한 리소스를 자동으로 빌드하는 이벤트 기반 서비스입니다. Lambda는 리소스를 실행하기 위한 코드, 종속성 및 구성을 포함하는 그룹 문인 함수를 사용합니다. 함수는 함수를 간접적으로 호출하는 활동 그룹인 트리거를 감지하면 자동으로 실행됩니다. 트리거는 API 직접 호출을 수행하는 애플리케이션, 리소스를 스핀업하는 계정 내 AWS 서비스 등이 될 수 있습니다. 함수가 트리거되면 수정할 데이터가 포함된 JSON 문서인 이벤트를 처리합니다.
Lambda는 코드를 실행하는 데 적합하며, 실행을 위해 리소스를 프로비저닝할 필요가 없습니다. 프런트엔드 웹 및 모바일 블로그에서 이 사용 사례를 확인하세요. 이 사용 사례는 DynamoDB 섹션에 소개된 사용 사례와 약간 비슷합니다. 이 애플리케이션에서 GraphQL API는 게시물 추가(변형) 및 해당 데이터 가져오기(쿼리)와 같은 작업을 정의하는 역할을 합니다. 작업의 기능(예: getPost ( id: String ! ) : Post, getPostsByAuthor ( author: String ! ) : [ Post ])을 구현하기 위해 Lambda 함수를 사용하여 인바운드 요청을 처리합니다. 옵션 2: Lambda 해석기로 AWS AppSync에서는 AWS AppSync 서비스를 사용하여 스키마를 유지 관리하고 Lambda 데이터 원본을 작업 중 하나에 연결합니다. 작업이 호출되면 Lambda는 Amazon RDS 프록시와 상호 작용하여 데이터베이스에서 비즈니스 로직을 수행합니다.
Amazon RDS
Amazon RDS를 사용하면 관계형 데이터베이스를 빠르게 빌드하고 구성할 수 있습니다. Amazon RDS에서는 클라우드의 격리된 데이터베이스 환경으로 사용할 일반 데이터베이스 인스턴스를 만들게 됩니다. 이 인스턴스에서는 실제 RDBMS 소프트웨어(PostgreSQL, MySQL 등)인 DB 엔진을 사용합니다. 이 서비스는 AWS 인프라를 이용한 확장성, 패칭 및 암호화와 같은 보안 서비스, 낮은 배포 관리 비용을 제공함으로써 백엔드 작업을 상당히 줄여줍니다.
Lambda 섹션에서 동일한 사용 사례를 확인하세요. 옵션 3: Amazon RDS 해석기로 AWS AppSync에서는 AWS AppSync의 GraphQL API를 Amazon RDS에 직접 연결하는 옵션도 제시되어 있습니다. 이 서비스는 데이터 API를 사용하여 데이터베이스를 GraphQL API와 연결합니다. 해석기는 필드(일반적으로 쿼리, 변형 또는 구독)에 연결되며 데이터베이스에 액세스하는 데 필요한 SQL 문을 구현합니다. 클라이언트가 필드를 호출하는 요청을 보내면 해석기는 문을 실행하고 응답을 반환합니다.
Amazon EventBridge
EventBridge에서는 연결한 서비스 또는 애플리케이션(이벤트 소스)으로부터 이벤트를 수신하고 정해진 규칙에 따라 이벤트를 처리하는 파이프라인인 이벤트 버스를 만들게 됩니다. 이벤트는 실행 환경의 상태가 일부 변하는 것을 의미하고, 규칙은 이벤트에 대한 필터 집합입니다. 규칙은 이벤트 패턴 또는 이벤트 상태 변화의 메타데이터(ID, 리전, 계정 번호, ARN 등)를 따릅니다. 이벤트가 이벤트 패턴과 매칭되면 EventBridge는 파이프라인을 통해 대상 서비스(대상)로 이벤트를 보내고 규칙에 지정된 작업을 트리거합니다.
EventBridge는 상태가 변경되는 작업을 일부 다른 서비스로 라우팅하는 데 적합합니다. 프런트엔드 웹 및 모바일 블로그에서 이 사용 사례를 확인하세요. 이 예시는 여러 팀이 서로 다른 서비스를 유지 관리하는 전자 상거래 솔루션을 보여줍니다. 이러한 서비스 중 하나는 프런트엔드에서 배송의 단계(주문 생성, 진행 중, 발송됨, 배송됨 등)마다 고객에게 주문 업데이트를 제공합니다. 그러나 별도의 백엔드 팀에서 주문 시스템 데이터를 유지 관리하기 때문에 이 서비스를 관리하는 프런트엔드 팀은 주문 시스템 데이터에 직접 액세스할 수 없습니다. 백엔드 팀의 주문 시스템은 블랙박스라고도 불릴 정도로 데이터를 구조화하는 방식에 대한 정보를 얻기가 어렵습니다. 하지만 백엔드 팀은 EventBridge에서 관리하는 이벤트 버스를 통해 주문 데이터를 게시하는 시스템을 구축했습니다. 이벤트 버스에서 오는 데이터에 액세스하고 이를 프런트엔드로 라우팅하기 위해 프런트엔드 팀은 AWS AppSync에 있는 GraphQL API를 가리키는 새로운 대상을 만들었습니다. 또한 주문 업데이트와 관련된 데이터만 전송하는 규칙도 만들었습니다. 업데이트가 이루어지면 이벤트 버스의 데이터가 GraphQL API로 전송됩니다. API의 스키마는 데이터를 처리한 후 이를 프런트엔드로 전달합니다.
데이터 원본 없음
데이터 원본을 사용할 계획이 없다면 none으로 설정할 수 있습니다. 명시적으로는 여전히 데이터 소스로 분류되지만 none 데이터 원본은 저장 매체가 아닙니다. 일반적으로 해석기는 요청을 처리하기 위해 특정 시점에 하나 이상의 데이터 원본을 간접적으로 호출합니다. 그러나 데이터 원본을 조작할 필요가 없는 경우도 있습니다. 데이터 원본을 none(으)로 설정하면 요청이 실행되고 데이터 간접 호출 단계를 건너뛴 다음 응답이 실행됩니다.
EventBridge 섹션에서 동일한 사용 사례를 확인하세요. 스키마에서 변형은 상태 업데이트를 처리한 다음 구독자에게 전송합니다. 해석기의 작동 방식을 생각해보면, 보통 한 번 이상의 데이터 원본 간접 호출이 있습니다. 그러나 이 시나리오의 데이터는 이미 이벤트 버스에 의해 자동으로 전송되었습니다. 즉, 변형이 데이터 원본 간접 호출을 수행할 필요가 없으며, 주문 상태를 로컬에서 간단히 처리할 수 있습니다. 변형은 none(으)로 설정되며, 이 경우 데이터 원본 간접 호출 없이 패스스루 값으로 작동합니다. 그러면 데이터가 스키마에 채워지고 구독자에게 전송됩니다.
OpenSearch
Amazon OpenSearch Service는 전체 텍스트 검색, 데이터 시각화 및 로깅을 구현하는 도구 모음입니다. 이 서비스를 사용하여 업로드한 구조화된 데이터를 쿼리할 수 있습니다.
이 서비스에서는 OpenSearch의 인스턴스를 만들게 됩니다. 이를 노드라고 합니다. 노드에서는 인덱스를 하나 이상 추가하게 됩니다. 인덱스는 개념적으로 관계형 데이터베이스의 테이블과 조금 비슷합니다. (하지만 OpenSearch는 ACID를 준수하지 않으므로 그와 같은 방식으로 사용해서는 안 됩니다.) OpenSearch 서비스에 업로드하는 데이터로 인덱스를 채우게 됩니다. 데이터가 업로드되면 인덱스 내에 있는 하나 이상의 샤드에 데이터를 인덱싱합니다. 샤드는 일부 데이터를 포함하는 인덱스의 파티션과 같으며 다른 샤드와 별도로 쿼리할 수 있습니다. 업로드가 완료되면 데이터는 문서라는 JSON 파일로 구조화됩니다. 그러면 노드에 문서의 데이터를 쿼리할 수 있습니다.
HTTP 엔드포인트
HTTP 엔드포인트를 데이터 소스로 사용할 수 있습니다. AWS AppSync는 파라미터 및 페이로드와 같은 관련 정보와 함께 엔드포인트에 요청을 보낼 수 있습니다. HTTP 응답은 해석기에 노출되며, 해석기는 작업이 완료된 후 최종 응답을 반환합니다.
데이터 원본 추가
데이터 원본을 만들었다면 AWS AppSync 서비스, 특히 API에 연결할 수 있습니다.
- Console
-
-
AWS Management Console에 로그인한 다음 AppSync 콘솔을 엽니다.
-
대시보드에서 API를 선택합니다.
-
사이드바에서 데이터 원본을 선택합니다.
-
데이터 원본 생성을 선택합니다.
-
데이터 원본의 이름을 지정합니다. 원하는 경우 설명을 입력할 수도 있습니다.
-
데이터 원본 유형을 선택합니다.
-
DynamoDB의 경우 리전을 선택한 다음 리전의 테이블을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 테이블과의 상호 작용 규칙을 지정할 수 있습니다. 버전 관리를 사용하도록 설정하여 여러 클라이언트가 동시에 데이터를 업데이트하려고 할 때 각 요청에 대한 데이터 버전을 자동으로 생성할 수 있습니다. 버전 관리는 충돌 감지 및 해결 목적으로 다양한 데이터 변형을 유지 및 관리하는 데 사용됩니다. 또한 데이터 원본을 가져오고 스키마에서 여기에 액세스하는 데 필요한 CRUD, List, Query 작업의 일부를 생성하는 자동 스키마 생성을 활성화할 수도 있습니다.
OpenSearch의 경우 리전을 선택한 다음 리전의 도메인(클러스터) 을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 도메인과의 상호 작용 규칙을 지정할 수 있습니다.
Lambda의 경우 리전을 선택한 다음 리전에서 Lambda 함수의 ARN을 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 Lambda 함수와의 상호 작용 규칙을 지정할 수 있습니다.
HTTP의 경우 HTTP 엔드포인트를 입력해야 합니다.
EventBridge의 경우 리전을 선택한 다음 리전에서 이벤트 버스를 선택해야 합니다. 새로운 일반 테이블 역할을 만들거나 테이블의 기존 역할을 가져와서 이벤트 버스와의 상호 작용 규칙을 지정할 수 있습니다.
RDS의 경우 리전을 선택한 다음 암호 저장소(사용자 이름 및 암호), 데이터베이스 이름, 스키마를 선택해야 합니다.
없음의 경우 실제 데이터 원본이 없는 데이터 원본을 추가하게 됩니다. 이는 실제 데이터 원본을 통하지 않고 로컬에서 해석기를 처리하기 위함입니다.
기존 역할을 가져오는 경우 신뢰 정책이 필요합니다. 자세한 내용은 IAM 신뢰 정책을 참조하세요.
-
생성(Create)을 선택합니다.
또는 DynamoDB 데이터 원본을 생성하는 경우 콘솔의 스키마 페이지로 이동하여 페이지 상단에서 리소스 생성을 선택한 다음 사전 정의된 모델을 채워 테이블로 변환할 수 있습니다. 이 옵션에서는 기본 유형을 채우거나 가져오고, 파티션 키를 포함한 기본 테이블 데이터를 구성하고, 스키마 변경 사항을 검토합니다.
- CLI
-
-
create-data-source 명령을 실행하여 데이터 원본을 생성합니다.
이 특정 명령에 대해 몇 가지 파라미터를 입력해야 합니다.
-
API의 api-id.
-
테이블의 name.
-
데이터 원본의 type. 선택한 데이터 원본 유형에 따라 service-role-arn 및 -config 태그를 입력해야 할 수 있습니다.
예를 들어 명령은 다음과 같을 수 있습니다.
aws appsync create-data-source --api-id abcdefghijklmnopqrstuvwxyz --name data_source_name --type data_source_type --service-role-arn arn:aws:iam::107289374856:role/role_name --[data_source_type]-config {params}
- CDK
-
CDK를 사용하기 전에 CDK의 공식 설명서와 함께 AWS AppSync의 CDK 참조를 검토하는 것이 좋습니다.
아래 나열된 단계는 특정 리소스를 추가하는 데 사용되는 스니펫의 일반적인 예시만 보여줍니다. 프로덕션 코드에서는 이 예시가 올바르게 작동하는 솔루션이 아닙니다. 또한 이미 작동하는 앱을 가지고 있는 것으로 가정합니다.
특정 데이터 원본을 추가하려면 스택 파일에 구성을 추가해야 합니다. 데이터 원본 유형 목록은 다음에서 찾을 수 있습니다.
-
대개는 사용 중인 서비스에 가져오기 지침을 추가해야 할 수 있습니다. 예를 들면 다음 형식을 따를 수 있습니다.
import * as x from 'x'; # import wildcard as the 'x' keyword from 'x-service'
import {a, b, ...} from 'c'; # import {specific constructs} from 'c-service'
예를 들어 다음과 같은 방법으로 AWS AppSync 및 DynamoDB 서비스를 가져올 수 있습니다.
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
-
RDS와 같은 일부 서비스는 데이터 원본을 생성하기 전에 스택 파일에 몇 가지 추가 설정이 필요합니다(예: VPC 생성, 역할, 액세스 보안 인증 정보). 자세한 내용은 관련 CDK 페이지의 예시를 참조하세요.
-
대부분의 데이터 원본(특히 AWS 서비스)의 경우 스택 파일에 데이터 원본의 새 인스턴스를 생성하게 됩니다. 일반적으로 다음과 같습니다.
const add_data_source_func = new service_scope.resource_name(scope: Construct, id: string, props: data_source_props);
예를 들어 Amazon DynamoDB 테이블의 예는 다음과 같습니다.
const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
partitionKey: {
name: 'id',
type: dynamodb.AttributeType.STRING,
},
sortKey: {
name: 'id',
type: dynamodb.AttributeType.STRING,
},
tableClass: dynamodb.TableClass.STANDARD,
});
대부분의 데이터 원본은 필수 속성을 하나 이상 갖습니다(? 기호 없이 표시됨). 어떤 속성이 필요한지 알아보려면 CDK 설명서를 참조하세요.
-
다음으로 데이터 원본을 GraphQL API에 연결해야 합니다. 권장되는 방법은 파이프라인 해석기용 함수를 만들 때 추가하는 것입니다. 예를 들어 아래 스니펫은 DynamoDB 테이블의 모든 요소를 스캔하는 함수입니다.
const add_func = new appsync.AppsyncFunction(this, 'func_ID', {
name: 'func_name_in_console',
add_api,
dataSource: add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table),
code: appsync.Code.fromInline(`
export function request(ctx) {
return { operation: 'Scan' };
}
export function response(ctx) {
return ctx.result.items;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
});
dataSource 속성에서 GraphQL API(add_api)를 호출하고 기본 제공되는 메서드(addDynamoDbDataSource) 중 하나를 사용하여 테이블과 GraphQL API 사이의 연결을 설정할 수 있습니다. 인수는 AWS AppSync 콘솔(이 예에서는 data_source_name_in_console)에 존재할 이 링크의 이름과 테이블 메서드(add_ddb_table)입니다. 이 주제에 대한 자세한 내용은 다음 섹션에서 해석기 제작을 시작하면서 설명하겠습니다.
다른 방법으로도 데이터 원본을 연결할 수 있습니다. 기술적으로는 테이블 함수의 속성 목록에 api를 추가할 수 있습니다. 예를 들어 다음은 3단계의 스니펫이지만, 여기에는 GraphQL API가 포함된 api 속성이 있습니다.
const add_api = new appsync.GraphqlApi(this, 'API_ID', {
...
});
const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
...
api: add_api
});
또는 GraphqlApi 구성을 별도로 호출할 수도 있습니다.
const add_api = new appsync.GraphqlApi(this, 'API_ID', {
...
});
const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
...
});
const link_data_source = add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table);
함수의 속성에만 연결을 만드는 것이 좋습니다. 그렇지 않으면 AWS AppSync 콘솔에서 수동으로 해석기 함수를 데이터 원본에 연결하거나(콘솔 값 data_source_name_in_console을(를) 계속 사용하려는 경우) data_source_name_in_console_2 등의 다른 이름으로 함수에 별도의 연결을 만들어야 합니다. 이는 속성이 정보를 처리하는 방식에 제한이 있기 때문입니다.
변경 사항을 확인하려면 앱을 다시 배포해야 합니다.
IAM 신뢰 정책
데이터 원본에 대해 기존 IAM 역할을 사용하려는 경우 Amazon DynamoDB 테이블에서 PutItem 같은 AWS 리소스에 대한 작업을 수행할 수 있는 적정 권한을 해당 역할에 부여해야 합니다. 또한 다음 예제 정책에서처럼 AWS AppSync에서 리소스 액세스용으로 활용할 수 있도록 해당 역할에 대해 신뢰 정책을 수정해야 합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
신뢰 정책에 조건을 추가하여 데이터 원본에 대한 액세스를 원하는 대로 제한할 수도 있습니다. 현재 SourceArn 및 SourceAccount 키를 이러한 조건에 사용할 수 있습니다. 예를 들어 다음 정책에서는 데이터 원본에 대한 액세스를 123456789012 계정으로 제한합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
또는 다음 정책을 사용하여 데이터 원본에 대한 액세스를 특정 API(예: abcdefghijklmnopq)로 제한할 수 있습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:appsync:us-west-2:123456789012:apis/abcdefghijklmnopq"
}
}
}
]
}
다음 정책을 사용하여 특정 지역(예: us-east-1)의 모든 AWS AppSync API에 대한 액세스를 제한할 수 있습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:appsync:us-east-1:123456789012:apis/*"
}
}
}
]
}
다음 섹션(해석기 구성)에서는 해석기 비즈니스 로직을 추가하고 이를 스키마의 필드에 연결하여 데이터 원본의 데이터를 처리합니다.
역할 정책 구성에 대한 자세한 내용은 IAM 사용 설명서의 역할 변경을 참조하세요.
AWS AppSync용 AWS Lambda 해석기의 크로스 계정 액세스에 관한 자세한 내용은 Building cross-account AWS Lambda resolvers for AWS AppSync를 참조하세요.
