본문 바로가기

# GraphQL/GraphQL.js

아마존 AWS AppSync 시작하기



아마존 AppSync란?


AWS AppSync는 아마존에서 제공하는 서버리스 GraphQL 서비스입니다. (= GraphQL As a service)

아마존에서 사용되는 자원들을 쉽게 GraphQL에 부착할 수 있다는 것이 큰 장점이며,

완전 관리형으로 동작하기 때문에 유지보수 비용도 크지 않습니다.


아래부터는 기본적인 GraphQL 지식이 있다는 가정하에 진행되므로,

아직 GraphQL이 무엇인지 모르시는 분은 여기를 한번 살펴봐주세요.




요금 상세


GraphQL 서비스를 이용한 만큼 비용이 결정됩니다.

  • 쿼리와 뮤테이션 
    호출한 횟수 1백만 건당 4.00 USD

  • 실시간 업데이트 (서브스크립션)
    연결된 시간 1백만 분당 0.08 USD
    수신된 자료 1백만 건당 2.00 USD
    ** 5kb 이하의 데이터는 1건으로 취급하고,
    ** 5kb 이상의 데이터는 5kb당 1건으로 취급합니다.

  • 캐싱
    캐싱의 수준에 따라 비용이 결정됩니다.
    아래 요금표에 기재된 비용이 시간당 청구됩니다.




프리티어 항목


AWS의 프리티어에는 12개월 또는 영구 프리티어 서비스로 나뉩니다.

AWS AppSync는 12개월 프리티어가 적용됩니다.

  • 쿼리 및 뮤테이션 호출횟수 250,000건
  • 실시간 업데이트 수신된 자료 250,000건
  • 실시간 업데이트 연결된 시간 600,000분


위의 한도를 벗어난 항목에 대해 추가분만큼 비용이 부과됩니다.




데이터 원본?


AppSync에서 말하는 데이터 원본이란 추출가능한 데이터의 위치를 말합니다.

예를 들어서, AppSync에서 참조할 수 있는 데이터 지점은 아래와 같습니다.

  • AWS DynamoDB
  • AWS Elasticsearch
  • AWS Lambda
  • AWS RDB
  • HTTP Endpoint


대부분의 데이터는 DB에 저장되어있기 때문에 DynamoDB 또는 RDB만으로 충분하지만,

외부 API를 사용해야 하는 경우 HTTP 또는 Lambda를 사용하면 좋습니다.




이렇게 추출된 데이터는 GraphQL의 응답에 삽입되는데 추출된 데이터가 어떻게 변환되는지를 정의해야 합니다.

데이터 소스에서 얻어진 구조와 반환해야하는 데이터 구조가 다를 수도 있기 때문이죠.


데이터를 올바른 응답구조로 변환하는 과정을 매핑mapping이라고 부르는데,

추출이나 처리가 복잡한 데이터는 매퍼 파이프라인을 구축하여 대처할 수 있습니다.





스키마 정의


AppSync는 웹콘솔에서 직접 스키마를 타이핑하여 정의해야 하는데,

이 과정에서 스키마 정의 언어schema define language가 사용됩니다.


위의 사진에서 [Schema]필드에 스키마를 정의하면,

[Resolvers]필드에 리졸버를 부착할 수 있는 공간이 활성화됩니다.


주의해야 할 점은 리졸버를 부착하기 전에 반드시 [스키마 저장]버튼을 눌러야합니다.

스키마를 저장하지 않아도 리졸버 부착버튼이 활성화되는데,

이 상태에서 리졸버를 부착하려고 하면 오류가 발생합니다.


이제 스키마를 저장하고, 

putPost 뮤테이션에 리졸버를 달아보겠습니다.




데이터 소스 생성


putPost의 [연결]버튼을 누르면, 먼저 데이터 원본을 선택해달라는 창이 나올것입니다.

하지만 데이터 원본이 정의되어 있지 않으므로,

DynamoDB로 이동하여 Post가 저장될 테이블을 만들겠습니다.




위처럼 테이블을 만들었다면 [add datasource]를 누르고, 

다음처럼 DynamoDB를 데이터 소스로 추가합니다.




매핑 템플릿 구성


putPost에 DynamoDB를 데이터 소스로 지정하면,

이제 추출된 데이터를 어떻게 매핑할지에 대한 템플릿을 지정해야 합니다.



템플릿은 json 형식으로 지정할 수 있고, 

자주 사용하는 템플릿은 오른쪽 동그라미부분에서 꺼내쓸 수 있습니다.

 

위에서 살펴보면 특수한 객체가 사용되고 있음을 알 수 있는데,

잠깐 이 객체에 대해서 살펴보겠습니다.


  • $util
    자주 사용되는 유틸리티 함수가 들어있습니다.
    자동으로 아이디를 생성해주거나, 정규식을 지원합니다.

  • $ctx
    문맥의 약자이며 요청 템플릿에서는 $ctx.args으로 매개변수를 참조할 수 있습니다.
    응답 템플릿에서는 $ctx.result로 소스에서 가져온 데이터를 참조할 수 있습니다. 


위가 공통으로 사용되는 인자이고,

각 데이터 소스마다 템플릿 문법이 다르니,

자세한 사항은 문서를 확인해주시기 바랍니다.



여기서는 템플릿만 사용하여 지정합니다.

  • putPost
    요청 : Put item
    응답 : Return single item

  • allPost
    요청 : List items
    응답 : Return a list of results




웹콘솔에서 AppSync 테스트


리졸버를 전부 부착한 뒤 [쿼리]섹션에 들어가면

지금까지 작성된 GraphQL API를 테스트할 수 있습니다.




사용된 리소스 정리하기


자습을 마치고 나면 반드시 생성된 자원을 삭제해주세요.

DynamoDB의 경우 1달을 내버려두면 3.5달러가 청구됩니다...





AWS AppSync Lambda와의 요금비교


서브스크립션 기능을 이용하지 않는다면,

아래의 조합을 통해 람다로 serverless GraphQL API를 만들 수 있습니다.


그렇다면 어떤 기능으로 만드는 것이 더 싸게 먹힐까요?

먼저 람다의 요금 상세를 살펴보면 다음과 같습니다.

  • 람다 호출횟수 1백만건당 0.20 USD  (반면, AppSync는 4.00 USD)
  • 컴퓨팅 성능에 따라 컴퓨팅시간 100ms 당 아래의 표를 따름. (반면, AppSync는 컴퓨팅 요금이 없음.)


백만건당 비용차이가 어마무시하지만, AppSync는 컴퓨팅 요금이 포함되지 않습니다.

즉, 컴퓨팅 요금을 포함해서 백만건당 4.00 USD 이상이 되면 AppSync를 사용하는 것이 낫겠죠. 


람다 요금 계산기를 통해 살펴보면,

각 요청의 컴퓨팅 시간이 1800ms 이하일 때만 Lambda가 경제적입니다.  (가장 싼 128M 기준)

네트워크 작업이나 데이터 정제작업이 오래걸리면 AppSync가 경제적이겠죠?



하지만 복잡한 데이터 추출이 아닌 이상, 1800ms 이상을 넘기기는 힘들어보입니다.

DynamoDB 기준으로 단일 데이터를 추출하는데에는 평균 20ms 밖에 걸리지 않기 때문입니다.

다중 데이터를 추출하거나 쓸때도 async가 가능하다면 극적인 컴퓨팅 속도를 보여줍니다. (환경에 따라 다르지만, 200ms 이하)


다만, 반드시 서브스크립션이 필요한 환경이라면 AppSync를 이용하는 것이 바람직합니다.




참고 링크


AWS 대학생 모임 - AppSync 소개 (Korean)