견고한 데이터 엔지니어링

이 글은 “견고한 데이터 엔니지어링”의 3장 “우수한 데이터 아키텍처 설계” 챕터를 읽고 쓰는 글입니다.

엔터프라이즈 아키텍처란?

엔터프라이즈 란 모든 정보 및 기술 서비스, 프로세스, 인프라를 포함하는 전체 기업 또는 기업 내 특정 도메인을 의미한다고 합니다. 이 내용에서 보면 엔터프라이즈는 결국 회사 내의 어떠한 형태로 구성되어 있는 무언가를 말하는 것 같습니다.

저자는 이러한 엔터프라이즈에 대한 아키텍처를 다음과 같이 쉽게 이야기하고 있습니다.

“엔터프라이즈 아키텍처는 기업의 변화를 지원하는 시스템 설계로, 신중한 트레이드오프 평가를 통해 도달한 유연하고 되돌릴 수 있는 의사결정으로 달성된다.” 이 정의가 저에게는 가장 쉽게 다가 온 것 같습니다.

그리고 이 문장에서 키워드는 되돌릴 수 있는 의사결정과 트레이드오프 입니다.

1.1 ) 되돌릴 수 있는 의사결정

책을 읽으면서 느낀 점 중 큰 부분이 되돌릴 수 있다는 점에 안전성입니다. 되돌릴 수 있는 의사결정은 세상의 변화와 새로운 정보 수집에 따라서 프로세스를 조정 할 수 있게 해줍니다. 또한 의사결정의 무게감을 줄임으로서 경직화를 극복 할 수 있다고 합니다.

저자는 AWS의 예시를 들며 되돌릴 수 있는 의사결정으로 인해 더 많은 의사결정과 반복, 개선, 데이터 수집등을 할 수 있었다고 합니다. 저도 업무를 하면서 의견을 내는 것에 두려움을 느끼게 되었을 때를 생각하면 확실히 이러한 되돌릴 수 있는 의사결정 ( 결국 작은 의사결정으로 생각되는 )을 하는 것의 장점을 떠올릴 수 있었습니다.

1.2 ) 트레이드오프

트레이드오프는 실제로 엔지니어링을 하면서 겪을 수 밖에 없는 현상이라고 합니다.

서비스를 개발 할 때는 언어와 프레임워크들의 특징을 비교하며, 서비스에 더 나은 프레임워크가 어떤 것인지 알아보고 심지어는 개발에 소요되는 인력, 시간, 비용 등의 리소스마저도 고려대상이 되곤 합니다.

결국 데이터 엔지니어는 모든 단계에서 트레이드오프를 고려해야하며 동시에 값비싼 기술 부채를 최소화해야 한다고 합니다. 뿐만 아니라 이러한 균형을 유지하기 위해 끊임없이 측정하고 재평가해야 한다고 합니다. 기업의 성장, 플랫폼의 확장, 서비스의 개선 등 많은 변화 사이에서 결국 아키텍처는 가만히 있을 수 없습니다.

데이터 아키텍처란?

데이터 아키텍처는 엔터프라이즈 아키텍처 내부에 존재하는 많은 아키텍처 중 하나입니다. 저자는 이렇게 정의합니다.

“데이터 아키텍처는 기업의 진화하는 데이터 요구 사항을 지원하는 시스템 설계로, 트레이드오프에 대한 신중한 평가를 통해 유연하고 되돌릴 수 있는 결정을 내림으로써 실현된다”

데이터 아키텍처는 인력, 프로세스 및 기술과 관련한 필요 기능의 요건인 운영 아키텍처와 데이터 엔지니어링 수명 주기를 통해 데이터의 수집, 저장, 변환 및 제공 방법을 설명하는 기술 아키텍처라는 개념이 있습니다.

운영 아키텍처의 경우에는 데이터가 실제로 어떤 비즈니스 프로세스를 지원하는가? 데이터 품질을 어떻게 관리하는가? 데이터의 생성 시점부터 쿼리 가능한 시점까지의 지연 시간 요구 사항은 무엇인가? 와 같이 기술적인 질문보다 비즈니스와 관련한 아키텍처입니다.

기술 아키텍처는 시간당 10TB의 데이터를 원천 데이터베이스에서 데이터 레이크로 옮기려면 어떻게 해야 할까? 와 같이 기술적인 아키텍처를 말합니다.

운영 아키텍처는 “무엇을?”이라는 의문을 구체화하고, 기술 아키텍처는 “어떻게?”라는 실질적인 방법을 제안합니다.

우수한 데이터 아키텍처

우수한 아키텍처는 최고의 아키텍처가 아닌 유연성을 유지하고 적절한 트레이드오프를 실현하면서, 광범위하게 재사용 가능한 공통 구성 요소를 사용하여 비즈니스 요건을 충족시키는 아키텍처입니다.

반대로 나쁜 아키텍처는 서로 긴밀하게 결합되었어나, 경직되었거나, 지나치게 중앙 집중화된 상태거나, 업무에 맞지 않는 잘못된 도구를 사용해 개발 및 변경 관리를 방해합니다. 이러한 아키텍처의 특징은 엔터프라이즈 아키텍처의 특징인 되돌릴 수 있는 의사결정과 유사하게 생각됩니다.

데이터 엔지니어링 아키텍처

데이터 엔지니어링 아키텍처는 데이터 아키텍처에 속해있는 개념으로 그 원칙을 알아보는 것은 데이터 엔지니어가 어떤 역할을 해야하는지 알 수 있을 것 같습니다.

1. 공통 컴포넌트를 현명하게 선택해라

일단 여기서 말하는 공통 컴포넌트는 객체 스토리지, 버전 제어 시스템, 관찰 가능성, 모니터링이나 오케스트레이션, 처리 엔진과 같은 넓게 사용되는 구성요소라고 합니다.

공통 컴포넌트를 사용하는 것은 팀의 협업을 이끌어내고 팀 간의 지식과 기술을 공유하기 좋은 환경을 만들 수 있습니다. 결국 가장 중요한 점은 협업을 촉진한다는 점인 것 같습니다.

2. 장애에 대비하라

이 부분에서 생각이 난 부분은 “끊임없이 의심해라”라고 말하는 데이터 기반 애플리케이션 설계의 문구가 생각납니다. 다음의 장애 시나리오를 고려하여 설계해야 한다고 합니다.

1. 가용성
   • 서비스 또는 컴포넌트가 작동 가능한 상태에 있는 시간의 비율
2. 신뢰성
   • 지정된 간격 동안 의도된 기능을 수행할 때 시스템이 정의 된 표준을 충족할 확률
3. 복구 시간 목표
   • 서비스 또는 시스템 장애의 최대 허용 시간
   • 내부 서비스와 외부 서비스는 복구 시간 목표가 다를 수 있다.
4. 복구 시점 목표
   • 복구 후 허용 가능한 상태
   • 허용 가능 한 최대 데이터 손실과 같이 복구 되었을 때 얼마나 완벽히 복구 되어야 하는가 입니다.

3. 확장성을 위한 아키텍처를 설계하라

서비스 확장을 생각하며 스케일 업과 스케일 다운을 유연하게 할 수 있는 아키텍처를 설계하는게 좋다고 합니다. 하지만 규모에 따라서는 단일 데이터 플랫폼을 사용하는 것도 잘못된 것은 아닐 수 있습니다.

4. 아키텍처는 리더십이다.

여기서 리더십은 기술에 대한 명령이나 통제를 의미하지 않습니다. 데이터 아키텍트의 역할에 대한 글이고, 데이터 엔지니어들과 기술과 환경에 대한 의논을 기반으로 의사소통하는 것에 대해 중요성을 말합니다.

5. 항상 아키텍처에 충실하라

6. 느슨하게 결합된 시스템을 구축하라

다른 팀에 의존하지 않고 테스트, 배포, 변경 할 수 있는 시스템 아키텍처는 작업 시 의사소통을 최소화 할 수 있는 방법이라는 말을 합니다.

7. 되돌릴 수 있는 의사결정을 하라

기술의 분리/모듈화 등의 변화 속도를 고려하여 항상 현재에 적합한 최고의 솔루션을 선택하도록 노력해야 한다고 합니다. 그리고 환경의 진화에 따라 업그레이드하거나 더 나은 방법을 채택할 수 있도록 준비해야 한다고 합니다.

여기에서 되돌릴 수 있는 의사결정은 이러한 환경의 진화에 유연하게 반응 할 수 있도록 도와준다고 합니다.

8. 보안 우선순위를 지정하라

외부의 보안 위협은 내부의 보안 위협이 되기 때문에 주의해야 하고, 클라우드 환경에서는 그에 맞는 보안을 주의해야 한다고 합니다.

저는 여기서 AWS의 보안 방향에 대해 주의깊게 봤습니다. AWS는 클라우드 보안과 클라우드 내 보안으로 나누어서 공동 책임 모델을 강조합니다. 그리고 이 중 AWS가 책임지는 부분은 클라우드 보안입니다.

“AWS는 AWS 클라우드에서 AWS 서비스를 실행하는 인프라를 보호 할 책임이 있다. 또한 AWS는 사용자가 안전하게 사용 할 수 있는 서비스를 제공한다.”

저희 같은 클라우드 사용자는 클라우드 내 보안에 대한 책임이 있습니다.

“사용자의 책임은 사용하는 AWS 서비스에 따라 결정된다. 또한 데이터의 민감도, 조직의 요구사항, 적용 가능한 관련 법률 및 규정등 기타 요인에 관해서도 책임져야 한다.”

AWS는 보안 서비스를 공개된 사양으로 지원하고, 그 서비스를 사용하여 보안 서비스를 구축하는 것은 곧 사용자의 책임이라는 말입니다.

9. 핀옵스를 수용하라

핀옵스는 제가 이해하는 문장으로는 비즈니스 가치를 극대화하기 위해 인프라 측면의 비용을 최적화하는 것으로 이해했습니다.

클라우드 서비스를 사용하여 리소스를 활용하게 되면 마주하게 되는 측면은 사용량에 따른 비용 지출이라는 키워드로 현재 재직중인 회사의 서비스는 IDC에 설치 된 서버로 온프레미스 환경에서 운영되기 때문에 예상 가능한 비용 지출이 가능합니다. 그리고 고정 지출로써, 별도로 최적화하거나 하는 등의 노력이 필요하지 않을 수 있습니다.

하지만 클라우드 핀옵스는 조금 다르게 리소스 사용량에 따라 비용을 지불하기 때문에 최적화하면 비즈니스의 가치를 극대화 하는 성과를 낼 수 있습니다.

주요 아키텍처 개념

이 부분에서는 아키텍처 내의 주요 개념에 대한 설명을 다룰 것 같습니다.

1. 도메인과 서비스

먼저 도메인은 실제 설계를 하는 주제 영역이고 서비스는 작업 달성이 목적인 기능 집합이라고 설명합니다. 조금 더 상세하게 설명하면 실제로 서비스를 하는 기능을 서비스라고 정의하면 도메인은 그 서비스를 통해 동작하는 설계상의 주제라고 볼 수 있을 것 같습니다.

정말 간단하게 주식 서비스를 개발하면 다음과 같이 표현 할 수 있습니다.

도메인은 여러 서비스를 포함 할 수 있으며, 여러 도메인이 하나의 서비스를 포함 할 수 있습니다. 이러한 도메인은 회사마다 특수한 지점이 있을 수 있기 때문에 필시 의사결정자, 분석가, 동업자와의 의사소통으로 좁혀나가야 한다고 합니다.

추가적인 내용 : 네이버 컨퍼런스에서 DDD에 대한 고찰

네이버 컨퍼런스에서 마지막 세션으로 DDD에 대해서 이야기를 공유받은 경험이 있습니다. “과연 모놀리틱하고 Messi한 서비스와 DDD를 통해 설계하는 것이 어떻게 좋은 것인가?”에 대해서 이야기를 나누었는데, 연설하신 개발자분은 “DDD는 Messi한 서비스에서 시작한다”라는 말씀을 하셨습니다.

처음부터 DDD를 통해 개발을 하는 것은 생산성에 치명적인 오버헤드를 발생시키기 때문에 빠른 생산성을 위해 Messi하게 펼쳐진 설계도를 도메인 단위로 묶어내는 것이 DDD의 단점을 보완하면서 개발을 하는 방법이라고 합니다. 그리고 새로운 확장을 진행 할 때도 완전히 다른 도메인인지 모르는 지점에 대해서는 기존의 도메인의 범위를 넓히고 추후에 분리시키는 것이 설계를 단순화 시킨다는 것을 공유 받은 적이 있습니다.

혹시 저도 설계 단계에서 이러한 개념을 잘 활용 할 수 있을지 모르니 일단 적어 놓겠습니다.

2. 분산 시스템, 확장성, 장애에 대비한 설계

여기서 중요하게 여기는 부분은 과거 “데이터 중심 애플리케이션 설계” 책을 공부하면서 어느정도 이해 한 부분이기 때문에 별도의 링크로 대체 하겠습니다.

1. 확장성 / 탄력성
   • 파티셔닝
   • 복제1
   • 복제2
2. 가용성
   • 분산 환경에서의 골칫거리
   • 일관성과 합의
   • 트랜잭션 - 정상적인 서비스 운영에 대해서는 중요 개념이기에
3. 신뢰성
   • 신뢰성의 관점에서는 서비스의 신뢰성(가용성)과 데이터 플랫폼 자체의 신뢰성(트랜잭션 등)과 같이 다양한 의미가 있기 때문에 적기 어려운 부분이 있습니다. 추후에 더 정확하게 알게 되면 추가적으로 적도록 하겠습니다.

3. 강한 결합, 느슨한 결험: 계층, 모놀리스, 마이크로서비스

강한 결합은 중앙 집중화된 종속성과 워크플로를 가져서 많은 도메인과 서비스가 서로 긴밀하게 의존하는 형태를 말합니다.

반대로 느슨한 결합은 도메인과 서비스가 다른 도메인과 서비스에 온전히 의존하지 않는 형태 입니다.

계층

계층은 단일 계층과 다중 계층이 있습니다.

단일 계층의 가장 간단한 예시로 로그인이 가능한 서비스에서 웹 서버와 데이터베이스 간의 직접 연결된 경우가 있습니다. 물론 로그인의 경우 유저 수에 따른 큰 확장이 필요하지 않을 수 있지만, 대량의 데이터가 입력되면서 확장의 필요성이 생겼을 때, 혹은 복제를 통해 장애 조치를 하고자 할 때 운영하기 어려운 점이 있습니다.

다중 계층은 그와 다르게 상향식이고 계층적인 구조로 이루어져 있으며, 하위 계층은 반드시 상위 계층에 의존하지 않습니다. 가장 대표적으로 클라이언트-서버 계층 또한 이 다중 계층에 속해 있습니다.

다중 계층은 상당히 큰 유연성을 제공합니다. 만약 클라이언트가 늘어서 서버에 부하가 가해질 경우 서버의 수를 키워서 로드밸런싱을 할 수 있고, 서버의 요청이 늘어서 데이터 플랫폼에 부하가 가해지면 데이터 계층을 분산시킬 수 있습니다.

여기서 추가적인 용어가 등장하는데 비공유 아키텍처와 공유 디스크 아키텍처라는 용어또한 알아보면 좋을 것 같습니다.

비공유 아키텍처는 단일 노드가 각자의 메모리, 디스크, CPU를 가지고 각 요청을 각각 처리하는 방식입니다. 아마 Spark이나 HDFS와 같이 각자의 노드에 데이터를 저장하거나 처리하고 결과를 같이 처리하는 방식으로 보입니다.

공유 디스크 아키텍처는 디스크와 메모리를 공유하는 부분이라고 하는데, 사실 어떤 부분인지 잘 모르겠습니다. 디스크와 메모리를 공용으로 CPU만 분리해서 사용하는건지.. 쿠버네티스 느낌인 것 같기도 합니다.

모놀리스

모놀리스는 가능한 한 많은 것을 한 지붕 아래에 포함하는 것이라고 표현했습니다. 모놀리스 내에서는 기술 결합과 도메인 결합이 있다고 합니다. 모놀리스 자체가 하나로 포함하는 것이기 때문에 결합에 민감한데 문제는 강한 결합은 컴포넌트의 모듈화가 부족하다는 의미이기 때문에 두더지 잡기와 같은 운영이 될 가능성이 있다고 합니다.

마이크로서비스

마이크로서비스는 개별적이고 분산되어 잇으며 느슨하게 결합된 서비스라고 합니다. 대부분 마이크로서비스로의 전환이 옳다고 여겨지기 때문에 모놀리스 서비스에서 마이크로서비스로 전환을 고려한다고 합니다.

하지만, 모놀리스 서비스가 얼마나 복잡한지 서비스를 추출하려면 얼마나 노력이 들어가는지 등으로 방식은 달라지며, 마이크로서비스에 친화적인 방식으로 서비스를 분리하는 새로운 병렬 아키텍처를 구축해야 한다고 합니다. 그리고 전체적인 리팩터링보다 서비스 분리를 통해 천천히 진행해야 한다고 합니다.

데이터 아키텍처에 관한 고려 사항

• 데이터 웨어하우스를 구축 할 때 가능하면 도메인 별 데이터 웨어하우스에 연결된 도메인 별 데이터 파이프라인과 워크플로를 분리합니다.
• 가능하다면 모듈화와 느슨한 결합을 허용하는 되돌릴 수 있는 기술을 선택합니다.
• 동일한 데이터를 다수의 도메인에서 의존할 수 있는 공유 도메인문제의 가장 기본적인 방법은 중앙 집중화, 하지만 데이터 메시를 통해 문제를 해결하기도 합니다.

접근 : 싱글 vs 멀티 테년트

이 내용을 들어가기전에 싱글테넌트와 멀티테넌트에 대해서 먼저 알아보도록 하겠습니다.

싱글테넌트는 하나의 서버에서 한 서비스의 데이터와 애플리케이션만 제공하는 방식입니다. 만약 100명의 사용자를 가진 어떤 서비스를 제공 할 때 혹시모를 미래의 부하를 대비하기 위해 10000명의 부하를 견딜 수 있는 서버를 구입하여 구축하는 방식이 싱글테넌트의 서버 구성 방식이라고 볼 수 있습니다.

이 경우에는 다음과 같은 단점이 있습니다.

• 아직 10000명의 부하가 발생하지 않아서, 실제로 사용되지 않는 리소스가 많아 비용에 낭비가 큽니다.
• 확장에 어려움이 있습니다.
• 확장이 된 프로젝트에 대해서도 각기 다른 서버의 리소스를 모두 관리해야 합니다.

이러한 문제를 해결하기 위해 멀티테넌트라는 개념이 등장하였고, 이 개념은 곧 클라우드 서비스의 발판이 됩니다.

멀티테넌트는 다수의 사용자에게 리소스를 공유하는 것입니다. 예를들면 파티션을 나누어서 별도의 디스크 공간을 가지듯 CPU 4개, 메모리 64GB를 별도로 구분하여 특정 사용자에게 할당하는 개념으로 보실 수 있습니다. 그리고 이 방식이 바로 클라우드 서비스의 방식입니다.

멀티테넌트 방식을 활용하면서 우리는 원하는 만큼의 리소스를 요청할 수 있게 되었습니다. 물론 사용하는 리소스에 비해 가격이 높지만, 이전에 이야기 한 핀옵스라는 새로운 개념이 탄생하며 이 또한 관리포인트로 부각되게 됩니다.

이벤트 기반 아키텍처

이벤트 기반 워크플로는 생산자, 이벤트 라우터, 소비자간의 강하게 결합된 종속성 없이 생성되어 소비하는 대상으로 라우팅됩니다. 이러한 아키텍처의 장점은 이벤트의 상태를 여러 서비스에 분산시킨다는 점으로 분산시스템의 장애 확인, 여러 소비자가 동일한 이벤트에 접근할 때 유리합니다.

CDC를 통해서 데이터베이스 간 데이터를 공유하는 방식이나, 비슷하게 메시지 브로커를 활용하여 데이터를 동기화 시키는 등의 작업등이 이러한 이벤트 기반 아키텍처를 잘 활용하는 것인가 싶습니다.

브라운필드 vs 그린필드 프로젝트

새롭게 알게 된 단어지만, 앞으로 제가 해야 할 업무와 큰 관련성이 있는 용어입니다.

브라운 필드는 기존의 아키텍처를 리팩터링하고 재구성하는 단계의 프로젝트 입니다. 이 내용은 제가 자주 볼 수 있는 내용이기 때문에 문장으로 정리 하겠습니다.

• 레거시 아키텍처에 대한 철저한 이해와 다양한 신/구 기술의 상호 작용이 필요합니다.
• 비판보다, 깊이 파고들어 결정에 대한 질문을 하고 이해하는 편이 좋습니다.
• 공감과 맥락에 대한 이해는 기존 아키텍처의 문제를 진단하고 기회를 식별하며 함정을 인식하는데 도움이 됩니다.
• 대중적인 대안은 스트랭글러 패턴입니다.
  • 레거시 아키텍처의 컴포넌트를 천천히 그리고 점진적으로 대체합니다. 결과적으로 완전 대체합니다.
  • 시스템의 한 부분을 한 번에 하나씩 폐기하는 표적 방식과 외과적 접근 방식입니다.
  • 이를 통해 종속 시스템에 미치는 영향을 평가하면서 유연하고 되돌릴 수 있는 결정을 내릴 수 있습니다.
• 누군가는 레거시 컴포넌트를 사용하고 있을 수 있음을 유념해야 합니다.

그린필드는 새롭게 아키텍처를 구성하는 단계입니다. 이 때는 레거시 코드에 영향을 받지 않고 아키텍처를 구축 할 수 있기 때문에 많은 개발자들이 재밌어하는 부분입니다.

하지만 뭔가 멋진 것을 개발하고싶은 욕망을 참아야 한다.라고 합니다.

어떤 프로젝트든지 결국 우수한 데이터 아키텍처의 원칙에 따라 트레이드오프를 평가하고, 유연하고 되돌릴 수 있는 결정을 내리고, 긍정적인 ROI를 실현하는 것을 목표로 해야 한다고 합니다.

데이터 아키텍처의 사례 및 유형

널리 사용되는 데이터 아키텍처의 주요 사례와 유형을 통해 일반적인 데이터 아키텍처 패턴의 일부를 알고, 사용 사례에 적합한 아키텍처를 설계하는 데 필요한 유연성과 트레이드오프 분석을 생각해보겠습니다.

데이터 웨어하우스

데이터 웨어하우스는 보고 및 분석에 사용되는 중앙 데이터 허브입니다. 제가 사용했던 Impala(with HDFS)와 같이 데이터를 쌓은 뒤 분석에 관련한 쿼리를 주로 사용하는 아키텍처입니다.

주로 사용하는 플랫폼은 컬럼지향 데이터베이스 혹은 MPP와 같이 대량의 데이터에서 집계하기 좋은 데이터베이스를 주로 활용하고 있으며 데이터가 어느정도 구조화 되어 있는 특징이 있습니다.

데이터 웨어하우스는 크게 조직 데이터 웨어하우스 아키텍처와 기술 데이터 웨어하우스 아키텍처로 구분되어 있습니다.

조직 데이터 웨어하우스 아키텍처

조직 데이터 웨어하우스 아키텍처의 경우에는 특정 비즈니스 팀의 구조 및 프로세스와 관련된 데이터를 구성하는 아키텍처입니다.

조직 데이터 웨어하우스 아키텍처는 크게 두 분야가 있습니다.

1. 운영 데이터베이스 ( OLTP -> OLAP )
   • 실제 사용중인 OLTP 데이터베이스에 영향이 없도록 분석을 위한 데이터를 별도의 OLAP 데이터베이스로 이전
2. 데이터 중앙 집중화 및 구성
   • 전통적으로 ETL 방식으로 데이터 웨어하우스에 데이터를 가져옵니다.
   • ELT 방식으로 데이터를 먼저 저장하고 데이터 웨어하우스의 성능(MPP)을 활용하여 Transform하는 방식입니다.

기술 데이터 웨어하우스 아키텍처

기술 데이터 웨어하우스 아키텍처는 MPP와 같은 방식을 말합니다.

클라우드 데이터 웨어하우스

기존의 데이터 웨어하우스는 온프레미스 상황에서 구축이 되어 왔습니다. 하지만 기술과 방법론의 발전(멀티테넌트 등)으로 이제 클라우드에서 데이터 웨어하우스를 운영하는 방식이 떠오르고 있습니다.

AWS의 레드시프트와 같은 클라우드 데이터 웨어하우스는 쉽게 스핀업, 다운을 할 수 있고 빅쿼리나 다른 경쟁사는 컴퓨팅과 스토리지를 분리하기도 했습니다. 과거에는 하둡 클러스터가 있어야 했던 빅데이터 사용 사례를 단일 쿼리로 수 페타바이트의 처리를 할 수 있도록 발전했습니다. 또한 수십 메가 바이트의 JSON형식 데이터를 저장하는 등의 발전으로 데이터 레이크와 같은 역할에 가까워진다고 합니다.

데이터 마트

데이터 마트는 단일 하위 조직이나 부서, 혹은 비즈니스 라인에 초점을 맞추어 분석 및 보고서를 제공하도록 설계된 하위집합입니다.

데이터 마트는 분석가와 보고서 개발자가 쉽게 데이터에 접근하도록 하고, ETL이나 ELT 단계에서의 변환보다 더 많은 변환을 하여 별도 저장할 수 있습니다.

데이터 레이크

데이터 레이크는 대용량의 정형, 비정형 데이터를 모두 중앙 위치에 저장하여 기업이 무한한 데이터의 샘에서 자유롭게 물을 마실 수 있도록 하는 방식이라고 합니다.

클라우드 기반 객체 스토리지에 데이터를 옮기고, 데이터 웨어하우스에 의존하여 모든 크기와 유형의 데이터를 저장하고 쿼리하거나 변환 할 때 클러스터를 스핀업하여 원하는 컴퓨팅 성능을 통해 데이터를 처리하는 방식입니다.

하지만 잘못 사용하면 쓰레기 매립장이 될 가능성이 높기 때문에 주의해야 합니다.

차세대 데이터 레이크, 플랫폼

데이터브릭스의 데이터 레이크하우스와 같이 데이터 웨어하우스가 가지고 있는 제어, 데이터 관리, 데이터 구조를 통합하면서 객체 스토리지를 통해 데이터를 저장하고 다양한 쿼리 및 변형 엔진을 가지고 있으며, 동시에 트랜잭션까지 처리해주는 플랫폼이 나오기 시작했습니다.

이 부분은 데이터 레이크가 가진 객체 스토리지를 통해 넓은 범위의 크기 및 유형의 데이터의 저장 과 데이터 웨어하우스가 가진 구조에 따른 데이터 관리 및 처리(쿼리/변환)을 동시에 지원해주기 때문에, 이제 데이터 레이크와 데이터 웨어하우스의 개념이 가까워 질 것이라 말합니다.

모던 데이터 스택

모던 데이터 스택은 다음과 같은 형태입니다.

데이터 원천에서 클라우드 기반 데이터 커넥터와 통합하여 클라우드 데이터 웨어하우스를 통해 BI 혹은 시각화에 사용됩니다.

가장 대중적으로 사용되는 스택으로 온프레미스 환경에서 저도 이러한 방식을 활용했습니다.

람다 아키텍처

스트리밍/실시간 분석용 프레임워크의 발전과 카프카등의 메시지 브로커의 등장으로 인해서 스트리밍 데이터 관련 작업의 인기가 높아지면서 부각된 아키텍처입니다.

람다 아키텍처는 배치, 스트리밍 및 서빙 시스템이 서로 독립적으로 작동합니다. 원천 시스템은 이상적으로 변경 할 수 없고 추가만 가능하며, 데이터를 처리 할 때는 스트림과 배치 두 목적지에 전송합니다.

일반적으로 스트림 처리는 NoSQL 데이터베이스인 ‘속도’계층에서 가능한 한 가장 낮은 지연 시간으로 데이터를 전달하고자 하고 배치 처리의 경우에는 데이터 웨어하우스와 같은 시스템에서 처리 되어 집계 뷰를 만듭니다.

문제점으로는 각기 다른 여러 시스템(배치, 스트림)을 관리하는 것이 매우 어렵기 때문에 리소스가 크다는 점이 있습니다.

카파 아키텍처

카파 아키텍처는 람다 아키텍처가 가진 여러 시스템의 관리에서 발생 할 수 있는 문제점을 없애기 위해 스트림 처리만으로 문제를 해결하는 방식입니다.

이론상 람다 아키텍처의 문제점을 해결 할 수 있지만, 스트림 처리의 안전성 확보와 배치 처리(대부분 높은 처리량)을 대체하기 위한 연산은 큰 부하를 가져오기 때문에 비용이 크다는 단점이 있습니다.

데이터 흐름 모델, 통합 배치, 스트리밍

데이터 흐름 모델은 모든 데이터를 이벤트로 간주하여 지속적인 스트림은 무한 데이터이며 배치는 경계가 있는 유한 데이터라고 생각합니다. 실시간 집계는 윈도우나 텀블링 윈도등을 사용하여 데이터를 집계하기 때문에 배치와 스트림은 서로 큰 차이가 없게 됩니다.

“배치는 스트리밍의 특수한 경우”라는 것을 강조했습니다.

IOT용 아키텍처

자세한 내용보다 제가 이해해야 할 부분에 대해서만 간략하게 적습니다.

• 데이터 엔지니어는 장치의 기능, 수집하는 데이터, 전송하기 전에 실행하는 에지 컴퓨팅 또는 ML, 데이터 전송 빈도를 알아야 합니다.
• 수집 과정에서는 게이트웨이에서 데이터를 축적했다가 나중에 분석용으로 일괄 업로드 할 수도 있습니다.
• 수집 과정에서는 IOT 시스템과 환경의 문제로 데이터 도착 지연, 데이터 구조나 스키마 차이, 데이터 손상 및 연결 중단 등 다양한 문제가 발생 할 수 있습니다.
• 스토리지 과정에서는 분석용도라면 배치를, 자동화 솔루션 등의 용도라면 메시지 큐나 시계열 데이터베이스가 적합합니다.
• 서빙 단계에서는 중요한 이벤트를 위한 스트림처리, 분석 보고서를 위한 배치 처리 등 다양하게 활용됩니다.

데이터 메시

데이터 메시는 도메인 기반 설계 개념을 데이터 아키텍처로 확장한 방식으로 이해했습니다. 도메인 단위로 데이터와 데이터의 소유권등을 분산시켜서 쉽게 사용 할 수 있도록 하는 방식입니다. 데이터 메시의 핵심 구성 요소로 다음의 4가지로 구분했습니다.

1. 도메인 지향 분산형 데이터 소유권 및 아키텍처
2. 제품으로서의 데이터
3. 플랫폼으로서의 셀프서비스 데이터 인프라
4. 통합 컴퓨팅 거버넌스

결론

데이터 아키텍처에 내재된 트레이드오프를 이해하고 깊이 연구하는 시간을 가진다면 요구사항에 맞는 아키텍처를 설계할 수 있을 것입니다.

참고

https://snowturtle93.github.io/posts/컬럼지향-데이터베이스와-MPP-데이터베이스/

https://www.cloudflare.com/ko-kr/learning/cloud/what-is-multitenancy/