주요 컨텐츠로 이동
솔루션

Lakebase를 사용하여 원활하고 비용 효율적인 마케팅 캠페인을 잠금 해제하세요

Databricks Lakebase Postgres가 SAP Engagement Cloud와 같은 옴니채널 마케팅 플랫폼을 위한 저지연 고객 세그먼트 제공을 지원하고, 서버리스 자동 확장 및 네이티브 Lakehouse 통합을 통해 TCO를 획기적으로 절감하는 방법

작성자: Thomas Nguyen

  • Lakebase Postgres는 서버리스 OLTP 데이터베이스로, 마케팅 캠페인 급증 시점 사이에 0으로 축소되어 개인화 워크로드에서 흔히 발생하는 미사용 데이터베이스 리소스 비용을 제거합니다.
  • 네이티브 동기화 테이블은 Lakehouse-to-OLTP 파이프라인 구축 및 유지 관리의 부담을 덜어주어 마케팅 팀이 몇 번의 클릭만으로 SAP Engagement Cloud와 같은 플랫폼에 새로운 고객 세그먼트를 배포할 수 있도록 합니다.
  • Lakebase는 스토리지와 컴퓨팅을 분리하므로 고객 속성의 폭과 깊이가 컴퓨팅을 선형적으로 확장하지 않고도 성장할 수 있어, 더 풍부한 개인화를 가능하게 하면서 비용을 일정하게 유지합니다.

최근 Deichmann은 Lakebase가 원활한 옴니채널 마케팅을 지원한 방법을 설명하는 고객 사례를 발표했습니다. 이 블로그에서는 해당 사례의 기술적인 측면을 다룹니다.

모든 소매 회사는 개인화되고 성능이 뛰어난 마케팅 캠페인을 제공하기 위해 데이터를 활용해야 합니다. 그럼에도 불구하고 업계 전반에 걸쳐 몇 가지 비효율성이 관찰됩니다.

  • 기업은 활용도가 낮은 데이터베이스 리소스에 비용을 지불합니다. 개인화된 캠페인에 사용되는 고객 세그먼트는 마케팅 도구가 읽는 OLTP 데이터베이스에 저장되는 경우가 많습니다. 마케팅 캠페인이 시작될 때 데이터베이스 요청이 급증하지만, 그 외 시간에는 데이터베이스 활용도가 낮습니다.
  • 마케팅 팀의 변화하는 요구 사항은 데이터 팀에 운영 부담을 줍니다. 데이터 실무자는 Lakehouse에서 새로운 고객 세그먼트를 생성하며, 마케팅의 모든 새로운 요청은 Lakehouse-to-OLTP 파이프라인 동기화 패키지를 생성, 유지 및 모니터링해야 합니다.

Lakebase는 트랜잭션 데이터베이스의 최상의 요소와 데이터 레이크의 유연성 및 경제성을 결합한 새로운 개방형 아키텍처입니다. Databricks Lakebase Postgres는 Lakebase 아키텍처의 구현으로 이러한 문제를 해결합니다.

  • 스토리지와 컴퓨팅을 분리함으로써 데이터는 컴퓨팅을 선형적으로 확장할 필요 없이 객체 스토리지에 저렴하게 저장될 수 있습니다. 이는 고객 속성의 수와 다양성이 컴퓨팅 리소스를 추가로 요구하지 않고도 크게 증가할 수 있음을 의미합니다. 데이터는 증가하지만 데이터베이스 트래픽은 증가하지 않으므로 Lakebase 비용은 기존 OLTP 데이터베이스보다 낮게 유지됩니다.
  • 탄력적인 서버리스 Postgres 컴퓨팅으로 구동되는 Lakebase는 수요에 따라 즉시 확장되고 유휴 상태일 때는 1초 미만으로 축소됩니다. 비용은 사용량과 직접적으로 일치하므로 예약된 마케팅 캠페인과 같은 버스티 워크로드에 이상적입니다. Lakebase 고객은 필요한 리소스에 대해서만 비용을 지불하므로 비용을 절감하고 사전에 컴퓨팅 용량을 계획할 필요가 없습니다.
  • Lakehouse와 원활하게 통합함으로써 Lakebase와 Lakehouse 간의 동기화는 완전히 관리되고 안정적이며 효율적이어서 데이터 실무자의 파이프라인 생성 및 유지 관리 부담을 덜어줍니다.

Lakebase와 Lakehouse 간의 동기화

Lakebase와 SAP Engagement Cloud 통합

마케팅 캠페인 플랫폼의 백엔드 데이터베이스로 Lakebase를 사용하는 이점을 설명하기 위해 Lakebase를 옴니채널 마케팅 플랫폼인 SAP Engagement Cloud와 통합하고 Lakehouse에서 이전에 생성된 고객 세그먼트를 기반으로 개인화된 마케팅 캠페인을 시작하는 방법을 보여드리겠습니다.

1단계: 새 Lakebase 프로젝트 생성 및 구성

새 Lakebase Autoscaling 프로젝트를 생성하여 Postgres 인스턴스를 설정합니다. 프로젝트는 데이터베이스 리소스의 최상위 컨테이너입니다. 새로 생성된 프로젝트에는 SAP Engagement Cloud가 연결할 PostgreSQL 인스턴스인 프로덕션 데이터베이스가 포함됩니다.

마케팅 캠페인은 시간 기반 트리거에 의존합니다. 캠페인이 트리거되면 SAP Engagement Cloud는 데이터베이스를 쿼리하여 지정된 기준을 충족하는 잠재 고객을 검색합니다. 이러한 메커니즘은 확장된 낮은 기간 동안 주기적인 스파이크를 유발합니다. 이러한 이유로 컴퓨팅의 경우 확장된 낮은 기간 동안 0으로 확장하여 해당 기간 동안의 컴퓨팅 비용을 제거하고 스파이크에 대한 최대값으로 16 CU (~32 GB RAM)의 중간 용량을 설정합니다. 선택한 메모리 범위가 비교적 크더라도 Lakebase 자동 확장 속도와 반응성은 리소스 부족의 위험을 제거하여 TCO를 낮추고 데이터베이스 용량 계획 및 프로비저닝의 필요성을 줄입니다.

Lakebase와 SAP Engagement Cloud 통합

Lakebase 컴퓨팅이 설정되면 SAP Engagement Cloud에 필요한 역할을 생성해야 합니다. Lakebase는 Databricks ID에 대한 OAuth 역할과 네이티브 Postgres 암호 역할을 지원합니다. Engagement Cloud는 OAuth 역할에 대한 시간별 토큰 회전을 처리할 수 없으므로 네이티브 Postgres 역할을 사용합니다. Postgres 역할은 다양한 방법으로 생성할 수 있습니다. Lakebase UI를 사용하여 높은 엔트로피 암호를 생성합니다. 암호를 즉시 캡처하여 비밀 관리자에 저장합니다. 정기적인 일정에 따라 새 암호를 생성하여 암호를 회전하는 것이 좋습니다.

그런 다음 Lakebase SQL 콘솔에서 이러한 명령을 실행하여 동기화된 고객 세그먼트에 사용되는 스키마에 대해 새로 생성된 SAP Engagement Cloud Postgres 역할에 필요한 권한을 부여합니다.

2단계: SAP Engagement Cloud를 Lakebase에 연결

SAP Engagement Cloud는 PostgreSQL 인스턴스에 연결하기 위해 CA 인증서가 필요합니다. Lakebase는 Let's Encrypt에서 발급한 인증서를 사용하므로 필요한 루트 인증서는 ISRG Root X1입니다.

다음과 같이 루트 인증서를 얻을 수 있습니다.

내보낸 인증서를 검사하여 올바른지 확인할 수 있습니다.

SAP Engagement Cloud에서 새 PostgreSQL 연결을 구성할 때 CA 인증서에 대한 프롬프트가 표시되면 이 파일의 내용을 붙여넣습니다.

3단계: 고객 세그먼트를 Lakebase와 동기화

연결 및 역할이 생성되었으므로 Lakehouse에서 Lakebase로 고객 세그먼트를 동기화할 수 있습니다. 이를 위해 동기화할 테이블에서 동기화된 테이블을 생성해야 합니다. Databricks Synced Tables는 Lakebase에서 Unity Catalog 데이터의 관리 복사본을 생성하여 OLTP 스타일의 저지연 쿼리가 필요한 애플리케이션에서 사용할 수 있도록 합니다.

스냅샷, 트리거, 연속 등 여러 동기화 모드를 사용할 수 있습니다. 우리의 경우와 마찬가지로 고객 세그먼트는 종종 야간에 일괄 처리로 다시 계산되어 데이터 세트의 상당 부분을 대체합니다. 데이터의 10% 이상이 업데이트될 때 스냅샷 모드를 권장하며, 이는 트리거 모드보다 10배 더 나은 성능을 제공합니다. 거기에서 관리되는 파이프라인이 생성되고 데이터가 동기화됩니다. 이제 몇 번의 클릭만으로 새로운 고객 세그먼트를 Engagement Cloud에서 사용할 수 있게 되어 시장 출시 시간을 단축하고 운영 부담을 줄입니다.

고객 세그먼트를 Lakebase와 동기화

또한 Lakebase의 컴퓨팅 및 스토리지 분리로 인해 Engagement Cloud에서 사용할 수 있는 데이터의 크기와 다양성은 클래식 데이터베이스와 같이 컴퓨팅 리소스를 확장할 필요 없이 증가할 수 있어 비용을 낮게 유지합니다. 그럼에도 불구하고 Databricks Lakebase는 대규모 스캔 또는 클래식 OLAP가 아닌 고차 동시성 포인트 조회 및 짧은 OLTP 쿼리에 최적화되어 있다는 점을 명심하는 것이 중요합니다.

운영 데이터를 Lakehouse와 동기화

생성된 고객 세그먼트 외에도 마케팅 캠페인은 다른 애플리케이션의 데이터를 통합할 수 있습니다. 예를 들어 고객은 특정 카테고리 또는 브랜드의 제품 재입고 또는 신상품 알림 수신에 동의할 수 있습니다. 애플리케이션은 Lakebase를 표준 Postgres 데이터베이스로 사용하여 이 알림 데이터를 저장하고 캠페인 타겟팅을 위해 Engagement Cloud에서 사용할 수 있도록 할 수 있습니다. Lakebase에 기록된 모든 데이터는 Lakehouse Sync를 통해 분석을 위해 Lakehouse와 동기화될 수 있습니다. Lakehouse Sync는 Lakebase Postgres에서 Unity Catalog Delta 테이블로의 네이티브 연속 CDC 기반 파이프라인으로, 운영 데이터를 더 풍부한 분석 및 AI에 사용할 수 있도록 합니다.

성능 최적화

Lakebase는 Postgres이며 클래식 Postgres 데이터베이스와 유사하게 성능을 최적화할 수 있습니다.

인덱스 구축은 가장 쉽고 영향력이 크며 일반적인 최적화 중 하나입니다. 마케팅 캠페인이 트리거되면 SAP Engagement Cloud는 WHERE 절로 필터링된 고객 ID를 검색하는 쿼리를 실행합니다.

이 필터링 조건을 기반으로 인덱스를 생성합니다. Lakebase SQL 콘솔에 다음을 작성하여 Lakebase에서 인덱스를 생성할 수 있습니다.

SAP Engagement Cloud의 경우, 인덱스로 이미 필요한 성능을 얻을 수 있어야 합니다. 추가 최적화가 필요한 경우, 먼저 pg_stat_statements를 사용하거나 쿼리 성능과 데이터베이스 모니터링 지표 세트를 제공하는 Databricks Lakebase UI를 사용하여 가장 길고 가장 빈번한 쿼리를 식별해야 합니다.

Monitoring

가장 길고 가장 문제가 되는 쿼리는 다음을 사용하여 분석할 수 있습니다:

PREFETCHFILECACHE 는 Lakebase에 특화되어 있으며, 각각 발행/히트/낭비된 프리페치 요청 수와 로컬 파일 캐시(LFC) 대비 히트/미스를 보여줍니다. Databricks Lakebase UI는 이러한 분석을 실행할 수 있는 편리한 인터페이스도 제공합니다.

SQL Editor

여기서 다음과 같은 추가 최적화 옵션을 탐색할 수 있습니다:

  • work_mem 구성 변경 - 더 큰 컴퓨팅을 위해 256MB로 늘리면 유익할 수 있습니다.
  • 높은 변경률을 가진 테이블에서 autovacuum_vacuum_scale_factor를 낮게 조정하고, pg_stat_user_tables로 블로트를 확인하세요.

결론

Lakebase는 고유한 기술과 Lakehouse와의 긴밀한 통합을 통해 분석 및 AI 워크로드로 생성된 고객 세그먼트의 저지연 서비스를 제공할 수 있습니다.

Lakebase는 리소스가 사용되지 않을 때 공격적으로 자동 확장하고 제로로 확장하여 유휴 리소스 비용을 제거함으로써 TCO를 크게 줄입니다.

Lakebase의 Lakehouse 통합은 동기화 파이프라인 유지 관리의 운영 부담을 제거하고, 새로운 고객 세그먼트의 시장 출시 시간을 단축하며, 더 개인화된 마케팅 캠페인을 가능하게 하여 더 짧은 시간 내에 더 큰 참여를 유도합니다.

마케팅 스택을 현대화할 준비가 되셨나요? 지금 Databricks Lakebase Postgres를 사용해보고 서버리스 OLTP와 Lakehouse의 결합이 TCO를 절감하고 캠페인 제공을 가속화하는 방법을 확인하세요. Databricks Lakebase 제품 페이지를 방문하거나, Deichmann 고객 사례를 읽거나, 마케팅 캠페인 워크로드에 맞는 개념 증명 범위를 정하기 위해 Databricks 계정 팀에 문의하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

최신 게시물을 이메일로 받아보세요

블로그를 구독하고 최신 게시물을 이메일로 받아보세요.