4 분 소요

[견고한 데이터 엔지니어링]견고한 데이터 엔지니어링 - 우수한 데이터 아키텍처의 원칙

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

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

de의 주요 업무 중 하나는 조직 전체에서 널리 쓸 수 있는 공통 컴포넌트와 관행을 선택하는 것

  • 공통 컴포넌트는 객체 스토리지, 버전 제어 시스템, 관찰 가능성, 모니터링 및 오케스트레이션 시스템, 처리엔진같이 조직 내에 폭넓게 적용할 수 있는 구성요소들
  • 공통 컴포넌트는 강력한 권한과 보안을 지원해 팀 간의 자산을 공유하면서도 부정 접근을 방지해야함
    • 클라우드 플랫폼이 공통 컴포넌트를 채택하기에 이상적인 장소




2. 장애에 대비하라

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

견고한 데이터 시스템을 구축하려면 설계 시 장애를 고려해야 함.

  • 가용성 - IT 서비스 or 컴포넌트가 작동 가능한 상태에 있는 시간의 비율
  • 신뢰성 - 지정된 간격 동안 의도된 기능을 수행할 때 시스템이 정의된 표준을 충족할 확률
  • 복구시간목표 (RTO -Recovery time objective) - 서비스 또는 시스템 장애의 최대 허용 시간
  • 복구시점 목표 (RPO - Recovery point objective) - 복구 후 허용 가능한 상태 (허용 가능한 최대 데이터 손실)

이러한 것들을 고려해야 함



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

확장성에는 두가지 주요 기능이 포함되는데


3-1 확장 가능한 시스템은 상당한 양의 데이터를 처리할 수 있도록 스케일 업 할 수 있음

일시적인 부하 급증을 처리해야 할 수도 있으므로 스케일-아웃이 유연해야함


3-2 확장 가능한 시스템 규모를 스케일 다운할 수 도 있음.

비용 절감을 위해 로드 스파이크가 줄면 용량을 자동으로 제거하는 경우




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

데이터 아키텍트는 기술의 결정과 아키텍처 설명을 담당하며, 효과적인 리더십과 교육을 통해 이러한 선택 사항을 전파할 책임이 있음.

이상적인 데이터 아키텍트는 de관련 기술을 보유하고 있지만 매일 연습하지 않는데, 현재 de를 지도하고, 조직과 협의해 신중하게 기술을 선택하고, 교육과 리더십을 통해 전문 지식을 전파함. 이들은 엔지니어에게 모범 사레를 교육하고 회사의 엔지니어링 자원을 통합해 기술과 비즈니스 모두에서 공통의 목표를 추구




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

데이터 아키텍트는 단순히 기존 상태를 유지하는 역할만 수행하는 게 아니라, 비즈니스와 기술의 변화에 대응해 새롭고 흥미로운 것들을 끊임없이 설게함.

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



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

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

-구글 DevOps 아키텍처 가이드


소프트웨어 아키텍처의 경우 느슨하게 결합된 시스템은 다음과 같은 속성을 지니는데..


  1. 시스템은 많은 수의 작은 컴포넌트로 나뉜다.
  2. 이러한 시스템은 메시징 버스나 API같은 추상화 계층을 통해 다른 서비스와 상호작용 한다. 이러한 추상화계층은 db 백엔드 또는 내부 클래스 및 메서드 호출과 같은 서비스의 내부적인 세부 정보를 숨기고 보호한다.
  3. 속성 2의 결과, 시스템 컴포넌트에 대한 내부 변경은 다른 부분에 대한 변경을 요구하지 않는다. 코드 갯ㄴ인으,ㅣ 자세한 내용은 안정적인 API 뒤에 숨겨져 잇다. 각 조각은 개별적으로 발전하고 개선될 수 있다.
  4. 속성 3의 결과, 시스템 전체에 대한 폭포수식 글로벌 배포 주기는 없다. 대신 각 컴포넌트는 변경 및 개선이 이루어짐에 따라 개별적으로 갱신된다.


이걸 기술적 시스템에 주목하여 크게 생각해보아 조직의 특징으로 변환해 보자면..

  1. 많은 소규모 팀은 크고 복잡한 시스템을 설계한다. 각 팀은 일부 시스템 컴포넌트의 엔지니어링, 유지보수 및 개선 업무를 담당.
  2. 이러한 팀은 API정의, 메시지 스키마 등을 사용해 컴포넌트의 추상적인 세부 사항을 다른팀에 공개한다. 각 팀은 다른 팀의 컴포넌트에 신경 쓸 필요가 없다. 게시된 API또는 메시지 명세를 이용해 이들 컴포넌트를 그저 호출할 뿐. 이들은 시간이 지남에 따라 성능 및 기능을 개선하고자 각자의 역할을 반복한다. 또한 새로운 기능을 추가하면 이를 공개할 수도 있고 다른 팀에서 새로운 기능을 요청할 수도 있다. 이때도 요청된 기능의 내부 기술 세부 사항은 팀이 걱정할 필요가 없다. 팀은 느슨하게 연결된 커뮤니케이션으로 협력한다
  3. 특징 2의 결과, 각 팀은 다른 팀의 업무와 독립적으로 자신의 컴포넌트를 빠르게 발전시키고 개선할 수 있다.
  4. 특히 특징 3은 팀이 최소한의 다운타임으로 컴포넌트 갱신을 배포할 수 있음을 의미한다. 근무시간동안 계속 배포해 코드를 변경하고 테스트한다.


이로써 기술과 인간 시스템을 모두 느슨하게 결합하면 DE팀은 서로 또는 회사의 다른 부문과 더 효율적으로 협업가능!




7. 되돌릴 수 있는 의사결정을 해라 (양방향 의사결정)

데이터 환경은 빠르게 변화하기 때문에 핫한 기술스택이 내일은 과거의 유물이 될 수 있음. 이를 위해 아키텍처를 단순화하고 민첩성을 유지하려면 돌이킬 수 있는 의사결정을 목표로 삼아야함.

데이터 아키텍처 전반에 걸친 기술의 분리/모둘화 등의 변화속도를 고려할 때, 항상 현재에 적합한 최고의 솔루션을 선택하도록 노력하자. 또한 환경의 진화에 따라 업그레이드 하거나 더 나은 방법을 채택할 수 있도록 준비하자.




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

모든 DE는 자신이 구축하고 유지 관리 하는 시스템의 보안을 책임져야 함.

이에 2가지 아이디어가 있는데..


8-1 ZERO-TRUST SECURITY

적어도 지난 10년간 언론 보도를 보면 강화된 조직 보안 영역 내에서 인간 타깃을 악용하는 보안침해 위협이 증가하고 있음. 직원들은 매우 안전한 기업용 네트워크에서 작업하는 그 순간에도 이메일과 모바일 장치를 통해 외부와 연결된 상태를 유지하는 데, 외부 위협을 사실상 내부 위협이 됨.. (미션 임파서블에서 서버실 침투만 어떻게 잘 하면 데이터 빼가는건 쉬운 느낌..)


8-2 공동 책임 모델

AWS에서는 공동 책임 모델을 강조하는데 AWS는 제공하는 서비스에서 인프라를 보호할 책임이 있지만, 사용자의 책임도 분리되어 있음. 사용자도 AWS서비스에 따라 다르지만 데이터의 민감도, 조직의 요구사항, 법률 및 규정에 따라 기타적인 요소에서 책임져야 함.

암튼 그래서 DE는 스스로를 보안 엔지니어라고 간주해야 함..




9. FinOps를 수용하라

핀옵스란 DevOps와 재무팀간의 협력적인 업무 관게를 지지하는 새로운 움직임을 의미하는 데, 인프라 지출을 반복해서 데이터 중심을 관리하는 (즉, 클라우드 단위 경제성을 낮추는) 동시에 비용 효율성을 높이고 궁극적으로는 클라우드 환경의 수익성을 높인다. 라는 말

온프레미스에서 클라우드 환경으로 바뀌다 보니 과잉 구매/ 괴소 구매 를 조심해야 함.. (대부분 종량제 과금이기 때문)

클라우드 서비스 이용하다 과금폭탄 맞기 싫으면 핀옵스에 대해서 진지하게 공부해보자..

댓글남기기

참고