[견고한 데이터엔지니어링] - 4장 데이터 엔지니어링 수명 주기 전체에 걸친 기술 선택

3장에서는 좋은 데이터 아키텍처와 그것이 중요한 이유를 설명했다. 이제 그러한 아키텍처에 적합한 기술을 선택하는 방법을 설명한다. 적절한 데이터 기술을 선택하는 기준은 간단하다. "그 기술이 데이터 제품과 광범위한 비즈니스에 가치를 더해줄 수 있는가?"이다.

 

4장에서는 전략적 아키텍처의 청사진을 확보하고, 기술을 선택하는 전술적 계획에 관해 설명한다.

 

1. 팀의 규모와 능력

2. 시장 출시 속도

3. 상호 운용성

4. 비용 최적화 및 비즈니스 가치

5. 현재 VS 미래: 불변의 기술과 일시적 기술 비교

6. 장소: 온프레미스, 클라우드, 하이브리드 클라우드, 멀티 클라우드

7. 구축과 구매 비교

8. 모놀리식과 모듈식 비교

9. 서버리스와 서버 비교

10. 최적화, 성능, 벤치마크 전쟁

11. 데이터 엔지니어링 수명 주기의 드러나지 않는 요소

 

4-1 팀의 규모와 능력

• 일반적으로 팀의 규모에 따라 할애할 수 있는 역량의 규모가 결정된다.
• 간혹 소규모의 데이터 팀이 대기업 데이터 팀의 블로그를 보고 그 기술을 따라하는 경우가 있는데, 이는 쓸데없이 시간과 비용을 소모하는 일이다. 이를 "cargo-cult-engineering"이라고 부른다.
• 따라서 소규모 팀이라면, 가능한한 많은 관리형 도구와 SaaS 도구를 사용해서 복잡한 문제를 해결하는 데만 집중하는 것이 좋다.
• 새로운 기술과 언어 및 도구를 적용할때는 신중하게 판단하는 것이 중요하다.

4-2 시장 출시 속도

• 기술 분야에서는 시장 투입의 속도가 승패를 결정한다.
• 팀원들이 이미 잘 아는 도구를 사용하면 시간적/기술적 우위를 가져갈 수 있다.
• perfect가 아닌 good을 목표로 하자.

4-3 상호 운용성

• 한 가지 기술 혹은 한 가지 시스템만 사용하는 경우는 거의 없다.
• 따라서 기술이 시스템을 선택할 때는 다른 기술들과 어떤 식으로 상호 작용을 하는지 등을 확인해야 한다.
• 데이터 엔지니어링 수명 주기 전반에 걸쳐 다양한 기술을 연결하는 것은 항상 복잡하다.
• 따라서 모듈식으로 설계하고 새로운 관행과 대안이 제공되면 기술을 쉽게 교체할 수 있는 기능을 제공할 것을 권장한다.

4-4 비용 최적화 및 비즈니스 가치

• 총 소유 비용, 기회 비용, 핀옵스라는 세 가지 관점에서 비용을 살펴본다.

4-4-1 총 소유 비용

• 총 소유 비용(total cost of ownership, TCO): 활용되는 제품 및 서비스의 직접 비용과 간접 비용을 포함한 이니셔티브의 전체 추정 비용.
• 직접 비용(direct cost): 이니셔티브에 직접적인 연관이 있는 비용. 예) 팀의 급여, AWS 청구서 등
• 간접 비용(indirect cost) : 이니셔티브와 무관하며, 어디에 귀속되는지와 관계없이 지불하는 비용

비용 종류는 이 외에, 크게 두 그룹으로 나눌 수 있다.

• 설비 투자 비용 (capital expense, CAPEX) : 하드웨어 및 소프트웨어 구매 등과 같은 설비를 구매하는데 사용되는 비용이다. 초기에는 비용이 꽤 많이 들 수 있으나 시간이 지나면서 점점 감가상각이 이뤄진다.
• 운영 비용 (operational expense, OPEX) : 특정 측면에서 CAPEX와 반대되는 개념으로, OPEX는 점진적이며 시간이 지남에 따라 분산된다. 즉, 단기적인 시각으로 바라 본다. 클라우드가 등장하면서 데이터 관련 프로젝트에 필수 사항이 되었다.

4-4-2 총 소유 기회 비용

• 총 소유 기회 비용(total opportunity cost of owership, TOCO): 기술, 아키텍처 또는 프로세스를 선택할 때 발생하는 기회 상실비용.
• 예를 들어 한 기술 스택을 사용하기로 결정하였는데 더 좋은 기술이 나타나면서 해당 기술로 이전하게 되는 등의 이슈가 발생할 수 있다. 따라서 이와 같은 이슈들을 위해서 TOCO를 잘 고려해야 한다.

4-4-3 핀옵스

• FinOps의 목표는 시스템을 모니터링하고 동적으로 조정하는 DevOps와 같은 방식을 적용하여 재무적 책임과 비즈니스 가치를 완전히 운용하는 것이다.

4-5 현재 VS 미래 : 불변의 기술과 일시적 기술 비교

" 기술에 관한 의사결정을 위해서는 무엇이 변화할 가능성이 높고, 무엇이 동일하게 유지되는 경향이 있는지를 이해해야 한다. 크게 두 가지 기술을 고려할 수 있다. 불변의 기술과 일시적인 기술이다."

 

• 불변의 기술: 클라우드의 기반이 되는 컴포넌트(객체 스토리지, 네트워킹, 서버, 보안 등) 혹은 오랜 세월을 견딘 언어와 패러다임 등.
• 일시적 기술: 자바스크립트 관련 프론트앤드 분야
• 따라서 불변의 기술을 기반으로 삼고 이와 관련한 일시적 도구들을 구축하는 것을 추천한다.

4-6 장소: 온프레미스, 클라우드, 하이브리드, 클라우드, 멀티클라우드

4-6-1 온프레미스

• 기업은 자체 하드웨어(데이터 센터 또는 임대 코로케이션)를 소유한다.
• 하드웨어 기반으로 작업을 수행한다.
• 한 번에 많은 트래픽이 몰릴 경우를 대비하여 큰 규모의 하드웨어를 구축해야 하며, 이는 비용적 측면에서 비효율적이다.

4-6-2 클라우드

• 온프레미스 모델과 거의 반대되는 개념이다.
• AWS, 애저, 구글 클라우드와 같은 클라우드 서비스 업체로부터 하드웨어와 관리형 서비스를 임대하여 작업을 수행한다.
• 동적 자원 할당을 통해 유연한 자원 관리가 가능하다.
• 서버리스라는 용어에 대해서는, 보통 "보이지 않는 많은 서버"를 의미한다.

4-6-3 하이브리드 클라우드

• 클라우드로 마이그레이션하는 기업이 점점 늘어나면서 하이브리드 클라우드 모델의 중요성이 커지고 있다.
• 크게 "온프레미스(일부 워크로드)  -> 클라우드"의 구조로 이해하고 있으며, 하이브리드 클라우드 모델은 조직이 일부 워크로드를 클라우드 외부에 무기한으로 유지한다고 가정한다.
• 데이터 이그레스(data egress)비용을 최소화 한다.

4-6-4 멀티 클라우드

• 간단하게 워크로드를 여러 퍼블릭 클라우드에 배포하는 것을 의미한다.
• 데이터 이그레스 비용과 네트워킹 병목 현상에 잘 활용할 수 있다.
• 여러 클라우드를 사용하는 만큼 상당히 복잡하다.

4-6-5 탈중앙화: 블록체인과 엣지

• 현재는 잘 사용되지 않지만 미래에 사용될 수 있는 기술 중, 분산 컴퓨팅 방법이 있다.
• 아직은 활용 사례가 거의 없지만, 블록체인과 Web 3.0, 엣지 컴퓨팅이 발전하면서 기존의 패러다임을 바꿀수도 있다.

4-6-6 조언

• 현재에 집중하되, 미래에 대한 계획을 동시에 해야 한다.
• 현재에 가장 적합한 기술을 선택하고 가까운 미래를 대비한 견고한 계획을 세우자.
• 그리고 특별한 이유가 없다면 멀티클라우드나 하이브리드 클라우드 전략은 선택하지는 말자.
• 다른 한편으로 탈출 계획(기술 변환 방법)을 세우자.

4-7 구축과 구매 비교

" 구축(build)와 구매(buy)는 기술 분야의 오래된 논쟁거리다. 구축을 할지 아니면 구매를 할지는 TCO(Totoal Cost of Ownership)과 TOCO(Total Opportunity Cost of Ownership)등을 잘 따져 봐야 한다."

• 하지만 책에서는 처음부터 직접 구축하는 것이 아닌, 기존의 잘 구현되어 있는 서비스 등을 구매하고 추가로 커스터마이징 하는 것을 추천하고 있다.

4-7-1 오픈 소스 소프트웨어

• Open Source Software (OSS) : 특정 라이센스 조건에 따라 소프트웨어 및 기본 코드베이스를 일반적인 용도로 이용할 수 있도록 공개하는 소프트웨어 분산 모델.
• 두 가지 주요한 OSS가 있다. (커뮤니티 관리 OSS, 상용 OSS)

커뮤니티 관리 OSS

• 커뮤니티를 통해 전 세계 개발자의 높은 기술 혁신과 활발한 기여가 이루어지는 OSS.
• 커뮤니티 관리 OSS 프로젝트에서 고려해야 할 요소는 다음과 같다.
  • (인지도 측면) 깃허브의 star, fork, commit 수가 많고 최신화된 OSS를 선택한다.
  • (성숙도 측면) 프로젝트가 시작된지 얼마나 되었는지, 얼마나 활성화 되었는지, 얼마나 많은 사람들이 사용하고 있는지.
  • (문제 해결) 문제 발생 시 개인이 알아서 해결해야 하는지, 아니면 커뮤니티의 도움을 받을 수 있는지.
  • (프로젝트 관리) 깃 이슈와 그 대처 방식은 무엇인지.
  • (팀) 기업이 OSS 프로젝트를 후원하고 있는지.
  • (자체 호스팅 및 유지 보수) OSS 솔루션을 호스팅하고 유지 보수할 수 있는 리소스가 있는지, 있다면 그 비용은 얼마인지.

상용 OSS

• 비즈니스 벤더(예, Spark, Kafka, dbt)가 OSS 솔루션을 호스팅 및 관리하면서 사용자에게 서비스를 제공하는 OSS.
• 핵심 기능은 무료로 제공하되, 일부 추가 기능에 대해서는 요금을 부과하는 방식.
• 상용 OSS 프로젝트에서 고려해야 할 요소는 다음과 같다.
  • (가치) 직접 OSS 기술을 관리할 때와 상용 OSS를 사용하는 것 중, 더 비용 가치가 있는 것은 무엇인가.
  • (접근 방식)서비스에 접근하는 방법은 무엇인가? 초기 버전 및 후속 릴리스에도 쉽게 접근할 수 있는가?
  • (릴리스 및 버그 수정)벤더가 개선 사항 및 버그 수정을 투명하게 파악하고 있는가?
  • (벤더의 목표) 해당 벤더 기업이 회사 logo를 알리는데 초점을 맞추는지,  아니면 수익 증대를 목표로 하는지. 내실이 튼튼하고 수익 증대를 목표로 하는 기업을 선택하자.

4-7-2 전용 폐쇄형 네트워크 서비스

데이터 시장에서 일부 기업들은 OSS가 아닌 비공개 소스 제품을 판매한다. 두 가지 주요 유형인 독립 기업과 클라우드 플랫폼 오퍼링에 관해 살펴본다.

 

독립 오퍼링

• 데이터 도구에 대한 독립형 오퍼링에 특화된 기업들은 자본이 풍부한 VC로부터 자금을 조달할 수 있으므로 규모 확장 및 뛰어난 인재들을 고용할 수 있다.
• 데이터 도구를 판매하는 대부분의 기업들은 이를 OSS로 출시하는 대신 독자적인 솔루션을 제공한다.
• 독립형 오퍼링에서 고려해야 할 사항은 다음과 같다.
  • 해당 도구가 다른 도구(OSS, 기타 독립형 서비스, 클라우드 오퍼링 등)와 상호 운용되는지 확인.
  • 인기가 있는지
  • 어느 문제가 발생할 시,해당 문제 해결 방법이 명확한지.
  • 가격은 합리적인지.
  • 해당 기업이 미래에도 계속 건재할지

클라우드 플랫폼 전용 서비스 오퍼링

• 클라우드 벤더는 스토리지, 데이터베이스 등을 위한 자체 서비스를 개발하고 판매한다.
• 대표적인 예시가 AWS 이다.
• 고려 사항은 다음과 같다.
  • 클라우드 방식이 독립형보다 성능 및 가격 측면에서 우수한가?
  • 만약 구매를 한다면, 온디맨드 방식으로 구매할 지 아니면 한정된 용량 혹은 장기약정 계약으로 비용을 절감할 수 있을지.

시간은 거래를 망친다. 구축과 구매 중, 여러 측면에서 가장 가치있는 방법을 택하기를 바란다.

4-8 모놀리식과 모듈식 비교

• 데이터 엔지니어링 측면에서 모놀리식(집약형) 방법과 모듈식(독립형) 방법의 트레이드오프를 살펴본다

4-8-1 모놀리식

• 과거 waterfall 방식 시대에 유용했던 방식이다.
• 추론하기가 쉽고, 모든 구성이 독립적인 만큼 인지적 부담과 컨텍스트 전환이 덜 요구된다는 장점이 있다.
• 한번에 모든것을 완성하려다 보니, 사소한 문제로 전체 시스템에 문제를 줄 수 가 있다는 단점이 있다.
• 기술(도구)전환이 어렵다는 단점이 있다.

4-8-2 모듈식

• 시스템과 프로세스를 독립적인 영역으로 분리하는 방식이다.
• 데이터 처리 기술은 상호 운용성에 대한 강력한 지원을 제공함으로써 모듈식 모델로 전환했다.
• 단점은 고려해야 할 사항들이 많다는 점이 있다. 수많은 시스템을 이해하고 운용해야될 수도 있기 때문이다.

4-8-3 분산형 모놀리스 패턴

• 분산 시스템을 서로 다른 서비스로 실행하여 서로 다른 작업을 수행하는 분산 아키텍처
• 예시로 전통적인 하둡 클러스터가 있다. 하둡 클러스터는 하이브, 피그, 스파크와 같은 여러 프레임워크를 동시에 호스팅 가능하며, 클러스터는 하둡 공통 라이브러리, HDFS, WARN, 자바 등의 핵심 하둡 구성 요소를 실행한다.
• 하지만 이처럼 많은 도구들을 오케스트레이션하려면 여러 API 호스트에 대한 클라이언트 라이브러리를 설치해야 하며, 이로 인해 충돌이 발생할 수 있다.
• 여러 서버를 구성하여 각 서버마다 독립적인 작업을 수행하도록 분리하거나, 컨테이너를 사용해 분산된 모놀리스를 여러 소프트웨어 환경으로 적절하게 분리하는 방식으로 문제를 해결할 수 있다.

"모놀리스와 모듈식의 트레이드 오프를 잘 고려하여 적합한 방식을 택하기를 바란다."

4-9 서버리스와 서버 비교

4-9-1 서버리스

• 2014년 AWS Lambda를 통해서 서버리스 트렌드가 본격적으로 시작됨.
• 서버 비용을 지불하는 대신 코드가 호출되었을 때만 비용을 지불하는 방식.
• 실제 환경에서의 이벤트당 비용 및 서버리스 실행의 최대 기간을 확인하기 위한 모니터링과,이벤트당 비용을 사용해 이벤트율 증가에 따른 전체적인 비용 판단을 위한 모델 작성이 필요함.
• 모델링에는 DDOS 공격 혹은 봇 스웜과 같은 최악의 시나리오도 포함되어야 함.

4-9-2 컨테이너

• 기존의 VM은 전체 운영 체제를 포괄하는 반면, 컨테이너는 파일 시스템 및 일부 프로세스와 같은 상위 단계에서 패키징을 수행함.
• 운영 체제 커널 전체를 지니는 오버헤드 비용이 발생하지 않는다는 장점이 있음

4-9-3 서버 VS 서버리스 평가 방법

• 서버리스 사용량이 점점 많아지면 그냥 서버를 직접 구축하는 것이 더 저렴해질 수가 있다. 따라서 다음과 같은 사항들을 고려해 볼 필요가 있다.
  • 서버 장애 예상하기.
  • 클러스터와 오토스케일링 사용하기.
  • 인프라를 코드로 취급하기.
  • 컨테이너 사용하기
• 서버리스는 단순한 개별 작업과 워크로드에 가장 적합하다. 만약 컴퓨팅 능력이 중시되는 경우에는 컨테이너와 컨테이너 워크플로 오케스트레이션 프레임워크를 사용하자.
• 서버리스 앱의 처리 속도와 처리량을 잘 고려해야 한다. 만약 이러한 제한 내에서 수행하지 못한다면 컨테이너 중심의 접근 방식을 고려해 보자.
• VPC나 방화벽과 같은 네트워크 관련, 서버리스 시스템의 지원 언어 관련 등에 대해서 고려해 보자.

" 결론적으로, 초기에는 서버리스를 사용하다가 기업이 충분히 성장한 후에 서버를 사용하는 것이 좋다."

 

4-10 최적화, 성능, 벤치마크 전쟁

• 실제 사용 사례를 벤치마크하려면 예상되는 실제 데이터와 쿼리 크기를 시뮬레이션 해야한다.
• 단기 시스템과 비단기 시스템을 초당 비용으로 비교하는 것은 무의미 하다.
• 비대칭 최적화를 조심해야 한다. 예를들어 행 기반과 열 기반 시스템을 비교할때, 정규화된 데이터 모델은 행 기반 시스템에 최적이지만, 열 기반 시스템은 일부 스키마를 변경해야 그 잠재력을 최대한 발휘할 수 있다.

4-11 데이터 엔지니어링 수명 주기의 드러나지 않는 요소

• 외부와 내부 모두에서 발생하는 침해로부터 데이터를 어떻게 보호하고 있는가?
• GDPR, CCPA와 같은 규정을 준수하는 제품은 무엇인가?
• 이러한 규정을 준수하며 데이터를 호스팅 할 수 있는가?
• 어떻게 데이터 품질을 보장하고 솔루션에서 올바른 데이터를 표시하는가?

4-11-2 데이터 옵스

• 새로운 코드 배포를 얼마나 제어할수 있을까?
• 문제 발생 시 어떻게 경고를 받고 어떻게 대응할 수 있을까?
• 벤더가 문제를 해결하는 방법을 투명하게 제공하고 있는가?

4-11-3 데이터 아키텍처

• 결정을 되돌릴 수 있는 상태를 유지하면서 장단점을 평가하고 작업에 가장 적합한 도구를 선택할 수 있는가?

4-12 결론

"기술을 선택할 때는 사용 사례, 비용, 구축VS구매, 모듈화 간의 균형을 고려해야 한다.

항상 아키텍처와 동일한 방식으로 기술에 접근하고, 트레이드오프를 평가하고 되돌릴 수 있는 결정을 내리는것을 목표로 삼자."