[동시성 제어] 비동기 Fan-In 구조에서의 레이스 컨디션 및 멱등성 확보
·
프로젝트/트러블슈팅
1. 장애 상황 (Incident)현상: 멀티모달 인덱싱 파이프라인에서 비동기 AI Worker들이 각각의 태스크 완료 이벤트를 동시에 발행할 때, 최종 단계로 진입하기 위한 Fan-In 상태 전이(모든 하위 작업 완료 판정)가 간헐적으로 누락되는 현상을 확인했다.연쇄 효과: 하위 비동기 작업들이 모두 성공적으로 끝났음에도 불구하고, 전체 파이프라인의 최종 상태가 '완료'로 갱신되지 않고 '진행 중' 상태로 멈추는 시스템 교착(Stall)이 발생했다.2. 원인 분석 (Root Cause Analysis)문제의 근본 원인은 비동기 환경에서 트랜잭션 격리 수준과 JPA 영속성 컨텍스트의 특성이 결합하며 발생한 TOCTOU(Time-of-Check-Time-of-Use) 레이스 컨디션 및 설계상 취약점이었다...
AWS t3.micro 환경에서 Network Throttling으로 인한 HikariPool Starvation 장애 복구
·
프로젝트/트러블슈팅
1. 장애 상황 (Incident)현상: AWS t3.micro 인스턴스 환경에서 부하 테스트(Load Test)를 진행하던 중, 애플리케이션 로그에 HikariPool - Thread starvation or clock leap detected 경고가 지속적으로 발생했다.연쇄 효과: 이와 동시에 AWS SQS(Simple Queue Service)와의 통신에서 TimeoutException이 발생했으며, 최종적으로 서버가 요청을 처리하지 못하는 마비(Stall) 상태에 진입했다.2. 원인 분석 (Root Cause Analysis)문제의 근본 원인은 단순한 DB 커넥션 부족이 아닌, 네트워크 대역폭 제한으로 인한 스레드 고갈이었다.Network Throttling 발생: Grafana 대시보드의 인프라..
[JPA/Spring] afterCommit 훅 내부의 TransactionRequiredException 발생 원인과 해결책 (Propagation.REQUIRES_NEW)
·
프로젝트/트러블슈팅
1. 배경 및 문제 상황1.1. 비즈니스 요구사항: 비동기 Fan-In 파이프라인과 오케스트레이션당시 개발 중이던 유실물 매칭 서비스(It's Mine)에는 대용량 이미지를 처리하기 위해 Spring Boot 메인 서버와 FastAPI 기반의 AI Worker 서버들이 분리된 구조로 파일럿 파이프라인이 구축되어 있었다. 전체 흐름은 비동기 분산 환경으로 설계되었다.사용자가 유실물 이미지를 업로드하면 메인 서버가 태스크를 생성하고 AWS SQS를 통해 AI Worker들에게 이벤트를 발행한다. 이기종 AI 모듈들은 각자 비동기적으로 특징 추출(Re-ID 등) 작업을 수행한 뒤, 결과 메시지를 다시 SQS 큐로 송신한다. 메인 서버의 SQS 리스너가 개별 AI 모듈의 완료 메시지를 수집하여 DB 상태를 DO..
5: 메모리 파편화와 하드웨어 최적화 (시스템 엔지니어링)
·
OS
챕터 5: 메모리 파편화와 하드웨어 최적화 (시스템 엔지니어링) (완전판)5.1 메모리 파편화(Fragmentation)의 구조적 인과관계핵심: 메모리 할당 정책의 고정성과 동적 런타임의 불확실성이 결합하여 발생하는 물리 자원의 공간적 낭비 현상입니다.내부 파편화 (Internal Fragmentation): 가상 메모리의 최소 관리 단위가 $4\text{KB}$(페이지)로 고정되어 발생합니다. 프로세스가 단 $1\text{Byte}$의 메모리만 요구하더라도 커널은 $4\text{KB}$ 블록 전체를 내어주어야 하므로, 할당된 블록 내부에서 사용되지 않고 버려지는 자투리 공간이 누적됩니다.외부 파편화 (External Fragmentation): 동적 할당과 예측 불가능한 오브젝트 수명(Lifecycle..
4: 가상 메모리의 규모와 주소 매핑 방식
·
OS
챕터 4: 가상 메모리의 규모와 주소 매핑 방식 (완전판)4.1 CPU 아키텍처 비트수와 가상 주소 상한선핵심: 가상 메모리의 최대 크기는 메인보드에 장착된 물리 RAM의 용량과 하드웨어적으로 완벽히 독립되어 있으며, CPU 주소 버스(Address Bus)의 너비와 포인터 비트 수에 의해 절대적으로 결정됩니다.32비트 아키텍처의 한계: 포인터 변수가 표현할 수 있는 고유 주소의 개수가 $2^{32}$개로 제한됩니다. 1바이트 단위 주소 지정 체계에서 이는 정확히 $4\text{GB}$의 가상 메모리 상한선을 가짐을 의미합니다. 물리 RAM을 아무리 증설해도 각 프로세스는 $4\text{GB}$ 이상의 주소판을 가질 수 없습니다.64비트 아키텍처의 실효 주소 범위: 이론상 $2^{64}$바이트, 즉 $1..
3: 주소 번역 인프라 아키텍처 (Page Table과 TLB)
·
OS
챕터 3: 주소 번역 인프라 아키텍처 (Page Table과 TLB) (완전판)3.1 MMU(Memory Management Unit) 하드웨어 엔진 [누락되었던 주제]핵심: CPU와 메모리 버스 사이에 위치하여 가상 주소를 물리 주소로 실시간 변환하는 독립된 하드웨어 회로입니다.역할: CPU 코어가 명령어를 실행하면서 발급하는 모든 가상 주소 접근 요청을 가로챕니다. 이후 내부 최적화 캐시(TLB)를 조회하거나 메인 메모리의 지도(Page Table)를 탐색하는 전체 번역 과정을 하드웨어 수준에서 총괄 제어합니다. MMU가 없으면 가상 메모리 아키텍처의 주소 변환 지연시간을 실용적인 범위 내로 억제할 수 없습니다.3.2 페이지 테이블(Page Table)과 TLB의 하드웨어적 대조핵심: 주소 변환 지도..