8percent 사전 과제

8percent 백엔드 사전 과제 프로젝트 입니다.

배포 링크
배포 swagger 링크

개발 환경

• IDE: PyCharm Professional
• OS: Window, Ubuntu
• GitHub

Server

• Python 3.12
• FastAPI 0.111.0
• SQLAlchemy 2.0.31

설치 및 실행

파이썬 버전 확인(3.12 준수)

python -V

가상환경 세팅(루트 디렉터리에서 실행)

python -m venv venv

가상환경 실행

./venv/Scripts/activate

라이브러리 설치

pip install -r ./requirements.txt

실행

fastapi dev app/main.py      

기본 http://127.0.0.1:8000/

docs http://127.0.0.1:8000/docs

user Create 이후 우측 상단 Authorize로 OAuth 세팅 가능

이후 account 생성 후 확인한 account_id로 입금,출금,거래내역 조회 API 사용 가능

주요 설계 고려 사항

• 모델, 라우터, 스키마를 구분하여 형상관리에 용이하게 함, 확장에 유리한 구조를 선택함
• auth는 의존성을 주입하는 형태로 나누어 라우터에는 핵심로직만 동작하게함, 가독성을 높임
• DB 설계 시 타입과 사이즈를 맞추어 최적화 하였고 필터링이 잦은 컬럼에 index를 붙여 성능을 높임

API Endpoint 설명

• 입금 API /account/deposit

  • api 호출시 account 필터를 진행, 이때 user_id를 access token에서 가져오게끔 하여 계좌의 소유주가 아니면 접근을 못하게 구현

  • 핵심로직 동작 이후 commit, 로그 추가 이후 commit 으로 커밋을 분산시켜 트랙잭션 중 발생하는 락을 최소화함

• 출금 API /account/withdrawal

  • 입금 API 와 마찬가지로 계좌의 소유주가 아니면 접근을 못하도록 구현
  • DB연결 없이 raise 할 수 있는 Exception들을 우선 배치하여 불필요한 DB연결을 최소화함.
  • 잔고 이상의 출금요청이 주어질 경우 바로 raise로 response함.

• 거래내역 조회 API /log/{account_id}

  • 계좌 테이블과 로그 테이블을 분리, 계좌와 거래 시점당시의 잔고가 따로 저장되어 데이터의 무결성이 보장된다.
  • 특정 계좌의 내역만 불러와야 함으로 account_id를 path parameter에 넣음. 그 외 나머지 파라미터들은 query paramrter로 order_by를 제외하고는 값을 넣지 않아도 기본값으로 동작한다.
  • 주로 account_id로 필터링 되기에 account_id 컬럼에 index를 추가하여 row의 수가 많아져도 성능이 하락하지 않도록 하였다.

테스트

테스트 실행(루트 디렉터리에서 실행)

pytest

테스트 설계 고려 사항

• 소스코드에서는 가독성과 효율성을 중시했다면 테스트 코드에서는 무결성을 입증하는게 가장 중요하다고 생각한다. 때문에 여러 시나리오를 구성하기 위해 반복되는 코드가 많고, 이에 주석을 달아 가독성이 떨어지는 것을 보완하였다.
• unit test 에서는 라이브러리나 함수레벨에서의 무결성을 확인하는걸 의도하였다.
• funtional test 에서는 라우터 단계에서 실제 서비스 중 생길 수 있는 시나리오 들을 구성하였다.
• funtional test 에서 가장 중요한 것은 타인의 정보에 접근이 가능한지 확인하는 것이다. test_account.py 에서 유저1과 유저2를 두어 각 라우터에서 유저2가 유저1에게 침투를 시도했을 때 막히는지 여부를 중점으로 시나리오 테스트를 구성하였다.

거래내역이 1억건이 넘었을 때에 대한 고려

• 데이터가 많을때 이를 관리하는 방법을 3가지 알고 있다. 인덱싱, 파티셔닝, 샤딩 인데, 파티셔닝은 sqlite에서 지원을 안한다. 만약 다른 db를 채용했더라면 log 테이블의 created_at을 컬럼을 기준으로 월 혹은 분기마다 파티션을 나누어서 진행을 할 수 있을 것이다. 샤딩은 현재 작성한 프로젝트의 테이블 규모가 작고 테이블간 연결성이 높아 부적절한 형태이다. 때문에 현 프로젝트에 직접적으로 적용한건 인덱싱밖에 없다.