견고한 데이터 엔지니어링 Chapter 5.2 원천 시스템의 실절적인 세부 사항

이 글은 스터디 활동에서 진행하는 견고한 데이터 엔지니어링 정리입니다.

Fundamentals of Data Engineering

---

5.3. 원천 시스템의 실절적인 세부 사항

 본 섹션에서는 최신 원천 시스템과의 실질적인 상호작용을 다루며 일반적으로 자주 사용하는 데이터베이스, API, 그리고 그 외 관련 사항에 대해 깊이 있게 살펴볼 것이다. 이러한 정보는 앞서 다룬 주요 아이디어에 비해 변화 속도가 빠르며, 인기 있는 API 프레임워크나 데이터베이스 같은 요소는 계속해서 빠르게 변하고 있다. 하지만 이러한 세부 사항들은 데이터 엔지니어에게 필수적인 지식이다. 이를 바탕으로 기본을 익히되, 최신 개발 동향을 파악하기 위해 폭넓게 학습할 필요가 있다.

5.3.1 데이터 베이스

데이터 엔지니어가 주로 다루는 원천 시스템의 데이터베이스 기술과 그 주요 고려사항을 설명한다. 데이터베이스는 다양한 데이터 활용 사례에 맞춰 여러 유형으로 분류되며, 각 데이터베이스는 고유의 특징과 요구 사항을 지닌다.

데이터베이스 기술의 주요 고려사항

• 데이터베이스 관리 시스템 (DBMS): 데이터 저장 및 서비스에 사용되는 시스템으로, 스토리지 엔진, 쿼리 최적화, 재해 복구 등 다양한 핵심 구성 요소로 구성된다.
• 조회 기능 (Lookups): 데이터베이스가 데이터를 조회하고 검색하는 방식. 인덱스는 조회 속도를 높이는 데 도움을 줄 수 있으며, B-트리와 로그 구조 병합 트리(LSM)와 같은 주요 인덱스 유형에 대한 기본 지식을 바탕으로 최적의 인덱스 설계를 고민하는 것이 필요하다.
• 쿼리 최적화: 데이터베이스가 쿼리 옵티마이저(최적화)를 사용하는지와 그 특성을 이해한다.
• 확장 및 분배: 수요에 따라 데이터베이스가 확장되는지와 적용되는 확장 전략을 고려해야 한다. 수평 확장(노드 추가) 또는 수직 확장(단일 머신 리소스 추가 추가) 여부가 여기에 포함된다.
• 모델링 패턴: 데이터베이스에 적합한 모델링 패턴(데이터 정규화 또는 넓은 테이블 등)은 무엇인가?
• CRUD 작업: 데이터의 조회, 생성, 업데이트, 삭제 방식은 데이터베이스에 따라 다르게 처리된다.
• 일관성: 데이터베이스가 완전한 일관성을 유지하는지, 혹은 완화된 일관성 모델(예: 궁극적 일관성)을 지원하는지, 그리고 읽기 및 쓰기 작업에서 선택적 일관성 모드를 제공하는지 확인한다.

 데이터베이스는 일반적으로 관계형과 비관계형 범주(category)으로 구분되며, 특히 비관계형 범주가 휠씬 다양하지만, 관계형 데이터베이스는 여전히 애플리케이션 백엔드에서 높은 비중을 차지한다.

 

관계형 데이터베이스 (Relational Database)

 관계형 데이터베이스 관리 시스템(RDBMS)은 애플리케이션 백엔드에서 널리 사용되는 데이터베이스 시스템으로, 1970년대 IBM에 의해 개발되어 이후 Oracle 등 주요 업체들에 의해 대중화되었다. RDBMS는 데이터를 테이블 형식으로 저장하며, 각 테이블은 행(relationship)과 열(field - column)로 구성된다. 각 행은 고유한 항목을 나타내며, 모든 열은 특정 데이터 유형(문자열, 정수 등)을 가진다. 이를 스키마라고 하며, 데이터의 구조를 정의하고 관리하는 데 필수적이다.

 

RDBMS는 행 수준에서 데이터를 저장하고 검색

 

 관계형 데이터베이스의 데이터는 일반적으로 기본 키(primary key)를 통해 고유하게 식별된다. 기본 키는 각 행을 고유하게 지정하며, 이를 통해 데이터 조회가 빠르고 효율적으로 이루어진다. 또한, 테이블 간 연관성을 나타내는 외래 키(foreign key)를 통해 여러 테이블에 걸쳐 데이터를 조인하여 복잡한 질의를 수행할 수 있다.

 

 관계형 데이터베이스는 정규화(normalization)를 통해 데이터를 중복 없이 저장하여 데이터 일관성을 유지한다. 정규화된 데이터 구조는 데이터 무결성을 보장하고, 데이터 중복으로 인한 불일치를 최소화한다. 또한, 관계형 데이터베이스는 일반적으로 ACID(원자성, 일관성, 고립성, 내구성) 특성을 유지하여 트랜잭션 안정성을 제공한다. 이러한 특성 덕분에 RDBMS는 빠르게 변화하는 애플리케이션 상태를 저장하기에 적합하다.

비관계형 데이터베이스: NoSQL

 관계형 데이터베이스(RDBMS)는 많은 사용 사례에서 매우 유용하지만 모든 상황에 적합하지 않다. 데이터와 쿼리 요구 사항이 다양해지면 관계형 데이터베이스는 확장성에서 한계를 보이기도 한다. 이때 특정 워크로드에 맞춘 비관계형 데이터베이스, 즉 NoSQL 데이터베이스가 등장한다. NoSQL이란 “Not Only SQL”의 약자로, 관계형 패러다임에서 벗어나 데이터를 유연하게 관리할 수 있는 데이터베이스들을 통칭한다.

 

 관계형 제약을 제거함으로써 NoSQL 데이터베이스는 성능, 확장성, 스키마 유연성에서 큰 장점을 가진다. 그러나 이와 맞바꿔 강력한 일관성, 조인, 고정 스키마 등의 RDBMS 특성은 다소 포기된다. 이는 아키텍처에서 트레이드 오프가 존재하는 대표적 예로, 최적의 데이터베이스를 선택할 때는 이러한 특성을 고려해야 한다.

 

 NoSQL 데이터베이스는 다양한 유형으로 나뉜다. 대표적인 NoSQL 유형으로는 키-값, 도큐먼트, 와이드 컬럼, 그래프, 검색, 시계열 데이터베이스가 있으며, 각 데이터베이스는 특정 워크로드와 요구에 따라 사용된다.

• 키-값 저장소: 고유 키로 레코드를 조회하며, 주로 세션 캐시나 내구성이 필요한 이벤트 데이터 관리에 사용된다.
• 도큐먼트 저장소: JSON 형식의 객체로 데이터를 관리하며, 유연한 스키마로 확장이 용이하다.
• 와이드 컬럼: 대규모 데이터와 높은 요청량을 처리하는 데 최적화된 데이터베이스로, 단일 인덱스와 행 키를 통해 데이터 조회를 지원한다.
• 그래프 데이터베이스: 데이터 간의 관계를 그래프 형태로 저장하여 소셜 네트워크 같은 복잡한 연결을 효율적으로 처리한다.
• 검색 데이터베이스: 텍스트와 로그 데이터를 빠르게 검색하고 분석하는 데 사용된다.
• 시계열 데이터베이스: 시간에 따른 연속적인 데이터를 기록하고, 효율적으로 검색하기 위한 구조로 설계되어 IoT와 이벤트 로그 처리에 적합하다.

키-값 저장소

 키-값 데이터베이스는 각 레코드를 고유하게 식별하는 키를 사용해 데이터를 조회하는 방식의 비관계형 데이터베이스이다. 이는 많은 프로그래밍 언어에서 사용되는 해시 맵이나 사전 데이터 구조와 비슷하지만, 더 확장 가능하게 설계되어 있다. 키-값 저장소에는 문서 저장소와 와이드 컬럼 데이터베이스를 포함한 여러 NoSQL 데이터베이스 유형이 존재한다.

 

 키-값 데이터베이스는 다양한 성능 특성으로 여러 애플리케이션 요구 사항을 충족한다. 예를 들어, 메모리 내 키-값 데이터베이스는 빠른 조회 속도와 높은 동시성을 필요로 하는 웹 및 모바일 애플리케이션에서 세션 데이터를 캐싱하는 데 널리 사용된다. 이 경우 데이터베이스가 종료되면 데이터가 사라지는 일시적인 스토리지를 제공해 주 애플리케이션 데이터베이스에 부하를 줄이고 빠른 응답을 가능하게 한다.

 

 반면, 내구성을 요구하는 애플리케이션에서도 키-값 저장소를 활용할 수 있다. 전자상거래 애플리케이션에서 사용자와 주문에 대한 이벤트 상태 변경을 저장하고 갱신하는 예가 있다. 사용자는 로그인 후 다양한 페이지를 탐색하고 쇼핑 카트에 항목을 추가하며 결제를 진행한다. 이러한 일련의 이벤트는 검색을 위해 내구성 있게 저장되어야 하며, 키-값 저장소는 데이터를 디스크와 여러 노드에 저장하여 이러한 요구를 충족시킨다.

 

도큐먼트 저장소  

 도큐먼트 저장소(document store)는 특수화된 키-값 저장소로, 각 도큐먼트를 중첩된 객체로 저장하며, 일반적으로 JSON 형식으로 생각할 수 있다. 도큐먼트는 컬렉션에 저장되고, 고유 키를 통해 검색된다. 컬렉션은 관계형 데이터베이스의 테이블과 유사하다. 그러나 관계형 데이터베이스와 달리, 도큐먼트 저장소는 조인을 지원하지 않아 데이터 정규화가 어렵고, 데이터를 여러 도큐먼트에 중복 저장해야 할 수 있다.

 

관계형 데이터베이스	도큐먼 데이터베이스
테이블	수집
열	문서, 엔티티 항목

 도큐먼트 저장소의 장점은 스키마나 데이터 타입을 강제하지 않는 유연성에 있으며, 이는 확장과 개발의 속도를 높인다. 하지만 스키마 진화가 잘 관리되지 않으면 데이터 일관성과 가독성이 저하될 수 있어 주의가 필요하다. 시간에 따라 데이터가 일관성 없이 비대해질 수 있고, 스키마의 진화가 적시에 전달 되지 않으면 다운스트림 수집을 중단시킬 수 있다. 

 

 또한, 대부분의 도큐먼트 저장소 는 관계형 데이터베이스처럼 ACID 특성을 보장하지 않는다. 예를 들어, 많은 도큐먼트 저장소는 결과적으로 일관성을 유지하며 클러스터 전체에 데이터가 분산된다. 이는 확장성과 성능을 높이지만, 이러한 일관성 모델을 정확히 이해하지 않으면 데이터 손실이나 처리 오류가 발생할 수 있다.

 

 문서 저장소에서 데이터를 분석할 때, 컬렉션에서 전체 데이터를 추출하는 전체 스캔 방식이나 CDC를 통해 이벤트 스트림으로 데이터를 전달하는 방식을 주로 사용한다. 하지만 전체 스캔은 데이터베이스 성능을 저하시킬 수 있으며 클라우드 환경에서는 상당한 비용이 발생할 수 있다. 이를 개선하기 위해 문서 저장소에서는 인덱스를 설정하여 검색 속도를 향상시킬 수 있다.

와이드 컬럼

 와이드 컬럼 데이터베이스는 초당 수백만 건의 요청을 처리하고 10ms 이하의 대기 시간을 유지하며, 페타바이트 규모의 데이터를 저장할 수 있는 비관계형 데이터베이스이다. 이러한 고성능 덕분에 전자상거래, 핀테크, 광고 기술, IoT, 실시간 개인화 애플리케이션 등에서 많이 사용된다.

 단일 인덱스(행 키)로 데이터 조회가 이루어지며 복잡한 쿼리에는 제한이 있기 때문에, 복잡한 분석이 필요할 경우 대규모 데이터 스캔이나 CDC를 통해 보조 분석 시스템으로 데이터를 전송하는 방식으로 처리해야 한다. 데이터 엔지니어는 최적의 성능을 위해 적절한 스키마 설계와 행 키 선택이 필요하다.

 

그래프 데이터베이스

 그래프 데이터베이스는 데이터를 수학적 그래프 구조(노드와 에지)로 저장하여 요소 간 연결성을 분석하는 데 최적화된 데이터베이스이다. 이 데이터베이스는 소셜 네트워크 같은 복잡한 관계를 효과적으로 처리할 수 있으며, 특히 서로 연결된 여러 요소 간의 순회 쿼리에 적합하다. Neo4j가 대표적인 그래프 데이터베이스로 인기를 끌고 있으며, Amazon과 Oracle도 그래프 데이터베이스 제품을 제공한다.

 

 예를 들어, 소셜 네트워크에서 각 사용자와 이들 간의 관계를 나타낼 때, 요소들 간의 복잡한 순회를 이해해야할 때, 그래프 데이터베이스는 이러한 연결 정보를 기반으로 복잡한 쿼리도 빠르게 처리한다. 노드에는 사용자 정보가, 에지에는 사용자 간의 관계가 저장되며, Cypher, SPARQL 등의 전용 쿼리 언어로 연결성 기반의 쿼리를 수행한다.

 

 그래프 데이터베이스는 빠르게 성장 중인 분야로, 복잡한 관계 분석이 필요한 데이터 과학, 머신 러닝에서도 중요하게 사용된다. 데이터 엔지니어는 그래프 데이터가 관계형 패러다임으로 전환이 가능한지 또는 그래프 데이터베이스 내에서 직접 분석할지 선택해야 한다.

 

검색 데이터베이스

 검색 데이터베이스는 텍스트나 로그 데이터의 복잡한 의미적, 구조적 특성을 빠르게 검색하고 분석하는 데 사용되는 비관계형 데이터베이스이다. 주요 사용 사례로는 텍스트 검색과 로그 분석이 있으며, 각각 다른 방식으로 활용된다.

• 텍스트 검색은 문서나 텍스트 본문에서 키워드 또는 특정 구문을 검색하여 관련성 있는 일치 항목을 찾는 작업이다. 이 과정에서 모호한 검색어도 유사성을 기준으로 일치하는 결과를 찾아내는 것이 특징이다.
• 로그 분석은 실시간 모니터링, 보안 분석, 이상 탐지, 운영 분석에 주로 사용된다. 시스템 이벤트와 관련된 로그 데이터를 빠르게 검색하고 분석하는 데 강점이 있다.

 검색 데이터베이스는 빠른 조회가 중요한 전자상거래 사이트에서 제품 검색을 최적화하거나, 운영 분석 및 KPI 보고서 생성과 같은 다운스트림 활용에 유용하다. Elasticsearch, Apache Solr, Lucene, Algolia와 같은 대표적인 검색 데이터베이스를 통해 텍스트와 로그 데이터를 빠르게 인덱싱하고 검색할 수 있어, 데이터 엔지니어링 작업에서 중요한 도구로 활용된다.

 

시계열 데이터

 시계열 데이터는 시간에 따라 기록되는 일련의 값으로, 주식 가격이나 대기 온도와 같은 변동적인 데이터를 포함한다. 이러한 시계열 데이터베이스는 시간의 흐름에 따라 데이터를 효율적으로 검색하고 처리하는 데 최적화되어 있어 IoT, 이벤트 로그, 애플리케이션 로그, 핀테크와 같은 대규모 고속 데이터 워크로드에 적합하다.

 

 시계열 데이터베이스는 측정 데이터와 이벤트 기반 데이터를 구분하여 처리한다. 측정 데이터는 온도 센서나 공기질 모니터링처럼 정기적으로 발생하는 반면, 이벤트 기반 데이터는 모션 센서에서 움직임을 감지했을 때와 같이 불규칙적으로 발생한다. 이 데이터베이스는 빠른 쓰기 성능을 위해 메모리 버퍼링을 활용하고, 일반적으로 시간별로 정렬된 타임스탬프와 몇 개의 필드로 구성된 단순한 스키마를 가진다.

 

 시계열 데이터베이스는 고속 운영 분석에 유리하지만 BI 사용 사례에는 적합하지 않으며 조인 기능이 일반적이지 않다. 다만, Apache 드루이드와 같은 일부 유사 시계열 데이터베이스는 제한적인 조인을 지원한다.

 5.3.2 API

 API는 클라우드, SaaS 플랫폼 및 내부 시스템 간의 데이터 교환을 위한 표준화된 인터페이스로, 현재 많은 시스템에서 보편적으로 사용된다. 특히 웹과 클라우드 환경에서 HTTP 기반 API가 가장 많이 사용한다.

 

REST

 

REST는 웹 애플리케이션과 서버 간의 데이터 교환을 단순화하는 HTTP 기반 API 설계 방식이다. HTTP 메서드인 GET, POST, PUT 등을 사용해 클라이언트와 서버가 통신하며, 각 요청과 응답은 별도의 세션 정보를 유지하지 않는 무상태성(stateless)을 갖는다. REST의 간결성과 유연성 덕분에 다양한 웹 서비스와 애플리케이션에서 널리 사용된다. 그러나 명확한 스펙이 정해져 있지 않아, 각 서비스마다 구현 방식이 달라 API 활용 시 도메인 지식이 필요할 수 있다.

 

GraphQL  

 GraphQL은 Facebook에서 개발한 API 쿼리 언어로, REST API의 대안으로 자주 사용된다. REST API가 고정된 엔드포인트에서 정해진 데이터 모델을 반환하는 데 비해, GraphQL은 단일 요청을 통해 여러 데이터 모델에 걸쳐 필요한 정보를 한 번에 조회할 수 있어 더 유연하고 표현력이 높은 쿼리가 가능하다. GraphQL은 JSON 형태의 요청과 응답을 기본으로 하며, 이를 통해 개발자가 원하는 데이터 구조와 정확히 일치하는 결과를 얻을 수 있다.

웹훅

  웹훅은 이벤트 기반 데이터 전송 방식으로, 원천 시스템에서 특정 이벤트가 발생하면 소비자의 HTTP 엔드포인트에 POST 방식으로 데이터를 전송해 다운스트림 프로세스를 트리거한다. 연결이 소스에서 데이터 싱크로 이동하므로 종종 ‘역 API’라고 불리며, 고속 대용량 데이터 수집에 메시지 큐와 함께 사용된다.

 

POST 방식 : 데이터 전송을 기반으로 한 요청 메서드

 

 RPC와 gRPC

 RPC는 원격 시스템에서 프로시저를 실행하기 위해 사용되는 분산 컴퓨팅 기술로, 분산 시스템 간 통신을 간소화한다. gRPC는 구글이 개발한 고성능 RPC 프레임워크로, Protocol Buffers를 사용해 데이터를 효율적으로 직렬화하고 HTTP/2를 통해 양방향 스트리밍을 지원한다. 이를 통해 REST보다 더 빠르고 효율적인 데이터 교환이 가능해, 구글 서비스와 여러 클라우드 애플리케이션에서 활용된다.

 

 

5.3.3 데이터 공유

 클라우드 기반 데이터 공유는 멀티테넌트 시스템을 통해 여러 사용자 간에 안전하게 데이터를 공유하도록 지원한다. 클라우드 데이터웨어하우스와 객체 스토리지는 세밀한 권한 관리와 데이터 필터링 기능을 제공해 다양한 공유 방식을 가능하게 한다

 

 데이터 마켓플레이스는 데이터를 사고팔 수 있는 환경을 제공하며, 조직 내부에서는 데이터 공유를 통해 부서 간 효율적인 데이터 관리와 비용 분배가 가능하다. 이를 통해 데이터 메시 같은 분산형 데이터 관리가 용이해지고, 단순하고 효율적인 데이터 교환이 가능해진다.

 

서드파티 데이터 원천

서드파티 데이터 원천의 주요 목적은 데이터를 사용자가 쉽게 접근하고 애플리케이션에 통합할 수 있도록 하는 것이다. 많은 기업과 정부 기관은 이를 위해 API, 클라우드 데이터 공유, 데이터 파일 다운로드를 제공한다. 예를 들어, CRM 데이터는 기업이 고객 정보를 분석하고, 추가적인 스코어링 모델을 통해 더 정교한 고객 맞춤 서비스를 제공하는 데 활용된다. 기업은 이러한 데이터 통합을 통해 더 높은 사용자 참여와 고객 경험 향상을 목표로 한다.

 

5.3.5 메시지 큐와 이벤트 스트리밍 플랫폼

메시지 큐와 이벤트 스트리밍 플랫폼은 이벤트 기반 아키텍처의 핵심으로, 클라우드 설정의 용이성과 실시간 분석의 수요 증가에 따라 중요성이 커지고 있다. 메시지 큐는 주로 마이크로서비스 간 메시지 전달을 돕고, 이벤트 스트리밍 플랫폼은 초당 수백만 개의 이벤트 데이터를 실시간으로 수집하고 처리하는 데 사용된다.

 

메시지 큐

 메시지 큐는 게시 및 구독 모델을 통해 시스템 간에 비동기적으로 작은 메시지를 전송하는 메커니즘으로, 데이터는 메시지 큐에 게시된 후 구독자가 수신을 확인하고 큐에서 제거된다. 이를 통해 애플리케이션과 시스템 간의 결합을 낮추고, 특히 마이크로서비스 아키텍처에서 중요한 역할을 한다.

 

간단한 메시지 큐

메시지의 순서 지정 및 전달

 메시지의 순서는 구독자에게 영향을 미치며, 분산 메시지 큐에서는 이를 유지하기 어렵다. 일반 큐는 선입선출(FIFO)을 적용하지만, 고도로 분산된 시스템에서는 메시지가 순서 없이 도착할 수 있다. 예를 들어, Amazon SQS의 표준 큐는 순서를 유지하려고 하지만, FIFO 큐를 통해 더 강력한 순서 보장이 가능하다. 다만, 메시지 큐 기술에서 명확한 순서 보장이 없는 경우, 순서와 관계없이 메시지를 처리하도록 설계하는 것이 중요하다.

 

전달 빈도

 메시지 순서는 구독자에게 중요한 요소로, 특히 분산 메시지 큐에서는 순서 보장이 어려울 수 있다. 메시지 전달 방식은 "정확히 한 번" 또는 "적어도 한 번"으로 구분되며, 멱등성을 유지하면 중복 처리에도 결과가 일관되게 유지된다.

 

멱등성 : 동일한 연산을 여러 번 수행해도 결과가 달라지지 않는 성질

 

확장성

 메시지 큐는 수평적 확장을 지원하여 여러 서버에 걸쳐 메시지를 버퍼링하고 장애 발생 시 안전하게 저장하는 복원력을 제공한다. 그러나 확장이 복잡성을 수반할 수 있다.

 

이벤트 스트리밍 플랫폼

 이벤트 스트리밍 플랫폼은 메시지 큐와 유사하게 메시지를 전달하지만, 데이터의 정렬된 로그에 기반하여 과거 메시지 재생이 가능하다. 이는 실시간 데이터 흐름을 분석하고 처리하는 데 적합하다.

 

토픽

 이벤트 스트리밍 플랫폼에서 프로듀서는 이벤트를 특정 주제(topic)에 스트리밍하여 관리한다. 주제는 특정 종류의 관련 이벤트 모음이며, 예를 들어 사기 경고, 고객 주문, IoT 기기의 온도 측정과 같은 이벤트가 포함될 수 있다. 각 주제는 여러 프로듀서와 소비자를 가질 수 있어 유연한 데이터 전송이 가능하다.

 

 주제를 통해 다양한 소비자가 동일한 이벤트를 수신할 수 있으며, 이를 통해 분석과 이벤트 기반 프로세스 간의 경계를 자연스럽게 넘나들 수 있다. 예를 들어, 고객 주문 이벤트가 fulfillment와 marketing 주제를 통해 전송되면 주문 이행을 트리거하면서 동시에 마케팅 분석에 활용될 수 있다.

주문 처리 시스템은 이벤트(작은 사각형)를 생성하여 web orders 토픽에 게시한다. 두 명의 구독자— marketing및 fulfillment—가 토픽에서 이벤트를 가져온다.

스트림 파티션

 스트림 파티션은 스트림을 여러 부분으로 나누어 병렬 처리를 가능하게 하고 처리량을 높인다. 마치 다중 차선 고속도로처럼 파티션을 통해 메시지를 여러 경로로 분산해 각 파티션을 독립적으로 처리할 수 있다. 파티션 키를 사용해 특정 메시지가 항상 같은 파티션에 저장되도록 설정할 수 있으며, 이는 메시지 순서를 유지하고 특정 기준에 따라 데이터를 분배하는 데 유리하다.

 

 예를 들어, 각 메시지에 고유한 ID를 파티션 키로 지정하고 ID를 기준으로 파티션을 나눌 수 있다. IoT 환경에서는 장치 ID를 파티션 키로 설정해 동일한 기기의 메시지가 같은 서버로 보내지도록 하여 처리의 일관성을 유지할 수 있다.

 

 그러나 파티션 설정 시 주의할 점은 핫스팟팅을 피하는 것이다. 특정 파티션에 메시지가 집중되는 현상은 시스템의 과부하를 초래할 수 있다. 이를 방지하려면 파티션 키가 데이터를 균등하게 분산하도록 설정해 모든 파티션이 고르게 활용되도록 해야 한다.

 

핫스팟팅 : 파티션 하나에 전달되는 메시지의 수가 불균형한 현상 

 

내결함성과 복원성

 내결함성과 복원성은 이벤트 스트리밍 플랫폼의 강점으로, 분산된 노드들이 장애 발생 시 데이터를 안전하게 보존하며 접근을 보장한다. 이러한 내구성 덕분에 스트리밍 플랫폼은 이벤트 데이터를 안정적이고 지속적으로 관리하는 데 적합하다.

소스 시스템에 접근하려면 시스템 및 데이터 이해 관계자들과 원활한 협력 관계를 구축하는 것이 중요하다. 시스템 이해 관계자는 소스 시스템을 설계하고 유지보수하는 소프트웨어 엔지니어나 개발자, 제3자일 수 있으며, 데이터 이해 관계자는 필요한 데이터 접근을 관리하는 IT 또는 데이터 거버넌스 팀으로 구성된다. 이들은 종종 다른 팀이지만, 동일한 경우도 있다.

5.4 함께 작업할 대상

 데이터 원천 접근 시 함께 일하게 될 이해관계자를 파악하는 것은 중요하다. 데이터 엔지니어링 성공의 핵심은 데이터 원천 이해관계자와의 원활한 소통과 관계 구축에 있다.이해관계자는 주로 시스템 이해관계자와 데이터 이해관계자로 나눌 수 있다. 시스템 이해관계자는 데이터를 생성하고 관리하는 시스템을 구축·운영하는 소프트웨어 엔지니어, 애플리케이션 개발자 등이 포함되며, 데이터 이해관계자는 데이터 접근과 관리를 책임지는 IT 및 데이터 거버넌스 팀으로 구성된다. 이들이 종종 동일 팀이 아닐 때가 많기 때문에 원활한 협력이 중요하다.

 

 특히 업스트림 데이터 소유자와 데이터 계약을 체결하면 유용하다. 이 계약은 데이터 추출 방식, 빈도, 추출 담당자 등의 세부 사항을 포함해 데이터 소비를 보장하고, 협업을 명확히 한다. 필요 시 SLA(서비스 수준 계약)와 SLO(서비스 수준 목표)를 설정하여 데이터 가용성과 품질에 대한 기대치를 수립하는 것도 좋은 방법이다.

 

데이터 엔지니어의 업스트림 이해관계자

 

5.5. 드러나지 않는 요소가 원천 시스템에 미치는 영향

 데이터 엔지니어링 라이프사이클의 다른 부분들과 달리, 데이터 원천 시스템은 보통 데이터 엔지니어의 직접적인 통제 범위를 벗어나 있다. 따라서 데이터 엔지니어는 데이터 원천 담당자들이 DataOps, DevOps, 데이터 아키텍처 및 관련 모범 사례를 준수하도록 협력하는 것이 중요하다. 이렇게 해야 데이터 생성과 관련된 작업이 원활하게 이루어져 이후 데이터 처리 과정도 원활해진다.

5.5.1 보안

데이터 보안은 데이터 원천 시스템을 다룰 때 매우 중요한 요소다.

• 데이터 암호화: 데이터는 저장 중이든 전송 중이든 안전하게 암호화되어야 한다.
• 접근 보안: 공용 인터넷이 아닌 가상 사설망(VPN) 등을 통해 접근하는 것이 안전하다.
• 자격 증명 보호: 비밀번호, 토큰, SSH 키와 같은 인증 정보를 안전하게 관리하여 키 관리자나 비밀번호 관리자, Single Sign-On(SSO) 솔루션을 활용하자.
• 출처 신뢰성: 데이터 원천 시스템이 신뢰할 수 있는지 확인하여 악의적 행위자로부터 데이터를 받는 위험을 방지하자.

5.5.2 데이터 관리

 대개 원천 시스템에 대한 직접적인 제어는 제한적이기 때문에, 데이터를 수집하고 저장하며 변환할 때 이러한 제약을 고려해야 한다. 

• 데이터 거버넌스: 데이터와 시스템이 신뢰성 있게 관리되고 있는지, 누가 관리 책임을 가지는지 확인한다.
• 데이터 품질: 데이터 품질과 무결성을 보장하기 위해 원천 시스템 팀과 기대치를 설정하고 협력한다.
• 스키마 : 예상되는 스키마 변화를 사전에 인지하고 이를 조율할 수 있도록 원천 시스템 팀과 소통한다.
• 마스터 데이터 관리: 원천 시스템이 마스터 데이터 관리 규칙을 따르고 있는지 확인한다.
• 개인정보보호 및 윤리: 원천 데이터 접근 시 개인정보보호, 데이터 난독화 여부, 보관 정책을 준수하며 데이터를 사용한다.
• 규제 준수: 필요한 규정에 따라 데이터를 접근하는가?

5.5.3 데이터 옵스

DataOps는 데이터 엔지니어링 라이프사이클의 운영 우수성을 목표로 하며, DevOps와 유사하게 자동화, 관찰 가능성, 사고 대응에 중점을 둔다. 원천 시스템의 가동 상태 및 성능을 모니터링하고, 장애 발생 시 신속히 대응하는 프로세스를 마련하는 것이 DataOps의 핵심이다.

• 자동화: 원천 시스템과 데이터 워크플로 자동화가 독립적으로 운영되도록 구성하여 상호 영향을 최소화하는 것이 중요하다.
• 관찰 가능성: 시스템 가동 시간, 데이터 품질, 스키마 적합성 등을 모니터링하고 필요한 검사를 통해 다운스트림 데이터 요구사항이 충족되는지 확인한다.
• 사고 대응: 원천 시스템 장애 시 데이터 파이프라인의 동작 계획과 시스템 복구 후 데이터 누락분을 백필할 전략을 마련해 두는 것이 필요하다.

5.5.4 데이터 아키텍처

 데이터 아키텍처는 원천 시스템의 설계와 성능을 이해하고, 해당 시스템이 데이터 파이프라인 요구에 부합하는지 파악하는 과정이다. 데이터 엔지니어는 원천 시스템 담당 팀과 협력하여 아키텍처의 신뢰성, 내구성, 그리고 사용 가능성을 파악해야 한다. 이 과정에서 시스템의 예측 가능성과 안정성을 확인하고, 하드웨어 오류나 네트워크 장애와 같은 예상치 못한 상황에도 데이터가 안전하게 보존될 수 있도록 설계되었는지 검토한다. 또한, 아키텍처 변경이나 문제 발생 시 신속하게 대응할 수 있도록 담당자와 협력하며 SLA를 통해 안정성을 확보하는 것이 중요하다.

 

5.5.5 오케스트레이션

 데이터 엔지니어링에서 원천 시스템 오케스트레이션은 데이터 접근 주기와 빈도를 설정하고, 데이터 요청이 정기적인지 혹은 수시로 가능한지 파악하는 데 중점을 둔다. 또한 Kubernetes나 Airflow 같은 공통 오케스트레이션 프레임워크를 활용해 통합할 경우, 시스템의 일관성과 효율성을 높일 수 있으나 긴밀한 결합으로 인한 잠재적 위험도 고려해야 한다.

 

5.5.5 소프트웨어 엔지니어링

 데이터 환경에서 원천 시스템 접근을 위한 코드를 작성할 때는 네트워킹, 인증, 접근 패턴, 오케스트레이션 통합, 병렬화, 그리고 배포가 핵심 고려 사항이다. 네트워크 안전성을 유지하면서 필요한 자격 증명을 적절히 관리하고, API나 데이터베이스 드라이버와 같은 접근 방식에 맞춰 오류 처리와 시간 초과를 설정해야 한다. 병렬 접근으로 효율성을 높이되, 오케스트레이션 프레임워크와의 통합을 통해 자동화된 워크플로를 구축하고 배포 프로세스를 체계적으로 관리해야 한다.

 

문제

비관계형 데이터베이스(NoSQL)의 장점으로 적절한 것을 고르시오.

 

a) 강력한 조인 기능 제공
b) 데이터 중복 최소화
c) 성능과 확장성에서 우수함
d) 정규화된 데이터 저장

답 : c) 성능과 확장성에서 우수함

 

REST API는 상태 정보를 유지하여 각 요청이 이전 요청과 연관된다. (O/X)

답 : X (REST API는 무상태성으로, 각 요청은 독립적입니다.)

GraphQL은 단일 요청으로 여러 데이터 모델에 걸친 정보를 조회할 수 있어 REST보다 유연한 쿼리가 가능하다. (O/X)

답 : O