[견고한 데이터엔지니어링] - 3장 우수한 데이터 아키텍처 설계

3.데이터 아키텍처란?

데이터 아키텍처라는 용어를 정의하기에 앞서, 해당 용어가 의미하는 여러 context를 이해하는것이 중요합니다. 따라서, 엔터프라이즈 아키텍처부터 살펴 봅니다.

엔터프라이즈 아키텍처 정의

엔터프라이즈 아키텍처에는 비즈니스, 기술, 애플리케이션 및 데이터를 포함한 많은 하위 집합 개념들이 속해있다. 따라서 데이터 아키텍처는 엔터프라이즈 아키텍처의 하위집합이라고 생각하면 된다.그렇다면 엔터프라이 아키텍처는 무엇을 의미하는 용어일까?

이를 위해서 TOGAF, 가트너, EABOK 등에 대해서 정의해 보자.

TOGAF의 정의

TOGAF(The Open Group Architecture Framework)는 오픈 그룹의 표준 아키텍처 프레임워크이다. 해당 정의에 의해서, 엔터프라이즈 아키텍처는 모든 정보 및 기술 서비스, 프로세스, 인프라를 포함하는 전체 기업 또는 기업 내 특정 도메인을 의미할 수 있다.

가트너(Gartner)의 정의

가트너(Gartner)는 기업 관련 동향에 관한 연구 기사와 보고서를 작성하는 글로벌 리서치 및 자문 기업을 의미한다. 해당 정의에 의해서, 엔터프라이즈 아키텍처는 비즈니스 비전과 목표를 향한 변화의 실행을 식별하고 분석함으로써 기업이 능동적으로 대응하도록 주도하는 분야라고 정의할 수 있다.

EABOK(Gartner)의 정의

EABOK(Enterprise Architecture Book of Knowledge)는 미국의 비영리 조직인 마이터코퍼레이션이 작성한 엔터프라이즈 아키텍처 참조 자료를 의미한다. 해당 책에 의해서, 엔터프라이즈 아키텍처는 전략,운용 및 기술을 조정해 성공 로드맵을 만드는 기업의 추상적인 표현이자 조직 모델로 정의할 수 있다.

 

책에서는 엔터프라이즈 아키텍처를 다음과 같이 정의하고 있다.

 

"엔터프라이 아키텍처는 기업의 변화를 지원하는 시스템 설계로, 신중한 트레이드오프 평가를 통해 도달한 유연하고 되돌릴 수 있는 의사결정으로 달성된다."

 

엔터프라이즈 아키텍처의 주요 개념은 가역적 의사결정, 변경 관리, 트레이드 오프 평가로 영역을 나눌 수가 있다.

• 가역적 의사결정: 언제든 roll-back이 가능한 의사결정.
• 변경 관리
• 트레이드오프 평가

엔터프라이즈 아키텍처의 정의 핵심 시항을 한 문장으로 정의하면, 유연성과 트레이드오프의 균형을 유지하는 것이라고 표현할 수 있다. 또한, 아키텍트는 세상이 역동적이라는 인식을 가지고 끊임없이 아키텍처를 측정하고 재평가 해야 한다.

데이터 아키텍처 정의

지금까지 엔터프라이즈 아키텍처에 대한 정의를 내려봤다. 이제 데이터 아키텍처에 대해서 자세히 설명해 보자.

데이터 아키텍처는 엔터프라이즈 아키텍처의 하위집합으로, 프로세스, 전략, 변경 관리, 트레이드오프 평가 등의 속성을 상속한다.

또한 다음과 같은 일부 용어에 의해 정의될 수 있다.

• TOGAF: 기업의 주요 데이터 유형과 원천, 논리적 데이터 자산, 물리적 데이터 자산, 데이터 관리 자원의 구조와 상호 작용 관련
• DAMA(DMBOK): 기업의 데이터 요구 사항을 파악하고, 이러한 요구를 충족하기 위한 청사진 설계 및 유지 관리. 청사진에 기반하여 데이터 통합, 데이터 자산 제어, 비즈니스 전략에 맞춘 데이터 투자 등 관련

책에서는 데이터 아키텍처를 다음과 같이 정의하고 있다.

 

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

 

또한 데이터 아키텍처는 기술적인 측면뿐만 아니라 운영적인 측면도 존재한다.

• 운영 아키텍처: 인력, 프로세스 및 기술과 관련한 필요 기능의 요건을 포괄한다. 즉, 무엇을(what)해야 하는지를 설명한다.
• 기술 아키텍처: 데이터를 수집, 저장, 변환 및 제공하는 방법을 개략적으로 설명합니다. 즉, 어떻게(how)해야 하는지를 설명한다.

우수한 데이터 아키텍처

데이터 아키텍처에 대한 정의는 위에서 살펴 봤다. 그렇다면 우수한 데이터 아키텍처는 무엇일까? 개괄적으로 우수한 데이터 아키텍처는 유연성을 유지하고 적절한 트레이드오프 관계를 실현하는 동시에, 광범위하게 재사용 가능한 공통 구성 요소를 사용해 비즈니스 요건을 충족한다.

 

"즉, 우수한 데이터 아키텍처는 변화에 대해서 빠른 민첩성을 보이는 아키텍처로, 우수한 데이터 아키텍처는 유연성 및 유지 관리에 견고함을 보여주는 아키텍처로 볼 수 있다."

 

---

3-2.우수한 데이터 아키텍처의 원칙

책에서는 우수한 데이터 아키텍처의 원칙을 다음과 같이 나열하고 있다.

• 1. 공통 컴포넌트를 현명하게 선택해라
• 2. 장애에 대비하라
• 3. 확정성을 위한 아키텍처를 설계하라
• 4. 아키텍처는 리더십이다
• 5. 항상 아키텍처에 충실하라
• 6. 느슨하게 결합된 시스템을 구축하라
• 7. 되돌릴 수 있는 의사결정을 하라
• 8. 보안 우선순위를 지정하라
• 9. 핀옵스를 수용하라

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

데이터 엔지니어의 주요 업무중 하나는 조직 전체에서 널리 쓸 수 있는 공통 컴포넌트와 관행을 선택하는 것이다. 공통 컴포넌트에는 조직 내에 공통적으로 적용되는 그 어떤 구성요소라도 될 수 있다. 구체적으로는 객체 스토리지, 버전 제어 시스템, 관찰 가능성, 모니터링 및 오케스트레이션 시스템, 처리 엔진 등이 있다.

장애에 대비하라

다음은 장애 시나리오를 평가하는 몇 가지 핵심 용어이다.

• 가용성 : 서비스 및 컴포넌트가 작동 가능한 상태에 있는 시간의 비율
• 신뢰성: 지정된 간격 동안 의도된 기능을 수행할 때 시스템이 정의된 표준을 만족할 확률
• 복구 시간 목표: 서비스 및 시스템 장애의 최대 허용 시간
• 복구 시점 목표: 복구 후 허용 가능한 상태, 허용 가능한 최대 데이터 손실

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

데이터 시스템의 확장성에는 다음과 같은 특징이 있다. 첫째, 확장 가능한 시스템은 상당한 양의 데이터를 처리할 수 있도록 스케일 업 할수 있다.따라서, 과도한 부하에 대해서 일시적으로 처리할 수가 있다. 둘째, 확장가능한 시스템은 규모를 스케일 다운 할 수 있다. 용량이 줄어들면 자동으로 제거해 비용을 절감한다.

아키텍처는 리더십이다.

높은 기술 역량과 강력한 리더십 기술을 겸비한 데이터 아키텍트는 드물지만 그만큼 매우 가치가 있다. 최고의 데이터 아키텍트는 이러한 이중성을 진지하게 받아들인다.

 

"훌륭한 아키텍트는 개발 팀을 멘토링해 지도하고, 그들이 더 복잡한 문제를 해결할 수 있도록 수준을 높여주는 역할을 수행한다."

항상 아키텍처에 충실하라

아키텍트의 임무는 기본 아키텍처(현재 상태)에 대한 깊은 지식을 개발하고,목표 아키텍처를 개발하며, 아키텍처 변경의 우선순위와 순서를 결정하는 시퀸싱 계획을 수립하는 것이다.

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

한 팀이 다른 팀에 의존하지 않고 독립적으로 시스템을 테스트, 배포, 변경할 수 있도록 아키텍처를 느슨하게 설계해야 한다.

기술과 인간 시스템이 모두 느슨하게 결합되면, 데이터 엔지니어링 팀은 서로 또는 회사의 다른 부문과 더 효율적으로 협업할 수 있다.

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

데이터 아키텍처 전반에 걸친 기술의 분리/모듈화 등의 변화 속도를 고려할 때, 항상 현재에 적합한 최고의 솔루션을 선택하도록 노력해야 하며, 환경의 진화에 따라 업그레이드 할 수 있도록 아키텍처를 설계해야 한다.

보안 우선순위를 지정하라

보안은 말하지 않아도 중요한 요소임을 모두가 알 수 있을 것이다.보안적 측면을 설명하기 위해 두 가지 주요 아이디어 '제로-트러스트-보안'과 '공동 책임 모델'에 초점을 맞추어 설명하겠다.

 

제로 트러스트 보안 모델

한마디로 '믿을 놈 하나 없다'라는 보안 모델이다. 외부자를 비롯하여 내부자 공격에도 방어하는 모델이다.

공동 책임 모델

아마존의 클라우드 보안과 클라우드 내 보안으로 나누는 공동 책임 모델이다. 즉, 클라우드를 지원하는 공급자(아마존)과 클라우드를 사용하는 수요자(고객) 모두에게 보안적 책임이 있는 모델이다.

 

"기본적으로 모든 데이터 엔지니어는 스스로를 보안 엔지니어로 간주해야 될 만큼 보안을 중시해야 한다. 데이터를 다루는 사람으로서 데이터 보안에 책임감을 가져야 한다."

 

---

3-3.핀옵스를 수용하라

핀옵스(FinOps)에 대한 몇 가지 정의가 있다.

 

"핀옵스는 진화하는 클라우드 재무 관리 분야이자 문화적 관행으로 엔지니어링,재무,기술 및 비즈니스 팀이 데이터 기반 지출 결정을 위해 협업할 수 있도록 지원함으로써 조직이 비즈니스 가치를 극대화 할수 있게 해준다."

 

"핀옵스라는 용어는 일반적으로 데브옵스(DevOps)와 재무(Finance)간의 협력적인 업무 관계를 지지하는 새로운 전문적인 움직임을 의미한다"

 

책에서는 높은 클라우드 요금에 직면하기 전에 미리 핀옵스를 알아볼 것을 권장하고 있다.

---

3-4.주요 아키텍처 개념

이제는 우수한 데이터 아키텍처를 설계하고 구축하는 데 필요한 주요 개념들을 더 자세히 살펴보겠다.

도메인과 서비스

• 도메인: 실제 설계를 하는 주제 영역
• 서비스 : 작업 달성이 목적인 기능들의 집합

예를 들어 식당 장사를 해 본다고 가정해 보자. 이 경우, 도메인은 식당 장사로 볼 수 있으며, 서비스에는 홀 담당 서비스, 주방 담당 서비스 등이 있을수 있다. 이처럼 도메인은 여러 서비스를 포함할 수 있다. 또한 다른 도메인에서도 해당 서비스를 공유할 수 있다.

예를 들어 카페 장사 도메인도 식당 장사와 유사한 서비스들을 가질 수 있다.

 

도메인을 설계할 때는 사용자 및 이해관계자와 직접 대화하고, 의견을 통해서 그들의 작업 수행에 도움이 될 서비스를 구축해야 한다.

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

데이터 시스템과 밀접하게 관련된 네 가지 특징은 다음과 같다.

• 확장성: 시스템 용량을 늘려 성능을 개선하고 수요를 처리할 수 있다.
• 탄력성: 확장성이 뛰어난 시스템을 동적으로 스케일 업/다운 할 수 있다.
• 가용성: 서비스 또는 컴포넌트가 작동 가능한 상태에 있는 시간의 비율이다.
• 신뢰성: 시스템이 지정된 간격 동안 의도한 기능을 수행할 때 정의된 표준을 만족할 확률이다.

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

• 강한 결합: 도메인과 서비스의 모든 부분이 다른 모든 도메인과 서비스에 필수적으로 의존되는 경우
• 느슨한 결합: 서로 온전히 의존하지 않는 분산형 도메인과 서비스의 경우

아키텍처 계층

아키텍처에는 데이터, 애플리케이션, 비즈니스 로직, 프레젠테이션 등의 계층이 있으며, 이러한 계층을 분리하는 방법을 알아야 한다.

단일 계층

단일 계층 아키텍처에서는 데이터베이스와 애플리케이션이 밀접하게 연결되어 단일 서버에 상주한다.강한 결합의 본질은 서버, 데이터베이스 또는 애플리케이션에 장애가 발생하면 전체 아키텍처에 장애가 발생한다는 의미한다. 따라서 단일 계층 아키텍처는 로컬 머신에서 시스템을 테스트하는 데는 적합하지만, 운영 환경에서는 사용하지 않는것이 좋다.

다중 계층

다중 계층 아키텍처는 데이터, 애플리케이션, 비즈니스 로직, 프레젠테이션 등의 개별 계층으로 구성된다. 이러한 계층들은 bottom-up 방식이며 계층적인 구조로, 하위 계층이 반드시 상위 계층에 의존하지 않는다. 반면에 상위 계층은 하위 계층에 의존한다. 따라서 앱에서 데이터를 분리하고, 프레젠테이션에서 앱을 분리한다. 3계층 아키텍처(PT - App - Data)에서는 모놀리식에 집중할 필요 없이 각 계층에서 원하는 모든 기술을 자유롭게 사용할 수 있다.

모놀리스

모놀리스의 일반적인 개념은 가능한 한 많은 것을 한 지붕 아래에 포함하는 것이다.모놀리스 내에서의 결합은 기술 결합과 도메인 결합의 두 가지 방식으로 살펴볼 수 있다.기술 결합은 아키텍처 계층이, 도메인 결합은 도메인이 서로 결합하는 방식을 의미한다.

하지만, 모놀리스 결합은 강한 결합으로, 컴포넌트의 모듈화가 부족하다는 것을 의미한다. 따라서 아키텍처 전체에서 컴포넌트를 재사용하기란 매우 어렵다.

마이크로서비스

마이크로서비스 아키텍처는 모놀리스와 정반대의 개념으로, 개별적이고 분산되어 있으며 느슨하게 결합된 서비스로 구성된다. 각 서비스는 특정 기능이 있으며 도메인 내의 다른 서비스와 분리된다.

 

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

모놀리스가 반드시 나쁘다고는 할 수 없으며, 특정한 조건에서는 모놀리스로 시작하는 편이 합리적일 수 있다. 하지만 결국에는 모놀리스 식의 아키텍처를 더 작게 분해할 준비를 해야하므로 이 점에 대해서 항상 고려해야 한다.

---

3-5.사용자 접근: 싱글 VS 멀티테넌트

어떤 의미에서는 모든 클라우드 서비스가 멀티테넌트(multitenant)지만, 이러한 멀티테넌트는 다양한 방식으로 발생한다. 멀티테넌시(multitenency)에서는 성능과 보안이라는 두 가지 요소를 고려해야 한다. 보안과 관련해서는 서로 다른 테넌트의 데이터를 적절히 분리해야 한다. 데이터 격리 전략은 시스템에 따라 다르다. 따라서 벤더 또는 프로젝트의 설명서를 읽고 적절한 전략과 리스크를 파악해야 한다.

이벤트 기반 아키텍처

비즈니스는 항상 동적이다. 다양한 이벤트 들이 발생할 수 있다. 이벤트 기반 워크플로에서는 데이터 엔지니어링 수명 주기의 다양한 부분에서 이벤트를 생성, 갱신하고 비동기적으로 이동하는 기능이 포함된다("생산자 -> 이벤트 라우터 -> 소비자")

이벤트 기반 아키텍처는 이벤트 중심 워크플로를 수용하고 이를 사용해 다양한 서비스 간에 통신을 한다. 장점은 이벤트의 상태를 여러 서비스에 분산시킨다는 것이다. 이는 서비스가 오프라인 상태가 되거나, 분산 시스템에서 노드에 장애가 발생하거나, 여러 소비자 또는 서비스가 동일한 이벤트에 접근하도록 할때 유용하다.

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

데이터 아키텍처 프로젝트를 설계할 때, 설계하기 전에 백지 상태에서 처음부터 시작하는 것인지 아니면 기존 아키텍처를 재설계 하는것인지 알아야 한다. 이에 브라운필드와 그린필드라는 두 가지 개념이 있다.

브라운필드 프로젝트

브라운필드 프로젝트는 기존 아키텍처를 리팩터링하고 재구성하는 경우가 많아 현재와 과거의 선택에 따른 제약을 받는다. 레거시 아키텍처에 대한 철저한 이해와 다양한 신/구 기술의 상호 작용이 필요하다.

그린필드 프로젝트

그린필드 프로젝트를 사용하면 이전 아키텍처의 역사나 레거시에 얽매이지 않고 새롭게 출발할 수 있다. 브라운필드 프로젝트보다 보다 쉬운 경향이 있으나 주의 사항이 있다. 무조건적인 최신 기술 적용과 같은 강박관념에 얽매이지 않아야 한다. 항상 뭔가 멋진 것을 구축하려 하기 보다는 작업 요건을 우선시 해야 한다.

 

"브라운필드 프로젝트든 그린필드 프로젝트든 항상 우수한 데이터 아키텍처의 원칙에 초점을 맞추어야 한다. 트레이드 오프를 평가하고, 유연하고 되돌릴 수 있는 결정을 내리고, 긍정적이 ROI를 실현하도록 노력해야 한다."

---

3-6.데이터 아키텍처의 사례 및 유형

데이터 웨어하우스

데이터 웨어하우스는 보고 및 분석에 사용되는 중앙 데이터 허브로, 가장 오래되고 잘 확립된 데이터 아키텍처의 하나이다. 데이터 웨어하우스의 데이터는 일반적으로 분석 활용 사례에 맞게 고도로 포맷되고 구조화되어 있다.

• 조직 데이터 웨어하우스 아키텍처: 특정 비즈니스 팀의 구조 및 프로세스와 관련된 데이터를 구성한다. 다음과 같은 특징이 있다.
  • 운영 데이터베이스(OLTP)에서 온라인 분석 처리(OLAP)를 분리
  • 데이터 중앙 집중화 및 구성(원천 시스템 -> ETL -> 데이터 웨어하우스 -> 데이터 마트)
• 기술 데이터 웨어하우스 아키텍처 : MPP와 같은 데이터 웨어하우스의 기술적 본질을 반영한다. 데이터 및 보고 업무의 니즈가 증가함에 따라 대기업의 고성능 쿼리를 실행하는데 필수 요소이다.
  • ELT 모델을 변형한 ETL 모델이 있다. ETL 모델은 (원천 시스템 -> 스테이징 -> ELT -> 데이터 웨어하우스 -> 분석 및 데이터 과학, 보고)

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

클라우드 데이터 웨어하우스는 온프레미스 데이터 웨어하우스 아키텍처의 상당한 발전을 의미한다. MPP 시스템의 기능을 확장해 과거에는 하둡 클러스터가 필요했던 많은 빅데이터 사용 사례를 포괄한다. 또한, 단일 쿼리로 페타바이트 단위의 데이터를 쉽게 처리할 수 있다.

클라우드 데이터 웨어하우스가 성숙해짐에 따라 데이터 웨어하우스와 데이터 레이크 간의 경계는 계속 모호해질 것이다. 그리고 클라우드 데이터 웨어하우스의 기능 확장의 영향으로 기존의 데이터 웨어하우스라는 용어는 완전히 사라질 수도 있을 수 있다.

데이터 마트

데이터 마트는 하위 조직이나 부서 또는 비즈니스 라인에 초점을 맞춰 분석 및 보고서를 제공하도록 설계된 웨어하우스의 한층 더 정교한 하위집합이다. 각 부서에는 필요에 따라 고유한 데이터 마트가 있다. 이는 조직 및 비즈니스에 서비스를 제공하는 전체 데이터 웨어하우스 와는 대조적이다. 데이터 마트의 장점은 다음과 같다.

• 1. 분석가와 보고서 개발자가 데이터에 더 쉽게 접근할 수 있도록 한다.
• 2. 초기 ETL 또는 ELT 파이프라인이 제공하는 것보다 더 많은 변환 단계를 제공한다.

---

3-7.데이터 레이크

데이터레이크는 빅데이터 시대에 등장한 가장 인기 있는 아키텍처이다. 데이터에 엄격한 구조적 제한을 가하는 대신, 정형 데이터와 비정형 데이터를 모두 중앙 위치에 저장하고 있다. 즉, 모든 크기와 유형의 방대한 데이터를 저장할 수 있다. 다만 데이터 레이크 1.0에는 심각한 몇몇 단점들이 존재했다. 데이터의 관리 불가능한 크기로의 증가, 쓰기 전용이라는 점 등이 있다.

 

하지만, 넷플릭스나 페이스북 같은 거대한 데이터 중심적인 실리콘 밸리 기술 기업에서 데이터레이크에 대한 상당한 가치를 발견했기에 이러한 점들을 참고하면 좋다.

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

1세대 데이터레이크의 단점을 보완하고자 여러 노력들이 존재했다.데이터브릭스는 데이터 웨어하우스의 제어, 데이터 관리, 데이터 구조 통합 등의 기능과 더불어 객체 스토리지에 데이터를 저장하고 다양한 쿼리 및 변형 엔진을 지원하는 데이터레이크의 기능을 융합한 데이터 레이크하우스라는 새로운 개념을 도입했다.

 

클라우드 데이터 웨어하우스의 기술 아키텍처도 데이터레이크 아키텍처와 매우 유사하게 진화했다. 컴퓨팅과 스토리지를 분리하고, 페타바이트 규모의 관리를 지원하며, 다양한 비정형 데이터 및 반정형 객체를 저장하고, 스파크 또는 빔과 같은 고급 처리 기술과 통합된다.

 

이처럼 미래의 데이터 엔지니어는 데이터 레이크 아키텍처와 데이터 웨어하우스 아키텍처를 결합한 데이터 플랫폼 을 선택할 수 있을것이다.

모던 데이터 스택

모던 데이터 스택은 현재 유행하는 분석 아키텍처로, 추상화 유형을 강조한다. PnP(Plug and Play)방식과 모듈식에, 비용 효율적인 데이터 아키텍처를 구축하는 것을 목표로 한다.(데이터 원천 -> 클라우드 기반 데이터 커넥터와 통합 -> 클라우드 데이터 웨어하우스 ->  BI와 시각화)

람다 아키텍처

배치 및 스트리밍 데이터를 단일 아키텍처로 조정하는 방법 중 하나로, 람다 아키텍처에서는 배치, 스트리밍 및 서빙 등의 시스템이 서로 독립적으로 작동한다. 이를 그림으로 표현하면, 다음과 같다.

 

원천 시스템은 이상적으로 변경할 수 없고 추가만 가능하며, 데이터를 처리할 때는 스트림과 배치라는 두 목적지로 전송한다.

하지만, 이처럼 코드베이스가 서로 다른 여러 시스템을 관리하는 것은 매우 어려운 작업이다.따라서 람다 아키텍처의 단점을 보완하기 위해 카파 아키텍처라는 개념이 등장했다.

카파 아키텍처

주요 논점은 다음과 같다. 스트림 처리 플랫폼을 데이터 처리, 저장 및 서빙 등 모든 데이터 처리의 백본으로 사용하는 것이다. 하지만, 아직까지 널리 채택되지는 못하였는데, 몇 가지 이유가 있다. 첫째, 스트리밍 자체는 많은 기업에 여전히 미지의 영역이다. 둘째, 매우 복잡한 아키텍처로 실제로 비용이 많이 드는 것으로 나타났다. 반면에 배치 스토리지와 프로세싱은 방대한 데이터셋에 비해 훨씬 효과적이고 비용 효율적이다.

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

배치 및 스트리밍 데이터를 통합한다는 핵심 과제는 여전히 남아 있다. 람다와 카파는 이 과제를 지속해서 추구하고 발전시킬 수 있는 영감과 토대를 제공한다. 배치 및 스트림 처리 관리의 주요 문제 중 하나는 여러 코드 경로를 통합하는 것이다. 이를 위해 구글은 데이터 흐름(data flow) 모델과 이 모델을 구현하는 아파치 빔 프레임워크를 개발했다.

 

데이터 흐름 모델의 핵심 개념은 다양한 유형의 window에서 집계가 수행되므로 모든 데이터를 이벤트로 간주하는 것이다.

지속적인 이벤트는 무한한 데이터이며, 데이터 배치는 단순히 경계가 있는 유한 이벤트 스트림이다.

loT용 아키텍처

loT 데이터는 주변 환경에서 주기적으로 또는 지속해서 데이터를 수집해 목적지로 전송하는 장치에서 생성된다.

loT장치는 최소한의 데이터 수집 및 전송 능력을 갖춰야 한다. 데이터 엔지니어는 loT장치의 내부를 자세히 알 필요는 없지만, 장치의 기능, 수집하는 데이터, 데이터를 전송하기 전에 실행하는 edge computing 또는 ML, 데이터 전송 빈도를 알고 있어야 한다.

 

다음은 loT 장치와 인터페이스를 이해하는데 필요한 주요 컴포넌트들이다.

loT용 게이트웨이

loT 게이트웨이는 장치를 연결하고 인터넷 상의 적절한 수신처에 안전하게 라우팅하는 허브이다. 데이터 보존의 중간 기착지 역할을 하며, 최종 데이터 수신처로의 인터넷 접속을 관리한다.

수집

모든 데이터는 셀룰러 또는 와이파이 네트워크 범위에 있을 때만 업로드 된다. 하지만, loT 시스템과 환경의 다양성때문에 엔지니어가 아키텍처 및 다운스트림 분석에서 고려해야 할 복잡한 문제가 발생할 수 있다.(데이터 도착 지연, 데이터 구조와 스키마의 차이, 데이터 손상 및 연결 중단 등)

스토리지

loT 장치의 지연 요건에 따라 크게 달라진다. 예를 들어, 단순 ML용은 지연 시간을 오래가져도 되지만, 실시간 자동화 시스템 등에서는 지연 시간이 거의 실시간으로 유지되어야 한다.

서빙

서빙 패턴도 스토리지처럼 다양하게 존재한다.

데이터 메시

데이터 메시(mesh)는 (중앙 집중식 데이터 레이크 및 웨어하우스와 같은)거대한 모놀리식 데이터 플랫폼과, 운영 데이터와 분석 데이터 사이에서 환경이 구분되는 '데이터 격차'에 대한 최근의 대응책이다. 데이터 메시는 도메인 기반 설계 개념을 채택해 데이터 아키텍처에 적용함으로써 중앙 집중식 데이터 아키텍처의 문제를 보완하려 한다.

---

3-8.기타 데이터 아키텍처 예시

데이터 아키텍처에는 데이터 패브릭, 데이터 허브, 확장 아키텍처, 메타데이터 우선 아키텍처, 이벤트 기반 아키텍처,라이브 데이터 스택 등 수많은 종류가 있다.

 

데이터 엔지니어는 새로운 데이터 아키텍처가 조직에 어떻게 도움이 되는지에 주목해야 한다. 해당 아키텍처의 잠재적 가치를 판단한 후 심화 학습을 수행하고 구체적인 결정을 내려야 한다.

 

데이터 아키텍처 설계 담당자는 누구인가?

대기업의 경우 데이터 아키텍트를 고용할 수 있지만, 규모가 작은 기업인 경우 데이터 엔지니어가 데이터 아키텍트로서 이중으로 업무를 수행할 수 있습니다. 따라서 데이터 엔지니어는 훌륭한 데이터 아키텍처를 구축하는 방법을 알고 있어야 합니다.

---

결론

데이터 아키텍처가 데이터 엔지니어링 수명 주기에 어떻게 부합하는지, 그리고 '우수한'데이터 아키텍처를 만드는 요소는 무엇인지를 살펴보며, 데이터 아키텍처의 몇가지 예시를 확인했다. 아키텍처는 성공을 위한 중요한 기반인 만큼 모든 아키텍처에 내재된 트레이드 오프를 이해하고 깊이 연구할 시간을 투자하기를 바란다. 이 과정에서 조직의 고유한 요구 사항에 대응하는 아키텍처를 설계할 준비가 될 것 이다.