안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Solving the Observability Mystery with AWS Step Functions]을 확인해보시기 바랍니다.

Solving the Observability Mystery with AWS Step Functions

AWS Step Functions를 활용한 대규모 데이터 처리 워크플로우 구축과 관측 가능성(Observability) 개선 방법에 대해 소개합니다.

1. 세션 소개 및 아젠다 개요

1-1. 발표자 소개

• Pavan: Principal Serverless Specialist로 활동하고 있습니다.
• Diego: AWS Step Functions 팀의 Principal Engineer로 근무하고 있습니다.
• 본 세션에서는 Step Functions 기반 관측 가능성(Observability) 심화 내용과 신규 출시된 CloudWatch 지표(Metrics)에 대해 소개합니다.

1-2.청중 현황 파악

• Step Functions를 프로덕션 환경에서 사용 중인 인원을 확인합니다.
• Step Functions 사용 경험이 없는 인원을 확인합니다.

1-3. 세션 아젠다 개요

• Step Functions를 이용해 구축을 시작하는 방식을 소개합니다.

• 복잡도 증가에 따른 디버깅 및 운영 관점에서의 관측 가능성을 논의합니다.
• 총 4개의 데모 시연을 통해 내용을 진행할 예정입니다.
  - 대규모 데이터 분석 워크플로우
  - 신규 CloudWatch 지표 기반 관측
  - 상태 전환(State Transition) 한도 모니터링
  - 크로스 계정 통합 시 권한 문제 진단

2. 데모 1: 대규모 데이터 분석 워크플로우 구축 (풍속 데이터 분석)

2-1. 데이터셋 및 준비 과정

• 사용 데이터셋
  - 전 세계 기상 관측소의 풍속 데이터를 포함한 오픈 소스 데이터셋을 사용합니다.
  - 파라미터에는 평균 온도, 이슬점, 기압 등이 포함됩니다.
  - 데모에서는 풍속 데이터에 집중합니다.
• 데이터 저장 구조
  - 제공된 명령어를 사용하여 S3 버킷에 데이터를 복사할 수 있습니다.
  - 연도(year) → 관측소 ID(station ID) 형태의 파티션 구조로 저장합니다.
  - 1929년부터 2024/25년까지의 데이터가 포함됩니다.
  - 각 파일에는 관측소 ID, 날짜, 위도/경도 및 다양한 지표가 포함됩니다.
• 최종목표
  - 전 세계 관측소의 평균 풍속을 보여주는 대시보드를 구축하는 것이 목표입니다.

2-2. Step Functions Distributed Map 구성

• Step Functions 콘솔 접속 및 상태 머신 생성 
  - 상태 머신 이름은 "wind speed analysis"로 설정합니다.
  - 유형은 Standard Workflow를 선택합니다.
  - Step Functions를 처음 접하는 사용자를 위해 콘솔에서 Amazon State Language(ASL)를 기반으로 시작할 수 있는 방법을 제공합니다.
• Distributed Map 상태 추가 및 구성
  - Map State를 추가하고 이름을 DMAP으로 설정합니다.
  - 목적은 S3에 저장된 약 60만 개 객체(약 70GB)를 처리하는 것입니다.
  - 처리 모드는 Distributed로 설정합니다.
  - 데이터 소스는 S3 object list를 사용합니다.
  - Parquet 및 Athena manifest를 지원합니다.
  - 배치 크기는 500개 객체 단위로 처리합니다.
  - 동시성 제한은 기본값인 1,000을 유지합니다.
  - 허용 실패율이 5%를 초과하면 워크플로우가 실패합니다.
  - 출력 경로는 S3 → prefix: demo 로 저장합니다.
• 분산 맵 내부 비즈니스 로직 구성
  - Map 단계에서는 Lambda(analysis function)를 사용하여 개별 객체를 처리합니다.
  - Reduce 단계에서는 Lambda(producer function)를 사용하여 결과를 통합합니다.
  - 단위 변환(노트 → mph)은 별도 Lambda로 처리합니다.
  - Step Functions의 math expression을 사용하면 비용과 성능을 최적화할 수 있습니다.
• 권한 설정
  - Step Functions가 필요한 IAM 권한을 자동으로 제안합니다.
  - 권한을 확인(Confirm)한 후 상태 머신 생성을 완료합니다.

2-3. 워크플로우 실행 및 결과 확인

• 실행 과정
  - 입력 없이 실행(Start)합니다.
  - 실행은 Pending → Running 순으로 진행합니다.
  - 전체 실행에는 약 2분 15초가 소요됩니다.
  - 반복(iteration)은 각각 독립 실행으로 분기되므로 대규모 병렬 처리가 가능합니다.
• 관측 요소
  - 실행 분산(Dispatching) 진행 상황을 확인합니다.
  - 실패율을 지속적으로 모니터링합니다.
  - 비동기 처리 특성상 반복 실행 지연 원인은 가시성이 부족할 수 있습니다.
• 결과 확인 및 실패 처리
  - S3 demo prefix에 결과 CSV 파일이 생성됩니다.
  - QuickSight 등을 활용해 추가 분석이 가능합니다.
  - 실패 파일(Failure file)이 별도로 생성되며, 이를 통해 재실행(re-drive)이 가능합니다.

3. 데모 1 Q&A

3-1. 동시성 제한과 Lambda 실행 기회

• 질문: Step Functions 동시성 1,000 설정 시 Lambda 계정 한도(1,000)를 초과하면 다른 Lambda가 실행 가능합니까?
• 답변: step Functions는 스로틀링을 감지한 후 백오프와 재시도 처리를 수행합니다.
• 추가정보: Lambda 동시성은 Soft Limit이며, Support 요청을 통해 즉시 상향이 가능합니다.

4. 데모 2: 관측 가능성 향상 - 신규 CloudWatch 지표

4-1.  비동기 실행의 가시성 확보

• 기존 문제
  - 분산 맵 실행이 비동기 방식으로 동작해 실패 원인을 파악하기 어렵습니다.
• 해결책 
  - AWS는 고객의 피드백을 반영하여 새로운 CloudWatch 지표를 출시했습니다.
• 새로운 지표 항목
  - 열린 실행 제한(Open Execution Limit): 계정에서 허용한 동시 열린 실행의 최대치를 의미 합니다.  
  - 현재 열린 실행 수(Current Open Execution Count): 특정 시점에 실제로 실행 중인 수를 의미 합니다. 
  - 백로그(Backlog): 시작하려는 맵 실행이 제한으로 인해 시작되지 못하고 대기 중인 규모를 의미 합니다.  
• 백로그의 중요성
  - Step Functions는 스로틀링이 발생해도 실행을 실패시키지 않고 미래에 실행되도록 예약함. 백로그 크기를 알아야 전체 완료까지 얼마나 걸릴지 예측이 가능합니다. 

4-2.  CloudWatch 기반 시각화

• 로드 테스트 설정
  - 발표자는 별도의 로드 테스트 Lambda 함수를 사용하여 열린 맵 실행 수(open map run count)를 시뮬레이션합니다.
• 지표 모니터링 대시보드
  - Open Map Run Limit
  - Current Open Map Run Count
  - Map Run Backlog Size등을 통해 실행 상태를 모니터링합니다.
• 백로그 알람 설정
  - Backlog 증가 시 알람을 설정하는 것이 모범 사례로 제시됩니다.
  - Backlog 지표는 Backlog가 실제로 발생할 때에만 게시됩니다.

5. 데모 2 Q&A

5-1.  S3 파일 대량 처리 시 Lambda 호출 제한 문제

• 질문
  - 60만 개 파일 처리 시 Lambda 비동기 호출 제한(1,000)을 어떻게 우회합니까?
• 답변
  - Step Functions는 **배치 페이로드(500개)**를 Lambda에 전달합니다.
  - Lambda 호출 자체는 함수별 제한을 따릅니다.
  - 스로틀링이 발생하면 재시도 및 백오프가 적용됩니다.
  - S3 API 호출에서 발생하는 스로틀링도 동일한 패턴으로 처리할 수 있습니다.

6. 데모 3: 상태 전환(State Transition) 모니터링

6-1.  상태 전환 개념 및 제한

• 상태 전환은 실행 시작/완료, 노드 이동, 분산 맵 반복 시작 시 발생합니다.
• 기본 제한은 초당 5,000회(대규모 리전)입니다.
• 제한을 초과하면 429 Too Many Requests가 발생합니다.
• Backoff 전략은 1초 → 2초 → 4초 → 8초 순으로 적용됩니다.
• 오퍼레이터는 실행 지연을 오류로 오해할 수 있으므로 모니터링이 필요합니다.

6-2.  상태 전환 지표 분석

• CloudWatch 지표
  - Bucket Size
  - Refill Rate
  - Consumed Capacity
  - Throttle Events
• 주의 사항
  - CloudWatch 지표는 분 단위로 게시되며, 제한은 초 단위이므로 시차가 존재합니다.
• 기여도 분석
  - Execution Throttled 지표를 활용하여 어떤 상태 머신이 스로틀링을 유발했는지 분석할 수 있습니다.
  - 위젯 hover 시 상위 기여 실행을 확인할 수 있습니다.
• 대응
  - 실패가 아닌 지연이므로, Service Quotas에서 한도 상향을 요청하면 복구가 가능합니다.

6-3.  상태 전환 Q&A

• 대규모 리전 기본 제한: 5,000 TPS
• 소규모 리전 기본 제한: 800 TPS
• 제한은 계정 단위(shared)로 적용됩니다.
• 상태 전환 지표를 활용하면 문제 원인을 파악하고 복구하기 용이합니다.

7. 데모 4: 크로스 계정 통합 – 권한 문제 진단 및 해결

7-1.  크로스 계정 통합의 작동 방식과 문제 발생 지점

• 통합 시나리오: 부모(Parent) 상태 머신이 다른 계정의 중첩된(Nested) 상태 머신을 호출하는 경우입니다.
• 동일 계정 시: Step Functions는 EventBridge에 관리형 규칙(managed rules)을 생성하여 중첩 실행 완료 이벤트를 수신하고 부모에게 알림으로써 자동으로 진행됩니다.
• 크로스 계정 시: 부모 상태 머신은 다른 계정의 이벤트를 직접 읽을 수 없으며, 해당 실행의 상태를 폴링(polling)하여 대기합니다.
• 문제 상황: 부모가 자식 실행 시작을 알리는 성공 응답만 받고 대기 상태에 머무르는데, 자식이 완료되었음에도 부모가 계속 대기하는 상황이 발생합니다.

7-2.  제품 리뷰 분석 시나리오 설정 

• 중앙 계정 워크플로우(부모)
  - 제품 리뷰 입력(ID, 설명, 리뷰 텍스트)을 받아 Bedrock API를 호출하여 리뷰가 가짜인지 분석합니다.
  - 가짜 리뷰일 경우 별도 로직으로 처리하고, 실제 리뷰일 경우 우회하는 구조입니다.
• 다른 팀의 재사용(자식)
  - 다른 팀이 동일한 워크플로우를 다시 구축하는 대신, 크로스 계정 호출을 사용하여 부모 워크플로우에서 자식 워크플로우를 호출합니다(예: StartExecution 또는 Run a Job 사용).
• 필수 권한 설정(역할 신뢰 관계)
  - 각 상태 머신은 고유한 역할(Role)을 가지며, 크로스 계정 호출을 위해 신뢰 관계(Trust Relationship)를 설정해야 합니다.
  - 부모 계정 역할은 자식 계정의 역할(Child Account Role)을 Assume Role할 수 있는 권한이 필요합니다.
  - 자식 계정 역할은 부모 계정의 Principal로부터 역할 가정을 허용해야 하며, 혼동된 수임자(Confused Deputy) 문제 방지를 위해 조건부 속성(Conditional Attribute)을 전달하여 특정 계정/상태 머신에서만 호출되도록 제한해야 합니다.
• 실제 데모 설정
  - 부모 계정 상태 머신이 자식 워크플로우를 호출하며, 대상 역할 ARN(Target Role ARN)을 지정하여 크로스 계정 호출을 수행합니다.
  - 자식 워크플로우는 Bedrock API를 호출하고 리뷰를 분류하는 로직을 포함합니다.

7-3.  크로스 계정 호출의 내부 메커니즘과 권한 문제 발생 

• 역할 체이닝(Role Chaining)
  - Step Functions는 역할 체이닝을 통해 크로스 계정 지원을 구현합니다.
  - 부모의 실행 역할(Execution Role)이 자식 계정의 역할을 가정(Assume)하고, 해당 자격 증명으로 API 호출을 수행합니다.
  - 이 역할 체이닝은 소스 계정(부모)에서 이루어지며, 대상 계정은 Step Functions를 통해 호출되는지 알 필요가 없습니다.
• 문제 재현
  - 부모 워크플로우를 실행하면, 자식 워크플로우는 입력(ID, 리뷰 텍스트 등)을 받아 성공적으로 완료합니다.
  - 하지만 부모 워크플로우는 계속 실행 상태(still showing in an execution state)로 남아있습니다.
  - 동일 계정과의 차이: 동일 계정에서는 EventBridge 관리형 규칙을 통해 즉시 알림을 받지만, 크로스 계정에서는 폴링을 통해 상태를 확인해야 합니다.
• 권한 문제 진단(CloudTrail 활용)
  - 문제: 부모가 자식 계정의 상태를 확인하려 하지만 접근 거부(Access Denied) 오류가 발생합니다.
  - 진단 도구: CloudTrail을 확인하여 원인을 찾습니다.
  - 필터링: 소스(State), 지난 30분, 이벤트 이름(DescribeExecution)으로 필터링합니다.
  - 결과: Describe Execution API 호출에 대해 Access Denied가 확인됩니다.

7-3.  권한 수정 및 복구 매커니즘

• 필요 권한
  - 자식 계정의 역할(Child Role)에는 현재 StartExecution 권한만 있습니다.
  - 추가 필요 권한: Describe Execution 및 Stop Execution 권한을 추가해야 합니다.
  - Describe Execution의 역할: 이 권한은 입력/출력 및 상태 정보를 확인하는 데 필요합니다.
  - Stop Execution의 역할: 부모 실행이 중단되거나 실패할 때 자식 실행도 중단시키고자 할 때 필요합니다. (Step Functions는 최선의 노력으로 중단을 시도합니다.)
• 복구 과정
  - IAM 역할을 업데이트한 후 재시도하면, Step Functions는 백오프 간격에 따라 새로운 자격 증명으로 폴링을 재시도합니다.
  - 다음 시도에서 성공: 권한이 수정되었으므로 Describe Execution 호출이 성공하고, 대기 중이던 부모 실행이 완료됩니다.
  - 폴링 속도 조절: 첫 폴링 간격(1분)이 너무 길다면, 지원팀에 요청하여 10초까지 단축할 수 있으나, 너무 빠르게 폴링하면 폴러 자체에서 스로틀링이 발생할 수 있으므로 주의해야 합니다.
• 동일 계정 vs 크로스 계정 알림 방식 비교
  - 크로스 계정: 폴링(Polling)만 사용하며, 권한 문제 발생 시 지연됩니다.
  - 동일 계정: EventBridge의 관리형 규칙을 통해 이벤트가 즉시 전달되므로 더 빠릅니다.
• 대안: Wait for Task Token 지원
  - 질문: Wait for Task Token을 지원하는지 여부
  - 답변: 지원합니다. 사용자가 직접 토큰을 제어하고 최종 상태에서 콜백할 수 있습니다.
  - 단점: 자식 워크플로우를 수정할 수 없는 경우에는 사용할 수 없으며, 수정 가능하다면 더 빠른 완료 방법이 될 수 있습니다.

8. 세션 마무리 및 자료 공유

8-1.  대모 자료 공유

• 세션에서 사용된 모든 데모는 GitHub 링크를 통해 공유되며, QR 코드를 스캔하여 접근할 수 있습니다.

8-2.  컴퓨트 블로그

• Step Functions의 새로운 출시, 확장성 관련 모범 사례 등은 컴퓨트 블로그에 게시됩니다.

8-3.  성능 최적화 요약

• 더 빠르게 실행하려면 배치 크기를 늘리거나 동시성을 증가시킬 수 있습니다.
• 단, 스로틀링이 발생하면 지연될 수 있으므로, 최근 출시된 분산 맵 지표를 활용하여 백로그 발생 여부를 확인하고 필요 시 한도 증가를 요청해야 합니다.