상품 검색의 깊은 페이징(deep paging) 루프가 공용 Elasticsearch 클러스터의 CPU를 90% 넘게 튀게 만들고 있었다. 원인을 추적해 보니 “쓰지도 않는 데이터를 매번 압축 해제하고 파싱하는” 구조였다. _source를 끄는 한 줄로 검색 시간의 대부분을 차지하던 fetch phase를 걷어낸 변경을 뜯어보며, 그 원인과 원리를 정...
마이크로서비스 환경에서 한 요청이 여러 서비스를 거치는 일은 일상이 되었다. 이때 “어느 구간에서 느려졌나”, “어디서 에러가 났나”를 추적하려면 분산 추적이 필요하다. OpenTelemetry는 이런 분산 추적과 메트릭, 로그를 벤더 중립적인 표준으로 통합하려는 프로젝트다. 이 글에서는 OpenTelemetry의 핵심 개념을 정리하고, 국내 환경에서...
ArgoCD와 Helm으로 구성된 환경에서 카나리 배포 단계를 deploy.canary.state 단일 필드로 표현하는 모델을 다룬다. 이 필드 값을 바꾸는 것이 곧 배포 단계 전이이고, ArgoCD가 그 결과를 Kubernetes 리소스에 반영한다. 마지막 섹션에서는 운영 중 발견한 상태 전이 관련 주의점을 정리한다. 1. 배포 파이프라인 P...
2편에서 구조화된 동시성과 Job 트리를 통한 취소 전파를 다뤘다. 코루틴이 트리를 이루고, 실패가 전파되고, 취소가 협조적이라는 것까지 이해했다면 — 이제 실전에서 가장 많이 부딪히는 문제를 볼 차례다. 예외가 launch와 async에서 다르게 전파되는 규칙, CoroutineExceptionHandler의 동작 위치, 그리고 withContext...
1편에서 suspend 함수가 CPS 변환과 Continuation으로 동작하는 원리를 다뤘다. 코루틴 하나의 동작은 이해했지만, 실제 서비스에서는 여러 코루틴이 동시에 실행된다. 이때 “누가 이 코루틴들을 관리하는가”, “하나가 실패하면 나머지는 어떻게 되는가”를 결정하는 것이 CoroutineScope와 CoroutineContext다. 이...
코루틴은 “가벼운 스레드”라고 흔히 소개된다. 하지만 이 한 줄짜리 설명은 오해를 낳기 쉽다. 코루틴은 스레드가 아니며, 스레드 위에서 실행되는 일시 중단 가능한 연산(suspendable computation) 이다. 스레드를 점유하지 않으면서도 동기 코드처럼 읽히는 비동기 처리 — 이것이 가능한 이유를 컴파일러 레벨부터 파헤쳐본다. 이 글의...
Part 1~3에서 캐시의 기본 개념, 읽기/쓰기 전략, 토폴로지를 다뤘다. Part 4에서는 캐시가 가득 찼을 때 어떤 데이터를 버릴 것인가(Eviction), 데이터를 얼마나 오래 유지할 것인가(TTL), 그리고 분산 락의 안전성 논쟁(Redlock, Fencing Token)을 다룬다. 1. Caffeine의 Window TinyLFU ...
TL;DR: OOM은 메모리 누수만으로 발생하지 않는다. 동시성 제어 실패로 데이터가 꼬이고, 대량 데이터를 한 번에 처리하려다 힙이 터진다. 실무에서 겪은 동시성 제어와 대량 데이터 처리의 교훈을 정리한다. 1. 재고 차감과 동시성 제어 커머스에서 재고 차감은 동시성 이슈의 대표적인 사례다. 여러 사용자가 동시에 같은 상품을 주문하면 재고가...
TL;DR: Redis의 SET NX PX는 동일 리소스에 대한 중복 요청을 빠르게 차단하는 데 유용하다. 다만 단일 Redis 인스턴스 기반 락은 페일오버, TTL 초과, unlock 방식에 따라 상호 배제가 깨질 수 있다. 이 글은 “완전한 분산 락” 구현법이 아니라, 상품 수정 API에서 best-effort 방어선으로 Redis 락을 사용한 사...
이 글은 K8S에서 JVM 앱 운영하기 시리즈의 세 번째 글이다. 클러스터 구조와 Probe Graceful Shutdown과 HPA Warmup CPU는 느려지고, Memory는 죽는다 ← 현재 글 TL;DR: K8S에서 JVM 앱을 운영할 때 CPU limit 초과와 Memory limit 초과는 커널의 처...