데이터 수명 주기를 다룬 후 아키텍처 설계에 대해 설명한다는 것은 우수한 아키텍처가 엔지니어링에 있어서 그만큼 중요하다는 뜻인 거 같다. 공감 하는게, 견고한 데이터 엔지니어링을 한다는 것은 곧 견고한 데이터 아키텍처가 기반이 되어야만 가능한 일이라고 생각한다. 이번 chapter3 후기도 chapter2와 마찬가지로 주관적인 메모장 정도이므로 책의 내용이 궁금하다면 꼭 구매해서 정독해보는 걸 추천한다.
데이터 아키텍처란?
기업의 진화하는 데이터 요구 사항을 지원하는 시스템 설계이다.
- 최적의 시스템을 설계하려면 모든 단계에서 트레이드오프를 고려해야 하며 동시에 값비싼 기술 부채를 최소화해야 한다.
- 되돌릴 수 있는 결정을 내려야 한다.
- 즉, 유연성과 트레이드오프의 균형을 유지하는 것이 중요하다.
우수한 데이터 아키텍처는 유연하고 유지 관리하기 쉽다.
우수한 데이터 아키텍처 원칙
원칙 1: 공통 컴포넌트를 현명하게 선택하라
- 조직 전체에서 널리 쓸 수 있는 공통 컴포넌트와 관행을 선택해야 한다.
- 공통 컴포넌트는 강력한 권한과 보안을 지원해 팀 간 자산을 공유하면서도 부정 접근을 방지해야 한다.
원칙 2: 장애에 대비하라
모든 것은 항상 실패한다.
- 장애에 대비해 설계할 때 허용 가능한 신뢰성, 가용성, RTO 및 RPO를 고려해야 한다.
원칙 3: 확장성을 위한 아키텍처를 설계하라
- 현재 부하와 대략적인 로드 스파이크를 측정하고 향후 몇 년간의 부하를 예측해 데이터베이스 아키텍처가 적절한지 판단해야 한다.
원칙 4: 아키텍처는 리더십이다
- 현직 데이터 엔지니어를 지도하고, 조직과 협의해 신중하게 기술을 선택하고, 교육과 리더십을 통해 전문 지식을 전파해야 한다.
- 아키텍처 리더십을연습하고 아키텍트의 조언을 구해야 한다.
원칙 5: 항상 아키텍처에 충실하라
- 현대의 아키텍처는 명령 제어 또는 폭포수 방식이 아닌, 협력적이고 민첩한 방식이어야 한다.
원칙 6: 느슨하게 결합된 시스템을 구축하라
- 느슨하게 결합하면 데이터 엔지니어링 팀은 서로, 또는 회사의 다른 부문과 더 효율적으로 협업할 수 있다.
원칙 7: 되돌릴 수 있는 의사결정을 하라
- 소프트웨어 설계에서 돌이킬 수 없는 부분을 제거하는 방법을 찾아내 아키텍처를 제거해야 한다.
- 항상 현재의 적합한 최고의 솔루션을 선택하도록 노력해야 한다.
- 환경의 진화에 따라 업그레이드하거나 더 나은 방법을 채택할 수 있도록 준비해야 한다.
병원에서 근무할 당시, 되돌릴 수 있는 의사결정을 해야 한다고 크게 느낀 적이 있었다. 교수님께서 개발한 기술을 꾸준히 발전시키시면서 아키텍처도 추가되는 작업이 불가피했다. 그 때 나는 단순히 현재에 적합한 최고의 솔루션이라고 생각하고 설계했지만 앞으로의 환경을 대비하지 못 했다. 한번 설계되면 활발히 연구가 진행되는 대학병원에서는 쉽게 수정할 수 없었고 (레퍼런스로 들어가기 때문에 수정되어서는 안 된다.) 결국 주먹구구식으로 진행할 수 밖에 없었다. 주니어로썬 한번 쯤 겪을 만한 경험이였지만 그 때의 나는 고통스러웠던 기억이 난다.
원칙 8: 보안 우선순위를 지정하라
- 자신이 구축하고 유지 관리하는 시스템의 보안을 책임져야 한다.
- 강화 보안 경계의 전체적인 약화와 함계 모든 데이터 엔지니어는 스스로를 보안 엔지니어로 간주해야 한다.
* 제로-트러스트 보안: 사용자를 신뢰하는 대신 사용자ID를 다시 검증하는 것
* 책임 공유 보안: CSP는 클라우드의 보안, 즉 물리적 시설, 유틸리티, 케이블, 하드웨어 등을 책임지고, 사용자는 클라우드 내의 보안, 즉 네트워크 제어 수단, ID 및 액세스 관리, 애플리케이션 구성 설정, 데이터 등을 책임지는 것
원칙 9: 핀옵스를 수용하라
- 데이터 리더의 새로운 과제는 예산, 우선순위, 효율성을 관리해야 한다.
모든 아키텍처의 주요 목표는
데이터를 가져와 다운스트림 소비에 유용한 결과물로 변환하는 것이다.
주요 아키텍처 개념
* 도메인: 실세 설계를 하는 주제 영역
- 도메인을 무엇으로 구성할지 고려할 때는 도메인이 실제 설계에서 무엇을 나타내는지에 초점을 맞추고 거꾸로 작업해보자.
* 서비스: 작업 달성이 목적인 기능 집합
데이터 엔지니어로서 관심 가져야 할 데이터 시스템의 4가지 특징
- 확장성: 시스템 용량을 늘려 성능을 개선하고 수요를 처리할 수 있다.
- 탄력성: 현재 워크로드에 따라 자동으로 스케일 업과 스케일 다운을 수행할 수 있다.
- 가용성: IT 서비스 또는 컴포넌트가 작동 가능한 상태에 있는 시간의 비율이다.
- 신뢰성: 시스템이 의도한 기능을 수행할 때 정의된 표준을 충족할 가능성(확률)이다.
유능한 데이터 엔지니어가 되기 위해서는 엔지니어적인 사고가 필요하다고 생각하는데 가장 기초가 되는 개념이 위 4가지로 보여진다. 꼭 명심하자!
* 모놀리스: 가능한 한 많은 것을 한 지붕 아래에 포함하는 것
- 특징: 복잡하게 뒤얽힌 서비스, 중앙 집중화, 서비스 간의 강한 결합
- vs. 마이크로서비스 아키텍처: 개별적, 분산, 느슨한 결합
* 브라운필드 프로젝트: 기존 아키택처를 재설계하는 방식
* 그린필드 프로젝트: 백지상태에서 처음부터 시작하는 방식
데이터 아키택처의 사례 및 유형
데이터 웨어하우스
보고 및 분석에 사용되는 중앙 데이터 허브이다. 데이터 웨어하우스의 데이터는 일반적으로 분석 활용 사례에 맞게 고도로 포맷되고 구조화되어 있다.
- 조직 데이터 웨어하우스 아키텍처: 특정 비즈니스 팀의 구조 및 프로세스와 관련된 데이터를 구성
- 운영 데이터베이스(OLTP)에서 온라인 분석 처리(OLAP)를 분리
- 데이터 중앙 집중화 및 구성
- 기술 데이터 웨어하우스 아키텍처: MPP와 같은 데이터 웨어하우스의 기술적 본질을 반영
- 클라우드 데이터 웨어하우스: MPP 시스템의 기능을 확장해 과거에는 하둡 클러스터가 필요했던 많은 빅데이터 사용 사례를 포괄
- 데이터 마트: 분석가와 보고서 개발자가 데이터에 더 쉽게 접근할 수 있도록 설계된 웨어하우스의 한층 더 정교한 하위집합
데이터 레이크
- 1세대 데이터 레이크의 성공적인 기업들은 상당한 가치를 발견했고 맞춤형 하둡 기반 도구와 향상된 기능을 만들 수 있는 자원을 보유하고 있었다.
- 그러나 많은 조직에서 데이터 레이크는 낭비와 실망, 치솟는 비용으로 얼룩진 내부의 슈퍼펀드 사이트로 변모했다.
신기술이 나왔을 때 그저 쫓지 말고 탄탄한 준비가 필요한 거 같다.
모던 데이터 스택
데이터를 활용하는 조직에서 데이터 통합 및 분석에 사용하는 모든 소프트웨어,툴, 기술 등 제품군의 집합체
- 클라우드 기반의 플러그 앤 플레이(PnP) 방식과 사용하기 쉬운 기성 구성 요소를 써서 모듈식이면서도 비용 효율적인 데이터 아키텍처를 구축하는 것
- 이해하기 쉬운 가격 책정과 구현을 갖춘 PnP 모듈 방식의 핵심 개념이야말로 미래의 방식이다.
* 람다 아키텍처: 배치, 스트리밍 및 서빙 등의 시스템이 서로 독립적으로 작동함
* 카파 아키텍처: 람다 아키텍처의 배치레이어와 스피드레이어의 기능적 중복성과 복잡성을 제거하기 위해 제안됨
데이터 흐름 모델, 통합 배치, 스트리밍
- 배치 및 스트리밍 데이터를 통합한다는 핵심 과제가 남아있다.
- 실시간 처리와 배치 처리는 거의 같은 코드를 사용해 같은 시스템에서 이뤄진다.
- '배치는 스트리밍의 특수한 경우'라는 철학은 이제 더 널리 퍼져 있다.
데이터 메시
거대한 모놀리식 데이터 플랫폼과 운영 데이터와 분석 데이터 사이에서 환경이 구분되는 '데이터 격차'에 대한 최근의 대응책
- 분산, 탈중앙화
데이터 엔지니어로서 새로운 아키텍처가 조직에 어떻게 도움이 되는지 주목하자.
