슬라이딩 윈도우 로그 처리율 제한에 대해서 정리하려고 합니다.Sliding Window Log Rate Limiter는 뭘까?Fixed Window(고정 윈도우)와 달리 고정된 시간 구간이 아닌 현재 시점을 기준으로 과거 N분간의 요청 기록을 실시간으로 추적하는 방식 입니다. 5분 슬라이딩 윈도우 예시는 다음과 같습니다. 현재 시각이 09:03:30 이라면09:03:30 기준으로 08:58:30 ~ 구간의 요청들을 확인해서09:04:00이 되면 08:59:00 ~ 09:04:00 구간으로 윈도우를 슬라이딩합니다. 동작원리마찬가지로 사이드 프로젝트에서 슬랙 알림 중복 발송 방지를 위해 사용하였습니다.Fixed Window의 문제점들을 해결하기 위해 개선된 방식을 적용했습니다. ConcurrentHashMa..
ConcurrentHashMap
지난 글에 Rate Limiter 성능 문제를 해결하기 위해 Caffeine 캐시를 도입했습니다.처리율 제한 시스템을 설계했을 때 어떤 알고리즘이 있으며, 어떤 이유로 선택했는지 정리하려고 합니다. 1. 왜 Rate Limiter를 직접 구현하게 되었는지?평소에 하던 업무에서 다음과 같은 부분을 중점으로 설계하고 구현한 적이 없어서 따로 고민해보지는 않았었습니다.다만, 사이드 프로젝트에서 슬랙 알림 연동을 마치고 예외나 배치 스케줄러가 종료했을 때 알림이 중복으로 발송되는 것에 대해 생각을 해보았습니다. 그래서 ConcurrentHashMap 형식으로 알림 발송 현황을 저장하는 방식을 선택해보았습니다. 처음 구현 코드에서는"고정윈도우 + 슬라이딩 요소"를 담았습니다. 고정 윈도우적 특성각 키별로 첫 ..
예외가 발생했을 때 알림을 슬랙과 연동하는 기능을 구현하면서, 처리율 제한(Rate Limiter) 을 도입하였습니다.https://medium.com/@anil.goyal0057/rate-limiter-sliding-window-logs-algorithm-using-deque-58831661b9eehttps://www.codereliant.io/p/rate-limiting-deep-dive?utm_sourcehttps://medium.com/%40shivammishra20121999/rate-limiter-696870cb99a2 이번 글에서는 현재 개발중인 RateLimiter의 성능 병목점을 분석하고, 이를 개선하기 위한 여러 방안을 비교해보겠습니다. 현재 구현의 문제점매 요청마다 전체 맵을 순회현재..
1편 - 예외 알림 슬랙 연동으로 가볍게 운영하기https://buly.kr/9tBJYQC 들어가며지난 글에서는 Slack 알림 시스템을 만들고, 동일한 예외가 반복해서 발생하더라도 알림이 중복으로 발생하지 않도록 처리율 제한 클래스를 만들었습니다. (SimpleRateLimiter) 단일 서버 환경에서는 기대한 대로 잘 작동했습니다. 근데 배포 전에 한번 더 생각해볼 점이 있다고 생각했습니다. 잠재적 문제점들에 대해서 분석한 점을 정리해보겠습니다. 어떤 문제가 예상될까?서버별 독립 동작private final ConcurrentHashMap alerts = new ConcurrentHashMap();ConcurrentHashMap이 서버 간 데이터 동기화가 불가능하다는 직접적인 공식 문서는 없지만, J..
목표와 범위목표: 운영 상에서 발생한 예외를 "채널명"으로 실시간 알림이 오게 하고 싶었습니다.범위: 비즈니스 로직 상에서 선언한 커스텀 예외를 타겟으로 잡았습니다.스크린샷 ↓ 파일 구조⏺ src/main/java/com/eventitta/common/notification/ ├── config/ │ └── SlackProperties.java ├── domain/ │ ├── AlertLevel.java │ ├── SlackAttachment.java │ ├── SlackField.java │ └── SlackMessage.java ├── exception/ │ ├── AlertErrorCode.java │ └── SlackNotificationException..
