https://kisusu115.github.io/흘려보내지 말고 기록하자. 2026-09-09T17:31:22+09:00 임제형 https://kisusu115.github.io/ Jekyll © 2026 임제형 /assets/img/favicons/favicon.ico /assets/img/favicons/favicon-96x96.png 2026-08-29T21:00:00+09:00 2026-08-29T21:00:00+09:00 https://kisusu115.github.io/posts/rate-limiter-study/ 임제형

대규모 시스템 설계 책 스터디에서 진행한 4장의 처리율 제한 장치에 대한 개념을 정리해보고자 한다. 추가적으로 본문을 다 읽기 전에 설계를 선행적으로 진행해보고 이상적인 설계를 확인한 후, 마지막에는 운영중인 서비스에 직접 적용해보았다. Rate Limiter 처리율 제한 장치 rate limiter 네트워크 시스템에서 처리율 제한 장치rate limiter는 클라이언트 또는 서비스가 보내는 트래픽의 처리율rate를 제어하기 위한 장치 API 요청 횟수가 제한 장치에 정의된 임계치threshold를 넘어서면 추가로 도달한 모든 호출에 대한 처리를 중단block한다. 사용 예시 사용자는 초당 2회 이상 새 글을 올릴 수 없다 같은 IP 주소로는 하루에 10개 이상의 계정...

2026-08-23T21:00:00+09:00 2026-08-24T01:41:39+09:00 https://kisusu115.github.io/posts/load-test-journey/ 임제형

파일럿 유치에 앞서 우리 시스템의 안정성을 테스트로서 보장해야했다. 게이트웨이부터 분석 서버, DB까지 총 14회차에 걸쳐 부하테스트를 진행했는데, 앞단 모듈부터 순차적으로 부하를 주며 아래 내용을 확인했다. 각 모듈은 어디까지 버티고, 그때 어떤 자원이 병목이 되는가? 모듈이 죽을 때까지 올리는 Breakpoint Test로 모듈별 한계와 취약 자원을 찾고, 그에 따라 개선을 붙이고, 목표 부하를 기준으로 스펙을 확정해나간 과정을 정리해보려 한다. 테스트 대상 서비스 테스트 대상은 게이트웨이, 분석 서버, DB 세 가지다. 먼저 서비스 아키텍처는 아래와 같다. 시스템은 크게 데이터 플레인과 컨트롤 플레인으로 나뉜다. 데이터 플레인: 고객사 엔드유저의 요청이 진행되는 부...

2026-08-11T21:00:00+09:00 2026-08-24T01:41:39+09:00 https://kisusu115.github.io/posts/analysis-query-tuning/ 임제형

먼저 Analytics 서비스 특성 상, 전환율을 계산해주는 로직이 필요하다. 분자/분모 형태로, 앞단 이벤트를 겪은 전체 인원을 분모로, 그중에서 뒷단 이벤트를 발생시킨 인원을 분자로 둔다. 여기서 앞단 이벤트는 LLM의 응답 데이터를 관측한 인원이고, 뒷단 이벤트는 유저가 브라우저나 앱에서 발생시킨 특정한 이벤트 데이터이다. 전체 LLM 응답을 받은 인원 중에서, 그 이벤트를 추가 발생 시킨 비율을 보는 것이다. 여기서 유저 데이터와 LLM 응답에 노출된 기록을 연결해줘야 한다. 시간축으로 앞선 노출에 유저 이벤트를 귀인하는 시스템을 구축해야했다! 용어 exposure: LLM 응답에 노출된 기록. 어떤 모델+파라미터의 응답이었는지를 포함하는 데이터. event: 유저 이벤트. ...

2026-07-23T23:00:00+09:00 2026-08-24T01:41:39+09:00 https://kisusu115.github.io/posts/rollback-hexagonal/ 임제형

분석 서버 스택을 코프링으로 정하고 나니, 다음 고민은 내부 아키텍처였다. MVP로 세운 단일 서버가 얼마나 오래 사용될지 몰랐기에, 한번에 잘 만들어두자는 욕심이 생겼다. 기본적으로는 도메인 패키징으로 디렉토리를 나눴고 그 하위를 구성하는 아키텍처를 정해야 했는데, 지금까지의 프로젝트에서 써온 레이어드 아키텍처가 당연하게도 먼저 떠올랐다. 다만 이번 프로젝트의 MVP는 (이때까지만 해도) 예상 구성이 이랬다. 인바운드: 대시보드와 연동된 REST API, SQS Consumer, 분석 집계 워커 아웃바운드: PostgreSQL, Key/정책 캐싱용 Valkey, S3, MailSender 등 이렇게 외부 의존성이 많다면, 헥사고날 아키텍처로 도메인 로직과 외부 의존성을 분리하면서도...

2026-07-21T02:00:00+09:00 2026-08-24T01:41:39+09:00 https://kisusu115.github.io/posts/mq-must-in-mvp/ 임제형

LLM Gateway를 만들면서, LLM 호출 정보를 분석 서버에 비동기로 넘겨줘야 했다. 토큰 사용량, 레이턴시, 요청/응답 본문, 서비스 자체 식별자 등등 이벤트 데이터를 분석 서버 쪽으로 넘겨야 하는데, 당연하게도 메시지 큐를 써야 한다는 생각이 들었다. 다만 지금 시기에는 개발 속도가 생명이었다. Kafka를 도입하자니 MVP라는 타겟에 비해 지금 필요한 것인가 하는 의문이 따라온다. 그렇다면 가벼운 Amazon SQS를 도입해볼까? 그런데 정합성 측면에서는 메시지 큐의 사용 자체가 관리 포인트가 많아진다. 그럼 그냥 분석 서버로 직접 호출하면 되는 거 아닌가? 고루틴으로 던져두고 응답은 안 기다리는 식으로. 걱정은 이 구조에서 분석 서버가 게이트웨이 단의 요청들에 대한 부하를 견딜 수 ...