푸른영혼의 별 | Tech Blog

---

Posts (총 199편 · 1 / 20 페이지)

• 2026-06-10
• 2026-06-10

  *콘서트 예매 / 한정 특가 의 *트래픽 폭증* 을 *Spring Boot 로 어떻게 *대기열로 평탄화* 하는가 — *Virtual Waiting Room + Redis Sorted Set + Bucket4j + Resilience4j + WebSocket* 5 layer 의 *실전 구축법***

  이 글은 콘서트 티켓 / 한정 특가 / 게임 오픈 같은 예고된 트래픽 폭증 을 Spring Boot 백엔드 가 터지지 않고 *공정하게 *처리 하는 5 layer 패턴 을 정리한다. Virtual Waiting Room (가상 대기실) → Token / Rate Limiting → Queue-based Admission → Optimistic Lock + 결제 분리 → CDN / Pre-warm 의 5 단계 의 *실전 구축법.

  #spring-boot #traffic-surge #waiting-room #redis #sorted-set #bucket4j #resilience4j #websocket #rate-limiting #flash-sale #concert-ticketing #optimistic-lock #pessimistic-lock #pg-payment
• 2026-06-10

  CDN 의 *효율* — CloudFront · Akamai · Cloudflare 의 *각자의 길*

  백엔드 서버를 *어떻게 튜닝 해도 — 사용자가 지구 반대편 에 있으면 300 ms 의 *물리 법칙 은 못 이긴다. 그 한계를 깨는 도구 가 CDN. 그리고 CDN 시장의 *3 거인 — CloudFront, Akamai, Cloudflare 가 서로 다른 길 로 그 효율 을 추구 한다.

  #cdn #cloudfront #akamai #cloudflare #edge #performance #latency #caching #infrastructure
• 2026-06-10

  백엔드 개발자가 알아야 할 *로컬 캐시 vs 리모트 캐시* — 언제 무엇을 *왜*

  느린 시스템 의 80% 가 적절한 캐시 로 극적 개선 된다. 그만큼 캐시가 중요 하다. 그런데 어떤 캐시를 *어디에 두는가* — 그 결정이 나중에 더 큰 *복잡도 가 된다. 한 잘못된 캐시 결정이 수개월의 *디버깅 비용 을 만들 수 있다. 이 글은 그 결정을 위한 정리다.

  #cache #local-cache #remote-cache #redis #caffeine #ehcache #performance #throughput #latency
• 2026-06-10

  백엔드 개발자가 알아야 할 *가비지 컬렉터와 메모리 사용* — JVM 중심으로

  백엔드가 *느려진다 의 체감 30% 는 GC pause 다. 단 원인을 잘못 짚으면 *반대 방향 으로 튜닝* 한다. 큰 heap 이 항상 좋은 게 아니고, GC 가 *항상 나쁜 것 도 아니다. 원리 + 측정 + 결정 — 이 세 가지가 GC 와의 *건강한 관계.

  #gc #garbage-collection #jvm #memory #heap #g1 #zgc #performance #java
• 2026-06-10

  Discord 가 *Go 로 만든 Read States 서비스를 *Rust 로 다시 쓴* 이유와 *실측 효과* — *GC pause 의 조용한 살인자*, *p99 의 *수 ms → < 1 ms*, *메모리 *5 배 감소* 의 *정공적 분해*

  Discord 가 *2020 년 자기들의 Read States 서비스 — 초당 수십만 메시지 의 *읽음 상태 추적 — 를 Go 에서 Rust 로 재작성 한 사례. *한 서비스 의 *언어 교체 가 수년 후 Rust 의 시스템 프로그래밍 지위 를 *대중 화 시킨 상징적 사건 이 됐다. 표면 상의 이유 는 “Go GC pause 가 p99 를 망친다” 였지만 — 진짜 이유는 *deterministic *메모리 모델 의 차이. 그 차이 가 실측 으로 *얼마나 큰지 가 압도적 으로 인상적.

  #discord #rust #golang #gc #garbage-collection #latency #p99 #ownership #borrow-checker #tokio #async #memory #rewrite #case-study #performance #system-language
• 2026-06-10

  캐시 적중률 (Cache Hit Ratio) — *90%면 충분한가*? *Working Set · 정책 (LRU/LFU/ARC) · Stampede · 분산 캐시* 의 *진짜 *체계화*

  “우리 캐시 적중률이 95% 인데 왜 여전히 느려요?” — 실무에서 가장 자주 묻는 캐시 관련 질문. 답은 *95% 가 사실 *낮은 숫자 일 수 있다는 것. *Working set 의 크기, *cache 의 *층층 구조, miss 의 *비용 비대칭, stampede 의 *조용한 살인자** — 이 *4 가지 의 진짜 이해 가 없으면 적중률 의 숫자 자체 가 *오해를 부른다.

  #cache #hit-ratio #miss-rate #working-set #lru #lfu #arc #caffeine #redis #cache-aside #write-through #write-back #stampede #thundering-herd #consistency-hashing #memory-hierarchy
• 2026-06-10

  수직 확장 vs 수평 확장 — CPU · Memory · HDD · SSD 각 자원에서 본 *처리량 / 응답시간* 의 개선 지점

  시스템이 느려진다. 서버를 *키울지 / 서버를 *늘릴지** 가 첫 결정이다. 단순해 보이지만 — *어떤 자원 이 병목인지에 따라 답이 다르다. 같은 느림 도 CPU 가 부족한 느림 과 메모리 가 부족한 느림 은 해결 방향이 정반대.

  #scaling #vertical-scaling #horizontal-scaling #throughput #latency #cpu #memory #ssd #hdd
• 2026-06-10

  백엔드 개발자가 알아야 할 *DB 커넥션 대기시간* — Spring Boot + HikariCP 의 *5 가지 *시간 설정* 을 *전부 *합쳐서* 보는 시야*

  동료가 p99 응답시간 알람 을 받고 와서 말했다.

  “DB 가 *느려. connection pool 늘려야 해.”*

  그 말이 틀린 건 아니다. 다만 정답도 아니다. DB 가 *느린지, pool 이 *작은지, pool 의 *시간 설정 이 서로 충돌하는지** 는 *완전히 다른 5 가지 진단. 각각의 *처방 도 완전히 다르다.

  #hikaricp #spring-boot #connection-pool #jdbc #connection-timeout #idle-timeout #max-lifetime #validation-timeout #leakdetection #database #postgresql #mysql
• 2026-06-10

  서버 성능 개선 *기초* — *DB 80% / 외부 API 15% / 서버 코드 5% 법칙* 으로 본 *측정 → 진단 → 처방* 의 일관 사이클

  서버 성능 의 체감 적 정공 은 세 줄 룰 로 압축 된다 — “측정 없이 최적화 하지 말 것, *DB 부터 의심 할 것, 코드 최적화 는 *마지막“. 실무 에서 *느린 endpoint 의 *80% 는 DB, 15% 는 외부 API 호출, 나머지 5% 만 서버 코드 자체. 우리 시간 의 80% 가 *DB 절 에 가야 한다 — 그러나 실제로는 코드 가독성 개선 같은 5% 쪽에서 시간 을 쓴다. 비대칭 이 *서버 성능 개선 의 *가장 큰 함정.

  #performance #latency #throughput #db #jpa #n-plus-one #indexing #connection-pool #caching #circuit-breaker #resilience4j #async #batch #gc #observability #apm #spring-boot