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

1. 데이터 아키텍처란?

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

• 엔터프라이즈 아키텍처(EA, Enterprise Architecture)
  • 비지니스, 기술, 애플리케이션 및 데이터를 포함한 다양한 하위집합을 포함
  • 많은 프레임워크와 자원이 엔터프라이즈 아키텍처에 할당됨

 

• 엔터프라이즈 아키텍처에 대한 다양한 정의
  • TOGAF
    • 엔터프라이즈: 모든 정보 및 기술 서비스, 프로세스, 인프라를 포함하는 전체 기업 또는 기업 내 특정 도메인
    • 엔터프라이즈 아키텍처는 기업 내 여러 시스템과 기능 그룹을 넘나듦
  • 가트너
    • 엔터프라이즈 아키텍처: 바람직한 비지니스 비전과 결과를 향한 변화의 실행을 식별, 분석해 기업이 파괴적 힘에 능동적이고 전체적으로 대응할 수 있도록 주도하는 분야
  • EABOK
    • EA: 전략, 운용 및 기술을 조정해 성공 로드맵을 만드는 기업의 추상적 표현이자 조직 모델
  • 책에서의 정의
    • 기업의 변화를 지원하는 시스템 설계
    • 신중한 트레이드오프 평가를 통해 유연하고 되돌릴 수 있는 의사결정으로 달성

 

• 유연하고 되돌릴 수 있는 가역적 의사결정이 필요한 이유
  • 미래는 예측할 수 없다 → 세상의 변화와 새로운 정보 수집에 따른 프로세스 조정이 필요함
  • 조직이 성장하면 기업의 경직화가 발생하는 경향이 있음 → 각종 의사결정에 수반되는 위험을 줄일 필요성이 있다.

 

• AWS의 의사결정 정의
  • 단방향 의사결정 (one-way door): 되돌릴 수 없는 결정
  • 양방향 의사결정 (two-way door): 쉽게 되돌릴 수 있는 결정

 

• 변경 관리
  • 기업은 대규모 이니셔티브를 수행해야 함
  • 대규모 이니셔티브는 작은 변화들로 나뉘는데 각각의 변화는 되돌릴 수 있는 결정임
  • 이런 작은 액션들을 관리하는 것이 변경 관리의 핵심사항

 

• 아키텍트의 목표
  • 현재 상태 문제를 식별
    • 낮은 데이터 품질, 확장성 제한, 비용 손실 등
  • 바람직한 미래 상태로 전환
    • 민첩한 데이터 품질 개선, 확장성 있는 클라우드 데이터 솔루션, 비지니스 프로세스 개선 등
  • 전환은 소규모 구체적 단계를 실행해나가며 이니셔티브를 실현
  • 반복을 감내할 수 있어야 함

 

• EA의 핵심사항
  • 유연성과 트레이드 오프의 균형을 유지하는 것
  • 아키텍트는 끊임없이 측정하고 재평가 해야함
  • 기술적 솔루션은 그 자체가 아니라 비지니스 목표를 위해서 존재한다는 것을 명시

 

[2] 데이터 아키텍처 정의

• 데이터 아키텍처(Data Architecture)
  • 엔터프라이즈 아키텍처 하위집합
  • 프로세스, 전략, 변경 관리, 트레이드 오프 평가 등 속성을 상속

 

• 데이터 아키텍처에 대한 다양한 정의
  • TOGAF의 정의
    • 기업의 주요 데이터 유형, 원천, 논리적/물리적 데이터 자산, 데이터 관리 자원의 구조와 상호 작용에 대한 설명
  • DAMA의 정의
    • 기업의 데이터 요구 사항을 파악하고 이를 충족시킬 마스터 청사진 설계 및 유지 관리
  • 책에서의 정의
    • 기업의 진화하는 데이터 요구사항을 지원하는 시스템 설계
    • 트레이드 오프에 대한 신중한 평가 → 유연하고 되돌릴 수 있는 결정으로 실현
    • 데이터 엔지니어링 아키텍처는 데이터 아키텍처의 하위집합이나 같은 의미로서 사용

 

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

 

[3] 우수한 데이터 아키텍처

• 데이터 아키텍트 목표
  • 기본적 수준에서 뛰어난 아키텍처로 이어질 중요 결정을 내리는 것
  • 중요한 것은 변경 비용

 

• 우수한 데이터 아키텍처
  • 유연성을 유지
  • 적절한 트레이드오프를 실현
  • 광범위하게 재사용 가능한 공통 구성 요소를 사용 → 비지니스 요건 충족
  • 민첩성 → 유연하고 유지 관리하기 쉬운 아키텍처
  • 비지니스 내부 변화와 새로운 기술 및 관행에 대응
  • 원래 상태로 되돌릴 수 있는 가역성있는 아키텍처 설계 → 변경 비용 절감

 

• 나쁜 데이터 아키텍처
  • 서로 긴밀히 결합
  • 경직화
  • 지나친 중앙 집중화
  • 업무에 맞지 않는 잘못된 도구 개발 및 변경 관리

 

---

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

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

 

[원칙 1] 공통 컴포넌트를 현명하게 선택하라

• 공통 컴포넌트 설계
  • 조직 전체가 사용할 공통 컴포넌트와 관행 선택
    • 잘 설계되면 팀 협업을 촉진하고 사일로를 허물 수 있음
    • 팀 내 또는 팀 간 공유된 지식 및 기술로 민첩성을 실현
  • 공통 컴포넌트는 적절한 사용 사례를 통해 누구나 접근 가능해야 함
    • 이미 사용 중인 공통 컴포넌트에 의존하는게 좋음
    • 강력한 권한과 보안을 통해 팀 간 자산을 공유하면서도 부정 접근은 차단
  • 클라우드 플랫폼은 공통 컴포넌트 채택이 용이케 함

 

• 공통 컴포넌트 활용
  • 개별 프로젝트에 유용한 공통 컴포넌트를 활용
  • 상호 운용과 협업을 동시에 촉진할 필요
  • 아키텍트는 엔지니어의 생산성을 저해하는 결정을 피해야 함

 

[원칙 2] 장애에 대비하라

• 견고한 데이터 시스템 구축을 위해 설계 시 장애를 고려해야 함
• 장애 시나리오 평가 용어
  • 가용성: 작동 가능한 상태에 있는 시간 비율
  • 신뢰성: 정의된 표준을 충족할 확률
  • 복구 시간 목표 (RTO, Recovery Time Objective): 시스템 장애 최대 허용 시간
  • 복구 시점 목표 (RPO, Recovery Point Objective): 복구 후 허용 가능한 상태

 

• 엔지니어는 장애에 대비한 설계 시 위 4가지를 고려해야 함
  • 아키텍처 결정에도 도움이 됨

 

[원칙 3] 확장성을 위한 아키텍처를 설계하라

• 데이터 시스템 확장성
  • 스케일 업(scale up)
  • 스케일 다운(scale down)
  • 탄력적 시스템(elastic system) 구축을 통해 부하에 따라 동적으로 확장할 수 있으며 이상적으로는 자동화된 방식으로 확장 가능할 수 있다.

 

• 부적절한 확장 전략은 시스템의 복잡성을 증대시키고 비용을 늘릴 수 있다.
  • 현재 부하와 로드 스파이크를 측정
  • 향후 몇년간 부하를 예측해 데이터베이스 아키텍처의 적절성 판단 필요

 

[원칙 4] 아키텍처는 리더십이다

• 데이터 아키텍트
  • 기술의 결정과 아키텍처 설명을 담당
  • 효과적 리더십을 보유하고 교육을 통해 기술 선택 과정 및 이유를 전파할 책임
  • 기술적으로 유능해야하나 실제 구현은 다른 작업자에게 위임할 필요
• 데이터 엔지니어로서의 역할
  • 아키텍처 리더십을 연습
  • 아키텍트의 조언을 구해야 함
  • 스스로 아키텍트 역할을 맡을 수도 있음

 

[원칙 5] 항상 아키텍처에 충실하라

• 데이터 아키텍트의 일
  • 기본 아키텍처(현상태, baseline architecture)에 대한 깊은 지식 개발
  • 목표 아키텍처(target architecture)를 개발
  • 시퀀싱 계획(sequencing plan)을 수립
    • 시퀀싱 계획: 아키텍처 변경의 우선순위와 순서를 결정하는 작업

 

• 아키텍처의 덕목
  • 폭포수 방식이 아닌 협력적이고 민첩한 방식으로 일해야 함
  • 시간에 따라 변화하는 목표 아키텍처와 시퀀싱 계획을 유지

 

[원칙 6] 느슨하게 결합된 시스템을 구축하라

• 베이조스의 API 선언문

---

① 자금부터 모든 팀은 서비스 인터페이스를통해 데이터와 기능을 공개한다.

② 각 팀은 이러한 인터페이스로 서로 소통해야 한다.

③ 다른 형태의 프로세스 간 통신은 허용되지 않는다. 직접 연결direct link, 다른 팀의 데이터 저장소 직접 읽기, 공유 메모리 모델, 백도어 등 그 어떤 것도 허용되지 않는다. 허용돠는 유일한 통신은 네트워크를 통한 서비스 인터페이스 호출을 사용한 것이다.

④ 어떤 기술을 사용하는자는 중요하지 않다. HTTP, CORBA, Pub/sub, 사용자 정의 프로토콜 등 무엇이든 상관없다.

⑤ 모든 서비스 인터페이스는 예외 없이 처음부터 외부화할 수 있도록 설계되어야 한다. 즉, 팀은 외부의 개발자에게 인터페이스를 공개할 수 있도록 계획하고 설계해야 한다. 예외는 없다.

---

 

• 느슨하게 결합된 시스템 특성

---

① 시스템은 많은 수의 작은 컴포넌트로 나뉜다.

② 이러한 시스템은 메시징 버스messaging bUs나 八|기와 같은 추상화 계층을 통해 다른 서비스와 상호 작용한다. 이러한 추상화 계층은 데이터베이스 백엔드 또는 내부 클래스 및 메서드 호출과 같은 서비스의 내부적인 세부 정보를 숨기고 보호한다.

③ 속성 ②의 결과, 시스템 컴포넌트에 대한 내부 변경은 다른 부분에 대한 변경을 요구하지 않는다. 코드 갱신의 자세한 내용은 안정적인 API 뒤에 숨겨져 있다. 그두 조각은 개별적으로 발전하고 개선될 수있다.

④ 속성 ③의 결과, 시스템 전체에 대한 폭포수식 글로벌 배포 주기는 없다. 대신 각 컴포넌트는 변경 및개선이 이루어짐에 따라 개별적으로 갱신된다.

---

 

• 느슨하게 결합된 조직 특성

---

① 많은 소규모 팀이 크고 복잡한 시스템을 설계한다. 각 팀은 일부 시스템 컴포넌트의 엔지니어링, 유지 보수 및 개선 업무를 담당한다.

② 이러한 팀은 API 정의, 메시지 스키마 등을 사용해 컴포넌트의 추상적인 세부 사항을 다른 팀에 공개 한다. 각 팀은 다른 팀의 컴포넌트에 신경 쓸 필요가 없다. 게시된 API 또는 메시지 명세를 사용해 이들 컴포넌트를 호출할 뿐이다. 이들은 시간이 지남에 따라 성능 및 기능을 개선하고자 각자의 역할을 반복 한다. 또한 새로운 기능을 추가하면 이를 공개할 수도 있고 다른 팀에서 새로운 기능을 요청할 수도 있다. 이때도 요청된 기능의 내부 기술 세부 사항은 팀이 걱정할 필요가 없다. 팀은 느슨하게 연결된 커뮤 니케이션으로 협력한다.

③ 특징 ②의 결과, 각 팀은 다른 팀의 업무와 독립적으로 자신의 컴포넌트를 빠르게 발전시키고 개선할수 있다.

④ 특히 특징 ③은 팀이 최소한의 다운타임으로 컴포넌트 갱신을 배포할 수 있음을 의미한다. 팀은 정규 근무 시간 동안 계속 배포해 코드를 변경하고 테스트한다.

---

 

[원칙 7] 되돌릴 수 있는 의사결정을 하라

• 아키텍처 단순화 및 민첩성 유지를 위해 돌이킬 수 있는 의사결정을 목표로 삼아라.
• 항상 현재에 적합한 최고의 솔루션을 선택하도록 노력하라.
  • 기술의 분리/모듈화 등 변화속도 고려 필요
• 환경의 변화에 따른 시스템 업그레이드나 더 나은 방법을 채택할 준비가 필요

 

[원칙 8] 보안 우선순위를 지정하라

• 강화된 경계 보안 모델과 제로 트러스트 보안 모델
  • 강화-경계(hard-perimeter) 보안 모델
    • 내부의 ‘신뢰할 수 있는 것’과 외부의 ‘신뢰할 수 없는 것’으로 경계를 설정해 보안을 설정’
    • 단점: 스피어 피싱 같은 외부 위협과 내부자 공격에도 취약한 모델임
  • 제로-트러스트 보안(zero-trust sequrity)

 

• 공동 책임 모델
  • AWS의 공동 책임 모델
    • 클라우드 보안(security of the cloud): AWS가 책임 → AWS 인프라를 보호, 사용자가 안전하게 사용할 수 있는 서비스 제공
    • 클라우드 내 보안(security in the cloud): 사용자가 책임 → 이용하는 AWS 서비스 내에서 관련 보안들을 책임

 

• 보안 엔지니어로서의 데이터 엔지니어
  • 클라우드에서 제공하지 않는 데이터 관련 보안 부분을 책임져야 함

 

[원칙 9] 핀옵스를 수용하라

• 핀옵스 정의
  • 클라우드 재무 관리 분야이자 문화적 관행
  • 데이터 기반 지출 결정을 위해 협업할 수 있도록 지원함
  • 데이터 중심으로 인프라 지출을 관리하며, 비용 효율성을 높이고 클라우드 환경의 수익성을 높이는게 목표

 

• 핀옵스 출현 배경
  • 온프레미스(on-premise) 환경 → 클라우드 환경으로의 전환
    • 클라우드 환경은 종량제 방식으로의 데이터 시스템으로 쉽게 확장이 가능함
    • 고성능을 위해 스케일업, 비용 절감을 위한 스케일 다운이 가능
    • 비용 지출은 더 역동적으로 데이터 리더가 예산, 우선순위, 효율성을 관리할 필요가 있음

 

• 엔지니어에게 핀옵스란
  • 엔지니어는 핀옵스를 통해 클라우드 시스템 비용 구조를 생각하는 방법을 배워야 함
  • 지출 급증에 대응하는 장애모드를 설정해 지출을 엄격하게 제한해야 할 필요가 있음
  • 비용 공격 측면에서도 생각할 필요가 있음 → 과도한 다운로드나 데이터 제한 정책, 지속적 모니터링 필요

 

---

 

3. 주요 아키텍처 개념

• 모든 아키텍처의 목표는 데이터를 가져와 다운스트림 소비에 유용한 결과물로 변환하는 것!

 

[1] 도메인과 서비스

• 도메인(domain)
  • 실제 설계를 하는 주제 영역
  • 여러 서비스를 포함할 수 있음
  • 도메인을 설계할 때는 실제 세계에서 무엇을 나타내는지 초점을 맞출 필요

 

•  서비스(service)
  • 작업 달성이 목적인 기능 집합

 

• 도메인과 서비스를 설정할 때는 사용자 및 이해관계자의 피드백을 듣고, 작업 수행에 도움이 되게 구축되어야 함

 

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

• 데이터 엔지니어로서 관심사항
  • 확장성
  • 탄력성
  • 가용성
  • 신뢰성
• 확장성의 실현
  
  • 단일 머신 → 사용 가능한 자원의 한계

  • 

  • 수평 확장(horizontal scaling) → 분산 시스템
    • 리더 노드 → 작업을 워커 노드에 분산 → 결과를 리더 노드에서 취합
    • 세부사항은 추상화 돼 높은 수준 아키텍처에 집중가능
    • 다만 파이프라인 성능 개선 및 이해에는 세부 사항 이해도 필요해 시스템을 자세히 이해하는 것이 도움이 됨

 

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

• 데이터 아키텍처에서의 상호의존성
  • 강한 결합(tight coupling)
    • 긴밀하게 결합된 패턴으로 도메인과 서비스의 모든 부분은 다른 도메인과 서비스에 의존
  • 느슨한 결합(loose coupling)
    • 서로 의존하지 않는 분산형 도메인과 서비스
    • 분산된 팀에서는 동료들이 데이터를 사용하기 어려울 수 있다.
  • 강한 결합과 느슨한 결합 사이의 트레이드 오프를 잘 파악할 필요가 있음
  • 도메인과 서비스를 소유한 팀에게 공통의 표준, 소유권, 책임, 의무를 부여해야 함

 

• 아키텍처 계층

• 

  • 단일 계층(single-tier architecture)
    • DB와 애플리케이션이 결합된 형태로 단일 서버에 상주
    • DB, 서버, 애플리케이션 각 단에서 장애가 발생하면 전체 아키텍처에서 장애가 발생할 수 있다.
    • 장점: 단순성, 빠른 프로토타이핑 개발
    • 단점: 운영 환경 시 장애 발생하면 전체 시스템 장애 위험
    • 로컬 머신에서 시스템 테스트에는 적합하나 운영 환경에서는 부적합
  • 다중 계층(multi-tier architecture)
    • 데이터, 애플리케이션, 비즈니스 로직, 프레젠테이션 등 개별 계층으로 구성
    • 각 계층은 다른 계층과 서로 격리돼 리스크 분산 가능
    • 상향식(bottom-up)이고 계층적(hierarchical) 구조
    • 상위계층은 하위계층에 반드시 의존적, 하위계층은 의존적일수도, 아닐수도.

    • 

  •  3계층 아키텍처(three-tier architecture)
    • 일반적인 다중 계층으로 데이터, 애플리케이션 로직, 프레젠테이션 계층으로 구성

 

• 아키텍처 계층에서 데이터 엔지니어의 역할
  • 계층을 사용해 계층 아키텍처와 종속성이 처리되는 방식 평가
  • 단순하게 시작 → 아키텍처가 복잡해지면 추가 계층으로 분화
  • 다중 계층에서는 계층 내에서 분산 시스템간 자원 공유 방식을 고려해야 함
    • 노드와의 자원 경합을 원하는가?
      1. 비공유 아키텍처(shared-nothing architecture): 단일 노드가 각 요청을 처리 → 노드간 메모리, 디스크, CPU 등 자원을 공유하지 않음 (데이터 자원은 노드로 격리)
      2. 공유 디스크 아키텍처(shared disk architecture): 모든 노드들은 동일한 디스크와 메모리를 공유 → 임의의 노드에 장애 발생 시 공유 자원을 사용할 수 있음

 

•  모놀리스
  • 기술 결합(technical coupling): 아키텍처 계층에서의 결합
  • 도메인 결합(domain coupling): 도메인이 서로 결합
  • 모놀리스에서는 기술과 도메인간 결합정도가 다양
  • 모놀리스에서 강한 결합 → 컴포넌트의 모듈화가 부족하다.
  • DE는 복잡한 모놀리스가 방치되지 않도록 해야함

 

•  마이크로서비스
  • 마이크로 아키텍처(microservice architecture): 느슨하게 결합된 개별적이고 분산된 서비스로 구성
    • 각 서비스는 특정 기능이 있으며 도메인 내에서 다른 서비스들과 분리
    • 한 서비스가 일시적으로 중단되도 다른 서비스는 영향받지 않음

• 모놀리스의 마이크로 서비스로의 전환 방법
  • 모놀리스의 복잡성, 모놀리스에서 서비스 추출에 들어가는 노력에 따라 방법이 달라짐
  • 모놀리스 분리가 어려울 시 마이크로 친화적 방식으로 서비스 분리하는 새로운 병렬 아키텍처를 구축할 필요가 있음 (전체적 리펙터링보다는 서비스 분리가 우선)
  • 모놀리스 분리 시 해당 모놀리스 이해관계자들로부터 동의를 얻을 필요
• 데이터 아키텍처 관련 고려 사항
  • 중앙 데이터 웨어하우스는 본질적으로 모놀리식
    • 마이크로서비스로 전환하려면 해당 도메인별 DW에 연결된 도메인별 데이터 파이프라인과 워크플로를 분리
  • 모놀리스 분리를 독단적으로 판단하기 보다는 데이터 기술 상태와 한계를 인식하며 이상적인 느슨한 결합을 실용적으로 사용할 필요
    • 가능하다면 모듈화와 느슨한 결합을 허용하는 가역적인 기술 선택들을 통합
  • 모놀리스를 반드시 나쁘다고 할 순 없다
    • 빠르게 움직여야 할 때는 모놀리스로 시작하는게 훨씬 간단
    • 시간이 지나면 결국에는 더 작게 분할할 준비해를 해야함

 

[4] 사용자 접근: 싱글 v s 멀티테넌트

• 멀티테넌시에서 성능과 보안
  • 보안
    • 서로 다른 테넌트 데이터를 적절히 분리해야 함
    • 외부 고객 테넌트는 서로를 인식해서 안되고 데이터 유출을 방지해야 함(적절한 데이터 격리 전략 필요)
    • ex> 멀티테넌트 테이블 → 뷰를 통한 데이터 격리

 

[5] 이벤트 기반 아키텍처

• 이벤트 기반 워크플로
  • 이벤트 중심 워크플로를 수용하고 다양한 서비스간 통신
  • 데이터 엔지니어링 수명주기의 다양한 부분에서 이벤트 생성, 갱신, 비동기적으로 이동하는 기능이 포함
  • 이벤트 생성, 라우팅, 소비 3가지 영역으로 요약
  • 이벤트는 생산자, 이벤트 라우터, 소비자간 종속성 없이 생성되고, 소비 대상으로 라우팅돼야 함
  • 장점
    • 이벤트 상태를 여러 서비스에 분산시킴
    • 서비스가 오프라인 상태일 때, 분산 시스템 노드에서 장애 발생 시, 여러 소비자나 서비스가 동일 이벤트에 접근할 때 유용함

 

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

프로젝트 유형은 브라운필드와 그린필드 두가지 유형으로 나뉨

• 브라운필드 프로젝트(brownfield project)
  • 기존 아키텍처를 리펙터링하고 재구성하는 경우가 많으며, 현재와 과거 선택에 따른 제약을 받음
  • 핵심 부분은 변경 관리로 새로운 비지니스 및 기술 목표 달성 경로를 설계해야 함
  • 레거시 아키텍처에 대한 철저한 이해와 다양한 신/구 기술간 상호작용이 필요
  • 이전 작업 내용을 비판하기보다는 결정이 내려진 히스토리를 이해하고, 기존 문제를 진단하는게 도움이 됨
  • 재검토를 통해 전면 개편을 하는 경우가 많은데 돌이킬 수 없고 비용이 많이 든다는 한계가 있음
  • 스트랭글러 패턴(strangler pattern)
    • 레거시를 천천히, 점진적으로 대체 (시스템 부분을 하나씩 리펙터링)
    • 종속 시스템에 미치는 영향을 평가하며 유연하고 되돌릴 수 있는 결정이 가능
  • deprication은 달성하지 못할 위험이 있다!
    • 대규모 조직이라면 레거시 기술이나 아키텍처를 배제하기 불가능할 수 있다 → 누군가는 사용하고 있을 수 있다.
    • deprication이 합의된다면 다양한 방법이 있다는걸 이해할 필요
    • 새로 구축된 플랫폼의 성숙도를 높이고, 시스템 폐쇄 계획에 따라 천천히 진행할 필요

 

• 그린필드 프로젝트(greenfield project)
  • 이전 아키텍처 역사나 레거시에 의존하지 않고 실행 가능!
  • 신기술과 최신 아키텍처 패턴 적용 가능
  • 이력서 주도 개발 유혹에 빠지지 말고 작업요건과 우수한 데이터 아키텍처 원칙에 초점을 맞출 것.
  • 트레이드 오프를 평가하고 유연하고 되돌릴 수 있는 결정, 긍정적 ROI 실현할 수 있도록 초점

 

---

 

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

[1] 데이터 웨어하우스

• 데이터 웨어하우스(data warehouse) → 분석 활용 사례에 맞게 고도로 포맷 및 구조화
  • 조직 데이터 웨어하우스 아키텍처: 데이터
  • 기술 데이터 웨어하우스 아키텍처: 기술적 측면(ex> MPP)

 

• 조직 데이터 웨어하우스 주요 특징
  1. 운영 데이터베이스(OLTP)에서 온라인 분석 처리(OLAP)를 분리
     • 데이터를 별도 물리적 시스템으로 이전 → 부하 줄이고 성능 향상
  2. 데이터 중앙 집중화 및 구성

 

• 클라우드 데이터 웨어하우스
  • ex> 아마존 레드시프트

• 데이터 마트
  • 조직이나 비지니스 라인(LOB)에 초점을 맞춰 분석 or 보고서 제공하도록 설계된 DW의 하위집합
  • 각 부서는 고유한 데이터 마트가 존재
  • 필요 이유
    • 분석가나 개발자가 데이터에 더 쉽게 접근 가능
    • 초기 ETL 또는 ETL 파이프라인 제공하는 데이터보다 더 많은 변환단계를 제공 → 복잡한 처리가 필요한 경우 성능 향상

 

[2] 데이터 레이크

• 데이터 레이크(data lake)
  • 구조적 제한을 허물고 정형 데이터와 비정형 데이터를 모두 중앙에 저장함
  • 방대한 데이터를 의미없이 저장해 관리가 불가능한 문제가 발생
    • 데이터 늪, 다크 데이터, WORN
    • 데이터 처리도 어려웠음
    • 하둡 클러스터의 관리 복잡성

 

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

• 데이터 레이크하우스
  • databricks에서 제시한 개념으로 DW의 제어, 데이터 관리, 데이터 구조를 통합하고 객체 스토리지에 데이터 저장, 다양한 쿼리 및 변형 엔진을 지원
  • ACID 트랜잭션 지원
  • 다양한 클라우드 업체가 DW와 데이터 레이크를 융합하는 추세

 

[4] 모던 데이터 스택

• 모던 데이터 스택(modern data stack)
  • 클라우드 기반 플러그 앤 플레이(PnP) 방식과 사용하기 쉬운 기성 구성 요소를 사용
  • 모듈식이면서도 비용 효율적 데이터 아키텍처 구축을 목표로 함
  • 데이터 파이프라인, 스토리지, 변환, 데이터 관리/거버넌스, 모니터링, 시각화, 탐색을 포함
  • 최종적으로 복잡성을 줄이고 모듈화를 늘리는 것이 목표
  • 저자는 향후 더 넓게 사용될 것으로 보고 있음

 

[5] 람다 아키텍처

• 람다 아키텍처
  • 배치, 스트리밍, 서빙 등 시스템이 서로 독맂벚그올 작동
  • 원천 시스템 변경 불가, 추가만 가능
  • 단점: 코드베이스가 서로 다른 여러 시스템을 관리하면서 오류가 발생하기 쉬운 시스템이 될 수 있음
    • 분석을 위한 스트리밍과 배치 데이터 결합에 선권장되진 않는 편..

 

[6] 카파 아키텍처

• 람다 아키텍처의 대안으로 나옴
  • 스트림 처리 플랫폼을 데이터 처리, 저장, 서빙 등 모든 데이터 처리의 백본으로 사용
  • 널리 사용되지는 않음
    • 스트리밍이 아직 보편화되지 않음
    • 복잡하고 고비용

 

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

• 다양한 유형의 윈도에서 집계 → 모든 데이터를 이벤트로 간주
  • 무한 데이터(unbounded data): 지속적인 실시간 이벤트 스트림
  • 유한 데이터(bounded data): 데이터 배치, interval은 자연스로운 윈도우로 간주
    • 배치는 스트리밍의 특수한 경우로 볼 수 있음

 

[8] IoT용 아키텍처

• 사물인터넷: 컴퓨터, 센서 등 인터넷 접속이 가능한 장치들의 분산 컬렉션
  • 보통 IoT 장비는 주변 환경에서 발생하는 데이터를 수집해 목적지로 전송
  • 저전력, 저자원/저대역폭에서 작동

 

[9] 데이터 메시

• 데이터 메시(data mesh)
  • 도메인 기반 설계 개념을 채택 → DA에 적용해 중앙 집중식 DA 문제를 해결하려 함
  • 핵심개념: 탈중앙화

 

• 데이터 메시 핵심 구성요소
  • 도메인 지향 분산형 데이터 소유권 및 아키텍처
  • 제품으로서의 데이터
  • 플랫폼으로서의 셀프서비스 데이터 인프라
  • 통합 컴퓨팅 거버넌

 

[10] 기타 데이터 아키텍처 예시

• 기타 데이터 아키텍처 유형
  • 데이터 패브릭
  • 데이터 허브
  • 확장 아키텍처
  • 메타데이터 우선 아키텍처
  • 이벤트 기반 아키텍처
  • 라이브 데이터 스텍

 

• DE의 역할
  • 새로운 아키텍처가 조직에 어떻게 도움될지 파악해야 함
  • 새로운 개발 관련 정보를 계속 파악
  • 한가지 접근 방식에 집착 ㄴㄴ
  • 아키텍처 가치 파악 + 심화학습 ⇒ 구체적 결정

 

---

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

• DE는 전담 DA와 함께 일하는게 이상적이나 DA역할을 겸할 수도..
  • DE는 우수한 아키텍처와 다양한 유형의 데이터 아키텍처 이해할 필요가 있음