팀플) 캘린더에 유성우 일정 업데이트.

일단 유성우든 대접근이든 한번에 요청해야하는 데이터량이 적지는 않을 것이라 판단한다.

그럼 API 호출을 여러번 하게 되고, 그건 성능과 비용문제로 직결됨.

그래서 이번에 도입해놓을 것은 Betch임.

---

Batch가 유용한 상황

1. 대량의 이벤트 추가/수정/삭제:
   • 유성우나 행성 대접근 데이터처럼 수십 개, 수백 개의 이벤트를 한꺼번에 처리해야 할 때.
   • 개별 요청을 보내면 네트워크 부하와 속도 문제가 생길 수 있는데, Batch로 묶으면 한 번에 처리 가능.
2. API 호출 비용 절감:
   • 구글 캘린더 API는 호출 횟수 제한(쿼터)이 있음.
   • Batch를 사용하면 여러 요청을 하나의 HTTP 요청으로 합쳐 보내므로 쿼터 소모량 감소.
3. 일관된 데이터 처리:
   • 여러 이벤트를 처리하는 중 일부 실패할 수 있음.
   • Batch를 사용하면 요청 단위로 성공/실패를 관리할 수 있어 안정적.
4. 네트워크 부하 감소:
   • 개별 요청을 반복적으로 보내는 대신, 한번에 묶어서 처리하면 네트워크 부하를 줄일 수 있음.

---

Batch와 기존 방식 비교

기준	개별 요청 방식	Batch 방식
속도	요청이 많을수록 느려짐	대량 데이터를 한 번에 처리하므로 빠름
네트워크 비용	요청마다 HTTP 연결 설정 및 데이터 전송	한 번의 연결로 여러 작업 처리
쿼터 관리	요청 수만큼 쿼터 소모	한 번의 요청으로 쿼터 소모 최소화
유지보수	각 요청 성공/실패 처리 코드가 복잡할 수 있음	성공/실패 결과를 묶어서 관리 가능
적합한 상황	소규모 작업 (몇 개의 이벤트 처리)	대규모 작업 (수십~수백 개의 이벤트 처리)

---

Batch를 활용하는 대표적인 사례

1. 유성우 데이터를 구글 캘린더에 동기화:
   • 예를 들어, 1년 동안 발생할 유성우 데이터를 캘린더에 추가하려면 수십 개의 이벤트를 생성해야 함.
   • 개별 addEvent 호출 대신 Batch를 사용해 한 번의 요청으로 모두 추가.
2. 행성 대접근 이벤트 업데이트:
   • 대접근 시기 데이터가 업데이트될 때 여러 이벤트를 동기화해야 함.
   • Batch로 구글 캘린더와 DB 데이터를 한꺼번에 동기화.
3. 구글 캘린더 정리:
   • 오래된 일정 삭제, 중복 일정 제거 등 대량 삭제 작업도 Batch로 빠르게 처리 가능.

---

Batch 도입 시 고려 사항

1. 데이터량 제한:
   • 구글 캘린더 Batch API는 요청 크기에 제한이 있으므로, 대량 데이터를 처리할 때는 적절히 나눠서 처리해야 함 (예: 50개씩 Batch).
2. 재시도 로직:
   • Batch 요청에서 일부 작업이 실패할 수 있으므로, 실패한 작업을 재시도하거나 오류를 기록하는 로직 필요.
3. 성공/실패 관리:
   • Batch 요청 내 각 작업의 성공/실패를 별도로 관리해야 함.

---

결론

• 대량의 데이터를 한꺼번에 처리해야 하는 경우 Batch는 성능과 효율을 크게 개선해 줌.
• 소규모 작업은 기존 방식으로 충분히 처리 가능하므로, Batch는 필요한 경우에만 활용하는 게 좋음.
• 프로젝트에서 유성우와 행성 데이터를 다룰 때, 한꺼번에 여러 일정을 추가/수정/삭제하는 상황에 Batch를 도입하면 효과적.

---

여튼 그래서 일단은 Batch를 구축해두고 Meteor로직에서 클래스 따로 나눠서 DB 업데이트용으로 따로 만들고, 그 데이터를 캘린더에다가 짚어넣는걸 성공하면 됨.

---

그래서 대충 만들고 테스트 해봤는데 primary가 아니면 오류나는걸 테스트 해보고알았음..

그래서 그냥 이벤트카테고리는 DB에만 저장하도록 로직을 바꿨고 DTO에 캘린더 ID 다시 만들어서 primary로 고정되게 바꿨음.

잘 되는구만..

여튼 바꿔서 해결 했고 이제는 유성우 데이터를 Batch에다가 엮어서 보내주면 됨!

---

우선 유성우 컨트롤러와 서비스에서 로직작성을 끝냈고 테스트 해보면 된다.

컨트롤러에서 요청을 받으면 유성우 서비스에서 값 찾고, 세팅하고, 캘린더 서비스로 보내고 반환받는다고 생각하면 됨.

오씨 뭐지? 한번에 성공했는데 불안하게

데이터 세개였는데 여기도 정상적으로 들어있고,

DB에서도 정상적으로 데이터가 들어있음.

지금은 Best 타임 기준으로만 넣었고 이제 피크타임기간도 함께 들어가게끔 설계해주면 좋을듯해서 해당 로직 추가해서 테스트해봄.

---

오케이 잘된다.

이렇게 들어감!

그럼 백엔드는 대충 마무리되었고 이제 화면으로 넘어가면 될듯.

추후에 이 작업을 스케줄러로 처리하게끔 해야되고 또 위치도 38,127 것만 찾아서 캘린더로 저장하게끔 해야됨.

근데 일단은 넘어가자.