Skip to main content

API 비동기호출 데이터처리 개발

· 5 min read
Eundo Park
Maintainer

이번 프로젝트에서는 사용자 로그인 시 대용량 데이터를 비동기로 호출하여 특정 화면에 표시하는 시스템을 구현했습니다. 데이터가 없으면 해당 내용을 알리는 메시지를 표시하는 기능이 필요했습니다.

비동기 호출 프로세스

4개의 API를 통해 데이터를 비동기로 호출했습니다:

  • 데이터 A: 첫 번째 API 호출
  • 데이터 B: 두 번째 API 호출
  • 데이터 C: 세 번째 API 호출
  • 데이터 D: 네 번째 API 호출

데이터 A, B, C의 비동기 호출이 모두 완료되면 이를 합쳐 하나의 총괄 데이터를 생성하고, 이를 세션 객체에 저장하여 애플리케이션 전반에서 사용했습니다.

문제 상황 및 해결 방안

데이터 부재 문제

비동기 호출이 완료되기 전에 화면에 접근할 경우 데이터가 없다는 메시지가 표시되었습니다. 이후 다시 접속하면 데이터가 정상적으로 표시되는 상황이 발생했습니다.

빈 데이터 처리 문제

비동기 호출 중 일부가 실패하면 빈 데이터로 처리되어, 최종 결과에 영향을 미쳤습니다.

해결 방안

모든 비동기 호출이 완료된 후 데이터를 종합하여 한 번에 화면에 표시하는 방식을 채택했습니다. 또한, 데이터 상태를 확인할 수 있는 API를 추가하여 호출 상태를 프론트엔드에서 확인할 수 있도록 했습니다. 오류 발생 시 최대 3회까지 재시도하는 로직도 구현했습니다.

비동기 처리 중 객체 공유 문제

비동기 호출 중 여러 스레드가 동일한 객체에 접근할 때 발생할 수 있는 Race ConditionData Corruption 문제를 방지하기 위해, 실시간 업데이트보다는 안정적인 데이터를 제공하는 방식을 선택했습니다.

추가 고려 사항

프로젝트 진행 중 비동기 호출의 이점을 더욱 극대화하기 위해 다음 사항들을 고려했습니다:

  • 백그라운드 데이터 업데이트: 데이터를 비동기로 가져온 후, 백그라운드에서 정기적으로 업데이트하는 작업 추가.
  • 병렬 처리 최적화: 비동기 호출 간의 의존성이 없는 경우 병렬 처리 최적화.
  • Fallback 전략: 비동기 호출 실패 시 기본값이나 대체 데이터를 제공하는 전략.
  • 모니터링 및 로깅: 비동기 호출의 성능과 안정성을 높이기 위해 모니터링 및 로깅 강화.

결론

이번 프로젝트에서는 안정성과 일관성을 우선시하여 모든 비동기 호출이 완료된 후 데이터를 종합하여 제공하는 방식을 채택했습니다. 추가적인 최적화 방안을 고려하면 비동기 호출의 이점을 더욱 효과적으로 활용할 수 있을 것입니다. 이 회고를 통해 유사한 상황에서 최적의 솔루션을 설계하는 데 중요한 교훈을 얻었습니다.