3.1 데이터 아키텍처

데이터 아키텍처는 어떻게 정의해볼 수 있을까? 엔터프라이즈 아키텍처에 대해 먼저 정의하는 것이 필수적이다.

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

• 단방향 의사결정, 양방향 의사결정, 변경관리 등 의사결정과 밀접한 관련이 있는 주제들이 존재한다!
• 기술적 솔루션은 그 자체를 위한 것이 아니라 비지니스 목표를 지원하기 위해 존재한다 !
• 유연성과 트레이드 오프의 균형을 유지해야한다.

아래는 데이터 아키텍처에 대한 책의 정의이다.

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

데이터 아키텍처 구성요소

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

우수한 아키텍처란?

• 유연성과 트레이드오프를 적절히 실현!
• 재사용 가능한 공통 구성요소
• 민첩성
• 가역성

등등을 포함!

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

AWS Well-Architected 프레임워크

1. 운영 우수성
2. 보안
3. 신뢰성
4. 성능효율성
5. 비용 최적화
6. 지속가능성

구글 클라우드의 클라우드 네이티브 아키텍처를 위한 5대 원칙

1. 자동화를 위한 설계
2. 상태의 스마트한 관리
3. 관리형 서비스 선호
4. 심층 방어 연습
5. 항상 아키텍처 설계

위의 원칙들을 토대로 우수한 아키텍처가 되기 위한 원칙을 조금 더 자세히 살펴보자!!!

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

민첩성을 실현할 수 있어야 한다. 공통 컴포넌트는 적절한 사용 사례로 누구나 접근 가능해야하며, 동시에 부정 접근을 방지해야한다.

클라우드 플랫폼은 공통 컴포넌트를 채택하기 이상적인 장소다.

원칙 2: 장애에 대비하라

모든 것은 항상 실패한다. - 베르너르 포헐스, AWS CTO

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

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

1. 확장 가능한 시스템은 상당한 양의 데이터를 처리할 수 있도록 스케일 업 할 수 있다.
2. 확장 가능한 시스템 규모를 스케일 다운할 수 있다.
3. 0으로 확장할 수도 있다
4. 탄력적 시스템은 부하에 따라 동적으로 확장할 수 있고, 이상적으로는 자동화된 방식으로 확장할 수 있다.

단, 부적절하게 확장 전략 도입하면 시스템이 지나치게 복잡해지거나 비용이 너무 많이 들 수도 있으니 조심!

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

리더십이 기술에 대한 명령과 통제 방식을 의미하지는 않는다.

모범 사례를 학습하고 공통의 목표를 추구해야한다! 리더십을 연습하고 아키텍트의 조언을 구하자><

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

단순히 기존 상태를 유지하는 역할만 수행하는 게 아니라, 기술의 변화에 대응해 새롭고 흥미로운 것들도 끊임없이 설계해라

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

한 팀이 다른 팀에 의존하지 않고도 시스템을 테스트, 배포, 변경할 수 있도록 시스템 아키텍처가 설계되면, 해당 팀은 작업을 수행할 때 의사소통이 거의 필요하지 않다.즉, 아키텍처와 팀 모두 느슨하게 결합되어 있다.

1. 지금부터 모든 팀은 서비스 인터페이스를 통해 데이터와 기능을 공개한다.
2. 각 팀은 이러한 인터페이스로 서로 소통해야 한다.
3. 네트워크를 통한 서비스 인터페이스 호출을 사용한 것이다.
4. 어떤 기술을 사용하는지는 중요하지 않다. HTTP, CORBA, Pub/sub, 사용자 정의 프로토콜 등 무엇이든 상관없다.
5. 모든 서비스 인터페이스는 예외 없이 처음부터 외부화할 수 있도록 설계되어야 한다. 즉 팀은 외부의 개발자에게 인터페이스를 공개할 수 있도록 계획하고 설계해야 한다. 예외는 없다.

API의 뒤에 데이터와 서비스를 두면서 → 느슨한 결합 가능해짐 → AWS 탄생함!

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

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

강화된 경계 보안 모델과 제로 트러스트 보안 모델

공동 책임 모델

보안 엔지니어로서의 역할도 해야한다.

원칙 9: 핀옵스를 수용하라

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

3.3 주요 아키텍처 개념

1. 도메인과 서비스

아키텍처의 구성 요소 설명 전에 도메인과 서비스 개념에 대해서 이해하는게 필요함

도메인: 실제 설계하는 주제 영역

서비스: 작업 달성 기능 집합

ex. 예를 들어보자

판매 도메인: 주문 서비스, 송장 서비스, 상품 서비스

회계 도메인: 송장 서비스, 급여 서비스, 매출채권 서비스

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

확장성: 시스템 요량을 늘려서 성능을 개선하고 수요를 처리하는 거!

탄력성: 확장성이 뛰어난 시스템을 동적으로!! 확장하는거!

가용성: 작동 가능한 상태에 있는 시간의 비율

신뢰성: 시스템이 지정된 간격 동안 의도한 기능을 수행할 때 정의된 표준을 충족할 가능성(확률)이다.

이들의 관계는 어떨까? 신뢰성이 낮으면 가용성이 저하되겠지! 탄력성은 신뢰성을 확장시킨다!

문제점

일반적으로, 단일 머신으로는 높은 가용성과 신뢰성을 제공할 수 없다.

대안

분산 시스템을 활용해 전체 확장 용량을 늘림ㄱ뫄 동시에 가용성, 신뢰성 높인다!

수평확장시스템: 부하와 자원 요건을 충족하는 더 많은 머신을 추가할 수 있다.

ex. 리더노드 1 → 워커노드, 워커노드, 워커노드 (3)

리더노드 : 워크로드의 인스턴스화, 주요 창구를 담당

워커노드: 작업 분산 받고 결과를 리더 노드로 반환

분산 아키텍처의 중복성: 머신이 정지했을 경우, 다른 머신이 이어 받을 수 있도록 데이터 복제!

클러스터는 용량 복원을 위해 더 많은 머신을 추가할 수 있다.

분산시스템의 활용: 클라우드 데이터 웨어하우스 객체 스토리지 시스템에는 분산 개념이 거의 모두 포함된다!

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

강한결합: 도메인과 서비스의 모든 부분이 다른 모든 도메인과 서비스에 필수적으로 의존하며 긴밀하게 결합된 패턴!!!!

단일 계층 아키텍처: 서버 ( DB↔애플리케이션 )

강한 결합의 본질! 장애 위험 때문에 운영 환경에선 권장 X

모놀리스: 가능한 한 많은 것을 한 지붕 아래에 포함 = 강한결합! 컴포넌트의 모듈화가 부족, 재사용이 불가능하고 어려울 수 있음. 이에 대한 대안으로 분산형모놀리스 논의 시작됐는데 뒷장에 나온다고.. (코드 베이스 → 데이터베이스)

느슨한 결합: 서로 너무 의존하지 않으면서..분산형 도메인과 서비스가 있음

다중 계층 아키텍처: 가장 널리 쓰이는 3-tier architecture ( 데이터 계층 → 애플리케이션/로직 계층 → 프레젠테이션 계층 ) 상향식 구조

상향식 구조로, 강한 결합의 문제점을 분리로 해결한 버전이다. 계층적이며 하위 계층이 반드시 상위 계층에 의존하지는 않는다. 반면 상위 계층은 하위에 의존!

애플리케이션에서 데이터 분리, 프레젠테이션에서 애플리케이션 분리!

+) 비공유 아키텍처: 단일 노드가 각 요청을 처리하고, 다른 노드들이 해당 노드 또는 서로 간에 메모리, 디스크, CPU등 자원을 공유하지 않음.

+) 공유 디스크 아키텍처: 모든 노드에서 접근할 수 있는 동일한 디스크와 메모리를 공유해야 하는지 여부에 따라 결정

마이크로서비스: 개별적이고 분산되어 있으며, 느슨하게 결합된 서비스로 구성. 서비스의 분리와 새로운 병렬 아키텍처! (서비스 → DB, 서비스→ DB …)

문제점: 좀 많이 복잡할 수 있음.

대안: 1. 도메인 분리를 고려 2. 중앙집중화 3. 데이터 메시 (3장 뒷부분)

4. 사용자 접근: 싱글 vs 멀티테넌트

싱글: 사용자(or 테넌트) 가 독립된 소프트웨어 인스턴스 가짐

멀티테넌트: 하나의 소프트웨어 인스턴스를 다들 공유!

멀티테넌시의 고려사항: 성능과 보안!

테넌시 개념은 클라우드 컴퓨팅에서 특히 많이 사용된다… 그 중에서도 아마 모든 클라우드는 멀티테넌시를 채택함!

5. 이벤트 기반 아키텍처

keyword: 생산자, 이벤트 라우터, 소비자

이벤트: 상태의 변화

아키텍처 구조: 생산자 → (이벤트)→ 이벤트 라우터 → (이벤트) → 소비자

장점: 이벤트의 상태를 여러 서비스에 분산시킴. 즉, 장애가 발생하거나 오프라인이 되거나 여러 소비자 또는 서비스가 동일한 이벤트에 접근하도록 할 때 유용.

서비스가 느슨하게 결합된 경우 항상 이벤트 중심 아키텍처가 후보가 됨!

6. 브라운필드 vs 그린필드

둘의 차이점은 백지상태부터 시작하느냐, 기존의 것을 재설계해서 활용하느냐의 차이!

브라운필드: 기존의 코드를 리팩토링

(스탱글러패턴) : 기존의 것을 외과적으로, 한 번에 하나씩 대체

옛날꺼 폐기하면서 성장함으로써 성공을 입증하고, 결국 레거시가 완전히 대체되는 시점이 옴!

그린필드 프로젝트 : 완전 반대! 레거시 얽매이지 않고 새롭게 출발

쉬운 경향, but 이력서 주도의 개발으로 변질될 수 있음. 유행에 대한 강박 생길 수도

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

1. 데이터 웨어하우스

보편화 배경

• 확장성이 뛰어난 종량제 모델 (cf. 종량제 모델은 고객이 사용한 만큼만 기한 내에 돈을 지불하는 방식)

→ 인건비와 자원을 대폭 줄일 수 있었다.

주목할만한 점 : 조직과 기술

조직: 팀의 구조와 프로세스

1. OLTP에서 OLAP 분리: 비지니스 성장에 따라 데이터를 별도의 물리적 시스템으로 옮기면서 운영 시스템의 부하가 줄고 분석 성능이 향상!
2. 데이터 중앙 집중화 및 구성: ETL을 사용해 데이터 가져옴. 추출(데이터 원천에서), 변환(ETL 시스템에서), 적재 (데이터 마트에)
   • (데이터 원천 → ETL 시스템 → 데이터 웨어하우스 → 데이터 마트)

기술: MPP 시스템의 등장 (Massively Parallel Computer)

1. SQL 시맨틱 지원
2. 행기반 → 열기반으로의 전환!!!! : 클라우드 데이터 웨어하우스에서 더 큰 데이터와 쿼리 지원할 수 있도록

ETL의 변형 ELT: 데이터를 운영 시스템에서 데이터웨어하우스 스테이징 영역으로 어느 정도 직접 이동이 가능. 변환은 데이터 웨어하우스에서 직접 처리됨! 데이터 웨어하우스와, 데이터 처리 도구의 방대한 계산 능력을 활용. 데이터 일괄 처리. 기록

• 데이터 원천 → ETL (스테이징 → 데이터 웨어하우스) → 분석, 데이터 과학, 보고
• 이벤트를 스트리밍해 스테이징 영역에 저장한 후 데이터 웨어하우스 내에서 변환하므로 스트리밍 배치에서도 인기 많았음

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

• Amazon Redshift
• Google Big Query
• Snowflake

On-demand 방식(사용자의 요구가 있었을 때 그 요구에 따라 서비스를 제공하는 것)의 스핀업(to create virtual machine using cloud computing ex. to spin up a new server)

클라우드 데이터 웨어하우스가 제공하는 기능 영향이 매우 크기 때문에, 데이터 웨어하우스 용어가 폐기될 수도 있음..!! MPP시스템에서 제공하는 것보다 훨씬 광범위한 기능 갖춘 새로운 데이터 플랫폼으로 발전하고 있다.

데이터마트

단일 하위 조직이나 부서 / 비지니스 라인에 초점 맞춰 분석 및 보고서를 제공하도록 설계된 웨어하우스의 한층 더 정교한 하위집합이다.

데이터 마트가 왜 필요할까?

1. 분석가와 보고서 개발자가 데이터에 더 쉽게 접근
2. 많은 변환 단계 제공 (분석 쿼리에 복잡한 데이터 조인 및 집계가 필요한 경우 데이터 마트에서 진행함으로써 전체적인 성능 크게 향상)

2. 데이터 레이크

정형과 비정형 모두 중앙 위치에 저장하고 엄격한 데이터 구조적 제한을 가하지 않는다!

역사

1. HDFS에서 데이터레이크 1.0이 시작됨
2. 클라우드의 인기 증가
3. 데이터 레이크 → 사실상 무제한 스토리지 용량 갖춘 클라우드 기반 객체 스토리지로 옮겨감 !

기능

• 모든 크기와 유형의 방대한 데이터 저장 가능
• 온디맨드로 스핀업해 거의 무제한에 가까운 컴퓨팅 성능 이용 가능
• 맵리듀스, 스파크, 레이, 프레스토, 하이브 등 원하는 데이터 처리 기술을 선택해 작업 수행 가능

단점 (매우 치명적임..)

• 쓰레기 매립장이 되어버림
• 데이터 늪, 다크 데이터, WORN 같은 용어의 탄생
• 데이터는 스키마 관리, 데이터 카탈로그 작성 및 검색 도구가 거의 없는 상태에서 관리 불가능한 크기로 증가했기 때문!
• 본질적으로 쓰기 전용 : 사용자 레코드를 지정 삭제 해야하는 GDPR과 같은 규제 도입이 골칫거리

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

데이터 레이크 하우스

데이터 웨어하우스 + 데이터 레이크

• 웨어하우스의 요소인 제어, 데이터 관리, 데이터 구조를 통합
• 레이크 요소: 객체 스토리지에 데이터 저장하고 다양한 쿼리 및 변형 엔진 지원
  • 단순 레이크와의 차이점: 데이터를 쏟아붓기만하고 갱신/삭제 안하는 레이크랑은 다르게 ACID 트랜잭션 지원!

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

(데이터 레이크와 유사)

• 컴퓨팅과 스토리지 분리
• 페타바이트 규모의 쿼리 지원
• 다양한 비정형 데이터 및 반정형 객체 저장
• 스파크/빔과 같은 고급 처리 기술과 통합

데이터 플랫폼

데이터 웨어하우스와 데이터 레이크의 기능을 융합

중요성이 증가하고 있음 !!!

4. 모던 데이터 스택

모던 데이터 스택: 현재 유행하는 분석 아키텍처! 향후 몇 년 동안 더 널리 사용되리라 예상되는 추상화 유형을 강조함.

• 클라우드 기반의 플러그 앤 플레이(PnP: 간편하게 연결해서 바로 사용할 수 있는) 방식 사용
• 모듈식 → 복잡성 낮춤!
• 사용자 기반, 커뮤닡, 코드리뷰
• 통합 data platform과 잘 어울림
• 기본 컴포넌트: 데이터 원천 → 클라우드 기반 데이터 커넥터와 통합 → 클라우드 데이터 웨어하우스 → BI와 시각화
• 이해하기 쉬운 가격 책정과 구현을 갖춘 PnP 모듈 방식의 핵심이 미래에는 중요할 것임 !

5. 람다 아키텍처

등장 배경

• 카프카의 등장! : 스트리밍 데이터 관련 작업의 인기가 폭발함
• 배치 및 스트리밍 데이터를 단일 아키텍처로 작동하는 방법을 찾아야 했다.

람다 아키텍처

• 배치, 스트리밍이 서로 독립적으로 작용
• 원천 시스템은 추가만 가능하고, 데이터 처리할 때는 스트림과 배치라는 두 목적지로 도달
• 인스트림 : 데이터 전달 ! (속도에서 가장 낮은 지연시간으로 전달하는 것이 목표)
• 배치계층 : 처리, 집계
• 서빙계층: 두 계층 쿼리 결과 집계
• 아키텍처 모습: 원천 시스팀 → 스트림처리, 배치처리 → 전달 (스트림쿼리, 배치쿼리) ↔ 쿼리

문제점

• 가장 권장되지는 않음 !
• 코드 베이스다르면 어렵기 때문
• 그래서 밑에 카파 아키텍처에 대해 알아보자

6. 카파 아키텍처

• 람다의 단점 보완
• 주요 특징: 스트림 처리 플랫폼을 모든 데이터 처리의 백본으로 사용!
  • 스트림 소스 → 스트림처리 → 서빙계층 ↔ 쿼리

장점

• 실시간 이벤트 스트림 직접 읽고 대량 데이터 청크 재생해 일괄 처리하여 동일한 데이터에 실시간 및 배치 처리 매끄럽게 적용할 수 있음

채택 X 이유

1. 스트리밍 자체는 사실 많은 기업에게 여전히 미지의 영역
2. 스트리밍 시스템 이용하기 때문에 복잡하고 비용 많이 듦. 반대로 배치 스토리지와 프로세싱은 방대한 데이터셋에 비해 훨씬 효과적이고 비용 효율적임

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

핵심과제 배치 및 스트리밍 데이터를 통합하는 것 !!

• 포인트 1. 여러 코드 경로를 통합

카파 아키텍처의 문제점

• 통합 큐잉 및 스토리지 계층에 의존하지만, 실시간 통계 수집이나 배치 작업하려면 다른 도구 써야된다.

데이터 흐름 모델, 아파치 프레임워크 (구글)로서의 해결

• 모든 데이터를 이벤트로 간주 !
  • 지속적인 실시간 이벤트 스트림은 무한 데이터
  • 배치 처리는 단순히 경계가 있는 유한 이벤트 스트림
• 따라서, 실시간 처리와 배치 처리는 거의 같은 코드 사용해 같은 시스템에서 이뤄짐 !
• 슬라이드나 텀블링 등 다양한 윈도 중에서 하나를 실시간 집계를 위해 선택

✅

배치는 스트리밍의 특수한 경우다 !

8. IoT용 아키텍처

사물인터넷: 주변 환경에서 주기적으로 또는 지속해서 데이터를 수집해 목적지로 전송하는 장치에서 데이터를 생성

장치 : 데이터 수집하는 장치는 모두 IoT 장치이다.

장치와 인터페이스:

• IoT 게이트웨이 : 장치를 연결하고 인터넷상의 적절한 수신처에 안전하게 라우팅하는 허브
• 적은 전력으로 장치 연결
• 중간 기착지 역할
• 장치의 스웜은 물리적 위치마다 하나씩 다수의 IoT 게이트 웨이 활용함

수집

• 이벤트 수집 아키텍처로 유입될 수 있다.

스토리지

• 지연 요건에 따라 크게 달라짐
  • 원격 센서: 배치 객체 스토리지
  • 모니터링 및 자동화 설루션: 실시간에 가까운 응답

서빙

• 패턴이 엄청 다양
• 역 ETL

9. 데이터 메시

개념

(중앙 집중식 데이터 레이크 및 데이터 웨어하우스 같은)데이터 모놀리식 데이터 플랫폼 ↔ 운영 데이터와 분석 데이터

사이에서 환경이 구분되는 ‘데이터 격차’에 대한 최근의 대응책이다.

포인트

• 중앙집중식 X ! 탈중앙화!
• 중앙 소유의 레이크에서 데이터 보내는 대신, 쉽게 소모할 수 잇는 방식으로 데이터셋 호스팅하고 제공

핵심 구성 요소

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

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

종류 엄청 다양

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

데이터 엔지니어의 역할

• 새로운 아키텍처가 조직에 어떻게 도움되는지 주목
• 한 가지 접근 방식에 집착 X
• 잠재적 가치 파악 → 심화 학습 → 구체적 결정 → 비지니스 긍정적 영향 초래

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

아키텍트의 역할

• 최신상태 유지
• 기술과 데이터의 상태에 부합하는 아키텍처

경계의 모호

• 데이터 엔지니어와 아키텍트 역할 경계가 모호해지고 있따 !