03 카프카 프로젝트

3.1 카프카 프로젝트 설계

3.1.1 기존 데이터 아키텍처 인수

• 가상의 컨설팅 회사는 원격으로 전기 자전거를 관리하는 공장을 재설계한다.
• 센서는 모니터링하는 내부 장비 상태와 이 상태 이벤트를 지속적으로 제공하는 자전거 전체에 설치된다.
• 현재 시스템은 대부분의 메시지를 무시해야할 정도로 많은 이벤트가 생성되고 있다.

3.1.2 첫 변경

• 모든 데이터를 한 번에 카프카로 옮기는 빅뱅 접근 방식이 아닌, 당분간 기존 애플리케이션을 실행하면서 새로운 아키텍처를 시작한다.

3.1.3 내장 기능

• 카프카 커넥트의 용도는 자체 프로듀서와 컨슈머를 작성하지 않고 카프카 안팎으로 데이터 이동을 돕는 것이다.
• 커넥트는 스트리밍 작업을 시작하기 위해 이전에 구축한 부품을 간단하게 사용할 수 있도록 만드는 프레임워크이다.
• 코드 없이 구성만으로 어떤 파일로부터 데이터를 얻어 카프카에 입력할 수 있다.

3.1.4 주문 송장을 위한 데이터

• 커넥트는 사용자가 커스텀 커넥터 생성에 대한 깊이 있는 지식을 다른 사용자와 공유할 수 있게 한다.
• 커넥트는 다른 시스템과 상호작용을 표준화하며 비교적 간단하게 커넥터를 조합할 수 있다.
• 목표는 기존 시스템을 유지하면서 동시에 테이블 기반 데이터베이스 애플리케이션의 업데이트를 가져와서 새 애플리케이션을 개발하는 방법을 보여준다.
  • 첫번째 과정은 로컬에서 실행할 데이터베이스를 셋업한다.
  • 송장 테이블을 만들고 테이블에 일부 테스트 데이터를 삽입하기 위해 쿼리문을 실행한다.
  • 테이블을 설계할 때 변경사항을 캡처해 카프카에 넣는 방식을 생각해 보면 이해하는데 도움이 된다.
  • 대부분의 사용사례는 초기 로드 후 변경사항만 필요하다. 따라서, ID나 modified 열은 테이블에 어떤 데이터가 변경됐는지 카프카가 알 수 있도록 커넥트에게 가이드가 될 수 있다.
  • 카프카 커넥트의 기능이 기존 데이터베이스 테이블을 카프카로 옮기기에 훌륭하지만, 우리 센서(데이터베이스가 지원되지 않는 시나리오) 예제에서는 또 다른 기술이 필요하다.

3.2 센서 이벤트 설계

• 데이터를 카프카로 보내는 프로듀서 작성은 이번절의 요구사항에서 살펴본다.
• 유지 관리나 오류로 인해 다운되는 경우 처리 지연을 피하기 위한 추가적인 품질 검사 센서는 무시할 수 있다.
• 센서는 자전거의 모든 내부 단계에 부착되고, 현재 시스템에 있는 클러스터화된 데이터 베이스 시스템에 메시지를 보낸다.

3.2.1 기존 문제

• 데이터 사일로와 복구 가능성이라는 두 가지 과제를 처리하는 방법을 살펴보자.

데이터 사일로

• 공장에서 데이터와 그 데이터의 처리는 애플리케이션이 소유한다.
• 다른 사람이 그 데이터를 사용하려면 애플리케이션 소유자와 대화해야 한다.
• 원시 소스에 있는 데이터를 누구나 사용할 수 있게 만든다면, 애플리케이션 API가 데이터를 특정 형식으로 노출하거나 커스텀 변환 후 노출하는 것에 대해 걱정할 필요가 없다.

복구 가능성

• 카프카의 뛰어난 장점 중 하나는 실패를 고려하고 설계된다는 점인데, 예상되는 실패는 통제가 가능하다.
• 결함 혹은 로직 이슈가 있는 경우 콘솔 컨슈머의 --from-beginning 플래그로 토픽 처음부터 소비를 시작할 수 있다.
• 데이터 보존 기간을 통해 계속해서 사용할 수도 있다.
• 이벤트는 특정 인스턴스의 센서 소스에서 한 번만 생성되기 때문에 메시지 브로커는 소비 패턴에서 중요한 역할을 할 수 있다.
  • ex. 큐잉 시스템의 메시지 구독자가 메시지를 읽은 후 브로커에서 제거되는 등
• 토픽 리플레이는 WAL 개념과 비교해 볼 수 있는데, WAL 을 사용하면 시간이 지남에 따라 변경사항을 알 수 있다.

데이터를 언제 변경해야 하는가?

• 데이터를 카프카로 항상 먼저 가져오는 것이 좋다.
• 그러면 실패가 발생하는 경우에도 데이터를 리플레이 할 수 있다.

3.2.2 카프카가 적합한 이유

기존 시스템 문제점은 아래와 같다.

• 데이터베이스가 수직으로 확장하는데 비용이 많이 든다.
• 지속적으로 생상되는 이벤트가 있고, 이 시스템은 메시지를 지속적으로 처리할 준비가 되어 있어야 한다.

3.2.3 우리 설계에 대한 생각의 시작점

다음 질문 목록으로 설계 시 고려해본다.

• 시스템에서 메시지를 잃어도 괜찮은가?
• 어떤 방식으로든 데이터를 그룹화해야하는가?
  • 이벤트를 미리 그룹화하면 애플리케이션이 토픽을 읽는 동안 여러 컨슈머의 메시지를 코디네이트할 필요가 없다.
• 특정 순서로 데이터를 전달해야 하는가?
• 특정 항목의 마지막 값만 필요한가? 아니면 해당 항목의 이력이 필요한가?
• 얼마나 많은 컨슈머를 가질 것인가?
  • 모두 독립적인가? 일종의 순서를 유지해야 하는가?

3.2.4 사용자 데이터 요구사항

• 소비 서비스가 다운된 경우에도 메시지를 캡처할 수 있는 기능이 필요하다.
  • 예를 들어, 컨슈머 애플리케이션 중 하나가 원격 공장에서 다운된 경우 메시지가 완전히 삭제되지 않고 나중에 이벤트를 처리할 수 있도록 하고 싶다.
  • 애플리케이션이 유지 관리가 중단되거나 오류가 발생한 후 다시 시작될 때 필요한 데이터가 계속 유지되기를 바란다.
• 이전 정보와 함께 센서의 얼럿 상태 기록도 유지하려고 한다.
  • 추세를 결정하고 실제 사건이 장비 고장으로 이어지기 전 오류를 예측하는데 사용할 수 있다.
• 센서에 대해 직접 업데이트 하거나 쿼리를 푸시하는 모든 사용자의 감사 로그 유지
  • 규정 준수를 위해 센서 자체에 대해 누가 어떤 관리 작업을 수행했는지 알고 싶다.

3.2.5 질문을 적용하기 위한 상위 수준 계획

• 감사 로그를 만들기 위한 요구사항에 집중해보자.
  • 각 메시지에는 데이터 자체에 타임스탬프가 있기 때문에 감사 토픽 내에서는 순서가 중요지 않다.
  • 각 감사 이벤트는 별도의 이벤트로 끝내야 하기 때문에 그룹화가 필요 없다.
• 상태 요구사항에 관한 얼럿 추세는 자전거 시스템의 각 프로세스를 다루면서 추세를 파악하는 것이 목표다.
  • 키(관련 이벤트를 그룹화하는 방법)를 사용해 이 데이터를 그룹화하는 것이 도움이 될 수 있다.
  • 센서가 설치된 내부 시스템의 각 스테이지에서 자전거의 부품 ID 이름을 키로 사용할 가능성이 높다.
  • 주어진 스테이지의 모든 이벤트에서 키를 살펴보고 시간이 흐름에 따라 추세를 파악할 수 있기를 원한다.
• 상태에 대한 얼럿과 관련하여 프로세스 스테이지인 키로 그룹화하려고 한다.
  
  • 센서의 과거 상태가 아니라 현재 상태에 관심이 있다. (현재 상태만이 요구 사항에 대해 우리가 관심을 갖고 필요로 하는 것이다.)
  • 카프카는 수신한 새 이벤트를 내부적으로 로그 파일 끝에 추가한다. 결국, 로그는 변경할 수 없으며 파일 끝에만 추가할 수 있다.
    • 하지만 카프카는 로그 컴팩션이라는 프로세스로 업데이트처럼 보이게 한다.
  • 특정 얼럿 파티션에 할당된 컨슈머의 사용량이 중요하다
    • 예를 들어, 크리티컬 얼럿은 해당 이벤트를 신속하게 처리해야 하는 가동 시간 요구사항으로 먼저 처리된다.

3.2.6 청사진 검토

• 논리적으로 데이터 그룹은 감사 데이터, 얼럿 추세 데이터, 얼럿 데이터 로 생각할 수 있다.
• 우선 각 이벤트는 각 토픽에서 끝난다고 가정하여 일대일 매핑을 토앻 당분간 더 쉽게 당면한 요구사항에 집중한다.

3.3 데이터 형식

• 카프카 문서를 보면 아파치 에이브로라는 직렬화 시스템에 대한 정보를 발견할 수 있다.
• 에이브로는 에이브로 파일에 스키마 정의와 스키마 저장을 제공한다.

3.3.1 데이터를 위한 계획

• 카프카를 사용해 얻을 수 있는 중요 이점 중 하나는 프로듀서와 컨슈머가 직접 연결되어 있지 않다는 점이다.
• 카프카는 기본적으로 데이터 유효성 검사도 수행하지 않는다.
• 그러나 각 프로세스 또는 어플리케이션이 해당 데이터의 의미와 사용중인 형식을 이해할 필요는 있다.