공지
주간 SaaS 의 발전을 위해 설문조사에 참여해 주세요!

멀티테넌시 모델 기반의 사용자 관리 개선 사례

Doordash의 멀티테넌시 모델 도입 사례

2023.11.21 | 조회 1.09K |
0

주간 SaaS

B2B SaaS 비즈니스 모델과 멀티 테넌트 아키텍처 설계에 관한 좋은 콘텐츠를 소개합니다.

안녕하세요. 주간SaaS 입니다. 오늘은 음식 배달 플랫폼을 제공하는 미국의 도어대시(Doordash)가 비즈니스를 확장하면서 멀티 테넌시를 기존의 시스템에 적용한 사례를 소개 합니다.

Doordash는 우리의 배민, 쿠팡이츠와 비슷한 서비스를 제공하다 2022년 2월 Storefront 라는 서비스를 런칭합니다. Storefront를 통해 레스토랑들이 자체 웹사이트를 구축하고 음식 픽업 및 배달 서비스를 제공할 수 있게 됩니다. 일종의 레스토랑판 네이버 스토어팜 이라고 해야할까요. 이런 비즈니스의 확장에 따라 자연스럽게 User와 Tenant 모델링에 대한 고민이 생겼던것 같습니다.

오늘 소개하는 Doordash의 글은 기존 사용자와 새로운 비즈니스를 위한 테넌트 간의 데이터 모델 수립 그리고 애플리케이션에 적용하는 접근 방법을 쉽게 설명 합니다. 간단한 내용이지만 멀티테넌트 설계시 핵심적인 내용 이기도 합니다.

사용자와 테넌트 관계를 모델링하고 이를 서비스에 주입(Injection)하는 문제로 고민하는 분들께 도움이 되었으면 좋겠습니다. 그럼 오늘도 좋은 하루 보내세요!


DoorDash가 제품 라인을 확장하고 성장함에 따라 사용자 데이터를 관리할 수 있는 더 나은 방법을 찾아야 했습니다. 판매자(Merchants)에게 맞춤형 온라인 주문 솔루션과 배송 실행을 위한 Dasher 네트워크를 제공하는 DoorDash의 Storefront 제품에서는 고객이 새로운 가입 없이 게스트로 결제할 수 있지만 결제할 때마다 결제 및 주소 정보를 제공해야 하는 부정적인 사용자 경험을 감수해야 했기 때문에 사용자 데이터를 관리할 수 있는 보다 나은 방법이 필요했습니다. 이를 해결하기 하는데 있어 기술적인 문제는 중복 사용자를 유지할 수 없다는 것이었는데, 이는 기존 DoorDash 계정이 있는 고객이 동일한 정보로 Storefront merchant 사용 계정을 만들 수 없다는 것을 의미했습니다. 이러한 사용자 데이터 관리 문제를 해결하기 위해 기존 코드베이스와 인프라에 멀티 테넌시(Multitenancy) 개념을 도입하여 민감한 사용자 데이터를 관리하는 방식을 변경하고 고객의 사용자 경험을 개선했습니다.

게스트 결제의 과제

고객들은 맞춤형 온라인 주문 UI를 제공하지만 DoorDash의 백엔드 인프라를 기반으로 하는 Storefront 판매자 중 한 곳에서 음식을 주문할 때마다 매번 개인 정보(예: 연락처, 결제)를 입력해야 했습니다. 몇 번 주문하고 나면 이 과정이 길고 지루하게 느껴집니다. 고객이 같은 매장에서 다시 쇼핑을 하러 오더라도 다시 정보를 입력해야 했습니다. 또한 재주문 추천이나 주문 경험을 개선할 수 있는 기타 개인적 기록들이 표시되지 않아 주문과 관련한 개인화된 경험을 제공하기에도 부족했습니다.

고객들이 느낄 이러한 마찰로 인해 많은 Doordash 고객, 심지어 판매자의 충성도 높은 고객까지 결제 중에 이탈하여 재주문율이 감소했습니다. 궁극적으로 저희는 고객들이 자주 이용하는 판매자 Storefront에 계정을 생성하여 정보를 반복적으로 재입력할 필요가 없고 보다 개인화된 경험을 제공 받을수 있도록 만들고 싶었습니다.

사용자 데이터 영구 저장에 내재된 데이터 문제

이 문제를 해결하는 데 있어 가장 어려운 과제 중 하나는 기존 사용자 데이터 테이블이 중복 사용자를 허용하지 않는 것이었는데, 이는 두 명의 사용자가 동일한 이메일을 가질 수 없다는 제약 조건에 의해 발생했습니다. Stroefront 제품 관점에서 볼 때, 동일한 이메일 주소와 전화번호를 가진 중복 계정이 생성되기 때문에 사용자가 선호하는 판매자들과 각각 연결된 여러 계정을 만들 수 있도록 지원할 수 없었습니다. 또한 Storefront 계정은 기존 DoorDash 계정과 중복될 수 있습니다. 향후 Doordash의 해외 확장 목표를 고려할 때, 명확한 사용자 데이터 분리를 선호하는 GDPR 요건을 위반하지 않도록 주의해야 했습니다.

멀티 테넌시의 필요성

멀티테넌시는 하나의 소프트웨어 애플리케이션과 이를 지원 인프라가 여러 고객 세그먼트(테넌트라고도 함)에 서비스를 제공하도록 설계된 아키텍처 패러다임입니다. 저희는 멀티 테넌시 모델을 채택하고 각 비즈니스 업종(예: Doordash marketplace vs. Storefront vs. Drive)에 대해 별도의 데이터베이스를 도입하여 데이터 문제를 해결했습니다. 각 업종은 L0 테넌트로 간주할 수 있으며, 이는 더 큰 단위로의 데이터 분리를 나타냅니다. 또한, 멀티 테넌트는 각 데이터베이스 내에서 논리적 분리를 적용하여 L0 테넌트 내에서 데이터를 더욱 세분화/라벨링할 수 있도록 했습니다. 즉 이 보다 세분화된 데이터 분할은 Storefront의 경우 판매자를 나타내는 L1 테넌트라고 부르는 것으로 구성됩니다. 이러한 멀티 테넌시 개념을 사용하여 이러한 데이터 분리 모델을 기존 DoorDash 엔지니어링 에코시스템에 통합하여 Storefront의 비즈니스 문제를 해결하고 향후 유연성을 확보할 수 있었습니다.

그림 1: L0 테넌트는 서로 다른 비즈니스 업종을 기반으로 하며, L1 테넌트는 업종 내 데이터베이스 구분(divisions)을 의미 합니다
그림 1: L0 테넌트는 서로 다른 비즈니스 업종을 기반으로 하며, L1 테넌트는 업종 내 데이터베이스 구분(divisions)을 의미 합니다

DoorDash의 코드에 멀티테넌시를 적용한 방법

Storefront의 비즈니스 요구 사항을 해결하기 위해 사용자 인증 플로우를 구축하여 사용자가 판매자당 하나의 계정을 생성하고 판매자의 매장을 다시 방문할 때 사용자 데이터를 미리 입력할 수 있도록 했습니다. 이메일 주소를 기본 식별자로 사용하는 대신 비밀번호가 필요 없는 인증 프로세스를 목표로 전화번호를 사용했습니다. 또한 DoorDash 사용자 데이터와 유사한 방식으로 Storefront 사용자 데이터를 처리했습니다:

  • 데이터에 대한 사용자 제어권 유지
  • 적절한 제약 조건으로 데이터 무결성 유지
  • 서로 다른 업종 간의 데이터 혼용 방지

이러한 요구사항에 따라 데이터를 처리하기 위해 멀티테넌시는 Storefront와 기존 DoorDash의 Marketplace/Caviar 사용자를 분리하고 여러 Storefront 판매자 간에 중복된 전화번호/이메일을 허용하는 두 가지 문제를 해결하는 데 도움이 되었습니다. 그리고 또한 멀티 테넌시를 시스템에 통합하는 데는 몇 가지 단계가 필요했습니다:

  1. 먼저 파트너 팀의 도움을 받아 Storefront 업종(L0 테넌트)을 위한 새 데이터베이스를 생성하고 모든 사용자 관련 테이블에 Tenant ID(L0 및 L1 테넌트를 모두 포함하는 문자열)라는 새 열을 추가했습니다. 이 단계에서는 더 큰 L0 분리 수준과 더 세분화된 L1 구분(division)을 모두 도입합니다.
  2. 그런 다음 사용자의 request header로부터 전달된 L0 테넌트(Tenant ID의 첫 번째 부분)를 기반으로 사용자 관련 쿼리를 올바른 데이터베이스로 라우팅하는 로직을 추가했습니다. 이를 조금 더 자세히 설명하기 위해 테넌트 ID를 아래 코드 샘플과 같은 형식의 문자열로 정의했습니다. 이 경우 "<비즈니스 업종>:<엔티티/Merchant ID>"로 나타났는데, 이 값을 통해 사용자 request에서 상위 업종(L0 테넌트)과 보다 세분화된 구분자(L1 테넌트/서브테넌트)를 도출할 수 있습니다.
    "<L0 tenant>:<L1 tenant>"
  3. 또한 이 Tenant ID 값을 서비스 Storefront 호출 체인 전체에 걸친 request header에 포함시켰습니다.
  4. 마지막으로 사용자 테이블의 고유성 제약 조건이 전화번호/이메일이 아닌 (전화번호/이메일, Tenant ID) 쌍에 적용되도록 변경했습니다. 이렇게 하면 사용자가 동일한 전화번호로 서로 다른 판매자에게 여러 계정을 만들 수 있지만, 판매자마다 Tenant ID가 다르기 때문에 데이터베이스 레벨에서 문제가 발생하지 않습니다. 따라서 사용자는 동일한 전화번호로 선호하는 각 판매업체에 로그인할 수 있지만, 시스템에서는 각각을 별도의 Merchant 계정으로 등록되는 셈입니다.
그림 2: 저희 솔루션은 멀티테넌트 데이터베이스 탐색을 포함하여 사용자 관리 서비스에 도달할 때까지 여러 서비스를 통해 Tenant ID를 전달합니다
그림 2: 저희 솔루션은 멀티테넌트 데이터베이스 탐색을 포함하여 사용자 관리 서비스에 도달할 때까지 여러 서비스를 통해 Tenant ID를 전달합니다

결론

동시에 여러 계정을 지원하는 것은 기업이 고객을 유지하고 고객 경험을 개선/개인화하고자 할 때 흔히 발생하는 문제입니다. 또한 GDPR과 같은 규정 준수 요건을 고려할 때 데이터 분리 및 라벨링의 중요성이 더욱 커지고 있습니다. 따라서 여러 제품을 제공하는 기업의 경우 민감한 사용자 데이터가 복잡해질 수 있습니다. 시간이 지남에 따라 제품 라인이 늘어남에 따라 새로운 데이터 저장 및 처리 프로세스를 마련하는 것은 반드시 건너야 할 다리입니다.

이 글에서 설명하는 멀티테넌시 솔루션은 사용자를 위한 여러 계정을 지원하거나 사용자 관리를 전반적으로 개선하기 위해 실용적이고 실현 가능한 솔루션을 원하는 분들에게 유용한 방법입니다. 이 솔루션은 지나치게 복잡한 기술이나 외부 시스템과의 통합을 필요로 하지 않습니다. 대신 기존 서비스에 이미 구축되어 있는 기능을 살펴보고 그것을 기반으로 확장 가능한 방식으로 구축하면 됩니다.

서비스를 처음 시작하는 대부분의 기업은 사용자 데이터 관리 목적으로 하나의 중앙 집중식 데이터베이스로 시작하는 것이 일반적인 패턴일 겁니다. 하지만 회사가 성장함에 따라 증가하는 데이터를 관리할 수 있는 더 좋고 확장 가능한 방법을 찾아야 할 수도 있습니다. 멀티테넌시는 이미 구축된 데이터베이스를 완전히 뜯어고치지 않고도 이 문제를 해결할 수 있는 실용적인 솔루션을 제공합니다. 저희는 멀티테넌시를 통해 비즈니스 업종별로 코드베이스와 인프라 레벨에서의 물리적, 논리적 데이터 분리를 적용함으로써, 기존 사용자 데이터 뿐 아니라 신규 사용자 데이터 모두 동일한 데이터 분리 모델을 적용할 수 있습니다. 초기 통합을 완료한 후에는 이러한 사용자 데이터 관리 모델을 새로운 업종으로 쉽게 확장할 수 있으며, 모든 업종에서 일관성과 데이터 무결성을 유지할 수 있습니다.

다가올 뉴스레터가 궁금하신가요?

지금 구독해서 새로운 레터를 받아보세요

✉️
댓글

의견을 남겨주세요

확인
의견이 있으신가요? 제일 먼저 댓글을 달아보세요 !
© 2024 주간 SaaS

B2B SaaS 비즈니스 모델과 멀티 테넌트 아키텍처 설계에 관한 좋은 콘텐츠를 소개합니다.

자주 묻는 질문 서비스 소개서 오류 및 기능 관련 제보

서비스 이용 문의admin@team.maily.so

메일리 사업자 정보

메일리 (대표자: 이한결) | 사업자번호: 717-47-00705 | 서울 서초구 강남대로53길 8, 8층 11-7호

이용약관 | 개인정보처리방침 | 정기결제 이용약관