리승자이의 삽질 그리고 정리

개요 회사의 기술스택에서 카프카를 사용하고 있다. 내가 이번에 정리하는 글은 막연하게 ack을 날리는 부분에 있어서 간과했던 로직 때문에 벌어진 이슈를 정리한다. 어떻게 로직이 생겼었는가? 우선 카프카를 사용하기 위해선 스프링 부트에서 Spring for Apache Kafka 를 사용해야 한다. 나는 로직에서 try-catch-finally 를 붙여 사용했는데 동료 개발자분께서 의도하신 것인지는 모르겠으나 catch절을 빼고 로직을 구성했다. @KafkaListener public void consumeExample(final ScrapeUpdateDto dto, final Acknowledgement ack) { try { // do something } finally { ack.acknowledge..

회사에서 어떻게 하면 좀 더 편하게 어떤 기능을 사용하게 할 수 있을까? 라는 생각이 계속해서 들었는데, 좋은 기회가 생겼다. 회사에서 영업을 하시는분들이 컨퍼런스, 세미나 등등을 많이 참석하여 홍보하고 고객을 유치하는 과정에서 기회가 생겼다. 그것은 회사의 카드를 발급을 받았는지에 대한 여부 확인을 따로 할 수 없었다는 것인데, 당연히 그럴 것이 회원가입할 때 법인 유무를 체크하지는 않으니 말이다. 그래서 종이로든 아니면 엑셀시트던 특정 자료를 세미나 전에 준비해서 가는 부분이 매우 불편해보였다. (갈 때마다 추가 법인이 있으니까 매번 정리해야 된다.) 자! 그래서 슬랙에서 /법인찾기 법인명 하면 우리에게 가입된 법인인지를 찾는 기능을 구현하고 싶었다. 그래서 데모로 슬래시 커맨드를 만드는 법을 데모로..

의문점 스크래핑 로직 실행 시간에 대해 의문을 가졌다. 평균 시간이 그럭저럭 다들 비슷한 수준에 머무는데, 이상하게 한 부분만 너무 느렸다. 증권사에 대한 스크래핑 내역이었는데, 특정 증권사만 중복 로그인이 감지되었을 경우 30초를 대기했다가 다시 수행할 수 있게 하는 로직이 들어있었고, 테스트 코드는 그에맞는 정말 30초를 기다리는지에 대한 여부를 테스트 하고 있었다. 🤔 그냥 30초를 기다리는것보단 특정한 법인이 아니라면 30초를 기다리지 않는다 를 테스트하면 되지 않을까? 이렇게 생각했던 이유는 30초를 테스트에서 기다리는 비용이 비싸다고 생각했고, 전체 테스트를 돌릴 때 이 부분때문에 30초를 더 기다려야 한다는 것이다. 그리고 milliseconds 차이값을 비교했기에 간헐적으로 실패하는 경우도..

분산 락 회사에서 스크래핑 작업을 수행하다가 분산락을 구현하게 되어 너무 잦은 야근으로 인해 이제야 포스팅을 끄적여본다. 한번의 스크래핑요청은 곧바로 비용 + 시간이 요구된다. 비용이 요청때마다 들고, 내가 구현했던 정부기관의 스크래핑 시간은 길면 15초까지 걸리는 작업도 있다. (의존도가 너무 높은것도 사실이다) 이런 비용과 시간이 드는 스크래핑 작업을 동시 다발적으로 같은 작업을 수행해준다? 이것도 문제가 있을 것이다. 한번의 스크래핑 데이터를 계속해서 돌려쓰면 되지않을까? 이러한 스크래핑 데이터를 공유자원이라 생각했고 이미 요청중인 작업이 있다면 이미 작업중인 스크래핑이 있다고 오류를 내려주는게 오히려 적합하다고 생각했다. Synchronized 우선 Java에서 제공해주는 synchronized ..

예제는 깃허브에 있다. 트랜잭션을 공부했다고 생각하고 업무에 임했던 나였는데, 도저히 풀리지않는 느낌으로 예외를 받았던게 있다. 이전에 한번 포스팅했던 Stream Closed 에러였는데 이게 또 한번 나를 붙잡았다. 처음 개발환경에서 OpenFeign을 사용하면서 또 logging level에서 IOException이 나는줄알고 이부분으로 삽질을 했다. 근데 그게 아니어서 이 포스팅을 작성했다. HelloController.java @RestController @RequiredArgsConstructor public class TestController { private final TransactionParentService transactionParentService; @GetMapping("/tra..

1일1커밋 회고나 다른 회고는 작성했으면서 정작 연말에 한번씩 작성하는 회고는 이번이 처음인 것 같다. 어제는 회사에서 백엔드 팀끼리 회고를 진행했다!!! KPT 방식으로 진행을 했었는데, 바빠서 못했던 것들 그리고 문제적으로 좀 느끼고 있던 것들 위주로 Try 에서 3가지가 꼽혔다. 1. 테스트코드 2. 레플리카 DB 활용 3. 컨벤션 확립 테스트코드는 나는 단위테스트를 짜면서 개발을 진행했었는데, 다른 분들도 이제 유지보수가 점점 어려워지면서 테스트코드를 지금이라도 늦지 않았으니 꼭 짜자 라는 방식으로 안건이 나와 채택되었다. 레플리카 DB는 구성은 되어있으나 제대로 활용하지 않고 있었는데, 이번 기회에 내가 건의하여 이슈를 수면위로 드러냈다. 다들 의견이 동일하셔서 안건이 채택됐다. 3은 협업한다면..

회사의 서비스들이 여러개로 쪼개져있다. 그래서 우리는 주로 FeignClient를 사용하는데, 애를 먹었던 로깅레벨에 대해 포스팅한다. 업무중에 삽질을 진행했었으며, 해당 내용으로 자바스럽게 고쳤던 경험을 좀 풀어본다.. 스프링 프레임워크를 사용하고 있기에 여기서 같이 제공해주는 Spring Cloud의 OpenFeign을 사용하였다. 아래는 사용하는 예시이다. 해당 예시처럼 나는 FeignClient를 구현했었다. 물론 @EnableFeignClients 는 별도의 Configuration 클래스 파일에 설정을 해주었었다! 여기까지는 일단 기본적인 설정이지만, 아래의 레벨 설명이 진짜다. Feing Logging Level은 총 4단계로 이루어져있다. NONE: 로깅 없음(Default) BASIC: ..

개발자 삶의 두번째 컨퍼런스인 NHN Forward에 다녀왔다. 인프콘 때와는 다르게 한 공간에서 쭉 들었다. 백엔드 세션만 들어야겠다 라고 생각했는데 그 세션들이 전부 한곳에 모여있었다 ㅋㅋㅋㅋ 들어가자마자 체크인을 QR로 진행하고 키노트를 진행하는데 계속 서서 컨퍼런스 장소까지 가니 다리가 아팠는데 또 내내 서있었다. 점심먹고 들었던 세션인 분산 시스템에서 데이터를 전달하는 효율적인 방법 세션에서 RDB, RabbitMQ, Kafka를 통한 서로 다른 마이크로 서비스들의 트랜잭션을 어떻게 관리할 것인가에 대해 되게 재밌게 봤다. RDB로 사용하는 방법을 이번에 처음 보게되어 예전에 면접에서 받았던 질문이 이런걸 물어본 거였구나 하면서 아~ 하고 깨닫는 순간이었다. 메시지 큐를 사용하는 방법은 현재 내..

오랜만에 포스팅하는데 회사에서 그동안 앱 2.0 버전을 출시한다고 이래저래 바빴던 나날을 보냈다. 결과적으로는 만족스러운 출시..? 였던것 같다 ㅋㅋㅋ 버그도 많았고, QA 엔지니어께서 고생을 많이 하셨을 수도 있고 내가 구현한 메시지 플랫폼도 테스트하기가 정말 까다로웠다. 각설하고.. 해당 에러사항을 구현하는건 Kafka를 이용하지 않아도 되기 때문에 RestAPI로 구현했다. (+ 테스트코드로만) 모든 코드는 깃허브에 있다. 이번엔 무슨 버그였냐? 이런 에러가 쏟아져나왔다. 기존 레거시 푸시는 NHN Toast를 이용한 푸시서비스로 구성되어 있었다. 변경한다고 해도 과도기가 존재하기 때문에 바로 지울수는 없고 이전 앱을 사용하는 사용자들에게는 해당 푸시로 알림은 계속 받아야되기 때문이다. 왜 났던 에..

저번 포스팅의 마지막 마무리가 바로 이 에러를 찾지 못했던 것이다. Kafka 에러를 고치게 된 시점 처음에 특정 Consumer만 consume을 못한다고 했었는데, 이는 당연 잘못된 것이었다!!! 그냥 로그를 좀 더 세세하게 찍고 검토를 더 열심히 했어야 했다! 우선 대략적으로 코드를 보면 아래와 같다. @KafkaListener(topics = "topic", properties = { "spring.kafka.consumer.properties.spring.json.type.mapping=com.github.lsj8367.MessageReq" }) public void consumeSomething(final MessageReq req, Acknowledgment acknowledgment) { ..