요약
- 스트림 처리의 나머지 부분에 대해 이해함.
- 내결함성
- 마이크로 일괄 처리와 체크포인트
- 원자적 커밋 재검토
- 멱등성
- 실패 후에 상태 재구축하기
메모
내결함성
- 스트림 처리자가 결함에 견딜 수 있는 방법을 고려해보자.
- 일괄 처리 프레임워크는 결함에 쉽게 대처할 수 있는데, 이는 입력 파일이 불변이고 각 태스크가 분리된 파일에 출력을 기록하기 때문임.
- 일괄 처리의 내결함성 접근법은 일부 태스크가 실패할지라도 결과가 정확하게 한 번 처리된 것처럼 보이게 함.
- 이 원리를 정확히 한 번 시맨틱(exactly-once semantics)이라 하지만, 결과적으로 한 번(effectively-once)이라는 용어가 그 의미를 더 잘 설명함.
- 스트림 처리에서도 동일한 내결함성 문제가 발생하지만, 이 문제를 다루는 방법은 덜 직관적임.
- 스트림은 무한하기 때문에 처리를 절대 완료할 수 없으며, 출력을 노출하기 전에 태스크가 완료될 때까지 기다리는 것은 해결책으로 사용할 수 없음.
마이크로 일괄 처리와 체크포인트
- 스트림을 작은 블록으로 나누고 각 블록을 소형 일괄 처리로 다루는 해결책이 있음.
- 이 방법을 마이크로 일괄 처리(microbatching)이라 함.
- 스파크 스트리밍에서 사용되며, 일반적으로 약 1초 정도의 크기로 성능상 타협한 결과임.
- 마이크로 일괄 처리는 일괄 처리 크기와 같은 텀블링 윈도우를 암묵적으로 지원함(처리 시간 기준).
- 큰 윈도우가 필요한 작업은 상태를 다음 마이크로 일괄 처리 작업으로 명시적으로 넘길 필요가 있음.
- 아파치 플링크는 변형된 접근법을 사용하며, 주기적으로 상태의 롤링 체크포인트를 생성하고 지속성 있는 저장소에 저장함.
- 스트림 연산자에 장애가 발생하면 가장 최근 체크포인트에서 재시작함.
- 마이크로 일괄 처리와 체크포인트 접근법은 일괄 처리와 같이 정확히 한 번 시맨틱을 지원함.
- 그러나, 외부 부수 효과가 두 번 발생할 수 있는 경우 이 방법만으로는 문제를 방지하기 충분하지 않음.
원자적 커밋 재검토
- 장애가 발생했을 때 정확히 한 번 처리되는 것처럼 보일려면 처리가 성공했을 때만 모든 출력과 이벤트 처리의 부수 효과가 발생하게 해야 함.
- 이 효과는 원자적으로 일어나거나 또는 모두 일어나지 않아야 하며, 서로 동기화가 깨지면 안 됨.
- 구글 클라우드 데이터플로, 볼트DB에서 사용되며, 아파치 카프카도 유사한 기능을 추가할 계획임.
- 이 접근법은 이종 기술 간 트랜잭션을 지원하지 않고, 스트림 처리 프레임워크 내에서 상태 변화와 메시지를 관리해 트랜잭션을 내부적으로 유지함.
- 트랜잭션 프로토콜에서 발생하는 오버헤드는 단일 트랜잭션 내에서 여러 입력 메시지를 처리해 상쇄할 수 있음.
멱등성
- 목표는 실패한 태스크의 부분 출력을 버리면서 처리 효과가 두 번 나타나지 않게 안전하게 재처리하기 위함임.
- 분산 트랜잭션 이외에도 멱등성(idempotence)에 의존하는 방법이 있음.
- 멱등 연산은 여러 번 수행해도 오직 한 번 수행한 것과 같은 효과를 냄.
- 연산 자체가 멱등적이지 않아도 여분의 메타데이터로 연산을 멱등적으로 만들 수 있음.
- 멱등성에 의존하려면 몇 가지 가정이 필요함.
- 실패한 태스크를 재시작할 때 같은 순서로 같은 메시지를 재생해야 하며, 처리는 결정적이어야 하고, 어떤 노드도 동시에 같은 값을 갱신하지 않아야 함.
- 멱등 연산은 정확히 한 번 시맨틱을 달성하는 데 적은 오버헤드만 드는 효율적인 방법임.
실패 후에 상태 재구축하기
- 상태가 필요한 스트림 처리는 실패 후에도 해당 상태가 복구됨을 보장해야 함.
- 원격 데이터 저장소에 상태를 유지하고 복제하는 방법과, 스트림 처리자의 로컬에 상태를 유지하고 주기적으로 복제하는 방법이 있음.
- 플링크, 쌈자와 카프카 스트림, 볼트DB는 각각 다른 방식으로 상태를 복제함.
- 상태 복제가 필요 없는 경우도 있다. 입력 스트림을 사용해 재구축할 수 있기 때문임.
- 이상적인 트레이드오프는 없으며, 로컬 상태 대 원격 상태의 가치는 저장소와 네트워크 기술의 발전에 따라 변할 수 있음.
댓글