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

포인트

• 하루 100만건 = 초당 10건의 트랜젝션(TPS)
• 10TPS는 별 문제 없는 양, 트렌젝션의 정확한 처리가 중요
• 각 거래별 멱등성을 위한 트렌젝션 아이디 필요(UUID)
• 금액은 double이 아닌 string으로 직렬화/역직렬화에 사용되는 숫자 정밀도가 다를 수 있기 때문(반올림 이슈)

디비

• 성능(nosql)보다는 안정성, ACID를 위한 관계형 데이터 베이스 선호

데이터 저장 시 고려

• 결제 -> 지갑; 결제 -> 원장 테이블에 저장 시 상태값을 계속 변경하여 관리..
• 지갑/원장 테이블의 상태가 모두 바뀌어야 결제 테이블 상태 업데이트..

시스템 구성 요소가 비동기적으로 통신하는 경우 정확성 보장?

• 관련 상태값이 특정 시간동안 부적절한 상태로 남는지 확인하는 배치 돌려서 개발자에게 알람
• 조정: 관련 서비스 간의 상태를 주기적으로 비교하여 일치하는지 확인(마지막 방어선)
  • 약간 파일 대사 같은 느낌.. 원장과 외부 업체와 데이터 비교

조정 시 불일치가 발생하면

1. 어떤 유형의 문제인지 파악하여 해결 절차를 자동화
2. 어떤 유형의 문제인지는 알지만 자동화 할 수 없으면(작업 비용이 너무 높으면) 수동으로
3. 분류가 불가(판단이 안됨) 수동으로 처리하면서 계속 이슈 트래킹필요

 

동기 통신

• 성능 저하
• 장애 격리 곤란
• 높은 결합도/낮은 확장성(트래픽 증가 대응 힘듦)

비동기 통신

• 단일 수신자: 큐 하나를 한 수신자가 처리. 병렬 처리를 위해 스레드 여러개가 동시에 처리하게 함. 큐에서 구독 후 바로 삭제됨
  • 보통 rabbitMQ사용
• 다중 수신자: 큐 하나를 여러 수신자가 처리. 동일한 메세지를 각기 다른 호흡으로 읽어감. 읽어도 삭제되지 않음. 하나의 메세지를 여러 서비스에 연결할 때
  • 보통 카프카 사용
• 실패 시 재시도 큐(일시적 오류) / dead letter queue로 이동(모든 재시도 실패)

 

정확히 한 번 전달? exactly once

• 최소 한 번 실행 at least once: (지수적 백오프 사용하여) 재시도; 시스템 부하와 컴퓨팅 자원 낭비
• 최대 한 번 실행 at most once: 멱등성 보장; 고유 키를 멱등 키로 잡아야
  • 광클 시 키 값을 확인하여 이미 처리되었는지 확인하고 되었으면 재처리 하지 않고 이전 상태와 동일한 결과 반환
  • 결제가 되었지만 타임아웃 나서 결과가 시스템에 전달되지 못함 ->  다시 결제 시도 시 이중 결제로 판단하여 종전 결과 반환

 

분산 환경에서 데이터 불일치가 발생할 수 있는데 일반적으로 멱등성과 조정 프로세스를 활용한다.

디비 불일치는 master-replica 동기화