들어가며

---

안녕하십니까. GS네오텍 황성영입니다.

이번 리인벤트 2019에서는 Step Functions 서비스에도 업데이트가 있었는데요. 내부적으로 Express Workflows 라는 이름의 타입이 새로 등장했습니다. 설명에 따르면 많은 처리량의 작업을 단기간​에 수행하는데 적합한 타입이라고 하는데요.

과연 그 정체가 무엇인지. Express Workflows 타입 소개와 함께 간단한 데모를 다뤄보도록 하겠습니다.

Standard Workflows vs Express Workflows

---

아시다시피 Step Functions은 시각적 워크플로를 사용하여 분산 애플리케이션과 마이크로 서비스 구성 요소를 손쉽게 조정할 수 있게 해주는 완전 관리형 서비스 입니다. 기존 Type인 Standard Workflows 에서는 기계 학습, ETL 작업과 같은 지속 시간이 긴 워크로드를 주로 처리해왔습니다. 하지만 스트리밍 데이터 처리, IoT 데이터 수집, 모바일 백엔드 등 단기간 이벤트 발생률이 높은 워크로드를 처리하는데 있어서는 일부 제약사항이 존재했는데요. 보다 엄밀하게 말하면 제약사항이라고 하긴 뭐하고, 서비스 컨셉에 완전히 부합하지 않는다라는 표현이 더 정확할 것 같네요.

아무튼 항상 사용자에게 다양한 선택지를 주는 AWS 답게 동일 서비스 내에서 새로운 타입을 출시했습니다. 기존 Step Function의 기능은 Standard Workflow로 분류하고, 무언가 짧고 집중적인 워크로드에 적합한 유형(Express Workflow)을 새로 내놨죠. 두 타입의 특징을 비교하면 아래와 같습니다.

표에서 말하는 Express Workflow의 특성을 정리하면

• ​단기간 대량의 이벤트 처리용
• ​과금 기준은 실행 횟수와 사용 되는 메모리 양
• 실행 로그를 CloudWatch Logs에서 확인 가능 
  
• Step Function Activities 미지원

좀 더 자세한 사항은 링크​를 참고하세요.

Express Workflows 구성 데모

---

이번에는 데모를 통해 간단한 흐름을 살펴보도록 하겠습니다. 전체 시나리오는 Base64로 인코딩된 문자열을 SQS에 보내면 각각의 람다에서 디코딩, 단어 분류, 카운트를 하는 작업을 수행하는 내용입니다.

관련 프로젝트 내용은 다음 링크​를 참고하시면 됩니다.
 

먼저 상태 머신을 생성 하면 위와 같이 2가지 옵션 중 하나를 선택해야 합니다.

샘플 프로젝트 중에서 새롭게 추가된 Process high-volume messages from SQS을 선택하겠습니다.

CloudFormation 템플릿을 통해 프로젝트에 필요한 리소스들을 생성합니다.

상태 머신이 생성되면 Type이 Express인 것을 확인 할 수 있습니다. 바로 실행해보도록 하겠습니다.

해당 머신을 클릭하면 Logging 메뉴가 있습니다. 클릭하면 위와 같이 작업이 완료된 것을 확인할 수 있습니다.

특정 로그를 클릭하면 CloudWatch Log Groups에서 상세 로그를 확인 할 수 있습니다.

▨ Standard / Express Workflow 유형 비교​

새로 나온 유형을 테스트하기(기존 유형과 대비되는 모습을 보여주기) 위해서는, 이를테면 State 변경이 매우 빈번하거나 기존의 Standard Workflow의 limit값이 제약이 될만한 상황을 구성할 필요가 있는데요. 그런 상황을 구성하기가 쉽지 않았습니다. 따라서 동일한 샘플 시나리오를 기반으로, 하나는 Standard 다른 하나는 Express Workflow로 구성해서 간단한 차이점을 살펴보도록 하겠습니다.

앞의 표에서 보여드린 것처럼 Express 모드의 경우 실행 히스토리를 CloudWatch Logs에서 확인해야 합니다.(Step Function Activity 미지원)​ 아무래도 엔트리가 더 복잡하고 개수가 많기 때문에 CloudWatch와 결합하여 정보를 제공한다는 생각이 드네요. 전체 Flow가 완료되는데 약 0.15초 정도의 시간이 소요되는 것을 확인할 수 있습니다. ​

동일한 로직을 Standard 모드에서 실행해봤습니다. Step Function의 Activity 항목에서 관련 상세를 확인할 수 있었습니다. 전체 작업에 소요되는 시간은 0.5~0.6초 정도네요. 실행 시간은 단순히 Express 모드가 빠르고 Standard 모드가 느리다기 보다는 내부에서 처리하는 구조가 다르고, 그 차이에 따라 이런 편차가 생길 수 있다는 관점에서 이해하는게 더 맞는듯 합니다.

데모를 마칩니다.

마무리

---

오늘은 Step Function 서비스에 새로 나온 유형에 대해 살펴보았습니다.

Step Function은 상태값을 기반으로 여러 AWS 서비스를 복합적으로 오케스트레이션할때 활용할 수 있는 서비스입니다. 서버리스 기반이기 때문에 관리가 쉽고, 로깅이나 API 권한 연계도 기존 AWS 서비스와 잘 융화되어 있기 때문에 효용이 높습니다.

새로 나온 유형은 STEP Function을 사용할 수 있는 모든 리전에서 사용할 수 있습니다. 아무래도 실제 활용 사례나 이런 부분은 앞으로 지속적으로 관심을 갖고 확인해 봐야 할듯 싶네요.

 

포스팅을 마칩니다. 끝!