2GB 서버를 지키는 가장 싼 방법 Rate Limiter 도입기

2GB 서버를 지키는 가장 싼 방법 Rate Limiter 도입기

저희 서비스에 요청률 제한을 넣으며 어디에, 어떤 알고리즘으로, 초과 시 어떻게 결정한 기록입니다. 그리고 실제로 부하를 걸어 검증한 글입니다. 1. 왜 넣게 되었는가통합 검색을 개선하는 과정에서 조회를 최적화해도 동시 요청이 많아지면 결국 응답이 느려진다는 걸 체감했습니다.(관련 글: https://wo-dbs.tistory.com/419)통합 검색에서는 다음과 같이 SLO를 세웠었습니다.DAU 1,000 규모(피크 동시 약 50명)에서, 통합검색을 p95 700ms 이내로 SLI 95% 이상 유지 개선 한 후 동시 접속자를 30 → 110명을 5분간 램프업하여 부하 테스트를 했을 때 요청은 전부 성공했지만 동시 사용자가 늘수록 응답이 점점 느려졌습니다.동시 VU SLI상태30~100%여유50~99.5..

  • format_list_bulleted 프로젝트/toIT
  • · 2026. 7. 4.
  • textsms

Rate Limiter

1. Rate Limiter란정해진 시간 안에 허용되는 요청 수를 제한하는 장치입니다.목적으로는 다음과 같습니다.남용/DDoS 방어, 서버 자원 보호(특히 2GB 같은 저사양)공정한 사용(한 유저가 자원 독점 방지)비용 제어(외부 API 호출량 등) 그러면 위 목적으로 사용하되 분명히 알아야할 것이 있습니다.rate limiter가 요청이 왔을 때 어떤 걸로 카운터를 셀 것인가.이 요청에 대해 통과를 시킬까 막을까에 대한 수학적 방법 == 알고리즘알고리즘 코드가 어느 서버/ 어느 층에서 도느냐. 즉, 요청이 지나가는 경로 중 어디에 rate limiter를 심을 것이냐→ 그래서 Rate Limiter를 도입할 때는 다음과 같은 문장이 완성되어야합니다[3번. NGINX 에서] [1번. IP 기준으로] [2..

  • format_list_bulleted 프로젝트/toIT
  • · 2026. 7. 4.
  • textsms

Docker 및 Docker Compose 도입 - 7/1

들어가며저희 서비스의 운영 서버는 2GB인 한 대로 운영하고 있습니다. 하지만 성능을 업그레이드를 하면서 스펙이 점점 올라가기 시작했습니다. NGINX, Spring Boot, PostgreSQL, 그리고 관측성을 위한 Grafana Alloy까지 올라갔습니다여기에 검색 성능을 위한 Redis 고려와 CI/CD 파이프라인까지 붙이려는 시점이 되게 되었습니다.서비스가 이 정도로 늘어나니 서버에 그때그때 손으로 설치하고 실행하는 방식이 한계에 부딪혔습니다. 이 글은 그 한계를 어떻게 느꼈고 왜 Docker와 Docker Compose를 선택했으며 2GB라는 제약 안에서 어떤 선택을 했는지 에 대한 기록입니다. 1. 왜 Docker인가1.1 서비스가 늘어나면 수동 관리가 무너진다서버에 현재 다음을 전부 설치한..

  • format_list_bulleted 프로젝트/toIT
  • · 2026. 7. 2.
  • textsms
통합검색 성능 개선기

통합검색 성능 개선기

1. 배경, 목표, 그리고 개선 방향1.1 배경 및 목표저희 서비스에는 통합검색 기능이 있습니다. 검색어 하나를 넣으면 보관함, 일정, 링크, 텍스트, 파일 5종을 한 번에 찾아줍니다. 그런데 이 API는 한 번 호출될 때마다 5개 테이블을 전부 검색하게 되었습니다.사용자가 자료를 수천 개씩 쌓고 여러 명이 동시에 검색하면 과연 버틸 수 있을까? 이 막연한 불안에서 이 개선을 시작하게되었습니다. 1. SLOSLI = 700ms 이내에 성공한 검색 요청 수 / 전체 검색 요청 수 SLO = SLI ≥ 95%검색의 기준선이 필요했습니다. 사용자 응답성 연구와 SRE의 latency SLO 설계 방식을 참고해 700ms를 초기 기준으로 잡았습니다. (제일 참고 부분에 첨부하였습니다.) 2. 동시 접속자의 한계..

  • format_list_bulleted 프로젝트/toIT
  • · 2026. 7. 2.
  • textsms

Spring의 요청 처리 순서

Spring에서 요청이 왔을 때 어떻게 되는지 하나하나 보려고 합니다. 하기 전에 알아야할 부분이 있습니다.1. OSIV가 항상 인터셉터인 것은 아님.Spring boot MVC에서는 보통 OpenEntityManagerInViewInterceptor 형태로 동작한다고 보면 되고 직접 OpenEntityManagerInViewFilter를 등록할 수도 있습니다.그래서 흐름은 2가지로 나누게 됩니다.OSIV Interceptor 방식: [필터들] → [DispatcherServlet] → [OSIV Interceptor] → [Controller]OSIV Filter 방식: [OSIV Filter] → [다른 필터들] → [DispatcherServlet] → [Controller]2. Repository..

  • format_list_bulleted 프로젝트/toIT
  • · 2026. 7. 2.
  • textsms
OSIV

OSIV

1. 트랜잭션 범위의 영속성 컨텍스트트랜잭션이 시작될 때 영속성 컨텍스트가 시작되고 트랜잭션이 끝날 때 영속성 컨텍스트도 끝난다.스프링에서는 보통 서비스 메서드에 @Transactional을 붙인다.@Transactionalpublic Order findOrder(Long id) { return orderRepository.findOrder(id);}그러면 흐름은 다음과 같다. 서비스 안에서는 엔티티가 영속상태 였는데, 서비스가 끝나고 트랜잭션이 종료되면 컨트롤러에 반환된 엔티티는 준영속 상태가 된다. 2. 문제점위 흐름에서 지연로딩 시에 문제가 생김예를 들어 Order 엔티티가 있다고 가정해보자@Entitypublic class Order { @ManyToOne(fetch = FetchTyp..

  • format_list_bulleted 프로젝트/toIT
  • · 2026. 7. 2.
  • textsms