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

의문점 스크래핑 로직 실행 시간에 대해 의문을 가졌다. 평균 시간이 그럭저럭 다들 비슷한 수준에 머무는데, 이상하게 한 부분만 너무 느렸다. 증권사에 대한 스크래핑 내역이었는데, 특정 증권사만 중복 로그인이 감지되었을 경우 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) { ..

일전에 카프카 에러 포스팅 에서 Configuration 설정을 자바 클래스에서 해주었다. 그것도 클래스별로!! 에러 포스팅과 더불어 This error handler cannot process 'SerializationException's directly; please consider configuring an 'ErrorHandlingDeserializer' in the value and/or key deserializer 이런 문구도 출력해줬었다. 근데 저 에러 포스팅을 보면서 좀 더 공통화할 수 없을까에서 찾아보다가 ErrorHandlingDeserializer 관련 검색을 해보다가 문서에서 찾게 되었던게 있는데, 기존의 설정을 이미지로 한번 가져와봤다. 그런데 이 방법을 Listener가 늘어나..

현재 회사에서 spring-kafka 를 이용해서 특정 서비스들의 푸시 메세지 이벤트를 받아서 전송해주는 서버를 구현하고 있다. (오늘 쿠버네티스에 배포까지 했다!! 모르는게 너무많은...) 로컬에서 내 맘대로 메세지 토픽을 발행해서 쏴도 잘 맞게 역직렬화를 수행을 해주길래 그냥 그런가보다. 하고 잘 넘어갔던 찰나에!!! Class Not Found Exception 왜? 이 에러가 났을까? 일단 나는 구독하는쪽 그러니까 Kafka에서는 Consumer 쪽 만을 구현해주었다. 내 지식이 부족했던 탓인지는 모르겠지만, 어쨌든 같은 JSON 형태라고 생각해서 클래스가 무엇이던 간에 JSON형식만 같다면 Consume해도 괜찮을 것이라고 처음 생각했었다. 그래서 발행 모델인 Producer쪽에서는 예를 들면 ..