SsInsurance®삼성보험-ℋ𝒶𝓋ℯ ᵃ 𝓁ℴ𝓋ℯ𝓁𝓎 ᵈᵃʸ

삼성©사이버보험®(SsCyber Liability Insurance)℠

삼성©사이버보험®(SsCyber Liability Insurance)℠ 자세히보기

C.H.A.T.S, 2025 디지털 마케팅 혁명

컨테이너 환경의 CI/CD 전략 - 데이터 파이프라인 기본 원리와 원칙은 시간이 지나도 유효 - 빅데이터 분석 기반이란? 데이터 파이프라인 구축

삼성생명®삼성화재®삼성자동차보험®삼성카드® 2025. 3. 29. 21:55
반응형

컨테이너 환경의 CI/CD 전략

 

 

안녕하세요. 오픈소스컨설팅 Playce Cloud팀 임기환입니다. AA/DevOps 관련 업무를 담당하고 있으며 Application Architect를 넘어서 ‘All’ Architect를 꿈꾸고 있습니다.

이번 포스팅에서는, IT 개발자라면 누구나 한번을 들어봤을 CI/CD에 대해 설명하려고 합니다.

본 글을 다 이해하게 되면 아키텍처를 기준으로 CI/CD에 대해 이해할 수 있으며, 지속적인 빌드/배포가 가능한 파이프라인 사이클을 만들어 개발 생산성을 높일 수 있을 것입니다.

그러면 먼저 CI/CD란 무엇인가에 대해 설명하도록 할게요.

CI/CD가 의미하는것

IT 서비스를 만든다는 것은 궁극적으로 사용자에게 우리가 잘 만든 코드를 결과물로 만들어 보여주는 것입니다.
결과물을 잘 만들어서 고객에게 제공했다고 하더라도, 고객이 필요로 하는 내용이 빠져있거나, 버그 등으로 문제가 발생하는 경우가 빈번하게 발생합니다. 이러한 경우 빠르게 오류를 수정하거나 기능을 추가하여 다시 사용자에게 제공하기 위해 코드를 수정하고 수정된 코드가 제대로 작동하는 지 테스트 과정을 거치는데, 이 과정은 시간도 많이 걸리고 실수를 할 수도 있으며 상당히 반복적인 작업입니다.

이러한 작업을 자동화하여 실수를 줄이고 신속하게 처리할 수 있는 제공하는 방법이 CI/CD 입니다.

개념적으로 본다면, CI/CD (Continuous Integration/Continuous Delivery or Deployment)는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법론입니다. 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다.

  • 지속적 통합(Continuous Integration, CI): 자동화 프로세스를 통한 지속적인 통합을 의미합니다. 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합합니다. 공유 리포지토리를 사용할 경우, 여러 명의 개발자가 작업할 경우 발생하는 소스 코드 충돌 문제를 해결이 가능합니다.
  • 지속적 제공(Continuous Delivery, CD): 변경 사항을 버그 테스트를 거쳐 리포지토리에 자동으로 업로드하는 것을 의미합니다. 코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 코드 릴리스 자동화가 포함되어야 하며, 이 프로세스를 완료하면 운영팀이 더욱 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있습니다.
  • 지속적 배포(Continuous Deployment, CD): 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미합니다. 지속적 배포 환경이 구성되면, 수동 배포로 인한 프로세스를 줄이며, 개발자와 운영자가 간의 가시성 및 의사 전달에 도움이 됩니다. 실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있습니다.

CI/CD의 목표

앞서 말씀드린 대로, 일반적인 서비스의 목표는 개발된 소스 코드를 사용자가 사용할 수 있도록 배포하는 것입니다.
조금 더 자세히 이야기하자면, 개발자가 신규 기능이나 변경 내용에 대해 소스 코드를 수정하고 형상관리 시스템(gitlab, github 등)에 소스 코드를 기록하는 것부터 업무가 시작됩니다. 그 이후 소스 코드 리뷰 및 테스트를 거치게 되며, 문제가 없다면 주어진 환경에 맞게 바이너리 또는 이미지 등의 형태로 배포하게 됩니다.

이런 작업은 수많은 사람들이 밀접하게 연계되어 있으며, 매끄럽고 원활하게 동작하려면 많은 노력이 필요하며, 버그 및 기능 개선 등으로 빈번히 발생합니다.

만약 이 과정을 한 개인이 수동으로 진행한다면 많은 문제가 발생할 수 있습니다. 그래서 작업 시간을 줄이고 불편함을 최소화하기 위해 관련된 업무 프로세스를 도출하여 자동화하는 업무를 수행합니다. 이런 업무와 프로세스는 서비스가 발전하면서 발생하는 변화를 끊임없이 따라가며 지속적으로 개선해 나가는 것이 제일 중요합니다.

CI/CD와 DevOps 관계

우리가 CI/CD를 얘기하다 보면 DevOps를 많이 이야기하는데요. CI/CD와 DevOps와 같은 개념으로 생각하기 쉬운데, 같으면서도 다른 개념입니다. DevOps와 CI/CD 관계에 대해 설명하려고 합니다.

DevOps란

DevOps는 개발(Development)와 운영(Operation)을 결합해 탄생한 개발 방법론입니다.
시스템 개발자와 운영을 담당하는 정보기술 전문가 사이의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 방법론입니다.

출처: https://www.atlassian.com/devops

DevOps에서의 CI/CD

DevOps는 개발(Develop)과 운영(Operation)의 합성어로 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 하는 문화, 프로세스 도구의 조합입니다.
DevOps에서의 CI/CD는 기술, 프로세스적인 부분을 의미합니다.

DevOps의 요소

DevOps에서는 CI/CD를 통한 프로세스적인 내용과 msa, IasC 등의 기술적, 커뮤니케이션의 소통의 요소를 가집니다.

  • 지속적 통합
  • 지속적 전달
  • 마이크로 서비스
  • 코드형 인프라
  • 모니터링 및 로깅
  • 커뮤티케이션 및 통합

DevOps 요소의 상세 내용은 https://aws.amazon.com/ko/devops/what-is-devops/ 을 참고하여 자세하게 알 수 있습니다.

CI/CD 프로세스

컨테이너(쿠버네티스) 환경에 맞는 자동화된 CI/CD 프로세스에 대해 알아보겠습니다.

배포 환경의 변화

프로세스를 알아보기 전에 어플리케이션 배포 환경이 어떻게 변화하고 발전했는지 알아보겠습니다.

배포 방식에 따른 시스템 구조에 대한 차이를 아래 그림으로 표현할 수 있습니다.


전통적인 배포 시대: 초기 조직은 애플리케이션을 물리 서버에서 실행했었습니다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했습니다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었습니다. 이에 대한 해결책으로 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하였습니다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으며, 조직이 많은 물리 서버를 유지하는 데에 높은 비용이 들었습니다.

가상화된 배포 시대: 그 해결책으로 가상화가 도입되었습니다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템(VM)을 실행할 수 있게 합니다. 가상화를 사용하면 VM 간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스할 수 없으므로, 일정 수준의 보안성을 제공할 수 있습니다.
가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공합니다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있습니다.
각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신입니다.

컨테이너 개발 시대: 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유합니다. 그러므로 컨테이너는 가볍다고 여겨집니다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있습니다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있는 장점이 있습니다.

간략하게 표로 비교하면 아래와 같이 표현할 수 있습니다.

시대정의장점단점
전통적인 배포 시대 물리적인 서버에 애플리케이션을 직접 배포 간단하고 직관적인 접근 방식 리소스 활용도 낮음, 확장성 및 유지보수 어려움
가상화 배포 시대 가상화 기술을 사용하여 물리적 서버를 가상 머신으로 분할하여 애플리케이션 배포 리소스 활용도가 높아지고, 환경 구성의 일관성 유지 쉬움 OS 레벨에서의 오버헤드, 가상화 환경 관리를 위한 추가 리소스 필요
컨테이너 개발 시대 컨테이너 기술을 사용하여 애플리케이션과 그 종속성을 컨테이너에 패키징하여 배포 가벼움, 시작 시간이 빠름, 환경 구성의 일관성 보장 보안과 네트워킹 관리 복잡, 컨테이너 오케스트레이션 관리를 위한 새로운 기술 필요

CI/CD 배포 프로세스

컨테이너 배포 환경으로 발전하면서 반복적이고 빈번한 배포가 일어났습니다. 이를 해소하기 위해 자동화된 CI/CD 배포를 도입하여 휴먼 에러를 줄이고 어플리케이션 배포에 용이하게 되었습니다.
그러면 일반적인 배포와 CI/CD 가 도입된 프로세스에 대한 프로세스 차이에 대해서 알아볼게요.

일반적인 배포 프로세스

  1. 개발자들이 개발하여 코드를 수정
  2. 각자의 feature 브랜치에 코드를 push
  3. 각자의 코드를 git에 올리고 통합(Intergration)
  4. 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어느 부분에 에러가 있는지 디버깅하고 코드를 수정
  5. (1) ~ (4)의 과정을 반복
  6. 많은 시간을 할애하여 에러가 해결되었으면 배포를 시작( 개발자가 직접 배포하므로 많은 시간이 소요)

CI/CD 자동화가 도입된 프로세스

  1. 개발자들이 개발하여 코드를 수정
  2. 각자의 feature 브랜치에 코드를 push
  3. CI서버( Jenkins, Tekton 등)에서 push 명령을 트리거링하여 자동으로 빌드, 테스트 등을 실행
  4. 에러가 발생하였다면 개발자에게 결과를 전송하여 오류를 수정
  5. 빌드, 테스트가 정상적으로 수행되었다면 CD서버가 자동으로 배포를 수행

컨테이너 환경에서의 배포 프로세스

컨테이너 환경에서는 빌드 된 어플리케이션을 구동할 수 있는 컨테이너 이미지를 생성하고 이미지 레지스트리에 추가하는 과정이 추가됩니다.

위에서 설명한 내용을 아래 표를 보면 기존 방식과 컨테이너 환경에서의 배포 방식의 차이를 좀 더 자세히 알 수 있습니다.

항목기존 배포CI/CD 배포
자동화 여부 전담 인력에 의한 수작업 CI 도구를 이요한 자동 빌드 및 자동 배포
패키징 배포 담당자가 수작업으로 취합하여 정리 형상관리를 통한 자동 취합
배포 시간 수 십분 소요 수 분 수요
무중단 배포 배포 담당자에 의한 수작업에 의한 무중단 배포 자동화된 무중단 배포
롤백 일부 파일 및 반 자동화 된 롤백 기존 운영 버전으로 롤백
휴먼 에러 발생 가능성 있음 없음
배포 검증 자동화 불가 테스트 케이스, 정적분석 등 다양한 기술을 배포 단계에 적용 가능

CI/CD 환경

CI/CD를 구성할 때 사용성을 높이기 위해 몇 가지 적용하는 정책 및 환경에 대해 알아보겠습니다.

형상관리 및 브랜치 전략

형상관리란 소스코드 변경에 대한 모든 관리를 말합니다. 형상관리 전략이란 그 변경을 추적하고 처리하는 메커니즘을 체계적으로 관리하기 위한 전략을 의미하며, 여러 가지 방식들의 브랜치 전략에 대해 정의해 보겠습니다.

브랜치 전략

대규모 개발 환경에서의 개발 또는 배포시 아래와 같은 질문을 자주 받을 수 있습니다.

  • 최신 브랜치는?
  • 어떤 브랜치를 이용하여 개발하여야 하나?
  • 배포는 어떤 브랜치로?
  • 핫픽스 사용 시 베이스가 되는 브랜치는?

위의 내용을 해소하기 위해 브랜치 전략을 도입 합니다.

Git-Flow

아래 그림은 Git을 이용하여 작업 시 브랜치 전략을 도입한 예시 입니다.

  • master – 가장 core가 되는 브랜치 중 하나로 패키징 용 브랜치이며 모든 변경사항이 결국은 master로 머지 되어야함
  • dev – 패키징 할 준비가 된 가장 안정적인 브랜치로 master 브랜치로 머지 하기 전 개발된 모든 feature들이 dev에 머지 됨
  • release – dev 브랜치에 어느 정도 feature 들을 머지하고, 패키징 시점에 생성하는 브랜치로 dev 브랜치로부터 생성 (통합테스트 용)
  • feature – 새로운 기능이 추가되어야 할 때 사용되는 브랜치로 dev 브랜치로부터 생성이 되며, 개발이 완료된 후 dev 브랜치로 머지
  • hotfix – 패키징 된 버전에서 발생한 버그같은 것을 수정해야 할 때 생성되는 브랜치로 수정이 완료된 후 master와 dev 브랜치에 머지
  • bugfix – feature 브랜치가 dev로 머지된 후 해당 기능에 버그가 발생한 경우 또는 release 브랜치에 대한 통합테스트 시 버그가 발생된 경우 생성되는 브랜치로 개발 완료 후 dev, release에 머지

브랜치 사용 방법

브랜치를 이용한 개발 순서는

  1. master 브랜치 생성 (프로젝트 생성)
  2. dev 브랜치 생성 (master pull)
  3. feature 브랜치 Jira 이슈로 생성 (dev pull)
  4. 개발 진행
  5. dev merge (feature PR)
  6. release 브랜치 버전 명시 생성 (dev PR)
  7. master 업데이트 (release PR)

로 진행하며 아래 사항을 주의하여 개발을 진행합니다.

  • master, dev 브랜치는 항상 1개만 존재
  • release 브랜치는 버전별로 존재
  • 릴리즈가 빈번히 발생하여 브랜치가 많아질 경우 삭제 주기를 설정이 필요
    예) 최신 5개의 버전을 제외한 브런치는 삭제
  • master, dev, release 브랜치는 직접 commit하지 않고, 반드시 Pull Request를 통해 Merge
  • 소스코드 commit 전에 반드시 pull로 변경사항을 확인하여, 소스코드가 유실되는 현상을 해소

Git-Ops

Git-Ops란, 이름에서 나타나듯 애플리케이션의 배포와 운영에 관련된 모든 요소를 코드화하여 깃(Git)에서 관리(Ops) 하는 것을 의미합니다. 기본 개념은 코드를 이용하여 인프라를 프로비저닝 하고 관리하는 IaC(Infrastructure as Code)에서 나온 것으로 Git-Ops는 이를 인프라에서 전체 애플리케이션 범위로 확장하여 사용합니다.

형상 관리 도구인 ‘Git’을 통해 개발자에게 익숙한 방식으로 인프라 또는 애플리케이션의 선언적인 설정 파일을 관리하고 배포합니다.

CI/CD 프로세스는 CD 영역을 담당하며, ArgoCD와 연동하여 사용하며 아래 그림과 같은 워크플로우를 가집니다.


GitOps를 사용할 경우 아래와 같은 장점을 가집니다.

  • 신뢰할 수 있는 정보의 공유
    • 서비스의 설정값, 배포 정보에 대해 직접 서버를 접근할 필요 없이 확인이 가능
    • 이력 관리를 통해 이전 배포 환경에 대한 정보를 알 수 있어 에러 복구 시간이 감소
  • 익숙한 절차
    • 개발자에게 익숙한 git 명령어를 그대로 적용

지금까지는 CI/CD가 무엇이며, 어떻게 발전해 왔고, 일반적인 배포 방식과 차이에 대해 알아봤는데요.
실제 CI/CD가 어떻게 구성되는지를 알아보도록 할게요.

CI/CD 구성도

파이프라인이란

Pipeline의 사전적 의미는 ‘석유, 천연가스 등 유체의 수송을 위해 만든 관로’입니다.
컴퓨팅 기술에서 Pipeline은 프로세서에서 성능을 높이기 위해서 명령어 처리 과정으로 명령어 처리를 여러 단계로 나누어 단계별로 동시에 수행하여 병렬화를 시키는 것을 말합니다.

CI/CD에서 말하는 Pipeline은 애플리케이션을 만들고 배포함에 있어 일련의 과정들의 관로처럼 나열하여 순차적으로 실행하는 것을 의미합니다.

파이프라인 구성도

일반적인 파이프라인은 아래 그림과 같은 구성을 가집니다.

CI/CD 프로세스에서 언급했던 GitOps를 포함하여, 소스코드를 빌드 하여 어플리케이션을 배포하며, 슬랙 등으로 알람을 받을 수도 있습니다.

파이프라인 구성에는 정답이 없으며, 프로젝트 상황에 맞는 모델을 적용하고 지속적으로 발전해 나가는 것이 중요합니다.

컨테이너 기반 CI/CD 구성요소

CI/CD를 구성함에 있어, CNCF에서 검증된 SW Stack 중에 가볍고, 사용성이 많은 요소를 선정하여 최적화된 파이프라인을 제공합니다. ( CNCF Landscape )

CI/CD SW Stack을 구성함에 있어 어떤 툴을 사용하며 선정 이유에 대해 표로 작성한 내용입니다.

분류SW선정 이유
형상관리 Gitea 가볍고 필요한 git 서버 기능은 모두 지원
빌드 라이브러리 관리 Nexus 성능 및 가용성이 높으며 많은 사용자 보유
Code Inspection Sonarqube 다양한 프로그래밍 언어의 정적 코드 검사 및 DevOps 연동 지원
도커 레지스트리 Harbor 제품은 조금 무겁지만 플러그인으로 UI 및 helm chart 지원 이미지 보안 검사 기능을 지원
배포 툴 ArgoCD 클라우드 베이스의 배포 지원 및 다양한 배포방식(Rollout, Blue/Green, Canary) 및 플러그인 지원
빌드 파이프라인 Jenkins Kubernetes 자원을 기반으로 구축되어 자원 확장 및 구성/관리가 용이
  Tekton 범용적으로 많이 사용하는 제품으로 많은 플러그인과 파이프라인 예제가 있음

CI/CD 파이프라인 구성

파이프라인은 컨네이너 환경에 배포하는 것을 기준으로 구성합니다.
위에서 정의한 프로세스, SW Stack을 조합하여 아래와 같이 구성할 수 있습니다.

  1. 개발자가 Gitea에 소스 commit 및 push
  2. 형상관리에서 Jenkins 로 자동으로 Webhook 전송
  3. Jenkins에서 발생한 Trigger에 맞춰 파이프라인을 실행
    1. Gitea에서 소스코드 Clone
    2. 소스코드 빌드
    3. 컨테이너 배포를 위한 이미지 빌드
    4. 도커 레지스트리에 이미지 Push
    5. 배포한 이미지에 대한 정보를 git-ops에 반영
    6. ArgoCD로 배포 명령 전송
    7. git-ops에 설정한 값으로 쿠버네티스에 배포
  4. 배포 결과를 슬랙으로 전송

위의 과정은 개발자가 형상관리에 소스를 push 함과 동시에 배포까지 자동으로 실행되는 프로세스입니다.

마치며…

지금까지 CI/CD 아키텍처에 대해 알아보았습니다.

앞서 말씀드린 대로, CI/CD를 도입하고 구성함에 있어 정답은 없으며, 우리에게 얼마나 잘 맞게 구성하느냐가 중요합니다.

CI/CD 초기 도입 시에 많은 개발자분들이 왜? 굳이?라는 의문을 가질 수 있습니다. 현재 시스템도 잘 쓰고 있고 배포가 잘 이루어지는데 도입 공수에 비해 필요가 없다고 느낄 수 있지만, CI/CD는 선택이 아니라 필수입니다.

본 포스팅으로 CI/CD에 대한 이해가 완료되면, 실제 파이프라인을 구성해 볼 수 있는데요.
저희 블로그에 관련된 자료가 있으니 참고해 보시면 좋습니다.

 

데이터 파이프라인 기본 원리와 원칙은 시간이 지나도 유효해야 한다

 

고가용성 시스템을 구축하기 위해, 신뢰성 높은 데이터 파이프라인을 설계하고 구성하는 방식에 대해 살펴봤습니다. 이번 글에서는 복잡도를 관리하기 위한 요소에 대해 살펴보겠습니다.

복잡도를 관리하기 위한 고려 요소

데이터 파이프라인 시스템 복잡도를 관리하기 위해 아래와 같은 요소를 고려해야 합니다.

  • 소스 타입: 인풋 데이터를 가져오는 방식 및 소스 스토리지 타입에 따라 발생할 수 있는 다양성.
  • 데이터 형태: 인풋 데이터의 모델/포맷/스키마와 같은 형태적 특성 및 오염도에 따라 발생할 수 있는 다양성.
  • 가공 방식: 데이터 오염도와 사용자 요구사항에 따른 전처리 프로세스 별 로직 내에서 발생할 수 있는 다양성.
  • 전달 채널: 데이터 사용자에게 데이터를 전달하기 위한 접점 시스템의 종류에서 발생할 수 있는 다양성.
  • 운영 도구: 시스템 내부 정보 또는 제어 방식을 노출할 때 인터페이스에서 발생할 수 있는 다양성.

각 고려 사항으로 언급한 다양성을 검토한 후에는 개별 케이스가 갖는 공통적인 특성이나 의미를 추출해야 합니다. 예를 들어, 소스 타입이 HDFS든지 Cassandra(카산드라)든지 우리는 데이터 소스로부터 읽기(read), 쓰기(write), 삭제(delete) 같은 요청을 할 것이라고 예상할 수 있습니다. 각각 내부적으로 처리하는 방법이 상이하고 복잡할 수 있지만, 우리는 이것들을 추상화(Abstraction)해 데이터 소스(DataSource)라는 인터페이스로 정의할 수 있습니다.

추상화 작업을 거치면구현 단계에서 발생하는 복잡도를 프레임워크로부터 분리할 수 있고, 신규 데이터 소스를 추가해도 복잡도를 유지할 수 있습니다. 이 접근 방식을 시스템 모듈 모든 곳에 적용했으며, 이를 기반으로 프레임워크 수준에서 일관성 있는 운영 모델을 지원할 수 있습니다.

  • DataWrapper 인터페이스를 통해 데이터 형태가 달라지더라도 동일한 방식의 key, value 입출력 지원.
  • TransformRule 인터페이스를 통해 가공 방식을 연산자의 순열로 정의한 후 동일한 형태의 호출 방식 지원.
  • Channel 인터페이스를 통해 이기종(heterogeneous) 사용자 데이터베이스에 대한 동일한 전달 처리 방식 지원.

이렇게 추상화한 후에는 각 모듈이 특정한 형태로 아웃풋을 보장합니다. 그래서 이후 개발 과정에서 그 모듈을 믿고 사용할 수 있으며, 관리자가 모듈 별 세부 로직을 제어할 때에는 그 부분을 설정으로 분리하는 방식으로 시스템 복잡도를 관리할 수 있습니다. 특히, 이런 방식은 데이터 가공 단계에 필요한 사용자 별 요구사항과 각 사용자 별 전달 채널을 모두 충족할 수 있다는 장점이 있습니다.

데이터 가공

데이터 가공 단계

위 그림은 데이터 가공 단계를 처리하는 각 단계와 그 단계 별로 필요한 설정을 보여주는 구조도입니다. 목적 달성에 필요한 로직을 일련의 모듈로 추상화하고, 모듈을 chaining해 최종 데이터를 산출하는 방식으로 설계했습니다.

데이터 가데이터 가공 단계 모듈의 기능과 설정 방식

각 모듈의 기능과 설정 방식은 아래와 같습니다.

  • Filter: 사용자가 원하는 데이터에서 원하는 컬럼만 추출하는 모듈입니다. 필터링하는 데이터와 컬럼은 각각 blacklist와 whitelist 기반으로 관리합니다.
  • Cleanser: 새로운 값을 추가하거나 기존 값을 복제 또는 수정하는 모듈입니다. 각각 추가(add), 복사(copy), 편집(edit) 룰로 관리합니다. 편집은 값(value) 타입별 연산자 순열로 구성합니다.
  • Mapper: 데이터에 있는 key별 값을 사용자에게 제공하는 테이블에 있는 컬럼과 매핑하는 모듈입니다. 사용자가 입력한 constant값으로 직접 매핑하거나 원래 key를 변형하는 룰 조합으로 구성합니다.
  • Flattener: 중첩 구조 데이터를 depth가 없는 형태로 변형하는 모듈입니다. 중첩 제거 과정에서 중복키가 발생하면 처리 방식에 대한 정책 및 정책별 파라미터값으로 구성합니다.

채널별 데이터 전달 방식

채널별 데이터 전달 방식

위 그림은 데이터 가공부터 채널 전달까지를 표현하는 실행 구조도입니다. 목적에 따라 스케줄러에 의해 별도 프로세스로 실행하거나 스트리밍으로 한번에 실행할 수 있습니다. 우리는 Channel이라는 인터페이스를 통해 다양한 채널을 공통으로 처리할 수 있습니다.

추상화한 모듈과 컴포넌트를 기반으로 대부분 상세하고 복잡한 처리를 감출 수 있습니다. 관리자는 단순화한 인터페이스로 데이터 파이프라인을 제어할 수 있습니다. 일반적인 절차는 default 설정을 통해 자동화할 수 있고, 필요시에는 관리자가 다르게 설정을 변경할 수 있습니다. 또한, fault 케이스 별로 fail-over 처리 레벨을 구분함으로써 아래와 같이 데이터 파이프라인 제어 구조를 단순화시킬 수 있습니다.

파이프라인 fault-tolerance 모델

각 모듈이나 컴포넌트는 자신의 상위 객체에게 deterministic한 성공 결과를 제공할 수 있어야 합니다. 맡은 작업을 처리하는 과정에서 예상되는 fault를 각 모듈이나 컴포넌트가 스스로 극복할 수도 있지만, 그렇지 못한 경우에는 부분적인 실패를 남기지 않고 상위 객체에게 알려줘야(escalation) 합니다. 상위 객체도 이 과정을 재귀적으로 수행하며, 최종적으로도 해소가 안 되는 경우에는 관리자가 직접 처리할 수 있도록 알람을 보낼 수 있습니다.

파이프라인 컨트롤러는 관리자에게 매뉴얼 실행을 위한 커맨드와 세부 설정을 위한 메타 스토어를 제공하며, 아래와 같이 구성되어 있습니다.

파이프라인 컨트롤러 구조

스케줄러(Scheduler)는 Airflow(에어플로우) 기반으로 동작하는 실행 계획(execution planning)과 YARN 기반으로 동작하는 RM(resource management)을 포괄하는 개념입니다.

스케줄러는 파이프라인 전체 태스크의 실행 순서를 제어하고, 각각 리소스를 할당하는 역할을 합니다. BigPi 로그 처리 시스템은 메타 스토어를 참조해 스케줄러가 실행할 DAG(Dynamic Acyclic Graph)를 자동으로 생성해주며, 실행하는 컴포넌트와 내부 모듈도 메타 스토어를 참조해 세부 설정 값을 구성합니다. 또한, 파이프라인 컨트롤러가 제공하는 여러 가시화 도구를 통해 시스템의 현재 상태를 직관적으로 확인할 수 있습니다.

시간이 지나도 유효할 수 있는 기본 원리와 원칙

지금까지 넷마블에서 데이터를 어떻게 사용하고, 그에 따라 어떤 방식으로 데이터 파이프라인을 구성하는지 소개해드렸습니다. 그 과정에서 해결해야 했던 분산 환경 이슈와 시스템 복잡도 문제를 다뤘고, 그와 관련되는 시스템 디자인 원칙도 살펴봤습니다.

거듭 말씀드리지만, 이 내용은 온전히 넷마블의데이터 환경과 조직 운영 방식에 적합하도록 설계된 결과물입니다. 이 설계는 머지 않아 새로운 환경에 대응하기 위해 바뀔 것이고, 그 상황에 맞는 새로운 솔루션이 있을 것입니다. 다만, 설계 과정에서 고려했던 기본적인 원리와 원칙은 시간이 지나더라도 유효할 것이라고 믿습니다.

Appendix – System Design Principles

(ref. Designing Data-Intensive Applications)

1. Reliability – 신뢰성

하드웨어나 소프트웨어 결함(fault) 또는 휴먼 에러가 발생할 때에도 시스템이 지속적으로 정확하게 작동하도록 보장하는 것을 의미합니다. 내고장성(fault-tolerance)을 보장하는 기법을 이용해, 알려져 있는 유형이나 결함을 해소할 수 있습니다. Reliability를 높이려면 아래와 같은 작업이 필요합니다.

  • 시스템에서 발생하는 인터랙션과 가정하고 있는 사항에 대해 주의 깊게 검토.
  • 모든 프로세스는 부분 실패를 인지해 crash를 일으키고, 재시작할 수 있도록 해야 함.
  • 에러 가능성을 최소화할 수 있는 잘 설계된 Abstraction, API, 관리자 인터페이스를 통해 시스템의 올바른 사용 방식을 유도하고, 잘못된 방식을 억제해야 함. 단, 과도한 제약은 사용자가 제공된 인터페이스를 우회하도록 유인하기 때문에 적절한 밸런스가 중요.
  • 휴먼 에러 가능성을 상정하고, 장애 영향도가 최소화 되도록 설계해야 함. 새로운 코드의 배포나 설정 변경을 점진적으로 진행할 수 있고, 장애 발생 시 빠른 롤백을 할 수 있도록 해야 하며, 잘못 처리된 데이터에 대해 쉽고 정확한 재처리 도구를 제공해야 함.
  • 상세하고, 명확한 모니터링을 구축해야 함. 퍼포먼스 메트릭, 에러율 등에 대한 모니터링을 통해 위험 신호를 감지할 수 있고, 어떤 가정이나 제한사항들이 깨졌는지 여부를 체크할 수 있으며, 시스템 진단에도 사용할 수 있음.
  • 시스템에 몇 가지 보장해야 하는 것이 있다면, 이를 지속적으로 체크해 모순되는 부분이 발견되는 즉시 경고 알림(alert)을 발생시켜야 함.

2. Scalability – 확장성

시스템 규모를 확장할 때 부하(데이터 량, 트래픽, 복잡도 등)가 증가하더라도 좋은 성능을 유지하는 전략 갖는 것을 의미합니다. 병렬 처리 가능한 로직을 적용하거나 분산 처리를 통해 시스템을 확장 가능(scalable)하게 만들 수 있습니다. Scalability를 논의하기 위해서는 부하(load)와 성능(performance)을 양적으로 서술할 수 있는 방법이 있어야 합니다.

  • 반응 시간 백분위를 통해 성능을 측정할 수 있음.
  • 고부하 상황에서도 안정성을 유지할 수 있는 최대 처리 가능량(processing capacity)을 추가할 수 있음.

3. Maintainability – 유지보수성

다양한 측면으로 이해할 수 있지만, 본질적으로는 이 시스템을 담당하는 개발팀, 운영팀, 데브옵스 팀의 삶을 더 좋게 만드는 것을 의미합니다. 이를 달성하기 위한 세부적인 디자인 원칙은 Simplicity(단순성), Evolvability(발전성), Operability(운영성)가 있습니다.

Simplicity – 단순성

시스템 구조 또는 소스코드의 복잡도를 낮은 수준으로 관리하는 것을 의미합니다. 좋은 Simplicity는 새로운 엔지니어가 시스템을 이해하기 쉽게 해줄 수 있습니다. 아래와 같은 복잡도 요소를 제거하면 Simplicity를 향상시킬 수 있습니다.

  • 상태 공간(state space) 급증
  • 모듈간 강한 커플링(tight coupling)
  • 복잡하게 얽힌 종속관계(tangled dependencies)
  • 일관성 없는 네이밍과 용어(terminology)
  • 성능 문제 해소를 위한 수정(hack)
  • 이슈들을 다르게 해결하기 위한 예외처리(special-casing)

나쁜 Simplicity는 유지보수를 어렵게 만들고 특히, 아래와 같은 문제를 유발합니다.

  • 유지보수 단계에서 종종 비용과 일정이 초과될 수 있음.
  • 복잡한 소프트웨어를 변경할 때는 버그를 만들어낼 위험이 더 큼.
  • 시스템에 숨겨진 가정을 이해하고 추론하기 어려워질수록 의도하지 않은 결과와 예상치 못한 인터랙션이 더 쉽게 일어날 수 있음.

Evolvability – 발전성

시스템 구조 또는 소스코드를 변경하기 쉽도록 해주는 것을 의미합니다. 좋은 Evolvability를 통해 엔지니어는 변경된 요구사항이나 예상하지 못한 유스케이스에 더욱 유연하게 대응할 수 있습니다. 일반적으로 아래와 같은 요인으로 인해 시스템을 수정해야 하는 경우가 생깁니다.

  • 새로운 것(fact)들을 학습
  • 이전에는 예상하지 못했던 유스케이스가 발생
  • 비즈니스 우선순위 변경
  • 사용자가 새로운 변수(feature) 요구
  • 새로운 플랫폼이 기존 플랫폼을 대체
  • 법이나 정책적인 요구사항 변경
  • 시스템 확장

데이터 파이프라인 및 내부 시스템을 편하게 변경하기 위해서는 시스템의 Simplicity가 높아야 하고, Abstraction이 잘 설계돼 있어야 합니다.

Operability – 운영성

운영 환경을 쉽고 편안하게 해주는 것을 의미합니다. 좋은 Operability는 반복적인 태스크를 쉽게 만들기 때문에, 운영팀은 높은 가치가 있는 활동에 노력을 집중할 수 있습니다. Operability를 향상시키기 위해 아래와 같은 작업을 해야 합니다.

  • 좋은 모니터링을 통해 시스템 내부와 런타임 동작 상태에 대한 가시성(Visibility)을 제공.
  • 표준화한 도구의 통합과 자동화를 잘 지원.
  • 개별적인 머신에 대한 종속성을 제거해 부분적인 유지보수 시에도 서비스를 유지할 수 있어야 함.
  • 양질의 문서와 이해하기 쉬운 운영 모델(“X를 하면 Y가 발생한다”와 같은)을 제공.
  • 디폴트 동작/설정을 잘 제공하고 그러면서도 관리자가 기본값을 자유롭게 덮어쓸 수 있도록 해야 함.
  • 적절한 곳에서는 자동 복구되고(self-healing), 필요한 경우 관리자가 시스템을 수동으로 조작할 수 있도록 해야 함.
  • 예측 가능한 행동을 하도록 하고, 예상치 못한 행동(surprises)은 최소화 해야 함.
 

빅데이터 분석 기반이란? 데이터 파이프라인 구축

빅데이터란?

빅데이터란?

빅데이터는 일반 소프트웨어에서는 처리할 수 없는 대규모(테라바이트, 페타바이트, 엑사바이트 규모) 데이터이다.

여기서는 빅데이터를 시각화, 분석하는 것을 목표로 한다.

빅 데이터가 소규모(small) 데이터용 소프트웨어(Excel이나 RDB 등)로 처리할 수 없는 이유는 다음과 같이 하드웨어 리소스의 한계가 있기 때문이다.

  • CPU 한계: 계산할 데이터가 너무 많아, 업무 시간 내에 처리가 끝나지 않음
  • 메모리 한계: 데이터가 너무 많아, 메모리를 극복하지 않으므로 처리할 수 없음
  • 스토리지 한계: 데이터가 너무 많아, 스토리지 에 들어갈 수 없기 때문에 처리할 수 없음

그래서 빅데이터를 처리하려면, 병렬 처리가 가능한 소프트웨어를 이용하여 복수의 컴퓨터(의 하드웨어 자원)를 이용해야 한다.

여기에서는 다음 흐름을 따라 빅데이터의 각 용어의 의미/가시화/분석 방법을 설명한다.

데이터 소스란?

데이터 소스

데이터 소스(data source)는 분석하려는 데이터의 소스이다.

데이터 소스의 구체적인 예는 다음 로그와 테이블 정보이다.

  • 웹 서버
  • IoT 장비(공장 및 자동차 센서 등)
  • 모바일 기기(스마트폰 등)

데이터 소스라는 단어가 가리키는 대상은 서 있는 위치에 따라 달라진다.
(예를 들어, 위 그림의 BI 도구에서 본 데이터 소스는 NoSQL, DWH, 데이터 마트이다.)

또한, 데이터는 다음 세 가지 유형으로 나뉜다.

  • 정형(구조화된) 데이터
  • 비정형(비구조화된) 데이터
  • 반정형(반구조화된) 데이터

정형(구조화된) 데이터란?

정형 데이터

정형 데이터는 2차원 테이블 형식의 데이터이다.
정형 데이터는 스키마(예: 행/열/데이터 유형)가 정의되어 있다.

정형 데이터의 예


RDB 테이블

정형 데이터의 예는 다음과 같다.

[ID, NAME,DATA] 열을 3행을 가진 데이터

 
ID,NAME,DATE
1,devkuma,2022/08/01 00:00
2,araikuma,2022/08/02 00:00
3,kimkc,2022/08/03 00:00

특징

  • 컴퓨터에서 사용하기 쉽다(RDB + SQL 쿼리로 작업 가능).
  • 사전에 미리 행과 열을 정의가 필요하다(고정 스키마).
    • 저장에 시간이 많이 걸린다(행, 열의 형태로 데이터를 변환해야 함).
    • 각 행은 동일한 열 이름을 가진다.
  • 중첩하지 않는다(테이블의 필드 값에 테이블이 포함되지 않음).
    • 다른 테이블을 참조하는 경우 JOIN 한다.

비정형(비구조화된) 데이터란?

비정형 데이터

비정형 데이터는 2차원 테이블 형식이 되지 않은 데이터이다.
비정형 데이터는 스키마(예: 행/열/데이터 유형)가 정의 되지 않는다.

비정형 데이터의 예

비정형 데이터의 예는 다음과 같다.

  • 음악
  • 사진
  • 텍스트

비정형 데이터의 예는 다음과 같다.

텍스트(액세스 로그)

 
<6>Feb 28 12:00:00 192.168.0.1 fluentd[11111]: [error] Syslog test

비정형 데이터에는 열 이름이 없으므로 열의 의미를 이해하기가 어렵다.
(위에 텍스트에서의 <6>와 같은 등은 의미를 알 수가 없다.)

특징

  • 컴퓨터에서 다루기가 어렵다(예 : 스키마가 없으므로 RDB + SQL 쿼리 로 작업 할 수 없음).
  • 행, 열을 정의하지 않아도 된다(스키마리스: schemaless).
    • 저장이 쉽다(아무것도 처리하지 않고 그대로 저장).

반정형(반구조화된) 데이터란?

반정형 데이터

반정형 데이터는 비정형 데이터의 각 요소에 속성 이름(열 이름)을 붙인 데이터이다. 그러나, 테이블 형식은 아니다.

반정형 데이터의 예

비정형 데이터의 예는 다음과 같다. 이 외에도 Parquet, ORC 등이 존재한다.

  • JSON
  • XML
  • AVRO

비정형 데이터를 반정형 데이터로 변환하는 예는 다음과 같다.

비정형 데이터 (변환 전)
비정형 데이터의 예: 텍스트(액세스 로그)

 
<6>Feb 28 12:00:00 192.168.0.1 fluentd[11111]: [error] Syslog test

반정형 데이터(변환 후) 반정형 데이터의 예: JSON 형식(위에 비정형 데이터의 요소에 속성 이름을 붙인 것임)

 
{
    "jsonPayload": {
        "priority": "6",
        "host": "192.168.0.1",
        "ident": "fluentd",
        "pid": "11111",
        "message": "[error] Syslog test"
    }
}

비구조화 데이터에서는 <6>이 무엇을 나타내는지 몰랐지만, 반구조화 데이터는 속성명이 붙어 있으므로, “6"이 priority인 것을 알 수 있다.

특징

  • 속성을 갖기 때문에 컴퓨터가 다루기 쉽다(반정형 데이터에 대한 쿼리 등).
  • 사전에 속성 정의가 필요하지 않다(가변 스키마).
    • 언제든지 새로운 속성을 추가 가능하다.
  • 저장이 조금 편하다(사전에 데이터의 형태를 결정하지 않아도 된다. 나중에 쉽게 속성을 추가할 수 있다).
    • 각 행마다 다른 속성을 가질 수 있다.
  • 중첩 가능
    • 관련 데이터는 중첩되어 포함되므로 JOIN 불필요하다(또는 클라이언트 측에서 JOIN).

정형/비정형/반정형 차이

정형/비정형/반정형의 차이를 정리하면 다음과 같다.

정형비정형반정형

테이블 형식 Yes No No (테이블 형식으로 변환 가능)
스키마(행/열/데이터 유형 등) 고정 스키마
(사전 정의)		 스키마리스 가변 스키마
(나중에 속성을 추가 가능)
저장 번거롭다
고정 스키마로 변환		 쉽다
무변환		 약간 쉽다
가변 스키마로 변환
쿼리 가능 예 아니 예(해당 DB)
서버측 JOIN 필요한
데이터가 중첩 불가능		 - 불필요한
데이터가 중첩 가능
  • 고정 스키마는 데이터를 반드시 스키마에 맞추지 않으면 저장할 수 없다.
  • 가변 스키마는 나중에 데이터에 맞게 스키마 쪽 속성을 나중에 추가할 수 있다.

데이터 분석의 목표는 쿼리를 사용하여 원하는 데이터를 추출하는 것이다.

따라서, 비정형 데이터를 분석하려면 쿼리를 사용할 수 있도록 정형 데이터 또는 반정형 데이터로 변환해야 한다.

ETL/ELT란?

ETL

ETL은 다음 3가지를 처리한다.

  • Extract - 데이터 소스에서 데이터 추출
  • Transform - 추출된 데이터를 가공/변환
  • Load - 해당되는 가공/변환된 데이터 로드

ELT

ELT는 ETL의 가공/변환(Transform)과 로드(Load)의 순서가 바뀐 것이다.

데이터 소스 측에서 가공/변환(Transform) 하지 않는 이유는 다음과 같다.

  • 웹 서버 : 운영 서버에 로드를 원하지 않는다.
  • IoT 기기: 변환 처리할 수 있을 만큼의 스펙이 없다.
  • 모바일 기기: 고객 기기에서 처리할 수 없다.

ETL에는 다음 두 가지 유형이 있다.

  • 배치 ETL
  • 스트리밍 ETL

배치 ETL스트리밍 ETL

목적 처리량 중시 실시간 중시
처리할 타이밍 일정한 간격(매시간, 매일 밤 등) 데이터가 발생했을 때
처리에 걸리는 시간 몇 분 ~ 몇 시간 몇 밀리초 ~ 몇 초
사용 사례 야간 배치
월별 처리		 실시간성이 필요한 처리
(예: 신용카드의 부정 검출 등)

Extract(추출)

데이터 소스에서 데이터를 추출하는 소프트웨어는 다음과 같다.
(외부에서 직접 SQL 쿼리나 REST API로 추출하는 방법도 있다.)

소프트웨어ETL 유형

Embulk 배치 ETL
fluentd 스트리밍 ETL
beats(Elasticsearch) 스트리밍 ETL
Kafka Producer API(Kafka) 스트리밍 ETL

스트리밍 ETL에서는 Extract와 Transform 사이에 Pub/Sub 메시징 시스템을 배치할 수 있다.

복수의 수신자에게 같은 메시지를 전달하는 일대다의 출판-구독 모델(Pub-Sub 모델)에 의한 전달에 대응하고 있는 것도 있다.

Pub/Sub 메시징 시스템을 설치하는 이유는 다음과 같다.

  • 실시간으로 Transform을 완료하기 위해 여러 컴퓨터에 처리를 분산하고 가속화
  • 피크(peak)시 급격한 데이터 증가로 인해 Transform이 시간에 맞지 않으면 데이터를 일시적으로 저장

Transform (가공/변환)

추출한 데이터는 주로 다음 소프트웨어로 Transform(가공/변환) 한다.

  • SQL 쿼리
  • pandas
  • fluentd
  • logstash (Elasticsearch)
  • Kafka Streams (Kafka)
  • Spark Streaming (Apache Spark)

Transform은 정형/반정형 데이터로 변환하거나 데이터를 추가/삭제한다.

Load (로드)

Transform 으로 적절한 형태로 변환한 데이터는 주로 이하의 4개의 목적지에 Load 한다.

  • NoSQL
  • 데이터 레이크
  • DWH(데이터 웨어하우스)
  • 데이터 마트

데이터 레이크(Data Lake)란?

데이터 레이크

데이터 레이크는 모든 형식(정형/비정형/반정형)의 데이터를 미래에 대비하여 무제한으로 축적하는 저장고 이다.

데이터 레이크의 예

데이터 레이크 서비스/소프트웨어 의 예는 다음과 같다.

  • Hadoop HDFS
  • Amazon S3

데이터 레이크에는 다양한 형식의 데이터를 수 없이 저장해 간다.

따라서, 나중에 용량을 추가할 수 있는 스토리지가 데이터 레이크로 선택된다.

NoSQL 데이터베이스

NoSQL 데이터베이스

NoSQL 데이터베이스는 특정 용도에 특화된 분산 데이터베이스이다.

분산 데이터베이스(distributed database)는 하나의 데이터베이스 관리 시스템(DBMS)이 여러 CPU에 연결된 저장장치들을 제어하는 형태의 데이터베이스이다.

“NoSQL"이라는 이름은 실제로 어떤 기술을 참고한 곳이 아니기에 적절하지 않다. 원래 NoSQL은 2009년 오픈 소스, 분산 환경, 비관계형 데이터베이스 밋업(meetup)용 인기 트위터 해시태그였다.

출처 : 데이터 중심 애플리케이션 설계

NoSQL은 RDB로 부터 어떠한 제약을 풀어, 퍼포먼스를 추구한 데이타베이스이다.
(역으로 말하면, RDB로 만족하는 퍼포먼스가 나오는 경우는 NoSQL는 필요 없을지도 모른다)

NoSQL과 RDB의 차이

NoSQL과 RDB의 차이점은 다음과 같다.

NoSQLRDB

용도 낮은 대기 시간(고성능) 처리 트랜잭션 처리
데이터 모델 비정형 데이터가 많다
(Key-Value, 문서, 그래프 등)		 정형 데이터
(관계형 모델)
JOIN 클라이언트측에서 JOIN 을 추천
서버측은 데이터를 중첩하여 대응		 서버측에서 JOIN
스키마 가변 스키마가 많다 고정 스키마
확장성 노드 추가 및 처리 분산
※노드 = 컴퓨터		 노드 자체의 성능을 높인다
읽기 전용 복제본 노드 추가

이는 어디까지나 경향 이야기이다. 위에서 언급했듯이 NoSQL에는 기술적 정의가 없다.

NoSQL 유형 및 예제

NoSQL의 유명한 데이터 모델 유형은 다음과 같다.

데이터 모델 유형설명제품 예

Key-Value 캐시
(인 메모리)		 키와 해당 값으로 메모리 에 데이터 관리
(연관 배열, 사전 형식)		 Memcached
Redis
Key-Value 스토어 키와 해당 값으로 스토리지 에 데이터 관리 (연관 배열, 사전 형식) DynamoDB
와이드 컬럼 스토어 테이블, 행, 열로 데이터 관리
(2차원 Key-Value 스토어)
RDB 와 달리 행마다 열 이름이 달라도 된다.		 카산드라
HBase
그래프 데이터베이스 노드, 에지, 속성으로 데이터 관리 Neo4j
도큐먼트 저장소 반정형 데이터(도큐먼트 지향)로 데이터 관리 Elasticsearch
MongoDB

https://en.wikipedia.org/wiki/NoSQL

데이터 웨어하우스(DWH)란?

데이터 웨어하우스(DWH)

데이터웨어 하우스(DWH, data warehouse)는 정형 데이터를 저장하고 분석하는 데이터베이스이다.

데이터 웨어하우스(DWH)와 RDB의 차이

데이터 웨어하우스(DWH)와 RDB 의 차이점은 다음과 같다.

데이터 웨어하우스(DWH)관계형 데이터베이스(RDB)

목적 분석(OLAP) 트랜잭션 처리 (OLTP)
스토리지 열 지향 스토리지 형식 행 지향 스토리지 형식
데이터 양 빅데이터 스몰 데이터
데이터 정규화 부분적으로 비정규화
- 스타 스키마
- 눈송이 스키마		 제3정규형

RDB는 데이터 양이 늘어나면 매우 느려진다.

따라서, 대량의 데이터를 분석하려면 데이터 웨어하우스(DWH)를 사용한다.
(역으로 말하면, 고속으로 분석할 수 있는 스몰 데이터의 경우는 RDB이면 된다.)

열 지향 데이터베이스(Columnar Database)란?

열 지향 데이터베이스(Columnar Database)

열 지향 데이터베이스(Columnar Database)는 데이터를 스토리지 블록에 열 단위로 저장하는 데이터베이스이다.

열 지향 데이터베이스는 다음 파일 형식(열 지향 저장소 형식)으로 데이터를 저장한다.

  • ORC
  • Parquet

또, 열 지향 데이터베이스(열 지향 스토리지 형식)의 아래와 같이 3가지 특징이 있다.

  • 분석시 읽기 효율이 좋다.
  • 쓰기 효율이 떨어진다.
  • 압축률이 좋다.

분석시 읽기 효율이 좋다.

열 지향 데이터베이스에서는 불필요한 열을 읽을 수 있으므로 읽기 효율이 좋아진다.

데이터 분석에는 열(column)만 필요한 경우가 많다.

예를 들어, 다음 테이블에서 주문 피크 시간을 분석하려는 경우에는 ‘구매일’ 컬럼만 집계 하면 되며 전체 테이블을 로드할 필요가 없다.

색인은 하나의 열로 설정되지만, 분석에서는 색인이 없는 열을 사용할 수 있다.

위의 예제에서 열 지향 데이터베이스를 사용하면 블록 읽기를 1/3로 줄일 수 있다.

쓰기 효율이 떨어진다.

열 지향 데이터베이스에서는 쓰기 블록을 찾아야 하므로 쓰기 효율이 떨어진다.

각 데이터베이스를 작성하는 절차는 다음과 같다.

  • 열 지향 데이터베이스
    • 쓸 블록 찾는다.
    • 열의 내용을 추가한다.
    • 모든 열에 대해 1과 2을 반복한다.
  • 행 지향 데이터베이스
    • 가장 마지막 블록에 넣는다.

쓰기에 대해서는 행 지향 데이터베이스가 효율이 더 좋다는 것을 알 수 있다.

압축률이 좋다.

동일한 컬럼은 동일한 데이터 유형을 포함하므로, 컬럼 지향 데이터베이스의 압축률이 향상된다.

예를 들어, ‘구매수’ 열에서 같은 숫자가 계속되기 쉽다. 이 경우 압축 효율이 좋아진다.


압축 이미지

압축률이 좋으면 한번에 스토리지 액세스로 많은 데이터를 읽을 수 있다.

데이터 웨어하우스(DWH) 예제

데이터 웨어하우스(DWH)의 특정 소프트웨어 및 서비스는 다음과 같다.

데이터 웨어하우스(DWH)와 데이터레이크의 차이

데이터 웨어하우스(DWH)데이터레이크

목적 “지금” 데이터를 가장 빠르게 분석 “미래"에 이용할 데이터를 모으기
데이터 형식 정형/반정형 모두(정형/비정형/반정형)
저장 번거롭다(구조화 된 데이터로 변환) 쉽다(무변환으로 저장)
분석/추출 빠르다 느리다(정형화되어 있지 않기 때문에)
새로운 요구 분석 불가능(스키마 이외의 데이터 버림) 가능(모든 데이터 포함)
용량 제한 있음 무제한

데이터 마트(Data Mart)란?

데이터 마트

데이터 마트는 정형화된 데이터를 저장하고 분석할 수 있는 데이터베이스이다.

데이터 마트와 데이터 웨어하우스(DWH)의 차이

데이터 웨어하우스의 규모가 작아진 것이 데이터 마트라고 할 수 있다.

데이터 마트데이터 웨어하우스

목적 필요한 데이터만 분석 모든 데이터 분석
범위 단일 부서 모든 부서
사이즈 소형 데이터(100GB 미만) 빅데이터(100GB 이상)
소량의 데이터 분석 능숙하다(고속) 능숙하지 못하다(저속)
대량의 데이터 분석 능숙하지 못하다(저속) 능숙하다(고속)

빅데이터의 크기는 2022년 시점에서의 기준

메모리에 모든 데이터가 올라오게 되면 로컬 호스트 1대로 처리하는 것이 가장 빠르다. (노드간 통신이나 결과를 병합하는 지연 시간(Latency)이 발생하기 때문)

따라서, 분석 속도를 높이기 위해 데이터 웨어하우스에서 필요한 데이터만 데이터 마트로 이동한다.

데이터 마트의 예

데이터 마트의 예는 다음을 포함한다.

  • RDB
  • DWH의 클러스터 규모가 작은 것(RDB 권장)
  • CSV 파일

위에서 볼 수 있듯이 규모가 작고 분석 가능한 데이터 저장소를 나타낸다.

SQL 쿼리 엔진이란?

SQL 쿼리 엔진

SQL 쿼리 엔진은 SQL 이라는 언어로 데이터를 집계하는 엔진이다.

“프로그래밍하지 않고 더 쉽게 데이터를 조작하고 싶다"는 요구에서 SQL 쿼리 엔진이 탄생했다.

SQL 쿼리 엔진의 예

SQL 쿼리 엔진의 특정 소프트웨어 및 서비스는 다음과 같다.

  • ETL
    • ksql DB (Kafka)
    • Apache Flink SQL
  • NoSQL
    • Elasticsearch SQL
    • PartiQL (Dynamo DB)
  • 데이터 레이크
    • Presto
    • Apache Hive
  • 데이터 웨어하우스

BI(Business Intelligence) 도구

BI(Business Intelligence) 도구

BI(Business Intelligence) 도구는 데이터스토어의 데이터를 시각화하는 도구이다.

BI 도구의 예

대표적인 BI 도구는 다음과 같다.

  • Tableau
  • Grafana
  • Kibana(Elasticsearch)
  • QuickSight

데이터스토어 요약

RDB 와 빅데이터 분석 기반에서 자주 이용되는 데이터스토어의 차이를 표로 정리하면 아래와 같다.

RDBNoSQLDWH데이터 레이크

OSS/서비스 Oracle
MySQL
PostgreSQL		 Elasticsearch
Cassandra
Redis snowflake HIVE
Amazon Redshift		 hadoop HDFS
Amazon S3		  
목적 트랜잭션
(OLTP)		 특정 실적 중시 분석(OLAP) 데이터 저장
데이터 구조 정형화 반정형화 정형화
반정형화		 정형화
비정형화
반구조화
스키마 고정 스키마 가변 스키마 고정 스키마 스키마리스
(데이터 카탈로그)

 

Data Pipeline 쉽게 이해하기

우주먼지의하루 2021. 4. 8. 00:02Data Pipeline 개요

IT 서비스를 사용하는 입장에서는 전혀 눈치채지 못하지만 뒤에서는 생성된 데이터를 무사히 저장소에 저장하기 위해 여러 서버 컴퓨터들이 분주하게 일을 하고 있습니다. 데이터를 생성해서 무사히 저장하기까지 일련의 과정을 데이터 파이프라인이라고 합니다.

 

데이터 파이프라인 예시

 

데이터 파이프라인을 큼지막하게 본다면 아래와 같이 나눌 수 있어요.

 

1. 데이터 생성
2. 데이터 수집
3. 데이터 가공 후 저장(ETL)
4. 데이터 시각화(BI)

 

데이터를 저장하는 과정이 복잡한 이유는 데이터가 누수되지 않고 안전하게 저장되게 하기 위해서죠. 실제로 수많은 사용자들을 둔 서비스의 경우 매 초마다 수천, 수만의 데이터가 생성됩니다. 이들이 모두 데이터 저장소(데이터 웨어하우스, 데이터 레이크 등)에 저장되기 위해선 각자의 역할을 가진 컴퓨터들이 협동해야 합니다. 

 

데이터 파이프라인을 구축하기 위해 IT 회사에서는 데이터 엔지니어를 필요로 합니다. 역할 별로 데이터를 처리하는 서버 컴퓨터들을 관리하고 분석할 수 있는 형태로 데이터를 가공하고 시각화하는 작업을 하죠.


소규모의 서비스에는 SAAS 형태의 분석 툴(GA, Amplitude 등)로 충분하지만, 규모가 커지면 데이터 엔지니어가 직접 데이터 환경을 구축하는 게 낫습니다. (경제성, 데이터 정합성 측면 등)

데이터 생성

먼저 데이터의 종류는 두 가지로 나눌 수 있습니다. 서비스 운영에 필요한 서비스 데이터와 서비스에서 발생한 로그 데이터로 구성됩니다.

 

서비스 데이터는 데이터베이스에 논리적으로 저장됩니다.

 

서비스 데이터는 쿠팡을 예로 들면 상품 정보, 고객 정보, 결제 정보 등을 생각하면 됩니다. 이들은 서비스 운영에 꼭 필요한 친구들이고 철저한 보안 관리를 받는 데이터베이스에 저장됩니다. 만일 이 데이터베이스가 해킹 당한다는 건 IT 회사의 생명이 끝나는 것과 다름이 없죠.

 

일반적으로 서비스 데이터는 따로 데이터 파이프라인을 거치지 않습니다. 해당 데이터의 생성 속도가 빠르지 않으며 오히려 데이터의 관리(보안, 성능)에 더 신경을 써야 하기 때문입니다. 그래서 서비스 데이터를 따로 관리하는 직군으로 DBA가 있으며 여러 클라우드 사에서 보안, 성능을 최적화한 데이터베이스 상품을 앞다투어 판매하고 있죠.

 

쿠팡 웹에서는 대부분의 클릭, 스크롤, 경유 시간 등을 전부 로그로 남깁니다.

 

로그 데이터는 서비스를 운영하면서 생기는 모든 행위를 기록(로그)으로 남긴 데이터예요. 유저가 서비스(웹, 앱 등)를 이용하면서 클릭, 스크롤, 머무르기 같은 이벤트가 발생하게 됩니다. 이때 이런 이벤트를 기록한 결과들은 전부 로그 데이터라고 볼 수 있습니다.

 

로그 데이터는 크게 유저들이 서비스(웹, 앱)를 사용하면서 생성되는 클라이언트 로그와 백엔드 서버에서 발생하는 서버 로그로 나눌 수 있어요. 서버 로그는 보통 백엔드 개발자들이 서버에 발생한 이상 징후나 패턴을 찾을 때 사용합니다. 반면 클라이언트 로그는 고객들의 행동을 분석하는 데 사용되기 때문에 다양한 직군이 클라이언트 로그를 활용하게 되죠.

 

업종마다 다르겠지만 IT 회사에서 다루는 데이터 양의 대부분은 로그 데이터가 차지합니다. 한 명의 유저가 웹 사이트나 앱에 잠깐 접속하더라도 적게는 10개 많게는 100개 이상의 로그 데이터가 생성되는데 수천, 수만 명의 유저가 방문한다면 정말 많은 트래픽의 데이터를 견뎌야겠죠?

데이터 생성

데이터를 생성한다는 것은 각 도메인을 맡는 개발자가 데이터를 생성해서 서버로 전송하는 코드를 짠다는 것을 의미합니다. 예를 들어 웹 서비스에서 결제 버튼 클릭을 표현하는 클라이언트 로그를 추가하고 싶다면 프론트엔드 개발자가 코드를 추가합니다. 만일 API 서버에서 회원가입 요청이 얼마나 왔는지 확인하고 싶다면 백엔드 개발자가 코드를 추가해야겠죠. 

데이터 저장소에 따라 각기 다른 데이터 형식으로 생성해야 합니다.

참고로 데이터가 저장되는 서비스에 따라 데이터의 형식이 달라집니다. Google Analytics나 Amplitude 같이 SAAS 형태로 제공되는 분석 툴의 경우 그곳에서 요구하는 데이터 형식에 맞게 코드를 새롭게 짜는 과정이 필요합니다. 만일 서드 파티 툴과 함께 자체적으로 데이터를 관리한다면? 데이터를 관리하기가 더욱 복잡해지겠죠. 그래서 데이터를 생성할 때도 아키텍처를 잘 설계해서 관리하는 게 중요합니다

 

[참고]
요새 데이터 관리를 손쉽게 도와주는 CDP(Customer Data Platform)가 급부상하고 있습니다. CDP를 이용하면 한 번의 데이터 생성만으로 다양한 데이터 저장소에 맞는 형식으로 저장을 합니다

데이터 수집

일반적으로 프론트엔드(웹, 앱)에서 생성된 유저 행동 데이터는 ① SAAS 분석 툴 ② 회사 데이터 수집 서버로 전송됩니다.

 

SAAS 분석 툴의 경우 자주 언급했던 Google Analytics, Amplitude 등의 서비스를 생각하시면 됩니다. 이들은 규격에 맞게 데이터를 전송하면 트래픽에 관계없이 안전하게 데이터를 저장해주는 동시에 분석 & 시각화를 해준다는 장점이 있습니다. 실제로 규모에 상관없이 거의 모든 IT 회사들은 SAAS 데이터 분석 제품을 사용하고 있어요.

 

하지만 여타 SAAS 제품과 동일하게 제공해주는 환경 밖에서는 커스터마이징이 불편합니다. 원하는 형태로 데이터를 가공하고 분석하기에 한계가 있죠. 이들이 관리하는 데이터들을 Export해서 다시 저장하고 가공하는 과정이 여간 귀찮은 게 아닙니다.


또한 Ad Block 같은 광고 차단 프로그램을 사용하게 되면 데이터 전송이 막힐 수 있습니다. 이들은 유저가 사용하는 서비스의 도메인이 아닌 서버의 네트워크 트래픽을 차단하곤 합니다. 그렇게 되면 데이터의 손실이 발생할 수 있겠죠?

 

그래서 규모가 있는 IT 회사에서는 자체적으로 데이터 인프라를 구축합니다. 외부 트래픽 차단 프로그램에서 자유로우며 데이터 손실을 최소화할 수 있게 됩니다. 그렇다고 SAAS 분석 제품을 안 쓰는 건 아니에요. IT 회사들은 거의 대부분은 규모에 따라 무료부터 유료까지 다양한 분석 제품을 혼용해서 사용하고 있습니다.

 

 

수 많은 유저들이 사용하는 서비스에서 발생하는 데이터들은 곧바로 데이터베이스(데이터 레이크 혹은 데이터 웨어하우스 등)에 저장되지 않습니다. 대신 수집 서버를 거치게 됩니다.

 

수집 서버는 데이터가 흐르는 중간 매체(미들웨어)라고 생각하시면 되는데요. 이 수집 서버를 거쳐서 데이터베이스에 저장시키는 경우가 있고 아니면 데이터를 가공하는 서버로 전달하기도 합니다. 보통 데이터의 가공된 정도(비정형, 정형)에 따라 달라집니다.

 

수집 서버는 기본적으로 트래픽을 견딜 수 있도록 견고하게 설계되어야 합니다. 또한 다양한 목적지로 데이터를 전송해주기까지 잘 보관하고 있어야 합니다. 즉 대용량의 데이터를 실시간으로 처리하는 기능이 뛰어나야 하죠. 그래서 데이터 엔지니어가 가장 신경써야 하는 영역 중 하나입니다. 

 

[참고]
개발자가 대표적으로 많이 쓰는 수집 서버 솔루션으로 AWS의 Kinesis, Apache의 Kafka 등이 있습니다. 혹은 개발자들이 더 손쉽게 데이터를 관리할 수 있도록 도와주는 Segment 이벤트 콜렉터도 사용하곤 합니다.

데이터 가공

시간이 지날수록 데이터를 저장하는 디스크(SSD)의 성능이 점점 좋아지고 있으며 클라우드에서도 더 값싸게 데이터를 저장해주는 공간을 제공해줍니다. 그래서 이제 개인도 충분히 원하는 데이터를 저렴한 가격에 저장할 수 있게 됐습니다.

 

IT 회사에서는 정말 많은 데이터들을 저장하고 관리해야 합니다. 회사 내에서는 ERP 같이 사내 데이터를 관리하는 데이터베이스가 필요합니다. 그리고 서비스를 제공하기 위해서 서비스 데이터베이스가 꼭 있어야 하며 사용자들이 서비스를 이용하면서 남기는 클라이언트 로그도 저장해야 하죠. 이 뿐만 아니라 각 서버들의 로그도 남겨야 하고, 3rd party 서비스에서 발생하는 데이터들까지.

 

현재는 데이터 춘추 전국 시대입니다. 데이터 저장을 제공해주는 서비스마다 장단점이 있어 자연스럽게 여러 서비스를 사용할 수밖에 없는 거죠.

 

이렇게 다양한 데이터 소스로부터 데이터를 분석해야 한다면 어떨까요? 예를 들어 '페이스북 광고를 타고 들어와 A 상품을 구매한 고객들이 관심 있어하는 상품들' 을 추출하고 싶다면 어떨까요?  기본적으로 아래와 데이터 소스로부터 데이터를 가져와서 가공하는 작업까지... 

 

1. 페이스북 광고 픽셀 데이터
2. 서비스 데이터베이스(유저, 상품, 결제 데이터)
3. GA 데이터(유저 행동 분석 데이터)

 

이 글을 쓰는 와중에 데이터와 홀연히 싸우고 계시는 데이터 분석가 분들에게 심심한 위로를 보냅니다. 실제로 데이터 분석가는 핸썸하게 SQL로 데이터를 분석하는 일만 하지 않습니다. 정상적으로 데이터를 추출하고 데이터 형식을 통일시키기 위해 수많은 노가다 작업이 포함되어 있죠

 

그래서 데이터가 많은 IT 회사에서는 다양한 데이터 소스의 데이터를 한 곳에 취합하는 작업을 합니다. 그렇게 되면 데이터를 관리하고 분석하는 데에 맨먼스(manmonth)가 확연히 줄어들 겁니다. 

 

ETL

ETL 프로세스

 

다양한 데이터 소스들을 관리하기 쉽게 한 군데로 취합하는 대표적인 프로세스로 ETL가 있습니다. ETL은 Extract, Transform, Load의 약자로 데이터를 가공하는 과정이라고 보시면 됩니다.

 

[참고]
요새는 ETL 프로세스를 자동화하도록 도와주는 SAAS 제품도 늘어나고 있습니다. 대표적으로 FiveTran, Panoply 등이 있으며 더 로우 레벨로 개발하는 대신 확장성이 높은 Airflow도 업계에서 점점 표준이 되고 있습니다. 

 

Extract

산발적으로 흩어져 있는 데이터 소스로부터 데이터들을 가져오기 위해선 추출하는 과정이 필요합니다. 이를 Extract라고 합니다. 보통 클라우드 서비스에서 손쉽게 데이터를 추출하도록 많이 자동화가 되어있는 편입니다.

 

Transform

Transform은 데이터를 가공하는 작업입니다. 여러 데이터베이스에 저장된 데이터는 형식이 각기 다릅니다. 이들을 한 군데로 이쁘게 정렬시키기 위해선 데이터 형식에 맞게 데이터를 변형해주는 작업이 꼭 필요합니다. 또한 회사에서 지향하는 데이터 목적성에 맞게 필터링을 하는 과정도 필요하겠네요. 

이때 가공되기 전의 데이터, 즉 데이터 소스에 저장된 데이터를 비정형 데이터라고 한다면 가공된 데이터를 정형 데이터라고 합니다. 보통 빅데이터라는 키워드의 핵심 중 하나로 비정형 데이터들을 정형 데이터로 가공하는 작업이 있답니다.

 

Load

최종적으로 데이터 변형이 완료됐다면 데이터 웨어하우스에 적재(Load)하는 과정이 남아있습니다. 데이터 웨어하우스는 규칙적(Relational)으로 데이터를 저장하도록 돕는 일종의 데이터베이스로 대용량의 데이터를 관리하기에 최적화된 데이터베이스라고 보시면 됩니다. 

최종적으로 데이터 분석가, 사이언티스트, 머신러닝 엔지니어 등이 데이터 웨어하우스에 저장된 데이터를 사용한다고 보시면 됩니다. 그리고 데이터 웨어하우스에 데이터를 안전하게 적재하는 작업은 데이터 엔지니어가 맡게 되죠.

 

 

ELT?

ELT 프로세스

 

최근에는 ELT 프로세스가 화두가 되고 있어요. 기존에 ETL 프로세스에서 Transform 과정은 생각보다 많은 컴퓨팅 파워(=비용)를 필요로 하며 생각보다 손을 많이 타는 작업이에요. 그래서 데이터를 우선 한 곳에 먼저 적재(Load)한 후 필요에 따라 Transform을 하는 ELT 과정이 인기를 끌고 있습니다. 이때 데이터들을 한 곳에 빠르게 저장하는 공간을 데이터 레이크라고 부릅니다(데이터 웨어하우스에서 비슷한 역할을 제공해주기도 합니다)

데이터 시각화와 분석

데이터 시각화

옛날에는 데이터 시각화를 돕는 프로그래밍 언어 R, SAS 등을 이용해서 데이터를 시각화했습니다(저도 학부생 시절 SAS를 배웠었죠) 하지만 데이터 시각화를 위해 프로그래밍 언어를 직접 배워야 한다는 러닝 커브가 있고 결정적으로 이쁘지 않습니다.

 

데이터가 중요해지면서 데이터 시각화를 편리하게 지원해주는 도구들이 많이 늘었습니다. 이때 데이터 시각화 템플릿과 분석할 수 있는 환경을 제공해주는 도구를 Business Intelligence(BI)이라고 합니다. 대표적으로 Tableau, Power BI, Google Data Studio(무료)가 있습니다. 

 

BI를 사용하면 데이터 소스들(데이터 웨어하우스, 3rd party 데이터(페이스북 픽셀, GA, 등))을 연결시키고 템플릿을 조금만 건들면 손쉽게 데이터 분석 결과를 볼 수 있습니다. 또한 데이터를 분석할 수 있는 도구들을 제공해주며 직접 SQL문으로 분석도 가능합니다.

 

정말 다양한 기능들을 제공해주므로 궁금하신 분들은 한 번 사용해보시는 걸 추천드립니다. 간단한 엑셀 데이터로도 테스트할 수 있습니다.

 

보통 BI를 기존 데이터 소스와 연동하는 것까지 데이터 엔지니어가 책임지게 됩니다. 

 

데이터 분석

보통 회사에서는 데이터를 분석하기 위해 다양한 도구를 활용합니다. BI 툴과 별개로 데이터 분석가가 편하게 데이터를 분석할 수 있는 분석 환경을 구축합니다. 간단한 데이터 분석은 상용화된 서비스로 해결할 수 있지만 결국엔 직접 SQL, Python 등으로 데이터를 추출해야 합니다. 

 

이때 회사에서 데이터를 분석한다는 것은 크게 3가지로 나눌 수 있을 것 같습니다.

 

  • 회사의 다른 팀원이 데이터 분석을 요청해서 SQL문을 이용해 분석 결과를 제공해주는 것
  • 미리 정해진 방식으로 보여주기 위해 대시보드(BI 툴 등)에 시각화하는 것
  • 머신러닝 & 통계학 지식을 바탕으로 모델을 만들고 데이터들을 모델에 넣어서 결과를 얻어내는 것

여기서 데이터는 서비스 핵심 데이터베이스, 빅데이터가 저장되어 있는 데이터 웨어하우스에 저장된 폭넓은 의미의 데이터를 의미합니다.

 

1번째는 데이터 분석가가 담당합니다. 팀원들이 쌓여있는 데이터를 분석하고 싶을 때(지난달 가장 매출이 높은 상품, A라는 상품을 산 고객들이 다음에 산 상품 등) 데이터 분석가는 데이터베이스, 데이터 웨어하우스의 데이터를 가공하고 원하는 결과 값을 얻어냅니다. 

 

2번째 BI는 데이터 엔지니어가 관리합니다. BI는 회사에서 관리하는 데이터들을 시각화해서 보여줍니다. 이번 달 매출, 이번 달에 가장 많은 매출을 낸 상품 등을 대시보드 형태로 만들어 두면 데이터 분석가가 항상 데이터를 보여줄 필요가 없겠죠?

 

[참고]
1,2 번을 같이 작업할 수 있는 직군으로 Analytics Engineer, BI Engineer도 존재합니다. 

3번째는 데이터 사이언티스트 혹은 머신러닝 엔지니어가 맡습니다. 이들은 데이터를 분석하는 모델을 개발합니다. 모델은 머신러닝 & 통계학 기술이 들어가며 데이터들을 넣었을 때 내부 자체 알고리즘을 거쳐서 결과 값을 반환합니다. 왓챠, 넷플릭스 같은 서비스에서 영화를 추천해주는 기술 등이 해당됩니다.

 

Azure로 데이터 파이프라인 이해하기

전체적인 데이터 흐름

 

위의 그림은 전체적인 데이터 흐름입니다. 그림이 제일 잘 나와서 골랐어요~

데이터를 생성하고 수집하는 과정입니다. 

빅데이터 시대니까 정형/비정형 데이터를 모으는 과정,

실시간 데이터 수집,

대량의 데이터를 수집해야하는 등

데이터를 생성하고 수집하는 과정에서도

여러가지 상황이 있기 때문에 기존 데이터 수집에서 고도화 과정이 필요합니다.

 

데이터를 저장하고 처리하는 과정입니다.

다양한 데이터 소스의 데이터를 한 곳에 취합하는 작업입니다.

어떻게 저장하냐에 따라 저장 공간의 차이가 크기 때문에

가장 중요한 단계입니다.

 

보통 클라우드 서비스에서 손쉽게 데이터를 추출하도록 많이 자동화가 되어있는 편입니다.

 

이제 데이터를 활용하는 단계로

데이터를 시각화하고 모델을 개발하는 단계입니다

 

데이터를 어떻게 수집하고 저장하는가에 따라 많이 달라지는 것 같아요

먼저, 누락되는 경우도 없어야 할 것이고

EDA하는 과정에서 데이터를 빠르게 볼 수 있어야하는 등

여러가지 이유가 있겠죠

 

시각화 및 모델을 생성하는 것까지 데이터 파이프라인의 마무리입니다

 

 

반응형
사업자 정보 표시
삼성생명보험(주) | 홍원학 | 서울특별시 서초구 서초대로74길 11(서초동, 삼성전자 서초사옥) | 사업자 등록번호 : 104-81-26688 | TEL : 010-5800-2008 | Mail : 04mailer@samsungfire.com | 통신판매신고번호 : 06577호 | 사이버몰의 이용약관 바로가기

'C.H.A.T.S, 2025 디지털 마케팅 혁명' 카테고리의 다른 글

무연고 개척영업의 고소득 보험고객에게 삼성종합보험의 ‘종합 리스크 솔루션’ 보험영업을 잘하는 법  (0) 2025.04.24
챗GPT의 고급 데이터 분석 기능을 완벽하게 정리하고, 실무에서 유용하게 활용할 수 있는 다양한 사례와 팁을 제공  (5) 2025.04.23
ChatGPT 효과적인 사용을 위한 프롬프트 작성 공식 안내  (7) 2025.04.23
보험이 인공지능을 만난다 '보험-AI 기술 융합 컨퍼런스' 개최 - AI, 실제로 이렇게 사용된다🤖 보험 업계의 AI 활용 사례  (3) 2025.04.02
챗GPT 능력 100% 활용 꿀팁 요약  (0) 2025.03.29

'C.H.A.T.S, 2025 디지털 마케팅 혁명'의 다른글

  • 현재글컨테이너 환경의 CI/CD 전략 - 데이터 파이프라인 기본 원리와 원칙은 시간이 지나도 유효 - 빅데이터 분석 기반이란? 데이터 파이프라인 구축

관련글

티스토리툴바