Computer Engineering/DataPlatform

SaaS의 홍수 시대에서 Data Warehouse/Lake 구축은 어떻게 해야 할까?

jordan.bae 2020. 5. 17. 15:34

지금은 바야흐로 SaaS의 시대이다. 

 

 

출처: https://www.blendr.io/add-native-integrations/

 

각 분야 별 대표 서비스 (사실 내가 들어본 각 분야별 서비스)

Cloud Infra: AWS, Azure, GCP, Alibaba

CRM: Salesforce, Hubspot CRM, ActiveCampaign 등

Marketing: Marketo, Hubspot, Mailchimp 등

CS: Zendesk, Sendbird Desk, Freshdesk

HR: BambooHR, Workday

Hiring: Lever, Greenhouse

Payment: Stripe, PayPal

 

이런 수많은 SaaS들이 나오면서 여러 SaaS의 구독을 관리하는 서비스가 나오기도 하고, 여러 SaaS 간의 통합과 연결할 수 있는 기능을 각 서비스에서 지원하고 있는 추세이다.

한국 회사들은 아직 그렇게 많은 SaaS를 사용하는 편은 아닌 것 같지만 대부분의 미국 회사들은 최소 10개 이상의 SaaS를 사용하고 있는 것으로 알고 있다.

내가 다니고 있는 Sendbird에서도 AWS, Salesforce, Marketo, Greenhouse, BambooHR, GA, Jira, StatusPage 등 수많은 외부 서비스를 사용하고 있다.

작년에 회사에 입사해서 지금까지 외부 서비스들과 Product metric들에 대한 데이터들을 통합하는 작업을 하게되었고, 이 경험을 조금 적어 볼까 한다.

 

왜 이렇게 많은 서비스를 쓰고 있냐고 물어보는 사람들도 있겠지만, 많은 서비스들을 internal로 개발 하기에는 개발 인력은 충분히 비싸고 부족하다. 

개발자의 관점에서 생각해보면 AWS같은 Cloud 서비스를 쓰는 것과 마찬가지이다. 

또, 이미 Marketing이나 Sales, HR 분들도 높은 수준의 서비스들을 이미 사용한 경험을 가지고 계시고 있기 때문에 회사가 엄청 크지 않은 이상 그들이 만족할 수 있는 내부 서비스를 만들기가 힘들다.

 

 

왜 데이터를 통합해야 할까?

각 서비스에서도 이미 많은 metric들과 analysis 툴들을 제공하지 않나요?

그렇다! 하지만, 전체 데이터를 통합해서 metrics을 만들었을 때 더 유의미한 insight를 얻을 수 있다.

예를 들어, 매출 데이터는 Salesforce에 있고, 회사의 인원에 대한 정보는 BambooHR에 있다고 하자. 회사 경영진은 1인당 매출액이나 1인당 영업이익을 알고 싶어 한다.

그런 경우 Salesforce나 BambooHR 각각에서 이런 데이터를 만드는 것은 쉽지 않다. 하지만 하나의 데이터 저장소에 통합하면 쉽게 데이터를 합쳐서 거의 실시간으로 1인당 매출액과 같은 Metric을 볼 수 있다.

여러 데이터들을 통합해서 훨씬 유의미한 Metric이나 인사이트를 얻을 수 있기 때문에 여러 외부 서비스에서 회사의 데이터 웨어하우스나 데이터 레이크에 데이터를 통합하는 작업이 필요해진다.

 

 

어떻게 데이터를 통합할까?

직접 여러 서비스로부터 데이터를 가져와서 파이프라인을 구성하려면 많은 비용이 들어간다. 

각각의 서비스의 스키마를 이해하고 있어야 하기도 하고, 각각의 Schema가 변경되는 것 또한 capture 할 수 있는 데이터 파이프라인을 개발해야 하기 때문에 각각의 서비스에 대한 이해가 필수다.

세일즈포스 같은 경우는 커스텀으로 수많은 필드를 만들어 낼 수 있고, API 종류만 3가지가 넘어서 이것들을 요리조리 잘 써야 한다. 

외부 서비스가 하나 혹은 두 개라면 괜찮겠지만, 통합해야 하는 소스가 10개라고 하면 데이터 파이프라인을 개발하고 유지보수하는 데는 많은 리소스가 필요하다.

죽으라는 법은 없다. SaaS의 시대다! 우리에게는 ETL 서비스가 있다. 회사에서 사용하는 모든 서비스를 지원하는 ETL 서비스는 없을 수 있지만 많은 서비스의 ETL을 지원하는 서비스들이 있다.

특히, 대표적인 서비스들은 대부분 connector를 지원하고 있다. 

여러 회사에서 이런 Needs가 있기 때문에 이런 외부 서비스들의 Data Integration을 위한 ETL 서비스가 존재하고, 대부분의 큰 서비스들 또한 REST API나 Export만 제공하는 것이 아니라 그들과 협력해서 고객들에게 데이터를 가져갈 수 있도록 돕고 있다.

요즘은 ETL 서비스로 데이터를 가져갈 수 있는지 여부 또한 외부 서비스를 선택할 때 생각하는 부분이 되었다.

 

 

아래는 Fivetran이라는 ETL 서비스에서 제공하는 Connector 목록 중 일부이다. 수많은 외부 서비스들이 있다.

(Fivetran은 현재 100개가 넘는 connector를 제공 중이다.)

 

 

출처: https://fivetran.com/directory

 

 

ETL Service란? (DTS, Data Transfer Service 라고도 불림)

말 그대로 ETL(Extract - Transform - Load, 요즘은 Data Lake가 대세가 되면서 작업 순서가 바뀌어서 ELT라고도 많이 부른다.)를 도와주는 서비스이다.

ETL 서비스를 간략하게 소개하면 특정 Service(Salesforce, Marketo, GA, Linkdin Ads, Facebook, Zen Desk, Greenhouse) 뿐만 아니라 MySQL, MariaDB, S3 등 여러 데이터 소스로부터 Destination(Data 저장소: Big Query, Snowflake, Redshift, S3, 여러 RDBMS)으로 ETL을 해주는 서비스이다. 아직 대부분은 Streaming ETL을 지원하지는 않지만 Batch로 여러 데이터 소스로 부터 데이터를 통합할 수 있다. 보통 Source마다 ETL 방법이 다르고, API를 이용하는 경우도 있고 CDC(Binary log)를 이용하는 경우도 있다.

(아직 Transformation기능은 훌륭한 편이 아니 기고 하고 Product 데이터나 지원하지 않는 Source로부터 데이터도 있기 때문에서 Transformation에 대한 파이프라인은 직접 구성하는 것이 좋다고 생각한다.)

 

 

아래는 Segment에서 ETL 서비스를 소개하는 데 사용한 그림이다.

 

 

어떤 ETL Service가 있을까?

대표적인 ETL 서비스 몇 개를 소개하면 아래와 같은 서비스들이 있다. 이 밖에도 많은 서비스가 있으니 관심 있으신 분들은 찾아보시길..!

 

   - Fivetran ( https://fivetran.com/ )

   - Segment (https://segment.com/)

   - Stitch (https://www.stitchdata.com/)

 

Fivetran vs Stitch

https://www.g2.com/compare/fivetran-vs-talend-stitch

Fivetran과 Segment 그리고 Stitch 비교 글.

(조금 오래된 글이라 현재 각 서비스의 스펙과는 차이가 있다.)

https://www.stephenlevin.co/segment-vs-fivetran-vs-stitch-which-data-ingest-should-you-use/

 

 

그래서 당신은 어떤 서비스를 쓰고 있나요?

현재 나는 회사에서는 Fivetran이라는 서비스를 사용하고 있다. 그 당시에 회사 내에 사용하고 있던 서비스들 중에 가장 많은 Connector를 제공하는 서비스 이기고 하고 Data masking 등 security와 관련된 기능도 제공되어서 선택하게 됐다.

각자 회사의 Needs나 상황에 따라서 여러 서비스 중에 회사에 잘 맞는 서비스를 선택하면 됩니다.

 

이제 ETL 서비스를 통해서 대부분의 Service를 통합했고, 일부 제공되지 않는 서비스는 API를 통해서 직접 통합을 했다고 하자. 

이제 Metric을 바로 만들면 될 것 같지만, 현실은 그렇지 않다. 

 

아직 고민해야 할 부분들이 많다.

 

외부 서비스 데이터의 Integrity 및 운영

 

데이터를 보면 Metric을 만들기 위해서 스키마가 설계가 되지 않은 경우도 많고, 데이터의 Integrity가 문제가 있는 경우도 많다. 하지만, 통합을 했기 때문에 다른 외부 서비스들의 데이터에 문제가 있다는 것을 알 수 있는 것이다..!

이제 데이터를 통합해서 문제점을 찾았으니 앞으로 어떻게 외부 서비스들에서 양질의 데이터를 생성할 수 있도록 운영할 수 있을지 governance 역할을 해야 한다. 서비스는 많고 각 서비스의 유저는 빠르게 기능을 추가하고 싶어 한다. (아주 큰 challenge다.)

 

기존에 직접 Data Pipeline을 구축해서 ETL 하는 데이터들과의 Orchestration

 

데이터 서비스를 통해서 데이터를 가져오는 데이터들만 있는 것이 아니라 직접 데이터 파이프라인을 구축해서 데이터를 쌓는 데이터들도 있고, 이들 간에 합쳐서 transformation이 필요한 경우도 많다.

이 데이터 소스들 간의 데이터 파이프라인 orchestration을 고민해야 한다. 

 

작업을 하면서 여러 데이터 소스들을 통합하면서 여러 SaaS 서비스들의 데이터베이스 모델링이 어떻게 되어 있나 보는것은 꽤나 흥미로운 포인트였다. 여러 데이터로 많은 Metric을 만들면서 어떻게 모델링을 해야 데이터를 통해 효율적으로 Metric들을 만들 수 있는지 배워나가고 있다. 

 

 

다음 글에서는 회사에서 BI Tool로 Looker를 구축했던 경험을 써볼까 합니다.

혹시, 관심있으신 분은 왼쪽 하단에 구독을 누르시면 쉽게 소식을 받으실 수 있습니다.

읽어주셔서 감사합니다.

 

반응형