05. 워크플로 관리와 데이터 플로우

안녕하세요 한소희입니다. 공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치하도록 하겠습니다. 감사합니다.

 

워크플로의 관리는 배치 수집에 반드시 필요하다. 나는 현재 기업 협업 프로젝트를 하고 있는데, 이 프로젝트에서도 워크플로 관리의 필요성을 여실히 느꼈다. 따라서 '워크플로 관리'와 '데이터 플로우'에 대해 자세히 공부해보려고 한다.

 

 

 

 

 

 

목차

워크플로 관리

배치형의 데이터 플로우

스트리밍 형의 데이터 플로우

 

---

 

01. 워크플로 관리

 

워크플로란, 작업 절차를 말한다.

 

 

1-1. 워크플로 관리가 필요한 이유

 

우리는 정기적/반복적 배치 처리의 상황에서 워크 플로우가 존재한다. 데이터 수집은 하나의 명령으로만 생성되는 것이 아니기 때문이다.

이때, 작업들은 순서가 있을 수 있고 & 일정 시간마다 처리를 해주어야 할 수 있다.

따라서 이 안정적인 관리가 필요하다. 순서가 꼬이는 등의 이슈가 발생하면 정상적인 수집절차가 일어나지 않기 때문이다.

 

 

1-2. 워크플로 관리도구

관리할 것이 많은데 이것까지 모두 관리하기엔 인적 리소스가 많이 투입되어야 한다. 따라서 이를 워크플로 관리 도구에게 맡겨야 한다. 워크플로 관리 도구는 여러 개의 태스크를 여러개의 워커가 병렬 처리한다.

 

 

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

이름	종류	개발사
에어 플로우	스크립트 형	에어비앤비
아즈카반	선언형	링크드인
디그더그	스크립트 형	트레주어 데이터
우지	선언형	아파치

 

 

 

여기서 잠깐! 선언형과 스크립트 형?

1) 선언형: xml이나 yaml 등의 서식으로 워크플로를 기술하는 타입. 누가 작성해도 동일한 워크플로를 만들 수 있어 유지 보수성이 높아짐.

2) 스크립트형: 스크립트 언어로 워크플로를 정의하는 유형. 태스크 정의를 프로그래밍할 수 있다는 장점이 있음.

 

 

 

1-3. 워크플로 관리에서 중요한 것 - 오류 복구 방법 생각하기

네트워크 일시적 장애, 하드웨어 장애, 용량 부족 등 이슈로 오류가 생길 수 있다. 이럴 때마다 오류 발생 시의 대처 방법을 지정하는 것이 중요하다.

 

즉 오류에 강한(안정적인) 워크플로를 구축해야 한다.

 

 

1-3-1. 오류의 예시

• 몇 차례 반복하면 성공하는 오류 : 예시 - 통신 오류 : 조금 기다려서 대처한다.
• 몇 차례 반복해도 성공이 안 되는 오류 : 예시 - 인증 오류 : 수동으로 대처한다.

 

워크플로에서의 오류 대처는, 수작업에 의한 복구를 전제한 태스크를 설계한다.

 

예를 들어, 일자 별로 나뉜 태스크 처리가 있다고 하자.
7월 7일 태스크 오류가 발생해 수행되지 않았었다면, 7월 7일이라는 파라미터 값(=플로우)으로 수동 실행해준다. 그러면 우리가 원래 하려던 태스크와 완전히 동일한 태스크가 실행한다. 이것이 복구의 기본이다.

 

🔥 복구 방법?

관리 도구는 데이터베이스에 과거에 실행한 플로우 및 파라미터를 저장하고 있다. 따라서 실패한 플로우를 재실행하면 복구가 된다. 

 

 

1-4. 복구방법 1 - 재시도

장애가 발생하면 자동으로 태스크 단위의 재시도를 수행할 수 있도록 정할 수 있다. 재시도가 너무 적으면 장애 복구 전 재시도가 종료해버려 태스크 실행에 실패한다. 재시도가 너무 많으면 중대한 이슈를 눈치채지 못한다.

 

가장 좋은 건 재시도가 없이 모든 오류를 통지한다. 그 후 문제가 발생하면 수작업으로 처리하는 겄다.

재시도를 반복해도 문제가 없다면,  1회에서 2회까지는 재시도를 해도 되긴 한다.

 

 

 

 

🔥 1-5. 복구방법 2 - 백필

 

실패한 플로우 전체를 처음부터 다시 실행한다. 파라미터 포함된 일시를 순서대로 바꿔가며 일정기간 플로우를 연속해서 실행한다. 이는 태스크 실패가 며칠 동안 계속된 후에 이를 모두 모아서 재실행하고 싶을 때 사용한다.

 

백 필은 너무 많이 하면 어떤 오류가 발생하는지 컨트롤이 힘드므로 재시도는 고려하지 않는 것이 좋다. 그렇게 플로우 전체를 쭉 다시 실행해주고, 거기서 발생한 추가적 오류만 재실행해주면 모든 백 필이 된다.

 

 

 

여기서 잠깐! 원자성 조작이란?

쓰기가 필요한 수만큼 태스크를 나누는 것이다. 이는 재시도에 의한 데이터 중복을 방지한다.
재시도를 하다 보면 실패한 태스크가 만약 절반은 성공해서 일정 데이터가 전달됐다고 가정하자. 이때 이 태스크를 재실행하면 절반의 데이터는 두 번 들어갈 것이다. 이를 해결하기 위해서는 트랜잭션을 시작하여 한 번에 커밋하도록 해야 하는 게 원자성 조작이다.

원자성 조작 방법?

처리될 때마다 치환되는 멱등한 중간테이블을 만들어 처리한 뒤, 마지막에 목적테이블에 한 번에 추가하도록 한다.

 

🔥 멱등한 조작이란?

여러 번 수행해도 테이블의 상태가 같은 것을 말한다.
sql 쿼리문을 돌릴 때면, sql문 시작 시점에서 테이블을 초기화하는 명령을 넣으면 멱등한 조작이 된다. 그리고 치환의 경우에도, 반복해도 결과가 변하지 않으므로 멱등하다고 할 수 있겠다. 

🔥 과거의 모든 데이터 치환하면 멱등하지만 오래 걸리지 않는가?

그렇다. 그래서 이때 파티션으로 테이블을 분할하고, 파티션 단위로 치환하도록 한다.

 

벽등은 필수인가?

그렇지 않다. 그저 이상적인 처리방법이다. 그리고 워크플로가 안정적이면 반드시 멱등하도록 조건을 걸지 않아도 된다.(하지만 워크플로 이슈에 대응하기 위해서는 멱등을 고려하는 게 좋다.)

 

 

---

02. 배치형의 데이터 플로우

 

데이터 플로우 프레임워크

명칭	개발원
구글 클라우드 데이터플로우	구글
아파치 스파크	아파치
아파치 플링크	아파치

 

위의 데이터 플로우 프레임워크들은 맵리듀스를 대체할 수 있다.

 

 

2-1. 맵리듀스란 무엇인가?

아래 포스팅을 참고하자.

https://eng-sohee.tistory.com/34

03. 빅데이터의 분산 처리

 

왜 맵리듀스를 대체하려고 하는가?
맵과 리듀스 중 하나의 사이클이 끝나지 않으면 다음 업무로 넘어가지 않아 비효율적이다.

맵리듀스를 누가 대체하는가?
DAG. 이는 Spark 등의 내부 표현 방법이다. 이는 비순환 방향성 그래프인데, 공부한 포스팅 자료는 아래와 같다.

DAG는 병렬적으로 실행된다. 배치 처리에서는 DAG에 태스크를 적당히 쪼개어 뭉치형으로 데이터를 넣어준다. SPARK에서도 DAG(시스템 내부적 표현) 구조로 스크립트를 설계해 구성할 수 있다.

 

 

 

 

---

 

 

03. 스트리밍 형의 데이터 플로우

 

배치형의 데이터 플로우는, 데이터 소스로부터 데이터를 분산 스토리지에 보관 후 시작한다. 하지만 스트리밍 형의 데이터의 경우에는 그런 처리가 없다.

 

스트림 처리는 제한이 없이 데이터가 보내져서, 무한 데이터라고 한다.

스트림 처리 또한 DAG를 통해서 실행한다는 특징이 있다.

 

 

대표적인 예로 Spark Streaming이 있다. Spark는 배치 처리로 만들어진 소프트웨어지만 이제는 스트림 처리도 가능하다.(하나의 소프트웨어에서 배치와 스트림 처리가 모두 가능하다는 것도 Spark의 장점이 되겠다.) 스트림 처리는 프로그램이 정지될 때까지 끝없이 실행된다.

 

 

 

3-1. 스트림 처리에서 고민해야 할 부분

• 틀린 결과 수정 방법
• 늦게 전송된 데이터 취급 방법

 

 

일별 보고서를 속보 값으로, 월별 보고서를 확정 값으로써 한번 더 배치 처리하는 방법을 사용하면 이 고민이 해결된다. 

이 기법을 발전시킨 것이 바로 람다 아키텍처다. 이는 배치 처리와 스트림 처리의 결점을 보완하고자 한 아키텍처다.

 

 

람다 아키텍처

람다 아키텍처의 전제

1. 모든 데이터는 배치 데이터에서 처리한다. 

2. 배치 처리 결과는 서빙 레이어를 통해 접근한다. 응답 빠른 DB를 설치해 집계 결과를 바로 추출하도록 한다. 여기서 얻어진 결과가 배치 보다. 이는 실시간 정보는 얻을 수 없다.

3. 스피드 레이어는 실시간 데이터를 처리한다. 이 처리 결과는 실시간 뷰에서 확인이 가능하다. 실시간 뷰는 배치 뷰가 업데이트될 때까지만 이용되고 오래된 데이터는 순차적 삭제된다.

 

 

 

 

람다 아키텍처의 장점?
실시간 뷰는 추후 배치 뷰로 치환된다. 즉, 스트림 처리 결과는 일시적으로만 사용한다. 따라서 안정성이 보장될 수 있다.

 

여기서 잠깐! 카파 아키텍처란?

카파 아키텍처란, 람다 아키텍처에서 배치 레이어나 서빙 레이어를 완전히 제거하고 스피드 레이어만을 남기는 아키텍처다. 메시지 브로커 처리 시간을 최대한 길게 하여, 스트림 처리의 문제에 대응하는 방법을 사용한다.

하지만, 람다 아키텍처는 했던 데이터를 한번 더 처리해야 하므로 나쁜 개발 효율이 있다. 이를 해결하기 위해 카파 아키텍처라는 것이 생겨난 것이다.

이는 부하가 높아진다는 단점이 있다. 하지만 아키텍처가 단순하다는 장점도 있다.