Section 28. AWS Step Functions 및 AppSync

AWS Step Functions

Step Function은 워크플로우를 상태 머신으로 모델링 하게 해준다.
워크플로우 당 하나의 상태 머신을 가질 수 있다!

JSON 형식으로 쓰이며, 워크플로우를 시각화하고 수행할 수 있다.
워크플로우를 시작하기 위해 SDK API 호출을 사용할 수도 있고, API Gateway나 CloudWatch Event를 이용할 수 있다.

 

옆에 보이는 여러 박스들을 태스크라고 부르는데, 이 태스크 안에서 일어나는 상태들을 알아보자!

• 태스트 상태는 상태머신에 어떠한 작업을 실행할 때 사용한다.
  • 람다 함수 호출
  • AWS Batch 작업 호출
  • ECS 태스크를 실행하고 완료되기까지 대기
  • DynamoDB에 항목을 직접 삽입 등등
• 태스크는 실행 중인 하나의 활동일 수도 있다.
  • 이 활동에는 Amazon ECS 태스크 또는 Step Functions에서 어떤 작업을 가져와서 해당 작업을 수행하고 결과를 다시 Step Function으로 보내는 온-프레미스 서버일 수도 있다.
  • 앱 서버가 Step Function에 의해 호출되는 것이 아닌
    앱 서버에 있는 Step Functions가 Step Functions를 가져와서 활동을 찾고 작업을 수행한다는 측면에서 더 자유로움!
  • AWS SWF(Simple Workflow Service) 서비스 동작 방식과 유사!

Step Function - Task의 작업 종류!

Step Functions - States

• Step Functions 각 상태는 다음과 같다.
• Choice State | 브랜치나 기본 브랜치로 보낼 조건을 테스트
• Fail or Succeed State | 단순이 입력에서 출력으로 통과하거나, 수행 작업 없이 고정된 데이터를 주입하는 상태
• Wait State | 특정 시간이나 날짜까지 지연시키는 상태
• Map State | 단계들을 동적으로 반복
• Parallel State | 브랜치의 수행을 병렬적으로 수행

Step Functions 상태를 시각화한 모습

---

Error Handling in Step Functions

• Step Functions는 작고 많은 태스크들을 실행한다.
• 어떤 상태든 다양한 이유에서 런타임 에러를 마주할 수 있는데, 에러는 언제 발생할까?
  
  • 상태 머신에 정의 문제가 있을 수 있다.
  • 람다 함수가 예외 처리 되는 예시를 들어 태스크가 실패할 때 문제가 있을 수 있다.
  • 네트워크 파티션 이벤트 같은 일시적 실패가 있을 수 있다.
• Step Functions 오류 처리에는 재시도와 캐치가 있다.
  재시도는 실패 상태를 재시도하는 것이고, 캐치는 실패한 경로로 전환하는 처리를 말한다.
  어플리케이션 코드가 아닌 상태 머신에서 해야함을 유의하자.
• 사전 정의되어 있는 오류 코드를 알아보자.
  1. States.ALL | 어떤 오류 이름과도 매칭
  2. States.Timeout | 태스크가 시간초과 초보다 길게 실행하거나 아무 신호도 받지 못했을 때
  3. States.TaskFailed | 태스크 실행이 실패했을 때
  4. States.Permissions | 권한이 충분하지 않은 경우

Retry

• 재시도할 작업 및 횟수를 정의할 수 있다.
  각 요소들을 알아보자.
• ErrorEquals | 특정 오류를 매칭
• IntervalSeconds | 재시도 전에 오래 대기해야 하는 정도
• MaxAttempts | 최대 시도 횟수
• BackoffRate | 재시도 후의 지연을 곱함. 이는 지수 백오프를 구현하기 위함이다.
• 모든 시도를 하면 캐치 블록이 실행된다!

Catch

• 캐치도 Retry와 비슷한 구조를 가진다.
• ErrorEquals | Retry와 동일
• Next | 다음 상태로 이동
• ResultPath | 전송되는 입력값의 경로를 설정
• ResultPath의 동작 방식을 알아보자.

 

 Catch는 어떤 종류의 에러든 다음 태스크로 이동할 것을 명령한다.

ResultPath에는 "$.error"가 있는 것을 볼 수 있는데 이는 입력값에 오류를 포함할 수 있게 해준다.

결과값이 다음 상태의 다음 태스크로 전달 될 때 같이 움직인다는 것이다.

 

 

 

 

 

---

Step Functions - Wait for Task Token

• waitForTaskToken은 기본적으로 Step Functions와 실행 워크플로우가 정의된 다음에 반환되기를 기다리는 값이다.
• 태스크는 다른 AWS 서비스, 사용자 승인, 서드 파티, 레거시 시스템 호출 등을 기다릴 수도 있다.
  이를 위해서는 Step Functions의 태스크에서 리소스 필드에 .waitForTaskToken을 추가하면 실행을 계속하기 전에 태스크 토큰이 반환될 때까지 대기하도록 Step Functions에 알려줄 수 있다.
• 모두 제대로 작동되면 "SendTaskSuccess"를, 아닌 경우에는 "SendTaskFailure"를 호출하여 태스크 토큰이 반환될 때까지 태스크가 일시적 중단된다.

• 위와 같은 TaskToken 반환 방식의 장점은 Step Functions 워크플로우로 돌아가기 전에 외부 시스템을 통한 처리 작업을 수행할 수 있다는 것이다.
  그리하여 모든 종류의 외부 메커니즘과 통합할 수 있다.

---

Step Functions - Activity Tasks

위에서 배운 waitForTaskToken 패턴과 비슷하다! 하지만 달성 방식이 다르다.
Activity Worker는 Step Functions에서 작업을 수행하는 구성 요소로 EC2 인스턴스, 람다 함수 등
원하는 모든 곳에서 실행할 수 있다.

 

 

• Activity Worker는 GetActivityTask API를 이용하여 정기적으로 Step Functions 워크플로우를 폴링하여 태스크를 찾으며, 작업을 반환받으면 이를 실행 및 완료한 다음 이전과 동일하게 SendTaskSuccess와 SendTaskFailure API를 사용하여 응답을 보낸다.
• 이전과 동일하게 "SendTaskSuccess"와 "SendTaskFailure" API를 사용하여 응답을 보낸다.
• WaitForTaskToken과는 차이가 있는데 Activity Tasks는 EC2 인스턴스나 그 밖의 어플리케이션들이 Step Functions에서 특정 작업을 폴링하므로 EC2 인스턴스가 Step Functions에 연결할 수만 있으며 되기에 네트워크가 쉽다!
• Task를 활성화하기 위해서는 다음과 같은 작업을 해야 한다.
  • TimeoutSeconds로 진행 중인 작업이 실패로 간주될 때까지 대기할 수 있는 시간을 설정
  • HeartBeatSeconds에 설정한 시간 내에 SendTaskHeartBeat를 사용하여 활동 작업자로부터 주기적으로 하트비트를 보낸다.
• 이렇게 긴 TimeoutSeconds를 설정하고 HeartBeat를 보냄으로써, Activity Task는 1년까지 대기할 수 있다!

---

Step Functions - Standard vs. Express

• 계단 함수 워크플로우를 실행하는 방법에는 두 가지가 있다.

1. 기본값인 표준 워크플로우를 사용하는 방법
2. 익스프레스 워크플로우를 사용하는 방법

• 익스프레스 워크플로우는 비동기식 워크플로우와 동기식 익스프레스 워크플로우가 있다!
  하나씩 알아보자!

1. 표준 Step Functions 워크플로우

• 표준 Step Functions 워크플로우의 경우 단일 워크플로우의 최대 기간은 1년이고, 초당 2000개의 표준 워크플로우를 실행할 수 있다.
• 실행 기록의 경우 콘솔에 최대 90일까지의 기록이 보관되며 cloudwatch를 사용하여 더 많은 로그를 보거나 로그 보존 설정을 통해 로그를 영구 보관할 수 있다.
• 비용은 한 상태에서 다른 상태로 전환하는 횟수에 따라 책정된다.

2. 익스프레스 워크플로우

• 최대 실행 시간이 5분인 짧은 워크플로우로 매우 빠른 속도로 높은 용량을 제공하며 초당 10만 회 이상 실행을 처리한다.
• 콘솔에는 기록을 추적할 수 없고, CloudWatch 로그를 통해서만 실행 결과와 분석 자료를 얻을 수 있다.
• 요금은 실행 횟수, 실행 기간, 메모리 사용량에 따라 청구된다.
• 익스프레스 워크플로우에는 비동기와 동기가 있는데, 비동기식 워크플로우는 최소 1회 실행 보장 모델이고, 동기식 워크플로우는 최대 1회 실행 모델인 점에서 차이가 난다.
• 비동기식 워크플로우를 사용할 경우, 실행이 시작되면 결과가 나오기를 기다리지 말고 실행 종료 여부와 결과가 제대로 나왔는지 확인해야 한다.
  최소 1회 보장 모델이기에 오류가 발생할 경우, Step Functions 내에서 바로 자동으로 다시 시도할 수 있기에 동일한 작업이 2번 수행될 수 있다. 따라서 동일한 작업이 실행되지 않게 하도록 중요도를 잘 관리해야 한다.
• 동기식 워크플로우를 사용할 경우, 결과가 나오기를 기다리며 즉각적인 응답이 필요하다.
  실패하더라도 Step Functions가 워크플로우를 다시 시작하지 않으므로 최대 한 번만 실행되며 재시도도 가능하지만 해당 로직은 사용자가 구현해야 한다.

---

App Sync

AppSync는 두 가지 포인트만 중시하면 된다!
1. GraphQL을 사용하는 관리 서비스
2. 실시간 WebSocket 또는 WebSockets의 MQTT 통합

 

GraphQL

• GraphQL은 어플리케이션이 요구하는 데이터를 쉽게 얻을 수 있다.
• 기본적으로 원하는 필드를 요청하면 GraphQL이 이를 반환한다.
• GraphQL은 하나 이상 소스의 데이터를 그래프로 결합할 수 있다. 즉 GraphQL의 데이터셋은 NoDQL 데이터 저장소, RDS 모두를 결합한다.

• AppSync에서 일어난 일의 로그를 보고 싶다면 CloudWatch Metrics와 CloudWatch Logs와 통합하여 정보를 얻을 수 있다!

AppSync - Security

• AppSync GraphQL API와 상호작용하는 어플리케이션에 권한을 주는 법에 4가지가 있다.

1. API_KEY로 API Gateway처럼 키를 생성하고 사용자에게 인가
2. AWS_IAM을 이용하여 IAM 사용자, 역할, 계정에 걸친 접근을 부재 API에 허용한다.
3. OPENID Connect 공급자와 JSON 웹 토큰을 통합한다.
4. AMAZON_COGNITO_USER_POOL은 Cognito 사용자 풀을 통해 생성한 기존 사용자 풀과 통합한다.

만일 AppSync에서 사용자 정의 도메인과 HTTPS 보안을 원한다면 AppSync 앞에 CloudFront를 사용해보자!!

 

---

AWS Amplify

Amplify는 모바일과 웹 어플리케이션을 바로 만들 수 있는 서비스로 다양한 구성 요소로 이루어져 있다.

• Amplify Studio | 프론트와 백엔드 모두에서 풀 스택 앱을 시각적으로 구축할 수 있도록 해준다.
• Amplify CLI | 동일한 작업을 CLI 수행할 수 있다.
• Amplify Libraries | 로그인을 위한 Cognito나 스토리지를 위한 S3와 같은 기존의 AWS 서비스에 앱을 연결해준다.
• Amplify Hosting | Amplify Libraries와 AWS에서 어플리케이션을 호스팅하여 아주 빠르게 전달한다.

AWS Amplify의 중요한 특징은 다음과 같다.

1. 별도의 설치 없이 즉시 사용 가능한 인증 기능을 제공한다.
   • amplify add auth 명령어를 사용하여 Amazon Cognito를 활용함으로써 사용자 등록, 인증, 계정 복구 및 그 밖의 작업 수행 가능
   • MFA, 소셜 서명 등을 지원하며 프론트엔드에서 이를 빌드하고 Cognito와 통합할 수 있도록 사전 구축 컴포넌트를 제공하고, 세분화된 권한을 부여할 수 있다.
2. 데이터스토어 관련 기능
   • amplify add api 명령어를 사용하여 API에는 Amazon Appsync, 데이터 저장소에는 Amazon DynamoDB를 활용하는데 Amplify 프레임워크 덕분에 데이터스토어를 통해 데이터와 로컬 데이터로 작업한 다음 복잡한 코드 없이 클라우드에 자동으로 동기화할 수 있다!
   • Amplify Studio로 데이터를 모델링할 수 있다.

Amplify Hosting

 

 어플리케이션을 배포하고자 할 때 사용하는 서비스로 amplify add hosting 명령어를 사용하여 최신 웹/앱을 빌드하고 호스팅할 수 있고, 빌드, 테스트, 배포와 같은 CI/CD 프로세스를 수행하며,
풀 리퀘스트 미리 보기, 사용자 지정 도메인 생성, 모니터링을 수행하고 리디렉션, 사용자 지정 헤더, 암호 보호 등을 설정할 수 있다!

 

 

 

 

 

Amplify - End-to-End Testing

• Amplify는 선택적 테스트 실행이 가능하며 단위 테스트와 종단간 테스트라는 두 가지 테스트가 존재한다.
• Amplify 테스트 단계에서는 종단간 테스트를 실행하는데 그 목표는 코드를 프로덕션으로 푸시하기 위해
  회귀를 포착할 수 있도록 하는 것이다.
• 테스트 단계를 사용하여 빌드 과정 중 테스트 명령을 실행하고 amplify.yml 파일에서 테스트 단계를 정의한 다음
  Cypress 테스트 프레임워크를 사용하여 E2E 테스트를 생성할 수 있다!
  Cypress 테스트 프레임워크를 사용하면 테스트에 대한 UI 보고서를 얻을 수 있고, 웹 클릭을 정의하여 앱이 예상대로 작동하는지 여부를 확인할 수 있다. 이 자체를 E2E 테스트라고 한다.