[빅데이터를 지탱하는 기술] 5. 빅데이터의 파이프라인 (1)

5-1. 워크플로 관리

워크플로 관리

▪ 전형적인 업무 프로세스를 원활하게 진행하기 위한 구조를 '워크플로 관리(workflow management)'라고 함 

▪ 워크플로 관리 기능은 매일 매일의 태스크를 관리하는데 사용

▪ 해당 구조가 정기적인 배치 처리의 실행에도 유용하기에 데이터 처리 현장에서도 자주 이용 

워크플로 관리 도구

오픈 소스의 워크플로 관리 도구

 

▪ 정기적으로 태스크를 실행하고, 비정상적인 상태를 감지하여 해결을 돕는 역할

▪ 요즘에는 데이터 파이프라인의 실행에 특화된 오픈 소스 도구들을 많이 사용 

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

워크플로 관리 도구에 의한 태스크의 실행

 

▪ 데이터 파이프라인의 실행 과정에서 데이터를 이동시키면서 정해진 처리를 반복, 이때 실행되는 개별 처리를 '태스크(task)'라고 부름

▪ 워크플로 관리 도구의 역할은 모든 태스크가 문제없이 실행되도록 관리 

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

▪ 워크플로 관리 도구를 사용하는 이유는 태스크 실행에 실패할 수 있기 때문 

▪ 데이터 파이프라인이 복잡해지거나, 태스크의 수가 증가할 경우 관리가 어려워짐 

▪ 워크플로 관리 도구의 주요 기능

   - 태스크를 정기적인 스케줄로 실행하고 결과 통지 

   - 태스크 간의 의존 관계를 정하고, 정해진 순서대로 실행 

   - 태스크의 실행 결과를 보관하고, 오류 발생 시에는 재실행 

선언 형과 스크립트 형

▪ XML이나 YAML 등의 서식으로 워크플로를 기술하는 '선언형(declarative)' 도구 

▪ 선언형 도구에서는 미리 제공된 기능만 이용 가능, 따라서 누가 작성해도 동일한 워크플로가 되기에 유지 보수성이 높음 

▪ 동일 쿼리에 파라미터만 바꿔 여러 번 실행하거나, 워크플로를 단순 반복적으로 자동 생성하는 경우 선언형 도구 사용

▪ 스크립트 언어로 워크플로를 정의하는 '스크립트 형(scripting)' 도구

▪ 스크립트 형 도구는 유연성을 가짐, 스크립트 언어에 의한 데이터 처리를 태스크 안에서 실행 가능 

▪ ETL 프로세스에서는 스크립트 형 도구, SQL의 실행에는 선언형 도구 등으로 나누어 사용하는 것도 하나의 방법 

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

▪ 데이터 파이프라인을 매일 동작시키다 보면, 예기치 못한 오류가 발생 

▪ 후속의 태스크 중에는 예정된 시간까지 끝내지 않으면 새로운 문제를 일으킬 수도 있음 

▪ 미리 예기치 못한 오류가 발생할 가능성을 고려하여 오류 발생 시의 대처 방법을 결정해두는 것이 중요 

복구와 플로우의 재실행

▪ 인증 오류와 같이 몇 차례 반복해도 실패하는 것은 수동으로 대처 

▪ 오류에는 수 많은 가능성이 있으므로 기본적으로 워크플로 관리에서는 오류로부터 자동 회복할 수 있다는 점은 고려하지 않음 

▪ 수작업에 의한 '복구(recovery)'를 전제한 태스크 설계

▪ 실패한 태스크를 기록하여 나중에 재실행 

 

일일 배치 처리가 여러 날 정지한 후의 복구 처리

 

▪ 워크플로 관리 도구에 의해 실행되는 일련의 태스크를 '플로우(flow)'라고 함

▪ 플로우 실행 시 고정 파라미터가 부여, 일일 배치 처리라면 날짜가 파라미터

▪ 플로우가 실패할 경우 실패한 파라미터로 재실행 가능 

▪ 대부분의 워크플로 관리 도구는 과거에 실행한 플로우와 파라미터를 자동으로 기록 

 

플로우의 재실행

재시도 

▪ 여러 번 발생하는 오류에 대해서는 되도록 자동화하여 수작업 없이 복구

▪ 간단한 것은 일정 시간 간격을 두고 태스크 단위의 자동적인 '재시도(retry)'

▪ 재시도 횟수에는 주의가 필요, 재시도가 적으면 장애 복구 전 재시도가 종료해 태스크 실행 실패 

▪ 반대로 재시도 횟수가 많으면, 태스크가 실패하지 않은 것처럼 되기 때문에 중대한 문제가 발생해도 알지 못함

▪ 로그를 보고 예상외의 문제가 발생하지 않았는지 확인하고, 올바른 문제 해결 방법 찾아야함  

백필

▪ 플로우 전체를 처음부터 다시 실행함으로써 실패한 플로우를 복구할 수 있음 

▪ 백필(backfill): 파라미터에 포함된 일시를 순서대로 바꿔가면서 일정 기간의 플로우를 연속해서 실행하는 구조

 

과거의 플로우를 백필하기

 

▪ 백필에 의해 대량의 태스크를 실행할 때에는 성능상의 주의가 필요

▪ 대규모의 백필을 실시할 때는 자동적인 재시도는 모두 무효로 하고, 오류는 모두 통지

▪ 태스트 삼아 조금씩 백필을 실행하며 어떠한 오류가 발생하지 않는지 확인 

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

▪ 복구의 전제는 재실행의 안정성, 태스크를 실행하다 도중에 실패했을 경우 아무것도 남기지 않도록 함 

 원자성 조작

태스크를 재실행하면 데이터가 중복

 

▪ 첫 번째의 INSERT가 종료한 상황에서 오류가 발생할 경우, 태스크가 재실행된 때에 동일한 데이터가 다시 쓰일 수 있음 

▪ 이 문제를 피하기 위해서 각 태스크가 시스템에 변경을 한 번만 할수 있도록 함 

▪ 또는 쓰기에 필요한 수만큼 태스크를 나눠서 재시도의 안정성 높임, 이를 '원자성 조작(atomic operation)'이라고 함

▪ 원자성 조작에서도 문제가 발생할 가능성이 있음

▪ 태스크 구현상의 버그 등으로 원자성 조작 직후에 문제가 발생하면, 원자성 조작은 성공했지만 워크플로 관리 도구는 오류로 여길 때도 있음 

▪ 아주 작은 가능성도 허가하지 않을 때는 원자성 조작에 의존한 플로우를 만들면 안됨 

멱등한 조작

▪ 멱등한 조작(idempotent operation): 동일한 태스크를 여러 번 실행해도 동일한 결과가 되도록 하는 것

▪ SQL의 경우 '테이블을 삭제한 후에 다시 만들기' 가 멱등한 조작의 예

▪ 일반적으로 워크플로의 각 태스크는 '추가(append)' 또는 '치환(replace)' 중 하나를 실시

▪ 치환은 반복해도 결과가 변하지 않으므로 멱등하다고 할 수 있음

 

멱등한 테이블 작성의 예

 멱등한 추가

▪ 과거의 모든 데이터를 치환하면 멱등하게 되지만, 부하가 커짐

▪ 테이블을 1일마다 또는 1시간마다 파티션으로 분할하고, 파티션 단위로 치환하는 '테이블 파티셔닝'

▪ 테이블의 파티셔닝의 구현은 시스템에 따라 다름, 이용하는 시스템에 맞춰 플로우를 조립해야함

 

파티션을 치환하기

 

원자성을 가진 추가

▪ 복잡한 플로우에서는 하나의 테이블에 몇 번이고 데이터를 써놓을 때가 있음 

▪ 이 경우 중간 테이블을 만들어 처리한 후, 마지막에 목적 테이블에 한 번에 추가하는 것이 안전 

▪ 플로우에 문제가 발생하더라도 어쩡쩡하게 데이터가 쓰이는 일이 없고, 중간 테이블을 삭제하고 재실행 가능 

 

중간 테이블을 만들어 마지막에 추가

 

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

▪ 데이터 파이프라인을 안정적으로 운용하기 위해서는 포함된 태스크나 플로우를 가능한 멱등으로 해야함 

▪ 데이터 수집의 파이프라인에서는 테이블 파티셔닝을 도입함으로써 파티션 단위의 치환이 가능

▪ 벌크 형의 데이터 전송에서도 워크플로 관리 도구에 파라미터를 전달함으로써 치환 형의 태스크 구현 가능

▪ 데이터 마트를 구축하는 플로우에서는 테이블마다 치환

▪ 각 태스크를 멱등으로 하는 것이 이상적이지만, 워크플로가 안정적으로 실행된다면 필수는 아님 

▪ 추가는 중복의 가능성도 있기 때문에 주의 

 

데이터 파이프라인 전체를 멱등으로 하기

 

▪ 데이터 자체에 문제가 발견되어 성공한 태스크를 취소하여 다시 재실행 하는 경우, 멱등한 태스크는 안전하게 재실행 가능 하지만 추가가 포함되어 있으면 불가능 

▪ 재실행의 안전성을 높이기 위해서는 각 플로우가 전체로서 멱등하게 구현되어야함 

태스크 큐 

▪ 워크플로 관리 도구는 외부 시스템의 부하를 컨트롤하는 역할도 수행

▪ 태스크의 크기나 동시 실행 수를 변화시켜 자원의 소비량 조정

▪ 파일 서버에서 분산 스토리지로 파일을 전송할때 병렬화를 고려 

▪ 파일 서버로부터 하나의 파일을 압축하고 분산 스토리지로 전송하는 과정을 하나의 태스크로 고려, 해당 태스크는 셸 스크립트화하여 워크플로 관리 도구 안에서 호출 

▪ 파일의 수 만큼 태스크를 실행하게 되는데, 동시 실행할 경우 서버의 과부하가 걸리므로 제한을 두어야함

▪ 이때 사용되는 것이 '잡 큐(job queue)' 또는 '태스크 큐(task queue)'

▪ 모든 태스크를 큐에 저장하고 일정 수의 워커 프로세스가 순서대로 꺼내면서 병렬화 실현  

 

태스크 큐를 사용하여 병렬 실행

병목 현상의 해소 

▪ 워커를 너무 증가시키면, 병목 현상이 발생해서 성능 향상의 한계점에 도달하거나 오류 발생 

▪ 이는 워크플로를 실행하는 서버의 내부적인 요인과 외부적인 요인으로 나뉨 

▪ 외부적인 요인의 경우 그 문제를 제거할 수 없음 

서버의 내부적인 요인

태스크 수의 적정화 

▪ 작은 태스크를 다수 실행하면 오버헤드가 커져 실행 시간이 증가하고 오류 발생률을 높임 

▪ 하나의 파일을 5초에 처리할 수 있다면, 수백 개 정도의 파일을 모아서 하나의 태스크로 처리 

 

태스크를 1일 단위로 분할하기

 

▪ 태스크를 크게하면, 많은 워커로 동시에 실행함으로써 처리 효율을 최대화 

▪ 태스크가 너무 클 경우에는 나누고, 너무 작을 경우에는 하나로 모음으로써 각 태스크가 적절한 크기가 될 수 있도록 조정

▪ 최종적으로 적당한 크기로 분할된 다수의 태스크가 여러 워커로부터 호출되어 처리

▪ 만약 부하 상승으로 인한 지연 및 오류가 발생할 경우 태스크의 크기를 바꾸거나 자원을 증설해서 문제 해결 

▪ 다음과 같이 데이터 파이프라인 전체가 원할하게 실행되도록 제어하는 것도 워크플로 관리 도구의 역할 

 

 

빅데이터를 지탱하는 기술(니시다 케이스케)