[요약 정리] 5-1. 워크플로 관리

5-1. 워크플로 관리

[기초 지식] 워크플로 관리

- 데이터의 흐름을 일원 관리하기

• 워크플로 관리 → 정해진 업무를 원활하게 진행하기 위한 구조

 

워크플로 관리 도구

• 정기적으로 태스크를 실행하고 비정상적인 상태를 감지하여 그것에 대한 해결을 돕는 것

 

워크플로 관리 도구와 태스크

• 태스크 → 데이터 파이프라인의 실행 과정에서는 데이터를 잇달아 이동하면서 정해진 처리를 반복함. 이때 실행되는 개별 처리

 

기본 기능과 빅데이터에서 요구되는 기능

• 워크플로 관리 도구의 기본 기능
  • 태스크를 정기적인 스케줄로 실행하고 그 결과 통지하기
  • 태스크 간의 의존 관계를 정하고, 정해진 순서대로 빠짐없이 실행하기
  • 태스크의 실행 결과를 보관하고, 오류 발생 시에는 재실행할 수 있도록 하기
• 하둡에서의 잡을 손쉽게 호출하거나 집계 결과를 데이터 마트에 기록하는 기능을 제공하는 등 데이터 파이프라인의 모든 태스크를 관리하기 쉽게 한것이 빅데이터를 위한 워크플로 관리 도구

 

선언형과 스크립트형 - 워크플로 관리도구의 종류

• 선언형
  • XML이나 YAML 등의 서식으로 워크플로를 기술하는 타입
  • 미리 제공된 기능만 이용할 수 있는데, 그 범위 안이라면 최소한의 기술로 태스크를 정의할 수 있는 특징이 있음
  • 누가 작성해도 동일한 워크플로가 되기 때문에 유지 보수성이 높아짐
  • 동알 쿼리를 파라미터만 바꿔 여러번 실행하거나, 워크플로를 단순 반복적으로 자동 생성하는 경우
• 스크립트형
  • 스크립트 언어로 워크플로를 정의하는 유형
  • 일반적인 스크립트와 동일하게 변수나 제어 구문을 사용할 수 있으므로, 태스크의 정의를 프로그래밍 할 수 있음
  • 스크립트 언어에 의해 데이터 처리를 태스크 안에서 실행하는 것도 가능
• ETL 프로세스에는 스크립트형, SQL 실행에는 선언형 도구 등으로 나누어 사용하는 것도 방법

 

오류로부터의 복구 방법 먼저 생각하기

복구와 플로우의 재실행

• 오류에는 수많은 가능성이 있으므로 기본적으로 워크플로 관리에서는 오류로부터 자동 회복할 수 있다는 점은 고려하지 않음
• 수작업에 의한 복구를 전제한 태스크 설계, 실패한 태스크는 모두 기록하여 그것을 나중에 재실행 할 수 있도록 함
• 워크플로 관리 도구에 의해 실행되는 일련의 태스크 → 플로우
• 각 플로우에는 실행 시에 고정 파라미터가 부여
• 동일 플로우에 동일 파라미터를 건네면 완전히 동일한 태스크가 실행되도록 함 → 나중에 재실행 가능, 복구의 기초

 

재시도 - 여러 차례 반복하는 오류는 자동화

• 태스크 단위의 자동적인 단순한 재실행
• 재시도가 작으면, 장애로부터 복구하기 전에 재시도가 종료해 태스크 실행에 실패
• 재시도가 너무 많으면, 태스크가 실패하지 않은 것처럼 되기 때문에 중대한 문제가 발생해도 눈치채지 못함

 

백필 - 일정 기간의 플로우를 연속해서 실행하는 구조

• 파라미터에 포함된 일시를 순서대로 바꿔가면서 일정 기간의 플로우를 연속해서 실행하는 구조
• 태스크의 실패가 며칠 동안이나 계속된 후에 이를 모두 모아서 재실행하고 싶을 때나 새롭게 만든 워크플로를 과거로 거슬러 올라가 실행하고 싶은 경우 사용
• 대규모의 백필을 실시할 때는 자동적인 재시도는 모두 무효로 하고, 오류는 모두 통지하는 편이 좋음

 

멱등한 조작으로 태스크를 기술하기

- 동일 태스크를 여러 번 실행해도 동일한 결과가 됨

• 각 태스크는 원칙적으로 마지막까지 성공하거나 실패하면 아무것도 남지 않음 둘 중 하나만 존재해야 함

 

원자성 조작

• 각 태스크가 시스템에 변경을 가하는 것을 한 번만 할 수 있도록 하는 것
• 트랜잭션 처리에 대응한 데이터베이스라면, 여러 번의 쓰기를 한 번의 트랜잭션으로 실행할 수 있지만 그렇지 않다면 쓰기가 필요한 수 만큼 태스크를 나누도록 함 → 원자성 조작
• 워크플로에 포함된 태스크를 모두 원자성 있는 조작으로 구현함으로써, 재시도 시의 안정성을 높일 수 있음

 

멱등한 조작 - 추가와 치환

• 동일한 태스크를 여러 번 실행해도 동일한 결과가 되도록 하는 것 → 멱등한 조작
• ex) 테이블을 삭제한 후에 다시 만들기
• 추가를 반복하면 데이터가 중복되지만, 치환은 반복해도 결과가 변하지 않음
• 태스크에 부여된 파라미터를 이용해 고유의 이름을 생성하고, 여러 번 실행해도 항상 치환이 시행되도록 설계

 

멱등한 추가

• 과거의 모든 데이터를 치환하면 멱등하게 되긴 하지만 부하가 커짐
• 테이블을 1일마다 or 1시간마다 파티션으로 분할하고 파티션 단위로 치환

 

※ 태스크 내부에서의 재시도 제어

• 재시도만으로 해결하기 어려운 것이 오류가 어느 만큼 계속되는지 알지 못하는 경우임
• but 예기되는 오류에 대해서는 워크플로 관리 도구의 재시도에 의존하는 것이 아니라 태스크 내부에서 명시적으로 대처해야 함
• 지수 백오프
  • 태스크의 내부에서 재시도를 제어함으로써 오류 발생 그 자체를 회피
  • 재시도 횟수를 늘림과 동시에, 조금씩 재시도 간격을 넓혀나가기 위해서 지수 백오프를 유효하게 함
• 타임아웃
  • 태스크가 아무리 기다려도 끝나지 않는 문제
  • 워크플로 관리 도구측에서 타임아웃을 지정해주기 (SLA)

 

원자성을 지닌 추가

• 추가를 반복하는 것이 아니라 중간 테이블을 만들어 처리한 후, 마지막에 목적 테이블에 한 번에 추가하는 것이 안전함

 

워크플로 전체를 멱등으로 하기

• 각 태스크를 멱등으로 하는 것이 이상적이지만, 필수는 아님
• 추가가 문제시되는 것은 재시도 시에 중복의 가능성이 있기 때문
• 데이터 자체에 문제가 발견되서 수정하는 경우, 멱등한 태스크는 그런 상황에도 안전하게 재실행할 수 있지만, 추가가 포함되어 있으면 그렇게 할 수 없음
• 각 플로우가 전체로서 멱등하게 되도록 구현 → 처음에 중간 테이블을 초기화하는 태스크를 실행하고, 그 다음부터 추가의 태스크 실행

 

태스크 큐

- 자원의 소비량 컨트롤하기

• 태스크의 크기나 동시 실행 수를 변화시킴으로써 자원의 소비량을 조정하여 모든 태스크가 원활하게 실행되도록 함
• 병렬화 고려하기
  • 각 태스크는 파일 서버로부터 파일을 추출하여 압축하고 분산 스토리지로 전송함
  • 파일의 수만큼 태스크를 실행함
  • 잡 큐, 태스크 큐라는 구조 사용 → 모든 태스크는 일단 큐에 저장되고 일정 수의 워커 프로세스가 그것을 순서대로 꺼내면서 병렬화가 실현

 

병목 현상의 해소

• 워커를 너무 증가시키면 어디선가 병목 현상이 발생해서 성능의 향상이 한계점에 도달하거나 오류가 발생하기 시작함
• 워크플로 실행 시 자주 발생하는 문제와 해결(서버의 내부적인 요인)
  • CPU 사용률 100% - CPU 코어수 늘리기, 서버 증설하기
  • 메모리 부족 - 메모리 증설, 스왑 디스크 추가, 태스크 작게 분할
  • 디스크 넘침 - 각 태스크가 임시 파일을 삭제하고 있는지 확인, 디스크 증설
  • 디스크 I/O의 한계 - SSD 등의 고속 디스크 사용, 여러 디스크로 분산
  • 네트워크 대역의 한계 - 고속 네트워크 사용, 데이터 압축률 높임
  • 통신 오류나 타임 아웃 - 시스템 상의 한계일 가능성, 서버를 분리

 

태스크 수의 적정화 - 너무 크거나 너무 작지 않은 정도로 잘 분할하기

 

 

[출처]

빅데이터를 지태하는 기술, 니시다 케이스케