뉴스 fetching이 진행중인데 끝났습니다...

시스템 구조 및 배경

이전 시스템 설계에서는 뉴스 데이터를 처리하는 서버가 단일 인스턴스로 구성되어 있었습니다. 이 때문에 Java의 ConcurrentHashMap을 이용한 간단한 동시성 처리 방식만으로도 어느 정도 운영이 가능했습니다. 그러나 파이썬에서 GPT API를 호출하는 결과와 자바에서 GPT API를 호출하는 결과에 차이가 생기면서, 추가적인 처리 로직을 자바 서버 쪽에서 담당해야 했습니다. 이 변화로 인해 단일 서버가 감당할 수 있는 동시성 처리의 한계가 명확히 드러났습니다.

 

아래 글은 서버 스케일아웃(확장) 작업 중 발생한 여러 문제를 해결해 나가는 과정(트러블슈팅)에 대해 정리한 내용입니다. 기존 단일 서버 환경에서 처리하던 뉴스를 대규모로 확장하고, 각 단계별로 분산 처리를 도입하면서 맞닥뜨린 이슈와 그 해결 방안을 공유합니다.

기존 시스템의 데이터 흐름

1. 초기 Payload 생성
   사용자가 특정 키워드(예: "이구산업")와 기간(예: 2024-03-05 ~ 2025-03-05)을 입력하면 하나의 요청이 발생합니다. 이 요청은 달(month) 단위로 쪼개져 총 12개의 페이지로 분할됩니다.
   
   
2. DB에 상태 저장
   각 페이지는
   • 상태(Status: NOT_STARTED)
   • 진행된 뉴스 개수(Proceed_News_Count: 0)
     등과 함께 DB(EventStore)에 저장됩니다.
3. SQS로 전달
   DB에 저장된 이후, 각 페이지 처리를 위한 요청은 Amazon SQS를 통해 AWS Lambda로 전달됩니다.
   
   
4. Lambda에서 뉴스 링크 수집
   AWS Lambda는 전달받은 요청을 바탕으로 해당 키워드에 맞는 뉴스 링크를 수집하고, 그 결과로 얻은 뉴스 총 개수(NEWS_COUNT: 121)를 다시 DB에 업데이트합니다.

이 과정에서 두 가지 주요한 문제가 발생했습니다.

문제 1: 데이터 처리 상태 동기화 문제

문제 현상

기존 시스템은 뉴스 분석 요청이 들어오면 초기 상태를 NOT_STARTED로 설정한 뒤, 실제로 뉴스 본문 분석이 시작될 때 IN_PROGRESS로 변경하도록 설계되어 있었습니다. 그러나 AWS Lambda가 SQS를 통해 매우 빠르게 병렬 요청을 처리하는 동안 상태 변경 로직이 지연되면서, 아직 분석 전인데도 분석이 끝났다고 간주하는 상황이 종종 발생했습니다.

• 비정상적인 플로우:
  AWS Lambda가 병렬로 뉴스 '링크' 패치를 수행하는 동안, 본문 분석 요청이 실행되기도 전에 종료 조건(예: “뉴스 패치를 모두 마쳤으니 분석도 끝났다”)이 성립해 버리는 경우가 있었습니다. 실제로는 NOT_STARTED 상태인 페이지가 남아 있음에도 불구하고, 시스템은 분석을 마친 것으로 인식했습니다.

•  

해결 방안

• 정상적인 플로우
  Lambda에서 뉴스 분석 요청을 받자마자, 즉시 EventStore의 상태를 IN_PROGRESS로 변경하는 로직으로 수정했습니다.
  • 이렇게 하면 DB가 더 빨리 상태를 변경하므로, 뉴스 '링크'만 패치된 상황에서 “분석 종료” 판정이 나는 문제를 줄일 수 있습니다.
  • 동시에, 분석 종료 조건을 점검할 때도 “아직 IN_PROGRESS 상태”임을 인지하게 되어, 올바른 순서로 본문 분석을 진행할 수 있습니다.

문제 2: Redis의 처리 속도 불균형

문제 의도

Redis를 임시 버퍼로 사용해 날짜별 뉴스 링크를 저장하고, 필요한 경우 하나씩 꺼내 분석하는 구조는 분석 비용을 최소화하기 위한 아이디어였습니다.

• 날짜별로 여러 뉴스를 미리 확보해 두되, 하나만 분석해 주가 상승 이유를 찾으면 나머지 뉴스를 사용하지 않아도 된다는 점을 노렸습니다.
• 이로써 분석에 필요한 데이터만 가져오고, 나머지는 무시함으로써 시스템 부담을 줄이는 효과를 기대했습니다.

문제 발생

실제 구현 과정에서, 서버가 재분석을 시도할 때마다 Redis가 동일 날짜의 뉴스 링크 N개를 한 번에 꺼내오는 현상이 발생했습니다. 이유는 다음과 같습니다.

1. 서버는 한 번에 하나의 뉴스만 분석하고, 결과가 만족스럽지 않으면 처음 단계로 되돌아갑니다.
2. 이때 Redis는 이미 사용한 링크임에도 불구하고 재요청을 받으면 다시 N개씩 링크를 제공하게 됩니다.
3. 결과적으로 Redis 내부에 쌓여 있던 뉴스 링크가 예측보다 훨씬 빠르게 소모되어, 뉴스 수집이 아직 끝나지 않았음에도 “링크가 모두 소진되었다”라는 잘못된 상태가 되어 버립니다.
4. 이로 인해 분석 프로세스가 조기 종료되는 문제가 발생합니다.

해결 방향

• 서버-Redis 통신 로직 정교화
  • 분석이 진행 중일 때는 동일 날짜 링크를 재요청하지 않도록 제어
  • 분석 결과가 성공·실패로 확정되면, Redis에 명시적으로 해당 뉴스를 제거하거나 상태를 업데이트하도록 구현
• 뉴스 패칭 진행 상황 모니터링 강화
  • 실제 뉴스 수집이 완료되기 전에는 “분석 종료” 신호가 발생하지 않도록, Redis와 실시간 동기화하는 장치 필요
  • 이를 통해 Redis 내부 상태와 실제 뉴스 수집 상황을 정확히 일치시켜, 불필요한 데이터 소진을 막고 분석 누락도 예방 가능

맺음말

1. 데이터 처리 상태 동기화 문제는 분석 시작 시점을 명확히 기록해 주는 것만으로도 해결할 수 있었습니다.
2. Redis의 처리 속도 불균형 문제는 재분석 로직과 Redis 데이터 사용 방식을 조정해, 중복 요청을 방지하고 실시간 진행 상황을 정확히 반영하도록 개선할 수 있습니다..

 

해당 구현 내용은 아래의 사이트에서 실행해볼 수 있다.

https://next-stock.com/

Next Stock - 주식 시장을 한눈에!