AWS Serverless Meetup - AppSync

AppSync를 활용한 리얼타임 서버리스 아키텍쳐

Speaker : 김태우 https://dev.classmethod.jp/author/kim-taewoo/

서버리스 아키텍쳐 특징

• 관리할 서버가 없다 (NoOps)

• 필요할 때마다 필요한 부분만 필요한 만큼 사용할 수 있다

• 컴퓨팅 리소스는 Lambda or Fargate

  • Lambda의 경우 자체적으로 connection을 유지할 수 없다!

Fargate

: a serverless compute engine for containers that works with both Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS)

Lambda

: a compute service that lets you run code without provisioning or managing servers

서버리스 아키텍쳐도 리얼타임 기능 만들 수 있다

How?

: by using API Gateway websocket or Pubsub

• API Gateway 에서 websocket을 지원함

• Connection 기반의 solution은 아니지만 PubSub Solution도 가능하기는 함

It's possible, but

• Front-end 와 Back-end 간의 통신을 위한 Data structure 정의 해야함

• Data 주고 받을 때의 Validation 필요

• Front & Back 양측에서 개발이 이루어져야 함

• Back-end 신경써야 할 것이 많음

  • High availality

  • reliability

  • scalability

---> AppSync 를 사용하여 극복 가능하다

AWS AppSync

• Strong typing으로 인해 Validation 코드 거의 생략 가능 ( GraphQL의 특징 )

• Real-time 통신을 위해서 Back-end에서 해야할 것은 Subscription 을 스키마에 선언해두는 것 밖에 없음

  • Schema에 해당 기능을 쓸거라고 명시만 해놓으면 된다!

• Frontend 측에서는 AppSync SDK나 Amplify를 사용하면 간단히 Subscription이 가능하다!

Pros of AppSync

1. GraphQL에서 빠른 prototype 생성 및 개발

2. 실시간 협업 mobile & web app

3. 원활한 오프라인 작업

4. 안전한 데이터 액세스

5. 여러 원본의 데이터 결합

6. 데이터 충돌 감지 및 충돌 해결

Real time Data 통신을 위한 AppSync Architecture

image-20200307010708273

Serverless Streaming Architecture

image-20200307011320581

• 전형적인 서버리스 데이터 스트리밍 패턴 중 하나

• Eventual Consistency or Event-driven processing 등을 처리하기에 적합

• Scalable & Reliable & Cost Effective

• 병렬도가 매우 높은 작업에 대해서는 실시간성을 보장하지 않으므로 Kinesis DS가 좋음

• DynamoDB Streams는 최대 24시간의 데이터 보존, 데이터 변경의 순번이 보증 가능한 서비스

image-20200307012139759

• RDS를 사용한 경우에도 스트리밍 처리가 가능함

• Kinesis Data Streams 는 샤드를 적절히 컨트롤 할 수 있어야함

  • 샤드

    : 스트림에서 고유하게 식별되는 데이터 레코드 시퀀스

• Kinesis Data Streams 에서 굳이 Lamda 로 연계할 필요는 없음

  • but, AppSync 연계를 위한 용도로는 Lambda 로 충분하다!

• DB(MySQL, PostgreSQL etc.) 으로 부터 직접 Lambda 를 실행시키는 방법도 존재함

image-20200307013708527

1. SQL 에서 Lambda 로 연계되는 패턴

2. Kinesis 에서 Lambda 로 연계되는 패턴

3. API Gateway 에서 Lambda 로 연계되는 패턴

4. CloudWatch Alarms 에서 Lambda 로 연계되는 패턴

5. CloudWatch Events 에서 Lambda 로 연계되는 패턴

   ... and a lot more!

Lambda로 불러온 후

image-20200307014333774

Demo Project Architecture

image-20200307014508453

AppSync를 Subscription의 용도로만 쓸거라면 굳이 Appsync용 DB 연결할 필요 없이 DynamicDB Stream를 쓰면 됨!

Microservice

• API Gateway -> Lambda -> DynamoDB 구성

• 가장 많이 쓰이는 Serverless Architecture API back-end pattern

• 간단한 input form을 처리하는 서비스를 예로 들어 데모코드 작성

AWS AppSync

• AppSync 구축 시에는 Serverless Framework를 추천

• Subscription 을 Schema에 추가하는 것만으로도 client 측에서 Subscription이 가

  • 백앤드 작업 발생 x

• 필요한 기능은 mutation, subscription 뿐이지만, query를 schema에 등록하지 않으면 GraphQL schema error가 되므로 간단한 query 하나를 추가해야함

  • getOrder 작성

• Mutation 하기 위해서의 DynamoDB 를 Data source로서 생성하고, TTL (Time-To-Live) 를 설정한다

  • expiresAt을 AWSTimestamp 타입으로 선언한다

DynamoDB Streams -> Lambda

• DynamoDB Streams 는 최대 24 시간의 데이터 보존, 데이터 변경의 순번이 보증가능한 서비스

  • but, Realtime Service 에서는 최대 24 시간의 데이터 보존은 별 의미가 없긴 함

• 병렬도를 높이려면 배치 사이즈를 조절하면 됨!

Lambda -> Appsync

• 실서비스용으로 releaase 된 AppSync Client SDK 는 JavaScript version 뿐이므로 Amplify를 권장

• AppSync Clinet SDK를 Lambda 상에서 동장시키기 위해 주의할 점

  • ismorphic-fetch를 import 해야 함

  • disableOffline 을 true로 변경해야 함

AppSync로 이런것도 되지 않을까?

State Management by AppSync

• Serverless Architecture pattern 에서는 Rich Client를 지향

  • but, Front-end code의 complexity가 지나치게 증가하는 것은 좋지않음

• Front-end 의 code complexity 의 상당 부분에 기여하는 State Management

• State Mangement 를 도입하기 위한 code의 complexity를 AppSync Subscription 에 의존해서 해결할 수도 있지 않을까?

  • but, Network의 속도/안정성 등에 의존성이 생김

• 그러나 5G 시대에는 큰 문제 없지 않을까?

+

GraphQL이 느린 이유

• http 라서

• resolver 때문

  • 이 부분은 해결 가능

​

당근마켓도 GraphQL 쓴다고 함! 속닥속닥

-> admin 만들 때 좋다고 함! 한번에 모든 데이터 받아올 수 있어서!

-> GraphQL 쓰면 node.js에서 data를 저장하는 방식이 빠를 수가 없는 방식임!

당근마켓이 gRPC 쓰는 이유 == 속도가 엄청 빠름

+

Looked up after the meetup

1. gRPC

   

   image-20200307032408544

   • gRPC (gRPC Remote Procedure Calls) is an open source remote procedure call (RPC) system initially developed at Google in 2015

   • In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services.

   • As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types.

   • On the server side, the server implements this interface and runs a gRPC server to handle client calls.

   • On the client side, the client has a stub (referred to as just a client in some languages) that provides the same methods as the server.

1. apollo gateway

   

   image-20200307032923930

   • Apollo is an implementation of GraphQL designed for the needs of product engineering teams building modern, data-driven applications.

   • It encourages an agile, incremental approach and takes special care to avoid requiring any changes to existing APIs and services.

   • Apollo puts particular emphasis on tooling and workflows.

   • Apollo is best used as a new layer in your stack that sits between your services and your applications.

   • It's a combination of open source components, commercial extensions, and cloud services.

1. 3factor app

   • 3factor app is an architecture pattern for modern full-stack apps.

   • Today, it is possible to build apps that have high feature velocity and scalability from the get go.

   • An architecture pattern which is composed of 3 factors:

     1. Realtime GraphQL

     2. Reliable eventing

     3. Async serverless