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

3.1 데이터 아키텍처란?

아키텍트는 단순히 IT 프로세스를 설계하고 머나먼 유토피아적 미래를 막연하게 바라보는 것이 아니라, 적극적으로 비즈니스 문제를 해결하고 새로운 기회를 창출한다. 아키텍트는 현재 상태의 문제(낮은 데이터 품질, 확장성 제한, 비용손실)를 식별하고, 바람직한 미래 상태(민첩한 데이터 품질 개선, 확장성 있는 클라우드 데이터 솔루션, 비즈니스 프로세스 개선)를 정의하며, 소규모의 구체적인 단계를 실행함으로써 이니셔티브를 실현한다. 

 

기술적 솔루션은 그 자체를 위한 것이 아니라
비즈니스 목표를 지원하기 위해 존재한다.

운영 아키텍처는 무엇을 해야 하는지를 설명하고, 기술 아키텍처는 어떻게 해야 하는지를 자세히 설명한다.

 

 

🤔 그렇다면 우수한 아키텍처와 나쁜 데이터 아키텍처를 가르는 기준은 무엇일까?

우수한 아키텍처는 유연하고 유지 관리하기 쉽다. 미래에 더 많은 가치를 창출할 수 있는 새로운 기술 및 관행에 대응해 진화한다.

나쁜 데이터 아키텍처는 서로 긴밀하게 결합되었건, 경직되었거나, 지나치게 중앙 집중화된 상태이다. 

 

3.2 우수한 데이터 아키텍처의 원칙

[데이터 엔지니어링 아키텍처 원칙]

 

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

2. 장애에 대비

(가용성, 신뢰성, 복구 시간 목표(RTO), 복구 시점 목표(RPO) 등을 고려해 장애에 대비해야 한다.)

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

(현재 부하와 대략적인 로드 스파이크를 측정하고 향후 몇 년간의 부하를 예측해 데이터베이스 아키텍처가 적절한지 판단)

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

(데이터 엔지니어로서 아키텍처 리더십을 연습하고 아키텍트의 조언을 구해야 한다.)

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

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

(즉, 어떤 걸 변경했음에도 불구하고 다른 팀과의 의사소통이 거의 필요하지 않아야 하는 것이다.)

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

(아키텍터의 중요한 임무 중 하나는 소프트웨어 설계에서 돌이킬 수 없는 부분을 제거하는 방법을 찾아내 아키텍처를 제거하는 것)

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

(데이터를 다루는 사람은 궁극적으로 데이터 보안에 책임이 있다고 가정해야 한다.)

9. 핀옵스를 수용하라

(인프라 지출을 데이터 중심으로 관리하는 동시에 비용 효율성을 높이고 궁극적으로는 클라우드 환경의 수익성을 높인다.)

 

3.3 주요 아키텍처 개념

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

ex) 판매 도메인 내부에는 주문 서비스, 송장 서비스, 상품 서비스 등이 있을 수 있다.

 

일반적인 수평 확장 시스템에는 워크로드의 인스턴스화, 진행 및 완료를 위한 주요 창구 역할을 하는 리더 노드가 있다.

워크로드가 시작되면 리더 노드는 작업을 시스템 내 워커 노드에 분산해 완료하고, 그 결과를 리더 노드로 반환한다. 

이러한 분산 아키텍처에 대해서는 [데이터 중심 애플리케이션 설계] 에 잘 담겨져 있다. 

 

우수한 아키텍처를 설계하기 위해서는 도메인과 서비스의 강한 결합과 느슨한 결합 사이의 트레이드오프에 의존해야 한다.

 

모놀리스 vs 마이크로 서비스

[모놀리스]

모놀리스의 강한 결합은 두더지 잡기 게임과 같은 상황이 발생할 수 있다. 즉, 한 컴포넌트가 개선되지만, 모놀리스의 다른 영역에서는 알려지지 않은 결과들을 희생하는 경우가 많다. 

 

데이터 팀은 점점 더 복잡해지는 모놀리스 문제를 방치하는 경우가 많으며, 결국 엉망진창으로 굴러가는 큰 진흙 공(big ball of mud) 처럼 만들어버린다. 

 

[마이크로]

각 서비스는 특정 기능이 있으며, 도메인 내에서 운영되는 다른 서비스와 분리된다.

 

중앙 데이터 웨어하우스는 본질적으로 모놀리식하다.
반면, 데이터 메시는 DDD 를 채택해 데이터 아키텍처에 적용함으로써 중앙 집중식 데이터 아키텍처의 문제를 뒤집으려 한다. 

 

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

[데이터 웨어하우스]

보고 및 분석에 사용되는 중앙 데이터 허브로, 가장 오래되고 잘 확립된 데이터 아키텍처의 하나다. 데이터 웨어하우스 아키텍처의 두 가지 유형인 '조직' 과 '기술'에 주목해야 한다. 

 

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

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

기술 데이터 웨어하우스 아키텍처는 MPP 와 같은 데이터 웨어하우스의 기술적 본질을 반영한다.

 

조직 데이터 웨어하우스 아키텍처의 주요 특징 두 가지는 다음과 같다. 

• 운영 데이터베이스(OLTP)에서 온라인 분석처리(OLAP)를 분리
• 데이터 중앙 집중화 및 구성

[ETL vs ELT]

ELT 데이터 웨어하우스 아키텍처에서는 데이터를 운영 시스템에서 데이터 웨어하우스의 스테이징 영역으로 어느 정도 직접 이동할 수 있다.

데이터는 일괄 처리되며, 변환된 출력은 분석을 위해 테이블 및 뷰에 기록된다. 

 

 

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

클라우드 데이터 웨어하우스가 발전되면서 조직 아키텍처에 큰 변화를 가져왔다. 기업은 향후 몇 년 간 MPP 시스템의 크기를 적절히 조정하고 시스템을 조달하기 위해 수백만 달러 규모의 계약을 체결하는 대신, 레드시프트 클러스터를 온디맨드로 스핀업해 데이터 및 분석 수요의 증가에 따라 단계적으로 확장할 수 있는 옵션을 선택할 수 있게 됐다. 

 

또한, 빅쿼리, 스노우플레이크 및 기타 경쟁업체는 컴퓨팅과 스토리지를 분리함으로써 사실상 무제한 스토리지를 사용할 수 있고, 

컴퓨팅 파워를 온디맨드 방식으로 스핀업할 수 있다. 

 

[데이터마트]

데이터 마트가 필요한 이유는 다음 두 가지다.

1. 데이터 마트는 분석가와 보고서 개발자가 데이터에 더 쉽게 접근할 수 있도록 한다.

2. 데이터 마트는 초기 ETL 또는, ELT 파이프라인이 제공하는 것보다 더 많은 변환 단계를 제공한다.

 

 

[데이터 레이크]

빅데이터 시대에 등장한 가장 인기 있는 아키텍처인 데이터레이크는 데이터에 엄격한 구조적 제한을 가하는 대신, 정형 데이터와 비정형 데이터를 모두 중앙 위치에 저장할 수 있게 함으로써 차세대 아키텍처가 될 거라고 확신했지만 결과론적으로는 데이터 늪, 다크데이터와 같은 평가를 받고 있다. 

 

아파치 생테계의 오픈 소스 소프트웨어는 독점적인 MPP 시스템에 대한 수백만 달러의 계약을 피하는 수단으로 홍보됐다. 저렴한 기성 하드웨어가 맞춤형 벤더 솔루션을 대체할 수 있다는 것이다. 실제로는 하둡 클러스터 관리의 복잡성 때문에 기업은 대규모 엔지니어 팀을 고액 연봉으로 고용해야 했으므로 빅데이터 비용은 급증했다.

 

하지만 넷플릭스나 페이스북과 같은 기업들은 데이터 레이크의 효용성을 활용해 성공적인 사례를 구축했다. 하지만 많은 조직에서 데이터 레이크는 낭비와 실망, 치솟는 비용으로 얼룩진 내부의 슈퍼펀드 사이트로 변모했다.

 

[차세대 데이터 레이크]

데이터브릭스는 데이터 레이크하우스라는 개념을 도입했다. 데이터 레이크하우스는 데이터 레이크 + 데이터 하우스로, 

데이터 웨어하우스에서 볼 수 있는 제어, 데이터 관리, 데이터 구조를 통합하는 동시에, 객체 스토리지에 데이터를 저장하고 다양한 쿼리 및 변형 엔진을 지원한다.

 

또한 레이크하우스는 기존의 데이터를 쏟아 붓기만 하고 갱신하거나 삭제하지 않는 본래의 레이크에서 벗어나 ACID 트랜잭션을 지원한다.

미래의 데이터 엔지니어는 데이터 레이크 아키텍처와 데이터 웨어하우스 아키텍처 중 하나를 선택하는 대신 벤더, 생태계, 상대적 개방성 등 다양한 요소를 기반으로 통합 데이터 플랫폼을 선택할 수 있게 될 것이다.

 

[람다 아키텍처]

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

 

람다 아키텍처는 여전히 인기가 높다. 하지만 분석을 위해 스트리밍 데이터와 배치 데이터를 결합하려는 경우 람다를 먼저 권장하지는 않는다.

 

 

[카파 아키텍처]

카파 아키텍처의 주요 논지는 다음과 같다. 스트림 처리 플랫폼을 데이터 처리, 저장 및 서빙 등 모든 데이터 처리의 백본으로 사용하는 것은 어떨까? 즉, 이벤트와 같은 모든 데이터를 처리하고 이러한 이벤트를 테이블이 아닌 스트림으로 저장하는 것이다.

 

하지만, 카파 아키텍처가 널리 채택되지 못한 이유는 다음과 같다. 

첫째로 아직 많은 기업에서 스트리밍 자체는 미지의 영역이기 때문이다. 

둘때로 카파 아키텍처는 복잡하고 실제로 비용이 많이 드는 것으로 나타났다. 일부 스트리밍 시스템은 대규모 데이터 볼륨으로 확장할 수 있지만 복잡하고 비용이 많이 든다. 

 

https://blog.jetbrains.com/ko/blog/2021/07/09/big-data-world-part-4-architecture/

 

 

결론

데이터 아키텍처가 데이터 엔지니어링 수명 주기에 어떻게 부합하는지, 그리고 '우수한' 데이터 아키텍처를 만드는 요소는 무엇인지를 살펴봤고, 데이터 아키텍처의 몇몇 예도 확인했다. 아키텍처는 성공을 위한 중요한 기반인 만큼 모든 아키텍처에 내재된 트레이드오프를 이해하고 깊이 연구할 시간을 투자할 것을 권한다.