삶을 개발하는 Developer

기력과 의욕은 충분히 쉬었다는 만족감 으로부터 회복된다. 그간 정립해온 나만의 방법이 있기는 하나 (충분한 수면, 회고 등의 생각 정리)같은 패턴속에서도 더 큰 만족감을 얻고자 하는 주간이 있는 것 같다. (지나친 보상 심리의 발동)아마, 다른 때보다 더 많은 에너지를 쏟은 주이지 않을까한다. 이때는 복잡한 생각들을 완전히 off 하고 싶다는 마음이 자연스레 쉽고 편한 방향으로(도파민을 쫓는 행위 등) 풀릴 때가 있다. 평상시에는 그런 행동들의 제어가 보다 쉽기 때문에 괜찮지만,이번 주와 같이 지나친 보상 심리가 발동할 때는 제어가 쉽지 않을 수 있다. 또, 그런 행위의 결과는 주말 컨디션에 영향이 있다. 자연스레 그렇게 되는 이유가 쉽고 편한 방법이어서 이기도 했겠지만, 그것말고 다른 방법을 찾지 못해..

결제 키가 중복해서 저장되는 원인 분석하면서 느낀점분석과정에서 여러 방법들을 활용합니다.Loki(로그), 묶혀있던 로그 테이블, ...요청 별 로깅의 중요성실제로 그런 값을 받았는지, 내부적으로 그렇게 처리한 것인지 확인에 용이했음요청 데이터와 적재된 데이터들 간의 관계를 따져보면서 이상 현상들을 확인함결제 실패 시, 결제 재시도마지막으로 재시도된 데이터만 관리됨.동일 pgRequestId 로 재요청결론: 실제로 서버로의 요청/응답 이력들이 원인을 분석하는데 도움이 많이 됐다.그간 불필요하다고 생각했던 로그 테이블의 뜻밖의 활용socar-payment socar-pg 간 연결고리가 pg_request_id 이다.socar-pg 에서 중복해서 결제 요청된 사실 발견 (다행히 중복 결제 요청해도 결제 실패..

SQS 적용 과정에서 아래와 같은 중복 수신 상황을 다룬 과정을 소개하려고 한다. 아래와 같이 동일한 바디(Message Body)를 가진 메세지를 중복하여 수신할 수 있는 상황이 존재한다. Source Queue 에서 처리 완료되지 못한 메세지를 MaxReceiveCount 만큼 재시도한다. 메세지 처리 불가 상태로 추정되어 DLQ 로 이동된 이후에 재시도된다. 메세지가 Visibility Timeout (가시성 타임아웃) 내에 정상적으로 처리되지 못하여 재시도되는 상황은 다음과 같다. 메세지 처리시간이 Visibility Timeout 을 초과할 경우 메세지 처리 중, 예외가 발생했을 경우 재시도 상황 1 설명에 앞서, Visibility Timeout 이 무엇이고, 어떻게 동작하는 것이며, Visi..

일반적으로 요청받는 서버에서 단시간에 지나치게 높은 호출 빈도를 제어하기 위한 목적으로(throttling) RateLimiter 를 사용하고 있다. RateLimiter 는 Guava 라이브러리에서 제공하는 유틸리티로, 외부 서버로의 API 호출을 제한하기 위해 자주 사용된다. RateLimiter 를 이용해 호출 빈도 제한 방법 의존성 추가 우선, RateLimiter 는 Guava 라이브러리 내에 존재하는 유틸리티기 떄문에 이를 사용하기 위해 Guava 라이브러리 의존성을 추가해야 한다. implementation("com.google.guava:guava:31.0.1-jre") RateLimiter 인스턴스의 생성 // 1초당 2회로 제한하는 케이스이다. // 넘겨 주는 인자는 permitsPer..

코루틴을 프로젝트에서 사용하다보면, 일시 중단 함수를 테스트하거나 테스트 코드 내부적으로 호출해야할 일이 빈번하게 발생한다. 하지만, 테스트를 진행하는 JUnit 환경에선 테스트 함수가 일시 중단 함수가 아니기 때문에 의무적으로 최상위 코루틴 스코프를 생성해 해당 스코프 내에서 일시 중단 함수를 호출해야 했다. @Test fun test() { runBlocking { // 일시 중단 함수 호출 // 일시 중단 함수 호출 } } 문제 - 테스트 코드 내에서 delay() 함수를 사용 이런 처리를 일일이 해야하는 것에 번거로움을 느낄때쯤, 기대한 처리가 완료될 때까지 대기하는 delay(1000) 함수를 테스트 코드 내에서 사용해야할 일이 발생했다. 사내에서 제공하고 있는 구매 서비스는 기본적으로 구매 요..

문제 상황 3/9 일 경, PM 분들에게 네이버페이 이용건 중 결제 후 바로 결제 취소 처리되는 이슈를 넘겨받게 되었습니다. 해당 케이스를 조금 살펴 보니 카셰어링(쏘카) + KTX 상품을 묶음으로 구매할 때, 네이버 페이 포인트를 포함한 결제를 진행하는 경우 포인트 작액 부족에 의해서 결제 실패가 되었고, 이에 따라 결제 취소 API 가 바로 호출되고 있었습니다. 해당 케이스에 경우, 내부 로직 상 묶음 상품(카셰어링 + KTX 상품1 + KTX 상품2) 에 의해 총 3번의 결제가 이루어져야 했는데, 카셰어링 + KTX 상품1 에 대해서만 결제가 성공하고, KTX 상품2 는 결제가 실패한 상태였기 때문에 한건에 결제 실패에 의해 나머지 결제가 성공한 건들 모두 결제가 취소되어야 하는 상태였습니다. 이에..

이번에 php 코드로 동작하고 있던 만료 예정 크레딧 발송 코드를 kotlin 으로 리팩토링하는 작업을 진행했다. 리팩토링이 필요한 코드는 총 1일, 7일, 30일 후에 만료되는 크레딧을 보유하고 있는 사용자에게 크레딧 만료 예정 알림톡을 보내주는 코드로 11000 ~ 14000건 정도를 매일 11시에 발송하는 코드이다. 1일 후 만료(5000 ~ 6000건) 7일 후 만료(5000 ~ 6000건) 30일 후 만료(1000 ~ 2000건) 코드를 확인해보니 만료 예정 크레딧을 받아오는 코드가 페이징 처리되어 있었고, 조회해온 Page 사이즈만큼의 크레딧에 대해 만료 예정 알림톡을 순차적으로 보내준 뒤, 반복적으로 다음 Page 리스트에 대해서도 동일 처리를 진행하는 코드로 파악이 되었다. 하지만, 100..