반응형
0. 서
과제를 하면서 이러한 생각을 차분하게 했다면 좋았겠지만, 시간에 쫓기고 팀원들과 함께하느라 못했으므로,, 리팩토링하면서도 해야겠다는 생각에 정리한다.
1. 문제의 해석
1) 왜 이러한 문제를 줬을까?
8 퍼센트는 핀테크 기업이다. 핀테크 기업에게 제일 중요한 것은 신뢰다. 사고는 곧바로 고객의 손실로 이어지거나 적어도 고객의 신뢰 저하로 이어진다. 때문에 견고하고 사고없는 프로그래밍이 매우 중요하다. 이에 따라서 계좌의 잔액과 거래내역의 잔액 무결성이라던지, 1억건이 넘어가더라도 손실이 없고, 빠르게 찾을 수 있는 부분에 대한 고려가 필요하다.
극단적으로 보수적으로 잡도록 할것이다.
2. 문제의 해결
1) 잔액 무결성
트랜잭션의 무결성을 유지하도록 설계가 되어야한다.
이러기 위해서는 원자성, 일관성, 고립성, 지속성이 유지가 되어야한다.
(1) 원자성이 보장되기 위해, atomic을 수행한다.
기본적으로 장고는 auto_commit이다.
이에 따라 해당 계좌에 가서, 잔액을 바꾸고 거래내역을 등록하는 이 2가지 행위가 한번에 이루어져야하지만, 각각 이루어질 우려가 있으므로, **with transaction.atomic()**을 넣어줘야 한다.
(2) 일관성 같은 경우는 테이블이 생성될 때 명시되므로, 크게 신경 쓸 필요없다.
(3) 고립성을 보장하기 위해, 동시성 제어를 한다.(concurrency control)
- 은행이니 만큼, 최고수준의 격리를 하여서 안정성을 확보해야한다.
- 쓰기와 관련된 충돌은 select_for_update()를 통해서 방지한다.
- 읽기/읽기와 관련된 충돌은 고립수준을 serializable 모드로 하여서 방지한다.
- *TMI:
main -replica db로 나뉘어져 있는 상황에도 isolation을 신경써야할까?
- 그렇다. 왜냐하면 main db가 다운되면 replica가 maindb가되기 때문이다.
(4) 지속성 역시 aws에서 로그기록을 남기도록 설정하였다.
추가적으로 aws-rds에서 multi-az를 활성화하였다.
이를 통해 혹시나 생길 db instance 중단에 standby replica로 대체하도록 하였다.
2) 1억건의 데이터고려
- 인덱싱
- main db 와 replication db로 나누어서, write, update는 main에서만 하고, read는 replication db 에서만 가능하게 한다.
- 거래방식(입금인지,출금인지)과 계좌번호로 인덱싱하였음.
- 월별 partinioning:
- partition의 기준을 월로 한 이유비즈니스 로직에 따라, 연이나 주단위로 하는 것보다 월단위로 하는 것이 효율적이라 판단하였음.
- 카카오뱅크나 기타 다른 은행앱들을 보면, 1개월, 3개월 단위로 거래내역 목록을 볼 수 있게 해놓음.
리팩토링 중입니다..
반응형