Loading
2022. 10. 31. 10:53 - lazykuna

AWS Step Functions

Step Functions는 workflow 서비스 중 하나입니다. (workflow 프레임워크에 대해서는 이미 전에 포스트를 작성한 적이 있어서 여기서는 생략합니다)

이미 Step Functions들에 대해서는 AWS 공식 문서를 비롯하여, 너무나 좋은 글들이 많이 있습니다. 여기서는 제 관점에서 정리한 내용을 적어 둡니다.

1. AWS Step Function 이란?

AWS의 여러 컴퓨팅 자원들(Lambda 등)을 일련의 단계(Step)로 구성하고, 이러한 워크플로우를 통해 컴퓨팅 자원을 활용할 수 있게 해주는 서비스입니다.

이러한 서비스가 필요한 이유는 바로 여러 컴퓨팅 자원들(Lambda들)을 쉽게 활용할 수 있게 해주기 때문입니다. 이를테면, 어떤 Request 가 들어왓을 때, 1차로 Lambda1 에서 처리하고, 여기에서 나온 결과값을 Lambda2 에 처리하여 나온 최종 Response 를 돌려주도록 하는 일을 AWS Step Function로 쉽게 만들 수 있습니다.

  • 즉 값을 적절하게 전달해주는 역할을 한다고 볼 수 있습니다. (실제 처리는 각 서비스들이 함)
  • 더불어서 AWS 컴퓨팅 자원들은 대부분 클라우드에 있으니, 클라우드의 이점을 십분 그대로 활용할 수 있다는 장점이 있습니다. (Scability 등)

입/출력 그리고 상태

Step Function이 구체적으로 어떻게 작동되는지까지 아키텍쳐화 된 문서는 없지만, 핵심이 되는 입출력 처리 문서에서 이를 어느정도 유추해 볼 수 있습니다.

  • State Input: JSON 정보이며, 전달될 입력 값/필터(InputPath), 결과 값/필터(ResultPath) 등의 정보를 담고 있습니다.
  • 위에 보이는 것처럼 실질적인 작업은 AWS 컴포넌트가 수행하게 됩니다. (Lambda 등)
  • 대개 이러한 신뢰성 있는 메시지를 전달해야 할 경우 메시지 큐(MQ) 를 많이 쓰는데, 정확한 내용은 없으나 여기도 마찬가지일 것으로 생각됩니다. 재미있는 점은 메시지 별 크기 제한(약 256Kb)이 있다는 것인데, 아마 이와 관련된 제약사항이 아닐까 싶습니다. #참고
  • 해당 작업은 멱등성(Idempotent)있게 수행될 수 있어 이를 감안해야 합니다. 자세한 건 아래 문맥 참고.

결국 workflow는 여러 step들로 구성되어 있고, 각 step은 state를 가지고 있습니다. 현재 step과 state를 기반으로 새 state와 다음 step를 계산하고, 이를 반복하여 결국 마지막의 Step 까지 도달하여 나온 마지막 State Output이 workflow의 최종 결과로 전달됩니다.

idempotence

클라우드 서비스들이 으레 그렇듯이, 이 서비스도 멱등성(Idempotent) 문제에 도달하고 있습니다. 본디 CAP 이론과도 관련이 있으나 여기서는 따로 다루지는 않고…

Step Functions는 여기서 몇 가지 사용할 수 있는 옵션을 주고 있습니다. 단일 실행을 위한 표준 워크플로우, 최소 한번의 실행을 보장하는 비동기 익스프레스, 최대 한번만의 실행을 보장하는 동기식 익스프레스 등의 옵션이 존재합니다. 내부 구현이 어떻게 되어있는지는 찾지 못했으나,

Timeout 및 로깅

으레 그렇듯이 복잡한 워크플로우들은 예기치 못한 타임아웃을 항상 고려해야 합니다. Step Functions는 물론 이에 대한 기능을 제공하고 있어, 워크플로우가 예상치 못하게 늘어질 경우 timeout 시킬 수 있습니다. 또한 관련된 정보를 로깅하여 이후 조회할 수도 있습니다.

UI

매 Step의 정의를 Json으로 하고는 있지만, 이것들을 모두 합친 거대한 DAG 형태의 Workflow를 텍스트로 보는 것은 꽤 괴로운 일이 될 것입니다. 심지어는 잘못 짤 위험도 있습니다! 그래서 workflow를 GUI로 작업할 수 있다는 점은 상당히 좋은 아이디어라는 생각이 듭니다.

2. 다른 workflow들과의 차이점은?

다른 workflow들이 많이 존재하는 상황에서 간단하게 비교를 해 보았습니다.

vs. Apache Airflow

둘 다 workflow를 수행하며, step과 state로 구성되어 있다는 점은 동일합니다. 또한 우수한 UI로 쉽게 사용할 수 있는 점 또한 동일합니다. 다만 몇 가지 소소한 차이가 있습니다.

  • Step Function은 AWS에서 제공하는 서비스인 만큼 scalability/durability 문제에서 굉장히 자유로운 반면, Airflow는 세팅에 어느 정도 신경을 써야 할 필요가 있습니다.
  • 비용 측면에서: Step Function은 사용한 만큼 비용이 청구되는 반면, Airflow는 deploy에 비용이 들어가는 구조입니다.
  • Step Function은 step의 정의가 json으로 되어 있는 반면, airflow는 python으로 되어 있습니다. 개인적 의견이지만, 어떻게 보면 airflow쪽이 더 자유롭기도 하지만, 그만큼 더 복잡해 보인다는 인상이 없잖아 있기도 합니다.

vs. AWS DataFlow

Step Function이 훨씬 일반적인 workflow 프레임워크이기 때문에, 사실 DataFlow로 처리할 수 있는 작업은 Step Function으로도 다 할 수 있습니다. 하지만 S3/EMR/DynamoDB/RDS/NoSQL 등의 DataSource to DataSource 작업을 수행할 경우, DataFlow가 훨씬 작업을 편리하게 할 수 있겠죠.

더 볼만한 자료들