Work
-
[번역 서비스] 로직 구현 시 고민한 부분Work 2025. 1. 30. 22:11
https://fordevelop.tistory.com/218 를 하며 고민한 부분에 대해 정리한 글이다. Q. 번역 실패 게시글을 어떻게 판별할까?상황번역 상태 정보는 게시글의 필드로 관리된다. (게시글의 번역 상태 값 : 번역 전, 번역중, 완료)번역상태 != 완료인 게시글을 무조건 번역 실패라고 할 수 있는가?할 수 없다.게시글 수정이 발생했을 때 번역 상태 필드가 초기화된다.번역 지연 시간이 존재하기 때문에 완료 상태가 될 때까지 시간이 소요된다. 방안번역 처리 완료 예상 시간이 지났는데 번역상태 != 완료인 게시글을 번역 실패라고 판단한다.이를 위해 번역 상태 업데이트 시간 정보를 추가한다. 적용 > 게시글의 번역 관련 정보 관리 방식 (필요 정보 : 번역 상태, 번역 상태 업데이트된 시간)1)..
-
[번역 서비스] 적용 - Delayed Retry TopicWork 2025. 1. 28. 22:03
개요Quarkus Kafka 라이브러리의 Delayed Retry Topic 전략을 적용해 재시도를 구현한 내용을 설명한다. 사전 개념Quarkus는 SmallRye Reactive Messaging 프레임워크를 통해 Apache Kafka와의 통신을 지원한다.Quarkus에서 Kafka와의 통신을 위한 kafka connector 기능을 제공한다.어플리케이션은 message를 주고받는다.message는 payload를 포함하고 있고 metadata를 포함하도록 확장될 수 있다.kafka와의 통신에서 하나의 message를 kafka record와 매핑한다.message는 channel을 통해 전송된다.message를 발행하고 컨슘하기 위해 어플리케이션 컴포넌트가 channel과 연결된다.kafka co..
-
[번역 서비스] 개선 - 번역 실패 모니터링 및 재처리Work 2025. 1. 9. 10:06
문제점 정의번역 로직 플로우는 아래와 같다. 현재 구조는 아래 3가지 문제점을 가지고 있다.모든 번역 실패 케이스에 대한 수동 재처리 필요일시적인 네트워크 에러 등 일정시간 이후 복구가 가능한 경우 자동 재처리 적용 가능함번역 요청 유실 가능성처리 중 서버가 다운되었을 때 에러 로깅조차 남길 수 없음번역 미완료 건을 확인하는 로직이 없어 서버 재시작 이후에도 번역을 다시 수행할 수 없음번역 결과 콜백 미수신 모니터링 불가능번역 콜백 미수신 확인 로직이 없어 모니터링 불가능함 개선 방향성번역 자동 재처리를 통해 수동 조치의 비효율성을 개선한다.정해진 재처리 횟수를 초과한 경우 원인을 파악하고 번역을 수동으로 생성한다.유실되는 번역 요청이 없도록 한다.번역 결과 콜백 미수신 모니터링이 가능하도록 한다. 작업..
-
[번역 서비스] 개선 - 번역 실패 모니터링 아키텍처Work 2025. 1. 8. 23:48
개요번역 실패 모니터링을 위한 아키텍처를 설계한 과정에 대한 문서이다. 구성 방안1) 번역 실패 모니터링 스케줄러1대의 스케줄러가 게시글을 조회하고 번역 재처리를 수행하는 구조 문제점번역 실패 게시글이 많아질 경우 번역 처리 서버에 부담을 줄 수 있음 (다음 스케줄링 시간 전까지 작업이 완료되지 않을 수 있음)번역 재시도 횟수 기준 번역 재처리를 위한 추가 구조가 필요함 2) 여러 대의 스케줄러 기반 아키텍처여러 대의 스케줄러를 두어 번역 실패 재처리를 나눠서 수행하는 구조 문제점여러 대의 스케줄러가 동일한 DB를 조회하므로 중복 조회하지 않도록 조회 분기 처리가 필수적임여러 대의 스케줄러가 동시에 번역 요청을 하게 되면 번역 서비스에 부담을 줄 수 있음번역 재시도 횟수 기준 번역 재처리를 위한 추가 구..