골드에그

Step Functions

AWS 의 마이크로서비스 워크플로우 구현을 위한 오케스트레이션 서비스

Lambda 와 같은 서버리스 서비스들을 조합하여 구현

Step Functions 특징

• AWS 의 다른 서비스들과 네이티브하게 연계 통합 가능
• 비즈니스 로직 중심 워크플로우 설계 가능 (관리형 서비스(내결함성, 안정성, 확장성, 고가용성))
  
  • 빌트인 된 try-catch-finally 패턴을 통해 타임아웃, 재시도, 에러메세지 관리가 가능하여 장애 대응에 원할
  • 모니터링 후, 요청량에 따른 자동 스케일링 가능
• 다양한 상태를 활용하여 워크플로우를 정의하기 쉬움

Step Functions 구조

Action 과 Flow 컴포넌트로 구성되어 있음

• Action
  • 다른 AWS 서비스를 활용하여 작업을 수행
  • 예 : 람다 함수 호출, SNS Publish, AWS Fargate 서비스 호출
• Flow
  • task 들의 제어 흐름을 정의하는 7가지 상태
  • 분기 choice, 반복 map, 동시 실행 parallel, 디버깅 path, 타이머 wait, 성공 success, 실패 fail

Step Functions 구축

• Workflow Studio
• IaC 프레임워크 + 서버리스 개발용 라이브러리(Chalice)
• Serverless Framework (https://www.serverless.com/framework/docs)

Step Functions 는 특성 상 비지니스 로직과 밀접하게 연결되어 있어 인프라와 애플리케이션을 디커플링하여 개발하면 새로운 개발 요청이 들어왔을 때 인프라와 코드를 둘 다 수정해야 되는 단점이 있음.

따라서, 인프라와 애플리케이션을 커플링하여 서비스 변경에 더 민첩하게 반응할 수 있는 애플리케이션 특수적 인프라를 활용하는 추세임.

Step Functions 한계점

Step Functions 는 별도의 요청으로 상한을 올릴 수 있는 소프트 할당량과 상한을 올릴 수 없는 하드 할당량이 있다.

소프트 할당량은 유연하게 대처가 가능하므로 하드 할당량에 대해서 알아본다.

• 페이로드의 최대 크기 (256 KB)

페이로드는 오직 실행이나 컨텍스트 관리에 필수적인 데이터만 포함하여 핸들링하는 것이 바람직하다.

이외 데이터들은 다른 서비스나 서버에 저장 후 로드한다.

• 실행 기록의 최대 이벤트 개수 (25,000 개)

상태머신을 활용할 경우, Step Functions 는 해당 실행에 대한 모든 이벤트를 기록하기 시작한다.

각 상태마다 2 ~ 5 개 정도의 이벤트가 발생한다. 예를 들어 람다 호출의 경우, 람다 예약 => 람다 시작 => 람다 성공 순으로 이벤트가 기록된다.

이베트 개수를 줄이는 방법이 있을 수 있다. 하지만 권장하지 않는다.

예를 들어, 여러 개의 Lambda 함수를 활용하여 병렬처리하는 구조의 애플리케이션을 Lambda 함수 하나로 포팅한다면 이벤트의 개수는 줄일 수 있지만, 병렬 처리로 얻는 속도, 효율 등의 장점들을 모두 포기해야 한다.

Lambda 함수를 통해 상태머신을 재실행하는 방법을 AWS 에서 권장하고 있다.

1 . (plan) StateMachine 시작 전 작업 크기를 계산하고, 현재 실행 정보를 담고 있는 컨텍스트 정보를 생성한다.

• 총 처리해야 하는 개수
• 현재 처리 개수
• 커서

2 . (fetch, apply) 병렬 작업자들에게 할당할 작업들을 생성하고 반복 처리한다.

• 최대 동시성(동시 실행 가능한 작업자의 최댓값)을 고려하여 전체 작업을 처리 가능한 크기의 작업으로 분할한다.
• 반복 실행을 통해 순차 처리한다. 아래 3, 4 단계를 참고한다.

3 . (aggregate) apply 결과 값들을 취합한다.

4 . 더 이상 작업이 없다면 Finish, 아직 작업이 있고 최대 반복 횟수 도달했다면 ExecuteNew, 최대 반복 횟수 미달했다면 다시 fetch 실행

4 - 1 . ExecuteNew 로 실행했다면 현재 실행의 Context 정보도 같이 전달하여 plan 재실행

Active Worker 패턴

AWS 서비스 이외에 다른 서비스(온 프레미스 서비스, 써드 파티 SDK, 다른 클라우드 서비스) 처리 시 지연시간으로 인해

비동기적인 처리가 필요할 수도 있다. 만약 Lambda 로 구현한다면 지속적으로 폴링해야 할 수도 있다. 불필요한 시간을 소요할 수 있으며 결국 Lambda 의 최대 실행 시간인 15분을 넘길 수 있다.

외부 서비스와 통합하기 위해 Activity 를 사용하는 것을 권고한다. 상태머신의 진행을 비동기적으로 바꿀 수 있다.

그런데 아래 공식 문서는 코드 분리 측면으로 봐야되고, 위 병렬 실행 TIP 과는 다른 컨셉으로 봐야 될 것 같다.

https://docs.aws.amazon.com/ko_kr/step-functions/latest/dg/tutorial-use-sfn-api-cont-exec.html

참고

https://www.youtube.com/watch?v=EZrL7p7Qlp4