CS/기타

[대규모 시스템 설계 기초 2] 11장. 결제 시스템 파헤치기

Joonfluence 2024. 4. 26.

오늘은 가상면접사례로 배우는 대규모 시스템 설계 기초 2의 11장 결제시스템의 내용을 어제에 이어 읽고 정리해봤습니다. 본 설계안에서는 하루 총 100만 건의 트랜잭션과 초당 10건의 트랜잭션(TPS)가 처리되며 결제 트랜잭션의 정확한 처리에 초점을 맞췄다.

문제 이해 및 설계 범위 확정

아마존닷컴과 같은 전자상거래 애플리케이션을 위한 결제 백엔드를 구축한다고 가정한다. 전 세계적으로 사용될 수 있는 애플리케이션이며, 하나의 통화만 사용한다고 가정한다.

기능 요구사항

  • 대금 수신 : 결제 시스템이 판매자를 대신하여 고객으로부터 대금을 수령한다.
  • 대금 정산 : 결제 시스템이 전 세계의 판매자에게 제품 판매 대금을 송금한다.

비기능 요구사항

  1. 신뢰성 및 내결함성 : 결제 실패는 신중하게 처리해야 한다.
  2. 내부 서비스와 외부 서비스 간의 조정 프로세스 : 시스템 간의 결제 정보가 일치하는지 비동기적으로 확인한다.
  3. 대금 수신 흐름
    • 구매자 (신용카드) - [대금 수신] -> 은행계좌(전자상거래 웹사이트) - [대금 정산] -> 은행계좌(판매자)으로 자세한 내용은 생략한다.
  4. 대금 정산 흐름
    • 대금 수신 흐름과 유사하다. 한가지 차이는 PSP(Payment Service Provider, A 계정에서 B 계정으로 돈을 옮기는 역할을 담당한다)를 사용해, 구매자의 신용 카드에서 전자상거래 웹사이트 은행 계좌로 돈을 이체하는 대신, 정산 흐름에서는 타사 정산 서비스를 사용하여 전자상거래 웹사이트 은행 계좌에서 판매자 은행 계좌로 돈을 이체한다는 점이다.

상세 설계

  1. PSP 연동
    • 왜 필요한가? 일반적으로 비자 또는 마스터카드와 같은 시스템에 직접 연결 할 수 있다면 PSP가 필요 없다. 그렇지만 그런 직접 연결에 투자할 수 있는 회사는 아주 큰 회사 뿐이다.
    • 어떻게 할 수 있나? 첫번째 방법은 API 연동을 통한 것이다. 회사는 결제 웹 페이지를 개발하고 민감한 결제 정보를 수집하며, PSP는 은행 연결, 다양한 카드 유형을 지원한다. 두번째로는 복잡한 규정 및 보안 문제로 인해 민감한 결제 정보를 저장하지 않는 방법이다. PSP가 카드 결제 세부 정보를 수집하여 PSP에 안전하게 저장할 수 있도록 외부 결제 페이지를 제공한다. 안전하게 저장할 수 있도록 외부 결제 페이지를 제공한다. 대부분의 기업들이 택하는 접근 방법이다.
  2. 조정
    • 왜 필요한가? PSP나 은행 같은 외부 시스템은 시스템 성능을 높이기 위해 비동기 통신을 자주 사용한다. 그러나 이 경우, 메시지가 전달되거나 응답이 반환된다는 보장이 없다. 이를 위해 조정을 한다. 조정이란 관련 서비스 간의 상태를 주기적으로 비교하여 일치하는지 확인하는 것이다. 일반적으로 결제 시스템의 마지막 방어선으로 받아들여진다.
    • 어떻게 할 수 있나? 일반적으로 재무팀에 의뢰하여 수동으로 고친다. 발생 가능한 불일치 문제 및 해결 방안은 세가지 범주로 나눌 수 있다. 첫째, 어떤 유형의 문제인지 알고 있으며 문제 해결 절차를 자동화 할 수 있는 경우. 자동화 프로그램을 작성하는 것이 비용 효율적인 경우이다. 엔지니어는 발생한 불일치 문제의 분류와 조정 작업을 모두 자동화할 수 있다. 둘째, 어떤 유형의 문제인지는 알지만 문제 해결 절차를 자동화할 수 없는 경우. 이 경우, 불일치의 원인과 해결 방법을 알고 있지만 자동 조정 프로그램의 작성 비용이 너무 높다. 이 경우 재무팀에서 수동으로 수정하도록 한다. 셋째, 분류할 수 없는 유형의 문제인 경우. 불일치가 어떻게 발생하였는지 알지 못하는 경우이다. 이런 문제는 특별 작업 대기열에 넣고 재무팀에서 조사하도록 한다.

결제 지연 처리

  • 왜 필요한가? 결제 요청은 많은 컴포넌트를 거치며, 내부 및 외부의 다양한 처리 주체와 연동한다. 대부분의 경우 결제 요청은 몇 초 만에 처리되지만, 완료되거나 거부되기까지 몇 시간 또는 며칠이 걸리는 경우도 있다. 특별한 사례를 공유한다. PSP가 해당 결제 요청의 위험성이 높다고 보고 담당자 검토를 요구하는 경우. 신용 카드사가 구매 확인 용도로 카드 소유자의 추가 정보를 요청하는 3D 보안 인증 같은 추가 보호 장치를 요구하는 경우. 결제 서비스는 처리하는 데 시간이 오래 걸리는 이런 요청도 처리할 수 있어야 한다. PSP는 결제가 대기 상태임을 알리는 상태 정보를 클라이언트에 반환하고, 클라이언트는 이를 사용자에게 표시한다. PSP는 우리 회사를 대신하여 대기 중인 결제의 진행 상황을 추적하고, 상태가 바뀌면 PSP에 등록된 웹훅을 통해 결제 서비스에 알린다.
  • 어떻게 할 수 있나? 결제 요청이 최종적으로 완료되면 PSP는 방금 언급한 사전에 등록된 웹훅을 호출한다. 결제 서비스는 내부 시스템에 기록된 정보를 업데이트하고 고객에게 배송을 완료한다.

내부 서비스 간 통신

  1. 동기식 통신 : 소규모 시스템에서는 잘 동작하지만 규모가 커지면 단점이 분명해진다. 대표적으로 성능 저하, 장애 격리 곤란, 높은 결합도, 낮은 확장성 등이 단점이다.
  2. 비동기 통신 : 단일 수신자인 경우와 다중 수신자인 경우로 나뉜다. 전자는 각 요청(메시지)은 하나의 수신자 또는 서비스가 처리한다. 일반적으로 공유 메시지 큐를 사용해 구현한다. 후자는 각 요청을 여러 수신자 또는 서버가 처리한다. 카프카가 이런 시나리오를 잘 처리할 수 있다. 소비자가 수신한 메세지는 카프카에서 바로 사라지지 않는다. 따라서 동일한 메시지를 여러 서비스가 받아 처리할 수 있다. 따라서 결제 시스템 구현에 적합한데, 하나의 요청이 푸시 알림 전송, 재무 보고 업데이트, 분석 결과 업데이트 등의 다양한 용도에 쓰일 수 있다.

결제 실패 처리

모든 결제 시스템은 실패한 결제를 적절히 처리할 수 있어야 한다. 안정성 및 결함 내성은 결제 시스템의 핵심적 요구사항이기 때문이다. 따라서 결제 주기의 모든 단계에서 결제 상태를 정확하게 유지하는 것은 매우 중요하다. 실패가 일어날 때마다 결제 거래의 현재 상태를 파악하고 재시도 또는 환불이 필요한지 여부를 결정한다. 또한 결제 상태는 데이터 추가만 가능한 데이터베이스 테이블에 보관한다.

재시도 큐 및 실패 메시지 큐

재시도 큐와 실패 메시지 큐를 두는 것이 바람직하다. 재시도 큐는 일시적 오류 같은 재시도 가능 오류는 재시도 큐에 보낸다. 실패 메시지 큐는 반복적으로 처리에 실패한 메시지는 결국 실패 메시지 큐로 보낸다.

정확히 한 번 전달

결제 시스템에 발생 가능한 가장 심각한 문제 중 하나는 고객에게 이중으로 청구하는 것이다. 따라서 결제 주문이 정확히 한 번만 실행되도록 결제 시스템을 설계하는 것이 중요하다. 다음 요건이 충족되면 주어진 연산은 정확히 한 번 실행된다. 최소 한 번은 실행된다 그리고 최대 한 번 실행된다. 재시도를 통해 최소 한 번 실행을 보증하고 멱등성 검사를 통해 최대 한 번 실행을 보증하면 된다.

  • 재시도 : 간혹 네트워크 오류나 시간 초과로 인해 결제 거래를 다시 시도해야 하는 경우가 있다. 이 때, 얼마나 간격을 두고 재시도할지 정하는 것이 중요하다.
  • 멱등성 검사 : 스트라이프, 페이팔 같은 많은 기술 회사가 UUID를 멱등 키로 권장하며 실제로 널리 쓰인다. 결제 요청의 멱등성을 보장하기 위해서는 HTTP 헤더에 <멱등 키: 값>의 형태로 멱등 키를 추가하면 된다. 동일한 멱등 키로 동시에 많은 요청을 받으면 결제 서비스는 그 가운데 하나만 처리하고 나머지에 대해서는 429 Too Many Requests 상태 코드를 반환한다. 멱등성을 지원하는 한 가지 방법은 데이터베이스의 고유 키 제약 조건을 활용하는 것이다.

일관성

내부 서비스 간에 데이터 일관성을 유지하려면 요청이 ‘정확히 한 번 처리’되도록 보장하는 것이 아주 중요하다.

보안

  1. 요청/응답 도청 : HTTPS 사용
  2. 데이터 변조 : 암호화 및 무결성 강화 모니터링
  3. 중간자 공격 : 인증서 고정과 함께 SSL 사용
  4. 데이터 손실 : 여러 지역에 걸쳐 데이터베이스 복제 및 스냅숏 생성
  5. 분산 서비스 거부 공격 (DDoS) : 처리율 제한 및 방화벽
  6. 카드 도난 : 토큰화. 실제 카드 번호를 사용하는 대신 토큰을 저장하고 결제에 사용
  7. PCI 규정준수 : PCI DSS는 브랜드 신용 카드를 처리하는 조직을 위한 정보 보안 표준이다.
  8. 사기 : 주소 확인, 카드 확인번호(CVV), 사용자 행동분석 등
반응형

댓글