13-6 [BE] [논문 상세 - 논문 정보] Request batch 작업

[leesungbin]

개요

• 클라이언트가 우리 서버를 통해 crossref에 다이렉트로 요청하는 것은 숨기는 작업을 진행했습니다.

• 62 를 발전시킨 PR입니다.

• 사용자는 우리 서버의 Elastic search에 있는 정보만 검색가능하고, crossref API에 검색하는 작업은 서버에서 전담합니다.
  • 우리 DB에 있는 논문 정보만 보여준다는 규칙이 개발 과정에서의 여러가지 고민을 해결해줄 것으로 예상합니다.
• Batch Flow 피그마

작업사항

• Batch service가 추가되었습니다.
• SearchBatcher 와 DoiBatcher 는 Batcher 라는 abstract class 를 상속합니다.
  • 각 Batcher 에서는 Redis의 list를 queue로 사용합니다.
    • 키 1개당 32byte 정도로 잡아본다면, 1GB에 33,554,432 개의 key를 담을 수 있는데, 터지면 별도의 redis instance를 사용해야하겠지만 당장은 터질 것 같진 않네요. (현재 서버 RAM: 2GB / 평균 30% 이하로 사용중)
  • 사용자가 검색한 키워드 혹은 doi를 적절한 url 형태로 만들어서 queue에 담습니다.
  • SearchBatcher 는 키워드로 검색하기 위한 url을 queue에 담으며, 한번의 요청당 최대 1,000*SEARCH_BATCH_SIZE 개의 논문정보를 가져옵니다.
  • DoiBatcher 는 doi로 검색하기 위한 url을 queue에 담으며, 한번의 요청당 최대 1 * DOI_BATCH_SIZE 개의 논문 정보를 가져옵니다.
    • 논문 정보를 가져올 때, status code가 404이면, crossref에 없는 논문이므로 재요청을 하지 않습니다.
    • 그 외에 error에 대해서(ex request timeout)는 MAX_RETRY 만큼 시도할 때까지 큐의 맨 뒤로 담습니다.
  • depth가 깊어지는 (ex: 다음 cursor로 이동, reference를 타고 검색) 구조로의 검색 url은 queue의 오른쪽으로 담고, 사용자의 검색은 왼쪽으로 담습니다.
    • 장점: 사용자가 검색한 내용이 서버에서 crossref로 요청을 보낼 때 우선순위를 갖게 되어 db에 빠르게 반영될 수 있습니다.
    • 단점: 사용자에 의해 SEARCH_BATCH_SIZE 혹은 DOI_BATCH_SIZE 보다 많은 검색요청이 들어오는 경우, 사용자에 의해 먼저보내진 요청요청이 나중에 오게될 수도 있습니다. (이 부분까지는 오버엔지니어링으로 생각했습니다.)
• 사용자가 반복된 키워드로 검색할 때, queue에 항상 검색 url이 담기는 것을 방지해야했습니다.
  • 검색 키워드에 대한 TTL은 24시간으로 설정했습니다.
• elasticservice에는 batch 작업 단위로 bulk insert합니다.
• process.env.ALLOW_UPDATE는 default가 false이고, elasticsearch에 doi가 이미 존재하면 update(덮어쓰기)하지 않습니다.
• 기존 test code가 통과하도록 변경했습니다.

이후 작업이 필요한 내용

• 추후, batch service에 대한 test 코드가 필요합니다.
• Crossref로부터 too many request를 받았을 때 처리하는 로직이 필요합니다.
• elasticsearch query에 citations 내림차순으로 정렬이 필요합니다. 문서

  리뷰 요청사항

• 환경변수 ALLOW_UPDATE 추가 필요
• batch 로직