개발자

헤드리스 데이터 아키텍처를 위한 개발자 가이드

Adam Bellemare | InfoWorld 2024.08.07
헤드리스(headless) 아키텍처는 더 이상 여러 데이터 복사본을 조정할 필요 없이 작업에 가장 적합한 처리 또는 쿼리 엔진을 자유롭게 사용할 수 있음을 의미한다. 이 아키텍처가 어떻게 작동하는지 알아보자.
 
헤드리스 데이터 아키텍처는 데이터를 쓰고 처리하고 쿼리하는 서비스에서 데이터 저장, 관리, 최적화, 액세스를 분리하는 데 따라오는 유기적 결과물이다. 이 아키텍처에서는 권한, 스키마 진화, 테이블 최적화를 포함하여 하나의 논리적 위치에서 데이터를 관리할 수 있다. 또한 데이터가 필요한 처리 엔진마다 복사되는 것이 아니라 한 곳에만 위치하므로 규정 준수도 훨씬 간단해진다.
 
ⓒ Getty Images Bank
 
‘헤드리스’ 데이터 아키텍처라는 이름은 각자의 모니터와 키보드를 사용해서 로그인해야 하는 ‘헤드리스 서버’와의 유사성에 착안해 만들어졌다. 헤드리스 데이터 아키텍처에서 데이터를 처리하거나 쿼리하려면 자신의 처리 또는 쿼리 "헤드"를 가져와서 데이터에 연결해야 한다(예를 들어 트리노(Trino), 프레스토(Presto), 아파치 플링크(Flink), 아파치 스파크(Spark) 등). 
 
헤드리스 데이터 아키텍처는 여러 데이터 형식을 포함하는데, 가장 일반적인 형식은 데이터 스트림과 테이블, 두 가지다. 스트림은 증분 데이터에 대한 저지연 액세스를 제공하며 테이블은 효율적인 대량 쿼리 기능을 제공한다. 이 둘을 함께 사용하면 운영, 분석 또는 그 사이의 무엇이든 해당 사용례에 가장 적합한 형식을 유연하게 선택할 수 있다.

먼저 헤드리스 데이터 아키텍처의 스트리밍부터 살펴보자.
 

헤드리스 데이터 아키텍처를 위한 스트림

오픈소스 분산 이벤트 기반 스트리밍 플랫폼인 아파치 카프카(Kafka)는 처음부터 헤드리스 데이터 모델을 사용했다. 카프카는 API, 데이터 스토리지 계층, 액세스 제어, 클러스터에 대한 기본적인 메타데이터를 제공한다. 생산자가 주제에 대해 쓰면 이후 하나 이상의 소비자가 자신에게 적절한 시점에 이 주제에서 데이터를 읽을 수 있다.
 
생산자는 완전히 독립적인 헤드 역할을 한다. 고, 파이썬, 자바, 러스트 또는 C 언어 등으로 작성 가능하며 카프카 스트림이나 아파치 플링크 등 인기 있는 스트림 처리 프레임워크도 사용할 수 있다. 소비자 역시 비슷하게 독립적이다. 예를 들어 소비자 중 하나는 카프카 커넥트 인스턴스, 하나는 파이썬이고 다른 하나는 C로 작성된 소비자일 수 있다.
 
헤드리스 데이터 아키텍처의 완전한 스트리밍 지원을 위해서는 부가적인 기능이 필요하다. 우선 이벤트에는 스키마 레지스트리에서 제공 및 강제하는 대로 신뢰성과 안전을 위해 잘 정의된 명시적인 스키마가 필요하다. 또한 소유권을 추적하고 태그 및 비즈니스 메타데이터를 관리하고 탐색, 발견 및 계보 기능을 제공하기 위한 메타데이터 카탈로그도 필요하다.
 
스트림은 전자상거래 주문 처리, 재고 주문, 비즈니스의 기반이 되는 복잡한 워크플로우 조율과 같은 운영 사용례에서 일반적으로 사용된다. 분석 사용례를 구축하기 위해 스트림을 사용할 수도 있지만, 테이블을 기반으로 하는 주기적인 일괄 처리 기반의 계산에 의존할 수도 있다. 테이블을 헤드리스 데이터 아키텍처에 통합하려면 어떻게 해야 할까?
 

헤드리스 데이터 아키텍처의 테이블

테이블은 오랜 기간 데이터 호수와 데이터 웨어하우스의 핵심 요소였지만 전통적으로 독점적 데이터베이스에 의해 정의됐다. 즉, 테이블을 쿼리하려면 처음에 그 테이블을 저장한 데이터베이스 엔진을 사용해야 했다.
 
지금은 아파치 파케이(Parquet)와 같은 인기 있는 오픈소스 형식에 의존해서 기반 데이터에 대한 명확한 정의를 제공한다. 테이블 정의는 여전히 기반 파일과는 별개다. 이 분야에서는 오픈소스 데이터 관리 프로젝트인 아파치 아이스버그(Iceberg)가 인기를 얻고 있다. 아이스버그는 열 형식 데이터(파케이 포함)를 위한 견고하고 강력한 파일 시스템 관리자이며 헤드리스 데이터 아키텍처에서 테이블을 구현하기 위한 여러 핵심 구성요소를 제공한다.


아파치 아이스버그 주요 구성요소:
  1. 첫 번째 구성요소는 테이블 저장 및 최적화다. 아이스버그는 일반적으로 아마존 S3와 같은 즉시 사용 가능한 클라우드 스토리지를 사용해서 테이블을 구축하기 위한 모든 데이터를 저장한다. 아이스버그는 파일 압축, 버전 관리와 같은 최적화를 포함한 데이터 저장과 유지보수를 관리한다.
  2. 아이스버그 카탈로그. 이 카탈로그에는 메타데이터, 스키마, 테이블 정보(예를 들어 어느 테이블이 어디에 있는지 등)가 포함된다. 아이스버그 카탈로그에 테이블을 선언하면 처리 및 쿼리 엔진을 연결해 기반 데이터에 액세스할 수 있다.
  3. 트랜잭션. 아이스버그는 트랜잭션과 동시 읽기 및 쓰기를 지원하므로 여러 헤드가 서로 영향을 미치지 않으면서 무거운 작업을 실행할 수 있다.
  4. 아이스버그는 시간 이동 기능을 제공한다. 특정 시점의 테이블에 대해 쿼리를 실행할 수 있으므로 감사와 버그 수정, 회귀 테스트에 매우 유용하다.
  5. 아이스버그는 연결 가능한 중앙 데이터 계층을 제공한다. 플링크, 트리노, 프레스토, 하이브, 스파크, 덕DB(DuckDB)와 같은 오픈소스 옵션 또는 빅쿼리, 레드시프트, 스노우플레이크, 데이터브릭스와 같은 인기 있는 SaaS 옵션을 연결할 수 있다.
 
이러한 서비스를 통합하는 방법은 다양하지만 일반적으로 아이스버그 카탈로그의 메타데이터를 복제해서 처리 엔진이 파일의 위치와 쿼리 방법을 알 수 있도록 한다. 사용 중인 처리 엔진의 설명서에서 아이스버그 통합에 대한 부분을 참고하면 더 많은 정보를 볼 수 있다.
 

헤드리스 데이터 아키텍처의 이점

헤드리스 데이터 아키텍처의 주된 이점은 무엇일까?
 
  1. 더 이상 데이터를 이리저리 복사할 필요가 없으므로 많은 비용과 시간이 절약된다. 예를 들어 AWS 사용자는 데이터를 옮기지 않고도 아테나(Athena), 스노우플레이크, 레드시프트에 테이블을 연결할 수 있다.
  2. 더 이상 여러 데이터 복사본을 조정할 필요가 없고 비슷하지만 다른 데이터 집합을 제거해서 데이터 파이프라인을 줄일 수 있다.
  3. 작업에 가장 적합한 헤드를 선택할 수 있다. 예를 들어 한 작업에는 플링크, 다른 작업에는 덕DB를 사용할 수 있다. 처리 엔진에서 데이터가 추상화되므로 더 이상 하나의 프로세서에 "묶이지" 않는다. 몇 년 전에 데이터를 엔진에 로드했다는 이유만으로 그 엔진에 종속되는 일이 없다.
  4. 단일 액세스 제어 지점을 통해 모든 프로세서에 대한 데이터 계층에서 액세스를 제어할 수 있다. 개인정보, 금융 정보의 경우 더 세분화된 제어를 선택해서 데이터 안전을 보장할 수 있다.
 

헤드리스와 데이터 호수 아키텍처 간의 중요한 차이점

헤드리스 데이터 아키텍처와 데이터 호수 아키텍처에는 세 가지 중요한 차이점이 있다.
 
  1. 헤드리스 데이터 아키텍처에서는 모든 서비스가 데이터를 사용할 수 있다. 분석이든 운영이든 그 중간의 무엇이든 관계없다. 헤드리스 아키텍처의 핵심은 데이터 액세스를 쉽게 하고 필요한 곳에 연결할 수 있도록 하는 것이며, 단순히 분석 툴 모음으로 제한되지 않는다.
  2. 비즈니스 사용례와 요구사항에 따라 테이블, 스트림 또는 두 가지 모두 자유롭게 사용할 수 있다.
  3. 헤드리스 데이터 아키텍처에서는 모든 데이터를 하나의 중앙 위치로 복사할 필요가 없다. 일반적으로 다양한 데이터 소스에서 데이터 계층을 구성해서 모듈형 데이터 계층을 만든다.
 
또한 헤드리스 데이터 아키텍처는 데이터 호수와 웨어하우스를 구축할 수 있게 해준다. 아이스버그 테이블을 데이터 호수 또는 데이터 웨어하우스에 연결하고 외부 테이블로 등록하기만 하면 된다. 물론 파이프라인을 설정해서 헤드리스 데이터를 호수 또는 웨어하우스에 복사할 수 있지만 헤드리스는 복사할 필요 없이 동일한 이점을 제공한다.
 
모듈성, 재사용성, 구조, 스트림과 테이블 두 가지 모두에 대한 손쉬운 액세스는 여전히 헤드리스 데이터 아키텍처의 핵심적인 특징이다. 데이터 호수 경계 안으로 들어온 이 데이터로 원하는 작업을 자유롭게 할 수 있다.
 

헤드리스 데이터 아키텍처를 구축하는 방법

헤드리스 데이터 아키텍처를 구현하기 위해서는 헤드리스 데이터 계층에 투자해야 한다. 헤드리스라고 명확히 지칭하지 않더라도 자체적인 헤드리스 데이터 아키텍처를 구축하고 있는 기업도 많지만, 처음 시작하는 경우 클라우드 서비스를 사용하는 것이 가장 쉽고 인기 있는 방법이다. 자체 헤드리스 데이터 아키텍처를 구축한다면 먼저 잘 정리되고 도식화된 데이터 스트림을 만드는 것이 중요하다. 아파치 아이스버그 테이블에 입력하는 것은 그 다음 일이다.
 
데이터 스트림을 아이스버그 테이블로 변환하는 데는 커넥터(카프카 커넥트 등)가 보편적으로 사용되지만 관리형 서비스를 사용할 수도 있다. 이러한 서비스는 주제를 추가 전용(append-only) 아이스버그 테이블로 자동으로 구체화하며 수정 작업, 파이프라인 없이 스트림 또는 테이블로 사용할 수 있는 동일한 데이터를 사용한다. 
 
마지막으로, 데이터 스트림과 테이블을 자신에게 필요한 데이터 호수, 웨어하우스, 프로세서, 쿼리 엔진, 보고 소프트웨어, 데이터베이스 또는 애플리케이션 프레임워크에 연결할 수 있다.
 
또한 선택한 처리 헤드에 대한 지원을 제공해야 한다. 일부 프로세서는 아이스버그 카탈로그에 직접 연결되어 데이터에 대한 즉각적인 액세스를 제공할 수 있다. 주요 클라우드 제공업체 엔진과 같은 독점적 처리 엔진의 경우 일반적으로 처리를 활성화하기 위해서는 아이스버그 메타데이터 복사본이 필요하다. 해당 설명서에서 관련 내용을 확인해야 한다.
 
다소 복잡해 보일 수 있지만 처음에는 대체로 한두 개의 헤드만 사용하게 된다. 다음 기사에서는 데이터 형식화(formalization)를 "왼쪽으로" 옮겨서 필요한 모든 사용자의 접근성과 신뢰성을 높이는 방법 등 헤드리스 데이터 아키텍처를 구현하는 방법에 대한 더 자세한 내용을 소개할 예정이다.
editor@itworld.co.kr 
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.