데이터 시스템에 대한 생각

일반적으로 데이터베이스, 큐, 캐시 등을 매우 다른 범주에 속하는 도구로 생각한다. 데이터베이스와 메시지 큐는 표멵거으로 비슷하더라도 (둘 다 얼마동안 데이터를 저장) 매우 다른 접근 패턴을 갖고 있어 서로 다른 성능 특성이 있기 때문에 구현 방식이 매우 다르다.

 

그러면 모든 것을 왜 데이터 시스템이라는 포괄적 용어로 묶어야 할까?

 

데이터 저장과 처리를 위한 여러 새로운 도구는 최근에 만들어졌다. 새로운 도구들은 다양한 사용사례(use case)에 최적화 되었기 때문에 더 이상 전통적인 분류에 딱 들어맞지 않는다. 예를들어 메시지 큐로 사용하는 데이터스토어인 레디스가 있고, 데이터베이스처럼 지속성을 보장하는 메시지 큐인 아파치 카프카도 있다. 분류 간 경계가 흐려지고 있다.

두 번째로 점점 더 많은 애플리케이션이 단일 도구로는 더 이상 데이터 처리와 저장 모두를 만족시킬 수 없는 과도하고 광범위한 요구사항을 갖고 있다. 대신 작업(work)은 단일 도구에서 효율적으로 수행할 수 있는 태스크(task)로 나누고 다양한 도구들은 애플리케이션 코드를 이용해 서로 연결 한다.

서비스 제공을 위해 각 도구를 결합할 때 서비스 인터페이스나 애플리케이션 프로그래밍 인터페이스(API)는 보통 클라이언트가 모르게 구현 세부 사항을 숨긴다. 기본적으로 좀 더 작은 범용 구성 요소들로 새롭고 특수한 목적의 데이터 시스템을 만든다. 복합 데이터시스템(composite data system)은 외부 클라이언트가 일관된 결과를 볼 수 있게끔 쓰기에서 캐시를 올바르게 무효화 하거나 업데이트 하는 등의 특정 보장 기능을 제공할 수 있다. 이제부터 개발자는 애플리케이션 개발자뿐만 아니라 데이터 시스템 설계자이기도 하다. 그래서 많은 회사에서는 데이터시스템 아키텍쳐라는 직무를 오픈을 하기도 하는 것 같다.

 우리 회사에서도 데이터 시스템 아키텍쳐 업무를 하는 테크팀이라는 팀을 조직해서 해당 업무를 할 직원들을 사내 공모를 통해 모집을 하기도 했었다. 나 역시 현재 하는 업무가? 내가 재미있어 하는 일이 데이터 시스템 아키텍쳐 업무를 할 때 즐겁게 하는 나를 발견하곤 한다.

언젠가는 해당 업무?로 전환을 하지 않을까 싶기도 하다.

 

데이터 시스템이나 서비스를 설계할 때 까다로운 문제가 많이 생긴다. 내부적으로 문제가 있어도 데이터를 정확하고 완전하게 유지하려면 어떻게 해야 할까?