automation `draft`¶

/usr/local/m2/setting.json 다음 영역에 대해 기술한다.

{
  "functions": {
    "backend": {
      "automation": {
        ...
      }
    }
  }
}

meta¶

"meta" : {
  "enable": false,
  "keyword": "automation"
}

enable (기본: false): 오토메이션 활성화
keyword (기본: automation): 오토메이션 키워드

workflows¶

독립적인 작업단위를 workflow라고 지칭한다.

Note

호출예제

# migrate_tmpimg를 수행한다.
# prepare -> execute -> complete 모두 수행한다.
https://foo.com/automation/workflows/migrate_tmpimg

# migrate_tmpimg를 수행한다.
# 세부 step을 비활성화할 수 있다. 아래 호출은 execute만 수행하며 이때 변수를 /vars/ 로 주어진다.
https://foo.com/automation/workflows/migrate_tmpimg/steps/prepare=false;complete=false;/vars/src_path=/tmp/source1.jpg;dest_path=/newdir/source1.jpg

"workflows": [
  {
    "name": "migrate_tmpimg",
    "description": "Migrate files from /tmp to /newdir",
    "enable": true,
    "allowApiExecution": false,
    "vars": null,
    "steps": { },
    "throttling": { }
  },
  {
    "name": "remove_old",
    ...
  }
]

name: 워크플로우 이름
description: 워크플로우 설명 (주석)
enable (기본: true): 워크플로우 활성화
allowApiExecution (기본: false): 워크플로우 클라이언트 호출허가
vars: 워크플로우 전역 변수. 모든 playbook의 vars 로 전달되며 세부 단계에서 동일한 이름이 있다면 덮어쓰기 된다.

steps¶

workflow 수행의 세부단계를 지정한다.

"steps": {
  "prepare": { },
  "execute": { },
  "complete": { }
}

prepare: 작업 준비단계
execute: 작업 실행. 병렬처리된다.
complete: 작업 완료. 주로 결과취합 및 임시파일 삭제등에 사용된다.

prepare¶

"prepare": {
  "schedule": "0 1 * * *",
  "playbook": "workflows/prepare_file_to_migrate.yml",
  "vars": null,
  "leaderElection": {
    "type": "file",
    "path": null,
    "authEndpoint": null
  }
}

schedule

polling 스케쥴. cron 형식

playbook

수행할 playbook 파일

vars

변수

leaderElection

리더선출 구성

See also

분산 병렬처리 의 배치 처리 참고

type (기본: file)

락 파일 생성 타입

file 마운트된 공용 스토리지
aws-s3 AWS-S3

path

락 파일 전체 경로. 만약 디렉토리로 / 표현으로 끝나면 {workflow.name}.txt 파일로 생성된다.

authEndpoint

인증이 필요한 백엔드와 연결할 경우 {endpoint}@{function} 형식으로 설정한다. 예를 들어 AWS S3를 연결한다면 aws_s3 에 엔드포인트를 먼저 구성한 뒤, 해당 구성을 사용하는 방식이다.

# aws_s3에 설정된 mystorage라는 endpoint를 사용한다.
"authEndpoint": "mystorage@aws_s3"

Warning

클라이언트로부터의 직접 호출시 prepare 단게는 기본 비활성화되어 있다.

작업목록(URL 리스트)를 작성한다.

example.com/automation/workflows/migrate_tmpimg/vars/src_path=/tmp/source1.jpg;dest_path=/newdir/source1.jpg
example.com/automation/workflows/migrate_tmpimg/vars/src_path=/tmp/source2.jpg;dest_path=/newdir/source2.jpg
example.com/automation/workflows/migrate_tmpimg/vars/src_path=/tmp/source3.jpg;dest_path=/newdir/source3.jpg

Note

작업목록 작성을 위해 항상 /workflow/ 하위의 임시 .txt 파일이 {{prepare_path}} 로 주어진다.

---
- name: prepare for sample worflow
  hosts: localhost
  gather_facts: no
  vars:
    prepare_path: /workflow/migrate_tmpimg-6e1ed0a7-ed29-47ff-83ed-a92ca5a766e7.txt

...

execute¶

개별 작업으로 throttling 이 활성되어 있다면 CPU 사용량이 확보될 때만 작업이 수행된다.

"execute": {
  "playbook": "playbooks/file_migration.yml",
  "timeout": 180,
  "vars": null
}

playbook: 수행할 playbook 파일
timeout (기본: 180초): 최대 수행시간
vars: 변수

Note

개별 작업의 트랜잭션이 완료되는 시점에 메트릭과 로그가 반드시 집계되어야 한다. 이는 아래 표준 가이드를 따른다.

complete¶

모든 작업이 완료된 상태에서 수행된다.

"complete": {
  "playbook": "playbooks/callback_api.yml",
  "timeout": 60,
  "vars": null
}

playbook: 수행할 playbook 파일
timeout (기본: 60초): 최대 수행시간
vars: 변수

vars 에는 모든 execute 의 결과가 요약되어 주어진다.

`vars`	설명
`{{_request_total}}`	execute 수행 회수
`{{_complte_total}}`	수행 성공
`{{_fail_total}}`	수행 실패
`{{_src_size_total}}`	소스파일 크기
`{{_dest_size_total}}`	대상파일 크기

throttling¶

CPU 가용량에 충분한경우에만 워크플로우를 수행한다.

"throttling": {
  "enable": true,
  "cpu": {
    "deactive": 60,
    "reactive": 40
  }
}

enable (기본: true)

throttling 을 활성화한다.

cpu

평균 CPU 사용량에 따라 동적으로 워크플로우를 수행한다.

Note

평균 cpu 사용량 기준은 전역으로 변경이 가능하다.

deactive (기본: 60, 범위: 0 ~ 100): 평균 CPU 사용량이 설정 값 이상이라면 부하를 낮추기 위해 수행을 잠시 중단한다.
reactive (기본: 40, 범위: 0 ~ 100): ( deactive 상태에서) 평균 CPU 사용량이 설정 값 미만이라면 다시 수행을 재개한다.

Note
reactive 값이 deactive 값을 초과하거나 유효 범위가 아니라면 deactive 의 2/3 수치로 적용된다.

분산 병렬처리¶

멀티 노드 분산구조를 통해 경제적이면서 안정적인 서비스 구축이 가능하다.

실시간 처리¶

실시간 처리는 개별 HTTP 트랜잭션 단위로 수행되기 때문에 prepare , complete 단계가 불필요하다. 워크로드는 L4나 ALB(AWS Load Balancer)등 L/B(Load Balancer)로부터 균등 분산되는 경우가 일반적이다.

대표적으로 AWS S3 PutObject 시 이미지 최적화 분산처리가 대표적인 사례이다.

배치 처리¶

배치 처리는 계획 -> 수행 -> 완료(보고)의 단계로 계획된 작업으로 명확한 작업 주체에 의해 관리된다.

단계	작업 주체
prepare	`master` 노드
execute	모든 노드
complete	`master` 노드

Note

master 노드는 workflows 당 유일하며, 락 파일(Lock file) 기반 리더선출 알고리즘을 사용한다.

../../../../_images/automation3.png — Master노드와 직접 통신으로 작업이 분배된다.¶

위 그림처럼 모든 노드는 master 노드로부터 작업을 분배받는 방식으로 병렬처리가 이루어진다. 개별 노드는 자신의 부하 throttling 정책을 감안하여 작업을 분배받는다.

Warning

master 유지와 장애처리

master 노드가 없다면 모든 노드는 투표를 통해 master 를 선출한다.
master 노드는 지속적으로 임기(기본: 5분)를 연장한다.
master 노드 장애시 임기동안은 작업이 중단된다.
임기가 만료된 상태에서 master 노드가 없다면 1번 단계를 수행한다.

automation draft¶

meta¶

workflows¶

steps¶

prepare¶

execute¶

complete¶

throttling¶

분산 병렬처리¶

실시간 처리¶

배치 처리¶

automation `draft`¶