この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
안녕하세요! 임채정입니다.
오늘은 5월 10일에서 11일까지 진행한 AWS Summit Online Korea 2022의 [나만 알기에 아까운 AWS Step Functions 사용법] 세션에 대해 소개하겠습니다
해당 세션은 크게 두 개의 파트로 나눠서 진행했습니다
본 블로그 에서 사용한 이미지는 AWS Summit Korea에서 제공된 발표자료와 영상을 사용했습니다.
아젠다
- 세션 개요
- 파트 1. 서비스 소개 및 작동 원리 (사례를 통해 설명)
- 파트 2. AWS Step Functions 을 잘 사용하기 위한 팁과 개발기
1. 세션 개요
개요
본 세션에서는 데이터의 병렬 처리를 위해 AWS Step Functions 및 Amazon DynamoDB를 사용한 비동기 작업 처리 및 효과적인 작업 추적 사례를 소개합니다. Step Functions을 잘 활용하기 위한 상태 머신 설계 등 개발 과정에서의 배운 점들을 공유합니다.
발표자
유용환 SW 엔지니어 슈퍼브에이아이
김재현 SW 엔지니어 슈퍼브에이아이
발표 난이도
중급 난이도
2. 파트 1. 서비스 소개 및 작동 원리 (사례를 통해 설명)
AWS Step Functions 이 필요한 경우
- 람다를 개발할 때 서비스의 크기가 커져서 서비스 로직이 복잡해지는 경우
- 복수의 람다를 마이크로서비스 형태를 통해 유기적으로 사용하여 함수들의 순서나 논리적인 연결관계를 정의하고 싶을 경우
- 람다와 같은 서비스를 활용해 마이크로서비스 워크플로우를 구현하기 위한 오케스트레이션 서비스
- 람다와 같은 AWS 서비스 사용, 비용 및 성능을 우선시 하는 경우 AWS Step Functions 이 좋은 선택지
AWS Step Functions 의 장점
- 다양한 서비스와 통합해서 사용할 수 있다. (Amazon SQS, Amazon SNS, AWS Fargate 등등)
- 빌트인으로 재시도 로직을 갖추고 있어 손쉬운 장애 대응 가능
- 다양한 상태를 활용해 상태머신을 정의하여 위크플로우를 만들기 용이하다
- 개발자의 인프라 운영에 대한 부담을 줄여준다
- 빠른 프로토타이핑, 소규모 조직 운영 가능
- 실행한 만큼 비용을 지불하기 때문에 비용 절감
AWS Step Functions 의 동작원리
[AWS Step Functions 의 상태머신]
- 실행될 위크플로우를 선언적으로 정의하는 그래프
- 하나의 워크플로우는 여러 개의 작업 단위로 구성될 수 있다.
- AWS Step Functions 의 언어로 말하면 Action, Flow라는 컴포넌트로 구성
- Action, Flow를 필요에 맞게 조합해 Start상태부터 End 상태까지 비즈니스 로직을 위한 다양한 워크플로우를 정의할 수 있다.
- 설계된 상태 머신 별 실행 내역은 AWS 콘솔에서 시각적으로 확인할 수 있다.
- 빌트인 형태로 제공되는 try - catch - finally 패턴을 통해 타임아웃, 재시도, 에러메시지를 등을 관리할 수 있다.
[Action]
- 다음과 같이 다른 AWS 서비스를 활용하여 작업을 수행한다.
- AWS Lambda 호출
- Amazon SNS 로의 publish
- Amazon ECS task 실행
- 등등
[Flow]
Task들의 제어 흐름을 정의하는 7개의 상태
- Choice - 조건문에 따른 분기를 정의
- Parallel - 동일 입력에 대해 여러 작업을 병렬 처리
- Map - 배열과 같은 Iterable 에 대해 Task의 동적 처리를 수행
- Pass - 디버깅을 위한 상태
- Wait - 타이머 기능
- Sauccess/Fail - 실행 성공 여부를 확인하기 위한 상태
Superb AI 의 비디어 데이터 전처리 사례
Mp4 형식의 파일이 업로드 되었을 때 해당 데이터를 전처리하기 위한 워크플로우를 설계한다.
1.Superb AI 스위트 서비스의 데이터 업로드 화면을 통해 고객이 Mp4 파일을 S3 버킷 등에 업로드
2.Object 생성 이벤트에 대한 알림 메시지를 SQS에 전달.
이 때 스위트 데이터를 업로드 하는 방식이 다양할 수 있으므로 업로드방식에 대한 정보를 페이로드에 담아 함께 전달할 수도 있다.
3.순차처리를 위해 대기큐를 통과한 메시지는 데이터 전처리 상태머신의 첫번째 람다 함수인 큐핸들러를 호출
4.두 번쨰 람다 함수에서 파일이 올바른 포멧인지 검증하고 동영상의 재생시간 정보를 추출하여 페이로드에 더한다.
5.Choice 상태에서 앞서 추출한 동영상의 길이에 따라 분기하는데 여기서는 재생기간이 긴 동영상의 전처리 시간이 길어질 수 있기 때문에 경우를 나눈다.
5-1.재생시간이 짧은 비디오는 람다 함수를 통해 처리
5-2.재생 기간이 긴 비디오 파일는 15분 안에 실행을 완료해야 하는 람다 함수의 실행 조건때문에 람다 함수로 처리 불가능.
이 경우 동일한 로직을 실행하기 위해 람다 함수 대신에 Amazon ECS에서 Fargate 태스크를 실행하여 처리한다.
6.파싱 완료된 이미지 프레임은 S3 버킷에 업로드되고 해당 업로드 정보가 페이로드에 더해져 다시한번 순차처리를 위해 SQS로 전달
7.파싱이 완료된 각각의 프레임에 대해 프리뷰를 제공하거나 오토라벨링의 머신러닝 인퍼런스를 연동하기 위해 개별 이미지 프레임에 대한 전처리를 적용.
이때, 일반적으로 이미지 데이터에 적용하는 여러 기법을 병렬로 적용하기 위해 Parallel 상태를 사용
8.여기에는 미리보기를 위한 썸네일 이미지 생성이나 회전 정보를 수정하는 단순한 작업 등을 실행하는데 짧게 끝나면 람다 함수. 긴 작업이나 많은 리소스를 사용하는 경우 Fargate를 사용하여 작업한다.
9.전처리 결과물을 S3 버킷에 업로드하고 데이터베이터 등에 해당 경로를 저장하면 위크플로가 완성된다.
그러면 다음과 같이 비디어 데이터를 타임라인 뷰로 탐색하거나 오토라벨링을 통해 정보를 생성하는 등의 서비스를 사용할 수 있다.
3. 파트 2. AWS Step Functions 을 잘 사용하기 위한 팁과 개발기
1. 서비스 할당량
[페이로드 최대 크기]
문제점 :
상태머신 내에서 주고받는 페이로드가 256K를 넘을 수 없다.
해결방법 :
상태머신으로 다루는 데이터의 크기가 해당 크기보다 크다면 다른 방식으로 저장하고 불러와야 한다.
예를 들어, 상태머신의 페이로드는 오직 실행이나 컨텍스트 관리에 필수적인 데이터만 포함시키고 이외의 데이터는 다른 서비스나 서버에 저장 후 불러온다.
페이로드에 직접 데이터를 넣지 않고 람다 함수를 사용하면 다양한 저장소에서 데이터를 불러올 수 있다.
[실행 기록의 최대 이벤트 개수]
문제점 :
상태머신을 실행하면 AWS Step Functions 는 해당 실행에 대한 모든 이벤트를 기록한다.
예를 들어 상태머신이 람다함수를 실행한 경우 예약, 시작, 성공의 3가지 단계의 이벤트를 순서대로 기록한다.
하지만 AWS Step Functions 는 최대 25,000개의 이벤트만을 기록한다. 25,000개의 이벤트를 넘을 경우 상태머신의 실행은 실패한다.
해결방법1 : 가능한 이벤트의 개수를 줄인다. 하지만 여러개의 람다함수를 실행하는 병렬처리의 구조인 애플리케이션을 람다함수 하나로 몰아서 실행해버리면 이벤트 개수는 줄일 수 있지만 병렬처리로 얻는 속도 및 효율과 같은 서버리스 서비스의 장점을 포기해야 한다.
해결방법2: 람다함수를 통해 상태머신을 재실행하여 작업을 이어간다.
2. 동적 병렬처리 (를 위한 상태머신 페이로드 줄이기)
문제점 :
동적 병렬성을 구현하려면 작업자들이 수행할 작업을 분할해야하며 최대 동시성은 실행 가능한 작업자의 최댓값이다.
Map 상태는 최대 동시성 값에 따라 병렬로 실행할 작업자의 수를 결정한다.
예를 들어, 리스트 안에 100개의 아이템이 있고 최대 동시성 값이 10이라고 한다면 우선 10갸의 아이템을 10개의 작업자들에게 할당해서 실행한다.
이 후 첫번째 아이템의 작업을 작업자가 끝내면 11번째 아이템을 할당받고 실행하는 식으로 반복된다.
문제점은 작업의 동적할당을 위해서는 작업을 배열의 형태로 만들어야 하고 이 배열은 Map의 이전단계의 출력값으로부터 경로 인자를 통해 전달받아야 한다.
즉, 이 배열은 전 단계 출력 페이로드안에 들어있어야 하기 때문에 최대 페이로드 크기인 256KB의 제한을 받는다.
아이템의 크기가 크면 리스크에 많이 넣을 수 없고 아이템의 크기가 작더라도 리스트가 커지다보면 256KB보다 커질 수 있기 때문에 상한이 존재한다.
해결 방법 : 순환 구조
전체 작업을 처리 가능한 크기의 작업으로 분할하여 반복실행을 통해 순차적으로 처리하는 방식이다.
예를 들어, 전체적으로 만 개의 작업을 처리해야 한다. 한 페이로드에는 천개의 작업을 넣을 수 있다.
순한 구조로 반복을 통해 천개씩 순차 처리를 한다.
이런식으로 페이로드에 들어갈 작업리스트의 크기를 제한할 수 있다.
3. 외부 서비스 통합
문제점 :
이미 다양한 AWS 서비스를 통합할 수 있다. 하지만 AWS 클라우드 환경이 아닌 다른 서비스와 같이 외부환경의 통합이 필요한 경우가 있다.
제일 쉬운 방법은 람다를 활용하는 것
이를 동기적으로 해결할 수 있다면 문제없지만 통신 시간이 길어져 비동기적인 처리가 필요한 경우가 있다.
해결 방법 : Activity
- 상태머신이 Activity 작업을 생성하고 대기하면
- 추론 서비스가 이 작업을 가져고 처리한 후
- 완료 상태로 바꾸고 작업의 성공을 전달
- 상태머신이 결과를 받고 실행을 재개한다.
4
