- Stripe는 2023년에 총 결제량 1조 달러를 처리하면서도 99.999%의 가동 시간을 유지함
- Stripe의 데이터베이스 인프라 팀은 API의 기반 계층으로 DocDB라는 데이터베이스 as a service (DBaaS)를 제공함
- DocDB는 MongoDB Community의 확장판으로, Stripe 내부에서 구축한 여러 서비스로 구성됨
- 초당 500만 건 이상의 쿼리를 처리하며, 페타바이트 단위의 중요한 금융 데이터를 2,000개 이상의 데이터베이스 샤드에 분산하여 5,000개 이상의 컬렉션에 저장함
- MongoDB Community를 선택한 이유는 문서 모델의 유연성과 대규모 실시간 데이터 처리 능력 때문임
- 2011년에는 MongoDB Atlas가 존재하지 않아 클라우드에서 실행되는 자체 관리형 MongoDB 인스턴스 클러스터를 구축함
- DocDB의 핵심은 Data Movement Platform임
- 원래는 MongoDB의 수직 확장 한계를 극복하기 위한 수평 확장 솔루션으로 구축되었으나, 다양한 목적으로 커스터마이징됨
- 활용도와 효율성 향상을 위한 미사용 데이터베이스 샤드 병합, 안정성을 위한 데이터베이스 엔진 주요 버전 업그레이드, 대형 사용자를 위한 멀티테넌트에서 싱글테넌트로의 전환 등
- Data Movement Platform은 소수의 대용량 데이터베이스 샤드에서 다수의 소용량 데이터베이스 샤드로의 전환을 가능하게 함
- 또한 클라이언트에 투명한 마이그레이션과 제로 다운타임을 제공하여 고도로 탄력적인 DBaaS 제공이 가능함
- DocDB는 트래픽 급증 시 데이터베이스 샤드를 분할하고, 트래픽이 낮을 때는 빈 패킹을 통해 수천 개의 데이터베이스를 통합할 수 있음
데이터베이스 인프라 구축 방법
- Stripe는 2011년 출시 당시 표준 관계형 데이터베이스보다 개발자 생산성이 뛰어난 MongoDB를 온라인 데이터베이스로 선택함
- MongoDB 위에서 API의 안정성을 우선시하는 견고한 데이터베이스 인프라를 운영하고자 했으나, 요구사항을 충족하는 기성 DBaaS를 찾을 수 없었음
- 최고 수준의 가용성, 내구성, 성능 충족
- 클라이언트 애플리케이션의 최적화되지 않은 쿼리로 인한 자체 문제를 방지하기 위해 최소한의 데이터베이스 기능 노출
- 샤딩을 통한 수평 확장성 지원
- 강제 할당량이 있는 멀티테넌시에 대한 일류 지원 제공
- 권한 부여 정책 시행을 통한 강력한 보안 제공
- 해결책은 MongoDB를 기본 스토리지 엔진으로 사용하여 DocDB를 구축하는 것이었음 - 진정한 탄력적이고 확장 가능한 DBaaS로, 온라인 데이터 마이그레이션이 핵심임
- Stripe의 제품 애플리케이션은 신뢰성, 확장성, 허용 제어 및 액세스 제어 문제를 시행하기 위해 Go로 내부적으로 개발한 데이터베이스 프록시 서버 플릿을 통해 데이터베이스의 데이터에 액세스함
- 수평 확장 메커니즘으로 샤딩을 사용하기로 결정하는 핵심 아키텍처 결정을 내림
- 누적 데이터의 작은 청크를 각각 보관하는 수천 개의 데이터베이스 샤드가 이제 Stripe의 모든 제품의 기반이 됨
- 애플리케이션이 데이터베이스 프록시 서버에 쿼리를 보내면 쿼리를 구문 분석하고 하나 이상의 샤드로 라우팅한 다음, 샤드의 결과를 결합하여 애플리케이션으로 다시 반환함
- 데이터베이스 프록시 서버는 청크 메타데이터 서비스에 의존하여 청크를 데이터베이스 샤드에 매핑함으로써 주어진 쿼리에 대한 관련 샤드를 쉽게 조회할 수 있음
- 데이터베이스에 대한 쓰기로 인한 변경 이벤트는 스트리밍 소프트웨어 시스템으로 전송되고, 최종적으로 변경 데이터 캡처(CDC) 파이프라인을 통해 객체 저장소에 보관됨
- Stripe의 팀은 제품 애플리케이션 수준에서 내부 문서 데이터베이스 컨트롤 플레인을 사용하여 관련된 목적을 가진 문서로 구성된 하나 이상의 DocDB 컬렉션을 포함하는 논리적 데이터베이스라고 하는 데이터의 논리적 컨테이너를 프로비저닝함
- 이러한 DocDB 컬렉션의 데이터는 컬렉션의 작은 청크를 보관하는 여러 데이터베이스(물리적 데이터베이스)에 분산됨
- DocDB의 물리적 데이터베이스는 프라이머리 노드와 복제 및 자동 장애 조치가 포함된 여러 보조 노드로 구성된 복제 세트로 배포된 샤드에 상주함
Data Movement Platform 설계 방법
- 제품 애플리케이션의 요구에 따라 확장 및 축소할 수 있는 수평적으로 확장 가능하고 높은 탄력성을 가진 DBaaS 제품을 구축하기 위해서는 클라이언트에 투명한 방식으로 제로 다운타임으로 데이터베이스 샤드 간에 데이터를 마이그레이션할 수 있는 기능이 필요했음
- 이는 중요한 재무 데이터의 고유한 요구사항으로 인해 더욱 복잡해지는 복잡한 분산 시스템 문제임
-
데이터 일관성 및 완전성: 마이그레이션되는 데이터가 소스 샤드와 타겟 샤드 모두에서 일관성과 완전성을 유지하도록 보장해야 함
-
가용성: 데이터 마이그레이션 중 장시간 다운타임은 허용될 수 없음. 수백만 기업이 하루 24시간 고객의 결제를 받기 위해 Stripe에 의존하기 때문
- 마이그레이션 프로세스의 핵심 단계를 계획된 데이터베이스 프라이머리 장애 조치 시간(일반적으로 몇 초 정도 소요)보다 짧게 유지하고, 제품 애플리케이션의 재시도 예산에 맞추는 것이 목표임
-
세분성 및 적응성: Stripe 규모에서는 데이터의 임의 개수 청크를 임의 개수의 소스에서 타겟 샤드로 마이그레이션할 수 있어야 함
- 플릿 내 진행 중인 데이터베이스 청크 마이그레이션 수에 제한이 없고, 특정 시점에 특정 샤드가 참여할 수 있는 마이그레이션 수에도 제한이 없어야 함
- 또한 데이터베이스 샤드 중 상당수가 테라바이트 단위의 데이터를 포함하고 있기 때문에 다양한 크기의 청크를 높은 처리량으로 마이그레이션할 수 있어야 함
-
소스 샤드에 미치는 성능 영향 없음: 데이터베이스 청크를 샤드 간에 마이그레이션할 때, 사용자 쿼리에 대한 성능과 가용 처리량에 부정적인 영향을 미치지 않도록 소스 샤드의 성능과 처리량을 보존하는 것이 목표임
- 이러한 요구사항을 해결하기 위해 목적 구축 서비스를 호출하여 데이터베이스 샤드 간 온라인 데이터 마이그레이션을 관리하는 데이터 이동 플랫폼을 구축했음
- 데이터 이동 플랫폼의 Coordinator 컴포넌트는 온라인 데이터 마이그레이션과 관련된 여러 단계를 오케스트레이션하는 역할을 담당하며, 아래에 설명된 각 구성 단계를 수행하기 위해 관련 서비스를 호출함
1단계: 청크 마이그레이션 등록
- 먼저 청크 메타데이터 서비스에서 데이터베이스 청크를 소스 샤드에서 임의의 타겟 샤드로 마이그레이션하려는 의도를 등록함
- 그 후 마이그레이션되는 청크에 대해 타겟 샤드에 인덱스를 구축함
2단계: 대량 데이터 가져오기
- 다음으로 시간 T에서 소스 샤드의 청크 스냅샷을 사용하여 데이터를 하나 이상의 데이터베이스 샤드에 로드함
- 대량 데이터 가져오기를 수행하는 서비스는 다양한 데이터 필터를 수용하고, 필터링 기준을 충족하는 데이터 청크만 가져옴
- 처음에는 간단해 보였지만 DocDB 샤드에 데이터를 대량 로드할 때 처리량 제한에 직면했음
- 쓰기를 일괄 처리하고 최적의 대량 데이터 수집을 위해 DocDB 엔진 매개변수를 조정하려고 했지만 큰 성공을 거두지 못함
- 하지만 DocDB가 B-트리 데이터 구조를 사용하여 데이터를 정렬한다는 점을 활용하여 삽입 순서를 최적화하는 방법을 모색했을 때 상당한 돌파구를 마련함
- 컬렉션에서 가장 일반적인 인덱스 속성을 기준으로 데이터를 정렬하고 정렬된 순서로 삽입함으로써 쓰기 근접성을 크게 향상시켜 쓰기 처리량을 10배 높임
3단계: 비동기 복제
- 타겟 샤드에 데이터를 가져온 후, 마이그레이션되는 데이터베이스 청크에 대해 시간 T부터 소스에서 타겟 샤드로 쓰기 복제를 시작함
- 비동기 복제 시스템은 CDC 시스템의 소스 샤드에 대한 쓰기로 인한 변경 사항을 읽고 타겟 샤드에 쓰기를 실행함
- 작업 로그 또는 oplog는 각 DocDB 샤드의 특수 컬렉션으로, 해당 샤드의 데이터베이스에서 데이터를 변경하는 모든 작업의 기록을 보관함
- 모든 DocDB 샤드의 oplog를 이벤트 스트리밍 플랫폼인 Kafka로 전송한 다음 Amazon S3와 같은 클라우드 객체 스토리지 서비스에 보관함
- Kafka와 Amazon S3의 oplog 이벤트를 사용하여 하나 이상의 소스 DocDB 샤드에서 하나 이상의 타겟 DocDB 샤드로 변경 사항을 복제하는 서비스를 구축함
- CDC 시스템의 oplog 이벤트에 의존하여 소스 샤드의 사용자 쿼리에 사용할 수 있는 읽기 처리량을 소비하여 사용자 쿼리 속도를 저하시키지 않고, 소스 샤드의 oplog 크기에 제약을 받지 않도록 함
- 서비스는 타겟 샤드를 사용할 수 없는 경우에도 탄력적이며, 언제든지 체크포인트에서 동기화를 시작, 일시 중지 및 재개할 수 있도록 설계됨
- 복제 서비스는 또한 복제 지연을 가져오는 기능을 제공함
- 마이그레이션 중인 청크의 변경 사항은 소스 샤드에서 타겟 샤드로, 그 반대로 양방향으로 복제되며, 복제 서비스는 순환 비동기 복제를 방지하기 위해 발행하는 쓰기에 태그를 지정함
- 이는 타겟 샤드로 트래픽을 전달할 때 문제가 발생하면 소스 샤드로 트래픽을 되돌릴 수 있는 유연성을 제공하기 위한 의도적인 설계 선택이었음
4단계: 정확성 확인
- 소스 샤드와 타겟 샤드 간 복제가 동기화된 후, 특정 시점 스냅샷을 비교하여 데이터 완전성과 정확성을 종합적으로 확인함
- 이는 샤드 처리량에 영향을 미치지 않기 위해 의도적으로 내린 설계 선택임
5단계: 트래픽 전환
- 청크의 데이터가 소스에서 타겟 샤드로 가져오고 변경 사항이 활발히 복제되면 Coordinator에 의해 트래픽 전환이 오케스트레이션됨
- 마이그레이션되는 데이터 청크에 대한 읽기와 쓰기 경로를 다시 지정하려면 먼저 소스 샤드의 트래픽을 잠시 중지하고, 청크 메타데이터 서비스의 경로를 업데이트하고, 프록시 서버가 타겟 샤드로 읽기와 쓰기를 리디렉션해야 함
- 트래픽 전환 프로토콜은 버전 게이팅 아이디어에 기반을 둠
- 안정 상태에서 각 프록시 서버는 DocDB 샤드에 대한 요청에 버전 토큰 번호를 추가함
- MongoDB에 사용자 지정 패치를 추가하여 샤드가 프록시 서버에서 받은 요청의 버전 토큰 번호가 알고 있는 버전 토큰 번호보다 새로운지 확인하고 이 기준을 충족하는 요청만 처리할 수 있도록 함
- 청크 경로를 업데이트하기 위해 Coordinator를 사용하여 다음 단계를 수행함:
- 먼저 소스 DocDB 샤드의 버전 토큰 번호를 올림. 버전 토큰 번호는 DocDB의 특수 컬렉션에 있는 문서에 저장되며, 이 시점에서 소스 샤드의 청크에 대한 모든 읽기와 쓰기가 거부됨
- 그런 다음 복제 서비스가 소스 샤드에서 미해결 쓰기를 복제할 때까지 기다림
- 마지막으로 청크 메타데이터 서비스에서 청크 경로를 타겟 샤드와 버전 토큰 번호를 가리키도록 업데이트함
- 완료되면 프록시 서버는 청크 메타데이터 서비스에서 청크에 대한 업데이트된 경로와 가장 최신 버전 토큰 번호를 가져옴
- 프록시 서버는 청크에 대한 업데이트된 경로를 사용하여 청크에 대한 읽기와 쓰기를 타겟 샤드로 라우팅함
- 전체 트래픽 전환 프로토콜은 실행하는 데 2초 미만이 소요되며, 소스 샤드로 전달된 모든 실패한 읽기와 쓰기는 재시도 시 성공함
6단계: 청크 마이그레이션 등록 취소
- 마지막으로 청크 메타데이터 서비스에서 마이그레이션을 완료로 표시하고 소스 샤드에서 청크 데이터를 삭제하여 마이그레이션 프로세스를 종료함
데이터 이동 플랫폼의 활용
- DocDB 샤드 간에 온라인 방식으로 데이터 청크를 마이그레이션할 수 있는 기능은 Stripe의 성장 속도에 맞춰 데이터베이스 인프라를 수평적으로 확장하는 데 도움이 됨
- 데이터베이스 인프라 팀의 엔지니어는 버튼 클릭만으로 크기와 처리량에 따라 DocDB 샤드를 분할할 수 있어 제품 팀을 위한 데이터베이스 스토리지와 처리량 여유 공간을 확보할 수 있음
- 2023년에는 데이터 이동 플랫폼을 사용하여 데이터베이스 인프라 활용도를 개선함
- 구체적으로 제품 애플리케이션에 투명한 방식으로 1.5페타바이트의 데이터를 마이그레이션하여 수천 개의 저활용 데이터베이스를 bin-pack하고, 기본 DocDB 샤드 총 수를 약 4분의 3 수준으로 줄임
- 또한 데이터 이동 플랫폼을 사용하여 중간 주요 및 부 버전을 거치지 않고 한 단계에서 데이터를 MongoDB 이후 버전으로 포크리프팅하여 데이터베이스 인프라 플릿을 업그레이드함
- Stripe의 데이터베이스 인프라 팀은 인터넷 경제의 성장에 맞춰 확장되는 견고하고 신뢰할 수 있는 기반을 구축하는 데 주력하고 있음
- 현재 크기와 처리량을 기준으로 샤드 간에 데이터를 사전에 균형을 맞추는 열 관리 시스템을 프로토타입으로 제작 중이며, 트래픽 패턴의 변화에 동적으로 대응하는 샤드 자동 확장에 투자하고 있음