스트리밍 데이터 아키텍쳐-1 수집 단계, 큐, 분석 단계

일반적인 스트리밍 시스템에서 사용하는 패턴의 아키텍쳐를 공부해보고자 합니다.

실시간 데이터 파이프라인 아키텍쳐를 보고 공부한 내용을 다룹니다!

스트리밍 데이터 아키텍쳐

스트리밍 아키텍쳐는 크게 6가지 단계로 나눌 수 있습니다.

수집 단계

클라이언트에서 생성되는 데이터가 시스템에 들어오는 스트리밍 시스템의 첫 단계입니다.

수집을 위한 몇가지 패턴들이 존재하며 이중 하나를 선택하여 사용합니다.

1. 요청/응답 패턴
2. 발행/구독 패턴
3. 단방향 패턴
4. 요청/확인응답 패턴
5. 스트림 패턴

요청/응답 패턴 $Request/response pattern$

클라이언트가 서버로 요청을 보내면 서버가 응답하는 웹 브라우저에서 자주 사용되는 일반적인 패턴입니다.

반비동기$Half-async$, 비동기$Full-async$ 방식으로 요청/응답 패턴을 구현할 수 있습니다.

요청/응답 확인 패턴 $Request/acknowledge pattern$

요청/응답 패턴과 유사하게 통신을 해야하지만 서버에서 반환하는 응답이 클라이언트에는 필요하지 않는 경우에 사용됩니다.

확인응답으로 전달되는 데이터는 현재 요청 상태를 확인하는 용도의 데이터나 다음 요청에 사용할 데이터를 내려주기도 합니다.

 

예를들어 고객이 접속한 모든 페이지에 대한 정보와 클릭한 링크에 대한 데이터를 수집해야한다고 한다면,

첫 요청이 들어올때 서버는 다음요청에서 고객이 사용할 고유의 식별자를 넘겨줍니다.

이후 식별자는 고객이 방문하는 모든 페이지들을 추적하는데 사용됩니다.

이러한 정보들을 토대로 고객의 구매성향을 분석 할수도 있습니다.

발행/구독 패턴 $Publish/subscribe pattern$

일반적인 메시지 기반 데이터 시스템에서 자주 사용되는 패턴입니다.

프로듀서가 브로커에세 메시지를 전달하는 것으로 시작됩니다.

메시지는 토픽$Topic$으로 전송되며, 전송 이후 토픽을 구독하는 모든 컨슈머$Consumer$에게 메시지가 전송됩니다.

브로커는 토픽을 관리하는 논리적인 클러스터입니다.

단방형 패턴 $One-way pattern$

단방향 패턴은 요청하는 시스템이 응답이 필요하지 않을 때 사용합니다.

'발사 후 망각' $Fire and forgot$ 패턴과 유사합니다.

요청/응답 확인 패턴과 유사하지만 서버가 응답을 보내지 않아도 됩니다.

일부 데이터의 유실을 허용하고 통신의 단순화, 리소스 감소, 전송 속도를 보장해야하는 환경에서는 단방향 패턴이 적합합니다.

스트림 패턴 $Stream pattern$

스트림 패턴은 앞서 다루었던 패턴들과 조금 다릅니다.

보통 클라이언트가 서버로부터 응답을 받거나 받지않으며 클라이언트에서 출발하는 한번 한번의 요청이 주를 이루었다면

스트림 패턴에서는 한번에 데이터를 모두 전달하지 않고 지속적으로 데이터를 응답으로 보내는 특징을 가집니다.

서버는 원천 스트림 데이터와 연결하여 지속적으로 원천 스트림 데이터를 가져갈 수 있습니다.

서버의 요청을 보내기 위해 클라이언트를 개발할 필요 없이, 스트림 패턴을 활용하면 스트림 데이터가 존재하는 부분에 연동하여 데이터를 지속적으로 처리 할 수 있습니다.

스트림 패턴$Stream pattern$의 수평확장

스트림 패턴에서는 지속적인 연결과 상태 유지를 전제로 하기 때문에, 일반적인 수평 확장처럼 단순히 인스턴스를 늘리는 방식은 비효율적일 수 있습니다.

이를 해결하기 위한 방법 중 하나는 버퍼링$Buffering layer$를 사용하는 방법입니다.

버퍼링 계층과 수집서버는 서로 상호 배타적$Mutually execlusice$이지 않으며 스트림 데이터의 유입량이나 크기에 따라 둘 다 적절한 상태로$크기, 갯수$ 설계되어야 합니다.

내결함성 설계

모든 소프트웨어는 장애에 대한 설계가 필요합니다.

수집 단계에서는 원천 데이터가 수집 서버로 들어오는 시점, 수집 서버에서 큐로 넘어가는 시점 크게 두곳에서 장애가 발생 할 수 있습니다.

내결함성을 달성하기 위해 체크 포인팅$Checkpointing$과 로깅$logging$ 방식이 사용됩니다.

체크 포인팅$Checkpointing$

체크포인팅의 두가지 키워드는 전역 스냅샷$Global snapshot$과 데이터 유실 가능성$Potential for data loss$입니다.

• 전역 스냅샷$Global snapshot$ : 시스템 전역 상태에 대한 스냅샷을 정기적으로 특정 저장소에 저장합니다.
• 데이터 유실 가능성$Potential for data loss$ : 가장 최근에 기록된 전역 상태까지 복구할 수 있도록 합니다. 이후 시점에 처리되고 생성된 메시지는 유실됩니다.

여기서 복원하는 전역상태는 영속성 저장소$Persistent store$에 저장되어있는 상태를 의미합니다.

 

일반적인 스트리밍 시스템에서 체크포인팅을 사용하는건 조금 어려움이 있습니다.

스트리밍 시스템은 단계별로 데이터가 이동할 때 마다 모든 시점에 대한 스냅샷 데이터를 일관성있게 유지하는것이 어렵고, 각 단계별로 각각 다양한 기술$스택, 프레임워크 등$들로 구성되어 있기 때문입니다.

로깅 $Logging$

로깅의 기본적인 아이디어는 '메세지를 제처리 할 수 있다면, 시스템은 전역 스냅샷이 없어도 전 구간에서 일관돤 상태에 도달할 수 있다' 입니다.

즉 로깅방식은 시스템을 구성하는 각 단계가 수신한 모든 메시지를 자체적으로 저장하고 장애가 발생하면 저장된 메시지를 재처리하는 방식입니다.

 

로깅은 RBML$Receiver-Based Message Logging$과 SBML$Sender-Based Message Logging$ 이 두 방식을 합친 HML$Hybrid Message Logging$이 있습니다. $HML방식은 RBML방식과 SBML방식의 장점만을 합친 방식입니다.$

RBML은 서버가 데이터를 받을 떄,  SBML방식은 데이터를 다음 단계로 보낼 때 데이터의 유실을 방지합니다.

로깅방식 $RMBL, SBML, HML$

RBML$Receiver-Based Message Logging$

RBML은 전달받은 모든 메시지를 저장소에 저장한 이후에 로직을 처리하는 방식입니다.

이 방식은 소프트웨어에 장애가 발생하더라도 이미 저장되어 있던 데이터를 바탕으로 재처리하여 복구 할 수 있습니다.

다만 저장소의 성능이 따라주지 않으면 시스템의 성능에 큰 영향이 있을 수 있습니다.

 

장애가 발생하면 수집서버는 프로듀서로 부터 더 이상 메시지를 받지 않습니다.

RBML로거는 메시지가 저장된 저장소에서 처리되지 않는 메시지를 읽고 기존 순서대로 로직을 처리합니다.

중지되었던 모든 메시지가 처리되고 나면 수집서버가 복구된 것으로 간주합니다.

1. 데이터 프로듀서 $클라이언트 등$가 메시지를 전송합니다.

2. 데이터 프로듀서가 보낸 메시지는 RBML로거 서버로 전달되고 저장소로 전달합니다.

3. 메시지가 저장소에 저장됩니다.

4. 비즈니스 로직 수행

5. 수집단계의 다음 단계인 큐 단계로 메시지가 전달됩니다.

SBML$Sender-Based Message Logging$

SBML은 서버가 처리한 데이터를 다음 단계로 보내기 전 수집서버에서 외부로 나가는 모든 메시지를 로깅합니다.

RBML과 SBML의 중요한 차이점은 RMBL은 메시지를 처리하기 전에 저장하고 SMBL은 다음단계로 넘어가기 전에 처리합니다.

즉 RBML은 원천데이터이고 SBML은 로직을 통해 한번 가공된 데이터입니다.

장애가 발생하면 수집서버는 RBML과 동일하게 프로듀서로 부터 데이터를 받지 않게됩니다.

SBML에서 메시지가 다음단계로 잘 넘어갔는지 확인하려면?

SBML에서 넘어간 데이터가 잘 처리되었는지 알 수 있는 방식은 메시지 큐 단계에서 메시지를 정상적으로 받았다고 수집 단계에 확인 응답을 보내주는 것입니다.

메시지 큐에 정상적으로 전달되었으면 수집단계에서 이상 수집 단계에서 데이터를 보관할 필요가 없으니 저장소에서 삭제하는 등 비즈니스에 따라 해당 메시지에 대해 전송완료 표시를 해두면 됩니다.

만약 메시지 큐에서 전달응답을 보낼 수 없는 경우에는 6,7 단계를 생략하고 수집 단계에 영속 저장소에서 삭제하는 방식을 사용합니다.

HML$Hybrid Message Logging$

HML은 RBML과 SBML의 장점을 최대한 활용하도록 설계되었습니다.

만약 3가지 로깅구조에서 하나만 선택해야한다면 HML을 선택하는게 일반적인 정답입니다.

HML에서는 메시지를 저장할 때 저장을 비동기로 처리한다는 특징이 있습니다.

메시지 큐 단계

소프트웨어 설게에서는 서버들간의 디커플링이 중요합니다.

서버들간의 통신 및 디커플링을 위해 '메시지 큐'를 많이 사용합니다.

'메시지 큐'를 통해 수집단계와 분석단계의 커플링을 끊고 통신을 할 수 있습니다.

프로듀서, 브로커, 컨슈머

메시지 큐는 프로듀서, 브로커, 컨슈머로 구성되어 있습니다.

브로커는 실제 메시지 큐들을 관리하는 추상화된 논리적 클러스터입니다.

메시지 큐 단계에서는 위 3가지 구성요소들끼리 통신합니다.

 

메시지 큐는 아래와 같은 순서대로 동작합니다.

1. 프로듀서는 브로커에세 메시지를 보낸다.
2. 브로커는 큐에 메시지를 넣는다.
3. 컨슈머는 브로커로부터 메시지를 읽는다.

메시지의 지속적저장 $Durable Messaging$

만약 수집단계에서 대량의 데이터가 들어온다면, 메시지 큐 단계에서는 데이터의 유실없이 적절하게 처리할 수 있는 방법이 필요합니다.

메시지의 지속적 저장$Durable Messaging$은 컨슈머가 데이터를 천천히 읽어가거나 일시적으로 컨슈머의 연결이 끊기더라도 다시 데이터를 읽어갈 수 있는 방법입니다.

또한 메시지의 지속적 저장이 가능한 큐를 Durable Queue라고 합니다.

 

만약 컨슈머가 장애나 성능등의 이유로 메시지를 읽지 못하면 큐에 쌓여버린 메시지들은 소멸되거나 유실될 수 있습니다.

하지만 Durable Queue는 메시지를 지속적 저장소$파일시스템. JDBC, 전용 시스템$등에 백업해두기에 메시지의 소실을 예방 할 수 있습니다.

 

RabbitMQ는 Queue 생성 시 durable=true, 메시지 deliveryMode=2 설정해야 디스크 저장이 되고,

Kafka는 기본적으로 모든 메시지 로그는 디스크 저장됩니다.

메시지의 전달 시맨틱 $Messaging Delivery Semantics$

메시지가 컨슈머에게 어떻게 전달되고, 몇 번이나, 어떤 조건에서 도착해야 하는지에 대한 규칙입니다.

 

1. 최대 한 번 $At-most-once$ 

일부 메시지가 유실될 수 잇습니다. 유실된 메시지는 컨슈머에 도달하지 못합니다.

 

2. 적어도 한 번 $At-least-once$

메시지가 절대 유실되지 않습니다. 그러나 컨슈머에서 동일 메시지를 두번 이상 처리할 수 있다.

 

3. 정확히 한 번 $Exactly-once$

모든 메시지는 절대로 유실되지 않으며, 컨슈머는 반드시 한 번만 메시지를 처리합니다.

 

일반적으로는 '정확히 한 번'이 당연히 가장 이상적이고 완벽한 방법입니다.

그렇기에 '정확히 한 번'을 구현하는건 어려운 일입니다.

 

그 이유는 사실상 각 큐의 요소간 모든 통신은 유실위험이 존재하며,

'정확히 한 번'을 구현하려면 큐의 각 요소에서 메시지 소실 및 재전송이 발생 할 수 있는 상황들을 알고 고려해야합니다.

('정확히 한 번'은 매번 정답이 아니며 비즈니스에 따라 적절한 시맨틱을 선택해야합니다. 실제로 카프카도 0.11.0.0 버전 이전까지는 정확히 한 번 기능을 제공하지 않았습니다.)

'정확히 한 번'을 위해 고려해야하는 부분들

'정확히 한 번'을 구현하기 위해서는 각 요소간에서 발생할 수 있는 문제들을 미리 알아두어야합니다.

 

프로듀서에서 위험요소

• 프로듀서 내부에서 메시지가 생성된 후 네트워크 통신을 통해 브로커로 보내기 직전 프로듀서 장애 발생 시 메시지 유실가능
• 프로듀서가 정상적으로 메시지를 보냈지만 브로커에서 메시지를 전달받았다는 응답을 받지 못하면 동일한 메시지가 브로커로 한번 더 전달 될 수 있음

프로듀서와 브로커 간 네트워크 통신간 위험요소

• 프로듀서와 브로커 간 네트워크 사이 통신에 이슈가 발생하면 프로듀서는 브로커로 메시지를 보내지 못함
• 브로커가 메시지를 저장했지만 저장 완료되었다는 응답을 프로듀서에 보내지 못하면 동일한 메시지가 두 번 전달될 수 있음

브로커에서의 위험요소

• 브로커에 장애가 발생하면 저장소에 저장하기 직전에 메모리가 가지고 있던 메시지가 유실 될 수 있음
• 프로듀서로 메시지를 전달받았다고 응답을 보내기 전에 장애가 발생하면 프로듀서는 동일한 메시지를 두 번 보낼 수 있음

메시지 큐에서의 위험요소

• 저장소에 장애가 발생하면 디스크에 저장된 메시지 중 일부가 유실될 수 있습니다.

컨슈머와 브로커 간 네트워크 통신간 위험요소

• 컨슈머와 브로커 간 네트워크 이슈 발생 시, 브로커가 컨슈머로 메시지를 보낼 수 없음
• 컨슈머가 처리한 마지막 메시지 정보가 브로커에 전달되지 않으면 동일한 메시지가 두 번 이상 컨슈머에서 처리될 수 있습니다.

컨슈머에서의 위험요소

• 브로커로부터 메시지를 전달 받은 후, 데이터를 처리하기 전에 장애가 생기거나 커밋정보를 브로커로 전달하지 못하면 동일한 메시지를 두번 이상 처리할수도 있습니다.
• 여러 컨슈머가 동일한 메시지를 여러 번 읽는 경우도 발생할 수 있습니다.

 

결론적으로 프로듀서와 컨슈머에서 정확히 한 번을 지원하기 위해서는 메시지를 두번 보내지 않아야하고, 마지막으로 처리한 메시지의 메티데이터를 저장해야합니다.

아파치 카프카, 아파치 Active MQ의 메시징 시스템에서도 이렇게 메타데이터를 이용해 정확히 한 번 처리를 구현합니다.

메시지를 두 번 보내지 말 것

정확히 한 번 처리를 위해 반드시 구현되어야하는 기능입니다.

프로듀서가 브로커로 메시지를 보낼 때 각 메시지들을 추적해야합니다.

만약 프로듀서와 브로커 사이 응답이 유실되거나 연결이 끊기면, 프로듀서가 이전에 보낸 데이터를 브로커가 정상적으로 받았는지 브로커로 요청하고 확인응답$Acknowledgement$를 받습니다.

 

예를들어 프로듀서가 브로커로 응답을 보내고 브로커는 응답을 받은 직후 네트워크가 끊겨 프로듀서가 브로커의 응답을 받지 못하면, 프로듀서는 다시 동일한 메시지를 보내게 됩니다.

이때 프로듀서가 메시지에 고유 ID$메타데이터$을 붙여 보내게 되면,

브로커는 고유 ID$메타데이터$를 통해 프로듀서가 이전과 동일한 메시지를 보냈는지, 즉 중복된 메시지를 보냈는지 판단하여 프로듀서가 메시지를 두 번 보내지 않도록 합니다.

마지막으로 처리한 메시지의 메타데이터 저장

저장해야하는 메타데이터의 종류는 메시징 시스템에 따라 다릅니다.

JMS 기반 시스템을 사용할 경우 JMS의 메시지ID를 사용하면 됩니다.

아파치 카프카를 사용할때는 메시지의 오프셋을 저장합니다.

결국 중복해서 처리하지 않기 위한 메시지 구분을 위한 메타데이터를 저장하면 됩니다.

또한 메타데이터는 장애복구 시 컨슈머가 어디서부터 메시지를 읽을지 기억하는 기준이 되기도 합니다.

메시지 큐 단계에서의 장애처리

장애처리는 어떤 단계에서든 중요한 부분입니다.

큐에서는 크게 브로커, 브로커간 통신, 저장소에서의 장애가 주된 위험지점이 될 것 같습니다.

브로커에서 장애 위험요소 및 처리방안

브로커가 내부 저장소에 저장하기 직전에 장애가 발생 할 수 있습니다.

이 때 메모리에 가지고 있던 메시지를 처리하는 방법은 3가지 정도가 있을 것 같습니다.

• 프로듀서와 브로커간 확인응답$Acknowledgment$를 활용$메시지 전달 시멘틱 방법과 동일!$
• 큐가 별도의 브로커로 메시지를 복제하여 백업
• 메시지를 저장하는 메모리의 사용률을 줄이고 저장소에 저장하도록 변경 $속도저하 가능성 있음$

브로커 통신간 장애 위험요소 및 처리방안

큐 소프트웨어들은 최소 1개 이상의 브로커에 메시지를 저장하여 안전하게 저장되도록하며,

브로커간 네트워크의 문제가 발생했을때도 복구 이후 각 브로커에 저장된 메시지를 동기화 하는 기능이 존재합니다.

큐를 직접 구현하는게 아니라면 '브로커 통신간 네트워크 장애 발생 시 또는 복구 시' 큐 소프트웨어가 어떻게 동작하는지 확인한 다음,

비즈니스에 맞는 몇가지 기준을 만들고 그에 적합한 큐 소프트웨어를 선택해야합니다.

 

저장소에서 장애 위험요소 및 처리방안

• 저장소에서 유실된 데이터에 대한 백업을 만들어 두어야합니다.

분석 단계 $스트림 프로세싱 아키텍쳐$

수집과 큐 단계를 거쳐 모인 데이터들이 모여 어떠한 비즈니스적 가치를 만들어내는 단계입니다.

여러 알고리즘들이 존재하기만 분석 알고리즘을 따로 포스팅하고 분석단계에서 사용되는 스트림 프로세싱 아키텍쳐를 위주로 다루어 보려고합니다.

 

전통적인 DBMS와 스트리밍 시스템의 데이터 접근에 대한 차이

아래 그림은 전통적인 DBMS와 스트리밍 시스템의 데이터 접근에 대한 차이입니다.

스트리밍 시스템에서는 사용자가 쿼리를 한번 등록하면 결과값은 지속적으로 클라이언트에게 푸시됩니다.

스트리밍 분석은 사용자 행동 추적, 실시간 분석 등 여러 비즈니스 요구사항을 풀 수 있습니다.

인플라이트 데이터$In-flight Data$와 연속 쿼리$Continuous quries$

인플라이트 데이터는 시스템의 파이프라인 속에서 이동 중이거나 처리 중인 데이터를 의미합니다.

시스템에 따라 인플라이트 데이터는 디스크에 저장되거나 사용 후 소멸되기도 합니다.

 

연속쿼리는 시스템에서 실시간으로 들어오는 데이터에 대해 즉시 실행되고, 그 실시간 결과를 지속적으로 반환하는 쿼리를 의미합니다.

즉 데이터가 들어올 때 마다 자동으로 실행되는 쿼리입니다.

스트리밍 시스템을 사용하는 사용자 입장에서 생각해보면 스트리밍 시스템의 쿼리$연속쿼리$를 실행하면 데이터가 지속적으로 들어오게 됩니다. 이러한 쿼리들을 조합한 일련의 형태 모델을 '연속 쿼리 모델'$Continuous query model$이라 합니다.

 

이렇게 쿼리로 추출된 데이터는 다음 단계로 PUSH됩니다.

분산 스트림 프로세싱 아키텍쳐

분석 단계는 많은 리소스를 필요로 하는 단계이기에 여러 서버를 사용하는 분산 시스템이 동반된 아키텍쳐를 도입해야합니다.

분석 단계에서 많이 사용되는 스트림 프로세싱 소프트웨어는 아파치 스파크, 스톰, 플링크 등이 있습니다.

 

각 소프트웨어마다 명칭과 아키텍쳐가 조금씩은 다르지만,

인기있는 스트리밍 어플리케이션의 구조를 일반화 해서 그려보면 아래와 같습니다.

어플리케이션 드라이버

개발자가 작성한 스트리밍 job 코드가 존재합니다.

작성한 job코드는 스트리밍 매니저와 연동되어 실행되어집니다.

job의 결과도 수집하며 이를 활용하여 통해 job의 생명주기 또한 관리합니다.

스트리밍 매니저

스트림 프로세서를 생성, 모니터링을 하며 생명주기를 관리하고, job을 할당합니다.

때떄로 스트림 프로세서가 필요로하는 리소스를 요청하거나 제어 할 수 있습니다.

스트림 프로세서

원천 데이터를 받아서 필터링, 집계, 패턴 감지 등 비즈니스 로직이 실행됩니다. $작성한 job 로직이 실행되는 장소$

스트림 프로세싱 프레임워크의 핵심 기능

메시지 관리 시맨틱

메시지 큐 단계에서 다루었던 메시지 관리 시맨틱에 대한 부분은 원천 데이터와 스트림 프로세서간 통신에서도 동일한 문제가 나타 날 수 있습니다.

그렇기에 스트림 프레임워크에서도 최대 한 번, 적어도 한 번, 정확히 한 번 등의 시맨틱을 제공합니다.

동일하게 비즈니스에 맞는 시맨틱을 선택하면 됩니다.

상태 관리 $State management$

스트림 시스템에서 계속 흘러가는 데이터들이 외부 데이터와 연동되거나 이전에 처리된 메시지를 참조하는 등 데이터를 다루는 로직이 복잡해지면, 프로세서가 데이터의 상태$State$를 기억하여 값을 안전하게 관리해야합니다. 

예를 들어 '방문자의 지난 한 시간 동안 페이지 수 뷰'를 추출해야 한다면 시스템은 '해당 사용자가 한 시간 동안 방문한 페이지 수 데이터'의 값, 즉 상태를 유지해야합니다.

 

스트리밍 프레임워크는 순수 인 메모리 $In-Memory$를 활용하는 방법에서 복제 기반 쿼리 영구 저장소 $Replicated Queryable Persistent Storage$를 활용하는 등 몇가지 상태관리 기능을 제공합니다.

장애 허용 설계 $Falut tolerance$

분석 단계에서는 다양한 위치에서 장애가 발생 할 수 있습니다.

스트림 데이터 입수, 네트워크 통신, 저장소, 어플리케이션 드라이버에서 장애가 발생하면?

위 4가지 상황에서의 장애는 프레임워크가 통제할 수 있는 상황은 아니지만 장애를 대응 할 수 있는 방법을 만들어 두는것이 좋습니다.

 

메시지 큐 자체는 스트림 프로세싱 프레임워크의 동작에 영향을 받지 않지만 '큐 단계 시스템'에서는 장애가 발생 할 수 있습니다.

이 경우 스트림 프로세싱 프레임워크는 메시지 큐 단계의 데이터를 사용할 수 없거나 접근이 불가능할 경우에도 정상적으로 동작해야합니다.

그리고 네트워크, 저장소, 어플리케이션 드라이버 장애 또한 동일하게 스트림 프로세스 시스템에 영향을 미칠 수 있기에 적잘한 장애 대응 방법을 고려하는것이 좋습니다.

스트림 프로세서에서 장애가 발생하면?

코드가 실행되는 부분이기에 작성한 코드에서나 소프트웨어 서버에 장애가 발생 할 수 있습니다.

장애가 발생하면 스트리밍 매니저는 프로세서들을 다시 실행하거나 다른 서버로 프로세스를 옮겨 실행해야합니다.

헤드리스 실행(Running headless)이란?

매니저에 장애가 발생하는 상황을 '헤드리스 실행$Running headless$' 이라고 합니다.

스트리밍 매니저의 통제 없이 스트림 프로세서가 계속해서 실행되는 상황을 의미합니다.

따라서 매니저에 장애가 발생하면 프로세서의 통제가 되지 않기에 신규 프로세서 생성이나 장애발생 프로세스 복구가 불가능합니다.

k-내결함성$k-fault tolerant$

장애를 다루기 위한 모든 기술은 복제$Replication$과 조정$Coordination$을 기반으로 합니다.

스트림 매니저가 계산 중인 데이터의 상태를 다른 스트림 프로세서로 복제하고, 장애가 발생하면 미리 복제해둔 데이터를 활용하여 복구합니다.

k-내결함성 시스템에서 k는 장애를 허용하는 노드의 수를 말하며, 분산시스템에서는 투표를 위해 일반적으로 2k+1 의 노드가 있어야합니다.

상태 머신$State-machine$과 롤백복구$Rollback recovery$

상태머신 방식은 스트리밍 잡을 복제하고 동일한 입력을 모든 노드에 동일한 순서로 복제 데이터를 만드는 방식입니다.

그렇기에 복제 데이터를 받을 프로세서가 필요합니다.

자원이 들지만 빠르게 복구가 가능하기에 침입 감지 시스템과 같은 서비스에 적합합니다.

 

반면 롤백 복구 방식은 스트림 프로세서가 주지거으로 상태를 체크포인트로 다른 스트림 프로세서 노드 또는 디스크와 같은 비휘발성 데이터에 저장합니다.

디스크에 저장하기에 상대적으로 지연이 발생 할 수 있기에 내결함성이 중요하고 어느정도 지연이 허용되는 상황에 유용합니다.

 

---

이후 단계$저장, 접근$는 다음 포스팅에서 다루겠습니다!