골드에그

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

개념

인프라 구축을 코드형 인프라(IaC) 로 구성할 수 있도록 괸리된 환경에서 배포해주는 서비스

• 지정된 사용자가 원하는 서비스를 골라 프로비저닝
• 해당 서비스에 다양한 Action 들까지 제공
• CloudFormation 으로 구성
• 내부적으로는 Systems Manager Automation 사용

구조

AWS Service Catalog 는 제품, 포트폴리오으로 구성되어 있다.

제품

• 엔드유저에게 제공할 미리 구성된 AWS 인프라
• 각 제품 별 버전 설정 가능
• 신규 버전 생성 시 서비스 액션 역시 다시 연동 필요
• CloudFormation Output 으로 엔드유저에게 정보 제

포트폴리오

• 다양한 제품을 모은 관리 단위
• 그룹/역할/사용자에게 해당 포트폴리오를 이용할 수 있는 권한 부여 가능
• 다른 계정과 공유 가능
• AWS Budget 생성 가능 (Tag 기반)

제약조건

• 사용자가 제품을 프로비전할 때 사용하는 권한
• 사용자가 권한을 가지고 있지 않더라도 제품을 생성하는데 필요한 권한 부여 가능
• 반대로, 사용자가 충분한 권한을 가지고 있어도 제품을 생성 및 사용하는데 제약할 수 있는 권한 부여 가능
• = > 즉 사용자의 권한을 가지고 프로비저닝을 하는 것이 아니라 제약 조건에 명시된 권한으로 프로비저닝
• 서비스 액션 등에도 제약 조건 권한 사용 가능
• IAM 정책 기반
• 아래 유형의 권한으로 구성
  • 시작
  • 알림
  • 템플릿
  • StackSet
  • 태그 업데이트

서비스 액션

• 앤드유저가 제품을 프로비전 후, 제품을 제한적으로 관리하는 방법
• 각 액션 수행 후 이벤트 로그를 통해 수행 결과 확인 가능
• 내부적으로는 Systems Manager Automation 사용

서비스 카탈로그 실습

1 . AWSServiceCatalogEndUserFullAccess 정책 가진  enduser 사용자를 생성한다.

(서비스 카탈로그에 접근 가능한 접근만 가지고 있다.)

2 . enduser 사용자가 사용할 제약조건 역할을 생성한다. 정책 생성 후 역할을 연결!

3 . 서비스 카탈로그에 제품 생성 후, 포트폴리오 생성한다.

4 . 해당 포트폴리오에 enduser 사용자를 추가하고 제약조건 역할을 연결한다.

인프라 관리자가 아니라면, 프로비저닝 하위 항목들만 표시된다. 인프라 관리자가 생성한 항목들만 확인할 수 있다.

삭제 시 주의해야 할 점

포트폴리오 삭제 시 제품과 포트폴리오에 연결된 주체/역할 부터 먼저 삭제해야 함