본문 바로가기

프로젝트

 (33)
어뷰징 대응의 시작 - 고정 윈도우 기반 Rate Limit 시범 운영기 1. 투표의 신뢰를 지키기 위한 첫 대응 이전 시상식 기간 중 매크로 사용과 다중 계정 생성 정황이 포착되었고, 행동이 이상한 일부 유저에 대해 CS 인입 및 커뮤니티 내 매크로 사용법 공유 사례도 있었습니다.회사의 투표 시스템 신뢰성 강화를 위해, 이러한 어뷰징 유저 탐지 및 단속의 필요성이 높아졌습니다. 2. 작게 시작한 시범 운영, 리스크를 최소화하다 이번 시상식에서 투표 기간 중에 시범적으로 어뷰징 탐지 시스템을 만들어 운영해보기로 했습니다. 처음 적용하는 시스템이면서 해당 시스템이 우리가 예상한대로 동작했을 때 이점보다, 동작하지 않았을 때 리스크가 더 크다고 판단이 되었기 때문입니다. 고정 윈도우 기반의 간단한 탐지 체계를 구성해 특이 행동을 모니터링하고, 개발자가 수동으로 판단 및 조치하는 ..
반복되는 장애, 우리는 어떻게 대응하고 있을까? 1. 장애 대응 과정에서 보였던 한계들우리 팀은 주로 고객센터(CS) 인입을 통해 장애를 인지하곤 했다. CS 인입이 없으면 문제를 모르는 경우도 많았고, 문제가 확인된 이후에는 개발팀이 임시 조치를 한 뒤 사용자에게 안내하는 방식이 반복되었다. 처음에는, 이 방식이 자연스럽다고 여겼지만 반복될수록 여러 문제점이 보이기 시작했다. 💢 CS 인입 정보 공유 지연예를 들어 5월 19일에 들어온 고객 문의가 4~5일 뒤에야 저에게 전달되었고, 그사이 대응이 늦어질 수밖에 없었다. 💢 상황 공유의 부재개발팀에서 조치하고 있는지, 근본 원인이 무엇인지 등 중요한 정보가 CS팀과 공유되지 않았다. 이에 따라 CS팀은 사용자에게 명확한 설명을 할 수 없어 불완전한 대응으로 이어졌다. 💢 임시 조치 후 회고 없음..
개발 환경의 시간대 차이가 만든 버그: LocalDateTime 이슈 해결기 1. 문제 사항중국 음원 사이트에서 데이터를 수집해 차트 정보를 생성하는 스크래핑 로직이 있었는데 로컬에선 정상 작동하지만 서버 환경에서는 예상과 다르게 동작하는 이슈가 있었습니다. 스크래핑 대상 사이트는 요청 시 현재 시간을 기준으로 ±15분 범위 내의 요청만 허용하는 정책을 갖고 있었고 이 로직에서는 해당 기준에 맞는 현재 시간을 생성해 요청 값에 포함시켜야 했습니다. 함께 작업하던 동료가 시간 생성 방식에 문제가 있을 수도 있다는 점을 짚어주었고 함께 해당 부분을 확인해 보았습니다. 실제로 시간을 생성하는 로직에서 LocalDateTime.now()를 사용하고 있었고 이로 인해 로컬(UTC+9)과 서버(UTC)의 시간대 차이로 서버에선 조건을 만족하지 못하는 요청이 만들어지고 있었습니다. 이 문제를..
코틀린 Data Class와 Mybatis 같이 사용할 때 주의점 Mybatis 기본 생성자가 없는 경우Mybatis에서는 기본 생성자가 없는 경우 Mapper에 정의된 규칙을 사용하지 않는다. 주 생성자의 파라미터와 조회해 온 데이터를 순서대로 매핑을 한다. DefaultResultSetHandler 클래스에서 createResultObject를 통해서 확인을 할 수 있다.hasDefaultConstructor 메서드는 파라미터 개수가 0인 생성자 여부를 알려주며, 이것이 충족하지 않을 때 Mybatis에서 정한 규칙에 따라 자동으로 객체와 데이터를 매핑을 해준다.   ✅ DefaultResultSetHandler.java private Object createResultObject(...){ if (hasTypeHandlerForResultObject(rsw, r..
Redis Scan으로 Key 삭제하기 무엇을 하고 싶은가?버그 수정 및 적용을 위해 실서버 환경에서 Redis 캐시(데이터) 갱신이 필요했다. 캐시 전략은 Cache-aside Pattern을 사용하고 있기 때문에 삭제를 통해 필요한 유저만 갱신하기로 했다. 패턴 조회를 통해 필요한 버그에 관련된 key값만 골라 삭제해 주기로 했다. 어떻게 할 수 있는가?패턴을 통한 삭제는 Redis 명령어 keys, scan을 통해서 처리를 할 수 있다. keys를 사용하면 전체 키를 조회해서 삭제를 할 수 있지만, Redis는 기본적으로 싱글 스레드로 동작을 하기 때문에 key가 많을 경우 다른 요청을 받아서 처리할 수 없는 특징이 있다. 실제 운영이 되고 있는 Redis에 keys를 날릴 경우 서비스에 장애를 가져다줄 수 있다. 운영 서비스에 영향을 ..
시간 유효성 검사에서 시간 값 생성 시점 생각하기API 요청은 상품의 만료 기간이 "12:00"라고 가정 했을 때 "11:59 59.959"에 들어온 요청은 상품을 사용할 수 있도록 해주어야 하는 것일까? 사용자 입장에서는 정상적으로 상품 사용이 가능해야 한다. 회사 서비스에서는 저와 같은 상황을 연출하고 테스트 했을 때 상품을 사용할 수 없었다. 이유는 비교해야 하는 현재 시간을 API 호출 시점이 아닌 유효성을 검사할 때 생성해서 사용을 하고 있었기 때문이다. 유효성으로 가는 과정에서 "12:00"가 지나버린 것이다.사용자를 중점으로 이루어져야 하는 것이 서비스이기에 위와 같은 경우 상품을 사용할 수 있도록 해주는 것이 맞는 것 같다. 그래서 문제가 되는 기능이라고 생각을 해 수정 요청을 했다. 생성 시점은 언제로?생성 시점은 언제로 해야할..
불변 객체와 깊은 복사를 사용 해야 하는 이유 문제 & 원인상품을 획득하는 과정에서 리워드가 지급해야 하는 것보다 더 많이 발급이 된다는 것을 확인이 되었다. 리워드를 지급하는 로직에서 Redis에 캐싱해 둔 데이터 객체 내부 값을 변경하여 사용하고 있었다.변경된 객체로 Redis 캐시를 업데이트 하지 않았기 때문에 초기에 작성했을 때는 버그를 발생시키는 않는 로직이었을 것이다. 하지만 추후에 또 다른 개발자 분이 Redis의 부하를 줄이고자 인메모리 캐싱을 추가하였다. 리워드 보상에서 사용이 되는 데이터가 계속해서 업데이트 되어 인메모리 캐시에 저장이 되었고 이 때부터 문제가 발생하게 된 것이다.불변 객체불변 객체 장점은 로직을 처리하는 과정에서 객체 내부의 값이 변경이 되었을 때 발생하는 사이드 이펙트를 방지할 수 있기에 코드의 안정성을 보장할 ..
Github PR을 했을 때 Slack 알림 보내기 사이드 프로젝트에서 PR 알림 필요사이드 프로젝트에서 PR를 통해 코드 리뷰를 진행을 하고있다. PR이 되었을 때, 메일을 통해서만 전달이 되기 때문에 확인하고 리뷰를 남기는 것에 불편함이 있었다. 메일보다 더 접근성이 있으며, 쉽게 적용해볼 수 있는 것을 찾아보니 Slack이 가장 적합하다고 판단했다.Slack 알림 추가1. Slack에서 GitHub 앱 추가하기MarketPlace에서 Github을 검색하여 설치할 수 있다.https://challenge-team-talk.slack.com/marketplace/A01BP7R4KNY-github 2. Slack과 Github 연동하기Github 게정에 인증코드를 요청하고 입력하면 연동을 완료할 수 있다. 3. 적용 채널에 명령어 날리기알림을 받고 싶..

티스토리툴바