TL;DR — 인계받을 때 채점 워커→서버 결과 회신이 HTTP POST(3회 retry + API 키)로 남아 있었다. 워커 최적화 작업 중, 유실·의존·장애 전파 측면에서 Kafka가 낫다고 판단해 grading-result 토픽 produce/consume로 바꿈. 워커 6종의 retry 로직·API 키·콜백 엔드포인트가 사라졌다(+58 / −222줄).

배경

• 프로젝트/기능: CodeQuest 채점 파이프라인. 서버가 제출을 워커로 보내고(이미 Kafka submission-* 토픽), 워커가 채점 결과를 서버로 회신한다
• 인계 시점: 결과 회신만 HTTP POST(/api/submit/result)로 남아 있었다 — 디스패치는 Kafka, 회신은 POST로 혼재
• 환경: Spring Boot, Kafka, Kubernetes(워커 5종 + KEDA 오토스케일)

문제 (기존 POST 구조의 약점)

• 유실: 서버 다운/일시 장애 시 워커가 3회 retry(1s) 후 실패하면 채점 결과가 영구 유실 — 채점은 끝났는데 점수가 반영 안 됨
• 의존/결합: 워커가 서버 주소(RESULT_ENDPOINT)와 API 키(RESULT_API_KEY)를 알아야 함
• 장애 전파: 서버가 느리거나 죽으면 워커가 동기 호출에 묶여 영향받음(채점 처리량 저하)
• 부가 비용: 콜백 엔드포인트(공격 표면) + ApiKeyFilter 유지

판단 (왜 Kafka)

• 디스패치(서버→워커)는 이미 Kafka라, 결과 회신만 POST로 남은 건 일관성 결여
• 워커 최적화(JVM 기동 등) 작업 중 결과 경로도 같이 손보면서, 비동기 메시지 큐가 유실·결합·장애 격리 모두에 유리하다고 판단

해결 (CQ-47, c37864b)

워커: HTTP POST(3 retry) → Kafka produce 단일 호출

// before: HttpURLConnection POST + for(attempt=1..3) retry, RESULT_ENDPOINT/RESULT_API_KEY 필요
// after: grading-result 토픽으로 produce
sendResult(producer, submitId, score, error, executionTime);

서버: POST 콜백 제거 → @KafkaListener 소비

@KafkaListener(topics = "grading-result", groupId = "submit-service")
public void handleGradingResult(String message) throws Exception {
    ReceiveResultForm form = objectMapper.readValue(message, ReceiveResultForm.class);
    receiveSubmitResult(form);
}

제거된 것: SubmitController의 POST /api/submit/result, ApiKeyFilter의 RESULT_API_KEY 검증, 5개 K8s deployment의 RESULT_ENDPOINT/RESULT_API_KEY env, 워커 6종(python/c/cpp/cs/java)의 HTTP retry 로직

결과