Feature/nyh365 Step3: 사용자 전체 정보 조회

[nyh365]

구현 사항

• 특정 사용자의 전체 정보를 조회 하는 API를 개발합니다.
• 해당 사용자가 개설한 모든 계좌의 정보와, 모든 거래 내역을 조회할 수 있어야 합니다.
• 해당 API를 두 가지 방법으로 개발하고, 각각에 대해 성능 테스트를 수행해 주세요.

사용자 전체 정보 조회(모든 계좌 정보, 모든 거래 내역)을 조회하는 API 1

• 입력 받은 사용자 아이디를 바탕으로 사용자의 전체 정보를 반환합니다.
• 특정 계좌와 연관된 모든 거래 내역을 조회하는 과정에서 병렬 처리가 가능하다고 생각했습니다.
• 예를 들어 A계좌와 연관된 모든 거래 내역을 조회하는 과정과 B계좌와 연관된 모든 거래 내역을 조회하는 과정은 서로 연관 관계가 없기 때문에 병렬로 처리할 수 있습니다.
• 따라서 병렬 처리를 통해 특정 사용자의 전체 정보를 조회하도록 구현했습니다.

사용자 전체 정보 조회(모든 계좌 정보, 모든 거래 내역)을 조회하는 API 2

• 입력 받은 사용자 아이디를 바탕으로 사용자의 전체 정보를 반환합니다.
• 비교를 위해 병렬 처리를 하지 않고 특정 사용자의 전체 정보를 조회하도록 구현했습니다.

성능테스트

시나리오 1: API 1 (병렬 처리 방식) 성능 테스트

• 목표: 병렬 처리를 사용해 각 계좌의 거래 내역 조회를 동시에 수행하는 방식의 성능을 테스트합니다.
• 방식:
  • 100명의 동시 사용자가 API 1 요청을 보냅니다.
  • 연관된 거래 내역이 많은 특정 계좌 번호를 요청에 포함했습니다.
  • API 2와 비교가 가능하도록 같은 요청 데이터를 포함하여 API 1을 호출하도록 했습니다.
• 결과:
  

시나리오 2: API 2 (병렬 처리 방식) 성능 테스트

• 목표: 병렬 처리를 사용하지 않고 각 계좌의 거래 내역 조회를 동시에 수행하는 방식의 성능을 테스트합니다.
• 방식:
  • 100명의 동시 사용자가 API 2 요청을 보냅니다.
  • 연관된 거래 내역이 많은 특정 계좌 번호를 요청에 포함했습니다.
  • API 1과 비교가 가능하도록 같은 요청 데이터를 포함하여 API 2를 호출하도록 했습니다.
• 결과:
  

비교 결과

Total Requests per Second (RPS)

• 시나리오 1: RPS가 약 200-260으로 유지되었습니다.
• 시나리오 2: RPS가 약 16-20으로, 요청 실패율은 0%로 안정적이지만, RPS 자체는 상당히 낮은 편입니다.

Response Times (ms)

• 시나리오 1:
  • 50th Percentile: 약 300-500ms로 안정적이었고, 응답 시간이 짧았습니다.
  • 95th Percentile: 약 500-800ms로, 일부 요청에서 다소 긴 응답 시간이 있었으나 비교적 안정적입니다.
• 시나리오 2:
  • 50th Percentile: 약 3,000-5,000ms로 상당히 높습니다.
  • 95th Percentile: 약 5,000-10,000ms로 응답 시간이 크게 증가하여, 상위 5%의 요청이 10초 이상 걸리는 경우도 있습니다.