[2] 우버는 어떻게 수 조개의 트랜잭션을 다루나
Uber는 어떻게 수 조개의 결제 트랜잭션을 단 한개의 트랜잭션도 놓치지 않고 처리하는걸까?
우리나라 카카오택시와도 비슷한 Uber의 작동방식은 다음과 같이 간단하다.
- 사용자는 목적지를 입력하고 Uber에게 요금을 지불한다.
- 운전자를 기다린다.
- 탑승 후 원하는 목적지에서 하차한다.
- Uber는 운전자에게 요금을 지불한다.
이제 이 간단한 일을 수억명의 유저들에게 적용하면 된다.
Uber도 초창기에는 이 결제 시스템이 불안정하고 지연도 자주 발생했다고 한다. 하지만 모든 시스템이 그렇듯 돈과 관련된건 아주아주 중요한일이고 단 한 건의 실수도 있어서는 안되는 시스템이다. 그렇기에 Uber는 결제시스템의 대대적인 업그레이드를 하기로 마음을 먹는다.
1. 결제시스템 분리
Uber는 급격히 증가하는 거래량에 맞춰 시스템을 좀 더 유연하고 효율적으로 관리할 수 있도록 MSA (Micro Service Architecture)를 적용하여 서비스를 분리했다. 큰 하나의 서비스를 작은 단위의 서비스를 담당하는 시스템으로 독립시켜 에러나 확장에 보다 건강하게 대응할 수 있게 하는 것이다. 하나의 서비스는 결제만 담당하고 또 다른 서비스는 환불만 담당하는 식이다. (MSA하면 보상트랜잭션 등 개인적으로 할 말이 많지만.. MSA를 소개하는 글은 아니기에 넘어가겠다.)
2. 이중 회계 시스템 도입 (금융 무결성 보장)
이중 회계 시스템이란 마치 가계부와 비슷하다. 요금이 부과될 때마다 별도의 가계부에 검증용 기록을 따로 해놓는 방식이다. 이때 금액뿐아니라 돈이 어디서 어디로 움직였는지까지 기록해야한다.
3. immutable DB (불변 데이터베이스) 도입
개인적으로 이 부분이 가장 흥미로웠다. Python 공부할 때 많이 들어봤던 용어, 불변객체 (Immutable Object). 말그대로 변경할 수 없는 객체다. 변경을 하려면 기존 불변객체에 새로운 내용을 더해 새로운 불변객체로 옮겨 담아야한다. 그게 데이터베이스에서도 사용할 수 있는 용어인가보다. Uber는 데이터를 삭제(Delete)하거나 수정(Update)하는 대신, 항상 새로운 기록을 추가하는 방식을 선택했다고 한다. 항상 Insert만 허용한다는 뜻이다. 그렇게 되면 데이터의 무결성이 유지될테고 과거 이력 그대로 남아있어 추적도 쉬워진다.
(항상 적재만 되는 방대한 양의 데이터는 어떻게할지 궁금하다. 리텐션 기간을 줄여 따로 보관하는건가...)
4. Ledger Store
Uber는 수조 건의 거래를 관리하기 위해 Ledger Store라는 특수화된 데이터베이스를 개발했다고 한다. ledger란 장부, 원장, 기록책이런 뜻이다. 이 장부는 각 거래를 저장할 뿐만 아니라, 데이터의 유효성 검사와 보안을 위한 추가적인 단계도 포함하고 있다. ledger store의 핵심 기능은 다음과 같다.
- 읽기 전용: 과거 거래를 검토하고 그 거래가 정확한지 확인 가능함. 일단 검증되면 해당 거래는 수정할 수 없도록 읽기 전용 상태로 변환
- 봉인(sealing): 각 거래가 진짜이고 변경되지 않았음을 확정하는 방법을 사용
- 매니페스트 검증(manifest validation): 모든 거래가 정확히 기록되고 처리되었는지 확인
4. 마이그레이션 챌린징
이 부분도 현업에서 써먹을만한 부분이었는데, Uber가 새로운 결제 시스템으로 변경할 때 마이그레이션 시켜야하는 결제 트랜잭션양이 자그마치 2500억건이었다고 한다 ㄷㄷㄷ;. 계속해서 적재되는 데이터를 무중단으로 마이그레이션 했다고 하는데 어떤 전략으로 했을까?
Uber는 체크포인트 시스템을 활용하여 마이그레이션을 진행했다. 체크포인트 시스템이란 데이터가 안전하게 이관되었는지 계속 확인하면서 이관을 진행하는 방법이다. 일정량의 데이터를 반복적으로 이관하는 중 이관된 데이터의 스냅샷을 찍어 원 데이터와 비교해 정확히 맞으면 다음 배치를 수행하는 방식이다. (Update없이 적재만 되는 DB라 가능한 것 같기도 하다.)
5. Shadow Rider
위 체크포인트 시스템에서 각 체크포인트마다 데이터가 맞는지 비교한다고 했는데, 이 때 ShadowRider라는 도구를 개발해 사용했다고 한다. 느낌상으로는 DB 이관 잡과는 별도로 작동하는 DB 값 검증 프로그램 같다. 구DB와 이관할 DB의 값을 계속 추적하여 값의 다름이 발견되면 즉시 알람을 보내거나 스스로 수정하는 기능을 가지고 있다.
6. 방대한 양의 인덱스
Uber는 수조 건의 거래를 관리하고 엄청난 양의 데이터를 신속하게 처리해야 하기 때문에 인덱스를 수 조개(!!) 만들었다고 한다. 내가 알고있는 상식으로는 인덱스를 많이 만들수록 Insert할 때 시간이 늘어난다고 알고 있다. (Insert 할 때마다 Index에도 기록해줘야하니까) 근데... 음... 인덱스를 수 조 개 만들었다니 이해가 좀 안되는 부분이다.. 비동기로 처리하는 건지..? 해당 칼럼에 더 자세한 내용은 나와있지 않다.
의견
당연하겠지만 위 칼럼에 아주 자세한 내용(어떻게 구현되었는지)까지는 없다. 그래도 불변DB, ledger storage, shadow rider 등 새로운 개념을 많이 알아서 지금 하는 일에 많은 힌트가 되었다.
관련해서 의견있으시다면 댓글은 언제나 환영입니다!