pre-onboarding 004 | 8percent 회고

This Is Empty.·2021년 11월 13일
0

wanted-pre-onboarding

목록 보기
5/8
post-thumbnail

github repository

  • 진행 기간 : 2021.11.11 pm 17:00 ~ 2021.11.13 am 10:00

  • 기술 스택 : Django@3.2.9, sqlite, python@3.8

  • 과제 요구사항

    • API 목록

      • 거래내역 조회 API

        거래내역 API는 다음을 만족해야 합니다.

        • 계좌의 소유주만 요청 할 수 있어야 합니다.
        • 거래일시에 대한 필터링이 가능해야 합니다.
        • 출금, 입금만 선택해서 필터링을 할 수 있어야 합니다.
        • Pagination이 필요 합니다.
        • 다음 사항이 응답에 포함되어야 합니다.
          • 거래일시
          • 거래금액
          • 잔액
          • 거래종류 (출금/입금)
          • 적요
      • 입금 API
        입금 API는 다음을 만족해야 합니다.

        • 계좌의 소유주만 요청 할 수 있어야 합니다.
      • 출금 API
        출금 API는 다음을 만족해야 합니다.

        • 계좌의 소유주만 요청 할 수 있어야 합니다.
        • 계좌의 잔액내에서만 출금 할 수 있어야 합니다. 잔액을 넘어선 출금 요청에 대해서는 적절한 에러처리가 되어야 합니다.
  • 추가 구현 사항
    다음의 경우 가산점이 있습니다.

    • Unit test의 구현
    • Functional Test 의 구현 (입금, 조회, 출금에 대한 시나리오 테스트)
    • 거래내역이 1억건을 넘어갈 때에 대한 고려
      • 이를 고려하여 어떤 설계를 추가하셨는지를 README에 남겨 주세요.

Review

이번 과제에서는 지난 과제진행사항에서 얻은 깨닳음을 바탕으로 모델링에는 팀원 전부가 참여하였습니다.

그리고 저는 이번 과제에서는 docker를 통한 EC2에 프로젝트 배포와 추가구현 사항에 적혀있는 거래내역이 1억건을 넘어갈때에 대한 고려 부분을 담당했습니다.

지난 freshcode에서 도커를 통한 배포를 실패했던 쓰린 경험이 있기때문에 블로그 다른 글을 보다시피 도커에 관한 글을 정리해두기도 했고, 여러 유투브 영상들이나 문서, 블로그 글을 보면서 도커를 계속 공부했습니다.

결론부터 말하자면 이번에는 도커를 통한 배포에 성공했고, 더불어 로컬 개발 및 테스트용 도커파일도 작성해보았습니다.(사실 두 파일에 큰 차이는 없습니다.) 지난번 과제에서 다음 과제에서는 꼭 도커로 배포를 성공하리라 다짐했는데, 공부한 것이 헛된 노력은 아니였음에 만족감이 큽니다.

이번 과제에서 가장 큰 blocker는 1억건의 데이터를 직접 넣어보는 것이였습니다. 사실 1억건의 데이터를 넣는 부분은 없어도 된다고 생각합니다. 과제의 요구사항은 거래내역이 1억건을 넘어갈 때에 대한 고려이기 때문입니다.

저희는 유의미한 결과를 눈으로 확인하고싶었기때문에 일단 1억건에 가깝게라도 데이터를 넣는것을 시도했습니다. 1억건의 데이터를 모두 집어넣는것은 시간 상 실패했고.. 총 약 5천만건의 데이터를 넣었습니다.

처음에 저는 관계와 데이터 무결성을 고려하여 accounts테이블의 balance도 데이터 insert와 동시에 업데이트를 시켰고, transactions 테이블의 balance_after_transactionaccounts테이블에서 불러와(get) transactionsamount에 적힌 값으로 업데이트 시켜주었는데 그렇게 작성하니 약 9만건의 데이터 삽입에 3분 가량이 걸렸습니다. 그렇게 되면 1억건의 데이터 insert시 약 18시간이 걸린다는 것을 깨닫고 get부분과 업데이트 부분을 제외하고 약 5천만건의 데이터를 insert하기로 했습니다.

저희는 거래 내역이 1억건을 넘어간다면 대량 데이터 처리 시 문제요소로 조회 성능을 꼽았습니다. 때문에 데이터베이스 테이블에 인덱스를 추가했는데, 실제 성능 테스트 결과 페이지네이션만으로도 인덱스 추가한 결과와 비슷하게 나왔습니다.

이러한 결과가 나온 이유를 한가지 꼽아보자면, 데이터 삽입시 여러 유저의 account_id를 사용한게 아닌 한 유저의 account_id를 사용한것이 이런 결과가 나타난데 한 몫 한게 아닌가 싶습니다.

시간 상 다른 방법을 사용해보지는 않았지만, 만약 시간이 넉넉했다면 데이터베이스 파티셔닝도 구현해보고 싶었습니다. 한 테이블에 너무 많은 데이터가 누적(5천만건 ~)되는 것도 이러한 결과를 보인데 영향이 있을것으로 판단했기 때문입니다.

이번 과제에서 부족했던 부분에 대해 주말동안 공부하고, 다음 과제에 비슷한 문제를 마주하더라도 당황하지 않고 여러 방법을 적용해볼 수 있게 노력해야겠습니다!

profile
Convinced myself, I seek not to convince.

0개의 댓글