[Web Service] 3. Web Service에서 발생하는 데이터의 종류 및 특징

1. Use Cases

출처 : Joey 교육자료

 

2. 서버 엔지니어(Server Engineer)가 다루는 데이터

데이터 엔지니어링의 특수성이 어디서 나오는지 구분하기 위해 데이터의 성격을 구분한 것이다. 꼭 서버 엔지니어는 이런 데이터만 다루고, 데이터 엔지니어는 어떤 데이터만 다룬다는 의미가 아니다. 비즈니스나 데이터가 커지다보면, 데이터의 성격에 따라 기술 스택도 다른 것이 필요하게 된다. 그 과정에서 역할이 나뉘다 보면 자연스럽게 이런 식으로 서버 엔지니어와 데이터 엔지니어의 역할이 나뉘게 된다. 백엔드(서버) 쪽을 한다면 모두 잘 다루는 것이 좋다.

 

2.1 Transaction (거래 데이터)

거래 요청이 있고 요청에 대한 처리의 결과가 있는 데이터로서, 비즈니스나 시스템에서 빈번하게 생성되고 업데이트 되는 데이터를 의미한다.

 

전자상거래 시스템 예시

• 상품주문
• 결제
• 환불 요청
• 기술적으로 시스템의 여러 동작/기능이 하나로 연결되어야 하고, 완결될 때 모두 같은 상태가 되는 경우 (all or nothing)

 

2.2 Metadata (메타데이터)

비즈니스나 도메인을 구성하는 추상화된 정보로서 시스템을 다루는 이해관계자(stakeholders)나 제품에 대한 상태 정보 등이 여기에 속한다. 메타데이터는 업데이트 될 수 있으나, 자주 업데이트 되진 않는다.

 

전자상거래 시스템 예시

• 회원의 기본 정보
• 판마재의 기본 정보
• 판매자가 등록한 상품 정보
• 광고주가 설정한 광고요청 설정
• 시스템의 설정 정보

 

3. 데이터 엔지니어(Data Engineer)가 다루는 데이터

데이터 엔지니어가 다루는 데이터의 특징

• 하나의 메세지가 그 자체로 완결성을 가짐
• 하나의 메세지는 Immutable 함
  1. 메세지 발생 이후 메세지 안의 값을 변경하지 않음
  2. 요구사항에 따라 파이프라인에서 특정 데이터를 추가/삭제 정도만 수행
• 메세지 안에 메세지의 고유값(다른 메세지들과 비교해서 unique함을 판단할 수 있는)을 구분할 수 있음
• 시간 정보가 항상 있음

 

3.1 Event

하나의 독립된 사건을 알리는 데이터로서 데이터의 발생만 있고 응답은 필요 없는 데이터이다. 발생한 데이터를 추후 활용해야 비즈니스/도메인의 의미가 부여된다. 또한, 언제나 발생시간(timestamp) 정보를 갖고 있다.

 

다음과 같은 상황에서 Event 데이터를 남김

• 거래 데이터가 아니지만, 비즈니스에 필요한 데이터인 경우
• 하나의 사건 이후에 여러 거래들이 후처리되어야 하는 경우
• Transaction으로 처리할 수도 있지만, 꼭 하나로 연결될 필요는 없어 독립된 여러 이벤트로 정의/발생시킨 뒤, 추후에 분석단계에서 엮어 활용하고 싶은 경우

 

3.2 Log

어떤 시스템이나 거래 중간에 순간의 정보를 기록한 데이터로서 Event와 의미가 거의 같거나 비슷하다. (사실, 구분하는 것 자체가 무의미할 수도 있음). 프로그래머의 관행상 파일로 남기는 event data를 로그라고 한다.

 

Event와 Log의 처리에서는 다음과 같은 기술적 주제를 다룸

• 하나의 사건 이후에 여러 거래들이 후처리 되어야 하는 경우
  • Message Queue를 이용한 Pub-Sub Model
• 실시간 Event 전송
  • Streaming, CDC
• Event, Log의 Visualization
  • ES(OS) - Kibana
• Event, Log의 Data Cleansing
  • Streaming, Batch

 

3.3 Aggregation

Raw-data(원본/원천데이터)로부터 비즈니스에 필요한 데이터를 얻기 위해 집계, 통계를 이용해서 데이터를 만든다.(주로, 합계, 평균, 추이를 나타내는 데이터를 만듦) 또한, 시간 또는 범위가 있는 시간 정보가 항상 있다.

 

Aggregation은 데이터 분석을 맡은 사람이 ad-hoc하게 하기도 함. 다음의 경우에는 데이터 엔지니어링 기술이 좀 더 본격적으로 필요함

• 비즈니스를 위해 지속적으로 집계 데이터가 필요한 경우
  1. Batch(ETL), Streaming 시스템
  2. 안정성과 신뢰성을 갖춘 시스템
• 집계 대상이 되는 데이터 사이즈가 큰 경우
  1. DB, OLAP 시스템
  2. Back-up, Merge, Partitioning, Sharing
• 집계 대상이 되는 데이터(데이터 소스 또는 테이블)가 많음 경우
  1. Denormalize, Star-Schema
  2. OLAP Cube
• 도메인의 특수성이 있는 경우

 

[ Idempotent ]

• Aggregation을 잘하기 위해서는 idempotent(멱등성)을 보장하는 시스템을 만들어야 함
• idempotent하다는 것(멱등성이 있다)은 같은 대상(raw-data)에 대해 재처리를 하면 언제나 똑같은 결과가 보장되어야 한다는 의미