ioh's Development

Spring에서 Connection Pool 누수 에러의 진짜 원인과 해결 방법

1. 들어가며실무에서 HikariCP 로그에 Connection is not available, request timed out 이 찍혔습니다. 처음엔 @Transactional이나 Spring 설정 문제라고 생각했는데, 조사해보니 전혀 아니었습니다... 실무에서 Connection Pool 누수(Connection Leak) 는 흔히 마주치는 골칫거리 중 하나입니다.로그에 찍히는 메시지는 다양합니다.HikariCP:Connection leak detection triggered for ...Commons DBCP:DBCP object created ... was never closedTomcat JDBC Pool:Connection has been abandoned많은 개발자가 이 로그를 보면 “@Tr..

왜 이걸 했나....검색/정렬/페이징이 섞인 목록에서 “매칭된 항목(is_matched=1)은 무조건 최상단”이라는 UX 요구가 있었다. 프론트에서 정렬만 하면 매칭 항목이 31번째에 있을 때 1페이지(30개)에는 절대 못 나온다. 이건 페이징 레이어의 책임이다. 데이터가 페이지로 잘리기 이전에 순서가 결정돼야 한다.1) 문제 정의: 왜 프론트 정렬로는 안 되는가사용자 요구: “매칭된 항목(is_matched=1)은 항상 1페이지 최상단에 노출되어야 한다.”일반적으로 프론트에서 정렬만 수행하면 서버가 이미 page_size=30으로 데이터를 잘라 보냈을 때, 31번째 위치의 매칭 항목은 2페이지에 묻혀 1페이지에 올 수 없습니다.즉, 정렬 → 페이징의 순서가 서버에서 보장되어야 합니다.2) 제약과 설계 ..

단순 연결 리스트(Singly Linked List)자료구조의 기본이자, 면접 단골 주제인 단순 연결 리스트(Singly Linked List)!이번 포스팅에서는 단순 연결 리스트의 구조와 특징부터,자주 등장하는 구현 예제 및 실전 응용 문제까지 하나하나 정리해보았습니다.📚 자료구조를 공부하면서 리스트 관련 핵심 개념을 정리해둔 글로,Java와 Kotlin 코드 예제를 함께 작성하며 복습 겸 블로그 기록으로 남깁니다.🧩 1. 단순 연결 리스트란?연결 리스트(Linked List)는 배열과 달리 메모리 공간을 동적으로 할당하며 데이터를 연결해 나가는 자료구조입니다.그중 단순 연결 리스트(Singly Linked List)는 한 방향으로만 노드가 연결되는 구조입니다. 리스트는 배열과 달리, 원소 간의 '..

1. 들어가며: 왜 이 시험을 준비했는가?개발자로서 실무를 하다 보면, 서비스 장애나 트래픽 이슈의 원인을 추적하는 과정에서 반드시 네트워크에 대한 이해가 필요하다는 걸 체감하게 됩니다. 특히, 로드밸런싱 이슈나 포트 포워딩 설정 문제, DHCP 서버 구성 오류와 같은 상황을 직접 겪으면서 백엔드 개발자에게도 인프라 지식은 선택이 아닌 필수라는 확신이 들었습니다.그동안 "코드만 잘 짜면 된다"는 생각에서 벗어나, 서비스가 실제로 어떻게 전달되고 라우팅되는지, TCP/IP 수준에서 무슨 일이 벌어지는지 더 깊이 알고 싶었습니다. 그래서 이론과 실무 모두를 아우를 수 있는 입문형 자격증인 네트워크 관리사 2급에 도전하게 되었고, 회사 업무와 병행하며 필기와 실기까지 한 번에 합격하게 되었습니다.공부하면서 단..

앞서 큐 기반 구조 설계 및 Redis Pub/Sub 확장을 통해 실시간 상태 처리 문제를 해결한 내용을 공유했습니다. 이 글에서는 그 확장 내용을 다음 3가지로 나누어 심화 정리합니다Spring 기반 Redis Pub/Sub Listener 설정SSE Emitter 등록 및 해제, 메모리 누수 방지단건/다건 SSE 처리 구조의 기술적 차이 및 도식화1️⃣ Spring에서 Redis Pub/Sub Listener 설정Spring에서 Redis를 통한 Pub/Sub 구현은 다음과 같이 구성합니다.✅ RedisMessageListenerContainer 설정@Configurationpublic class RedisPubSubConfig { @Bean public RedisMessageListene..

💡 실시간 번역 상태 처리를 위한 큐 기반 아키텍처와 Redis 확장기1. 도입 – 왜 이 기능이 필요했는가?법령 번역 비교 서비스에서는 AI 기반 번역 요청 후, 번역 완료까지의 시간이 수초에서 수분 이상 소요되며, 프론트엔드는 SSE(Server-Sent Events)를 통해 사용자에게 실시간 상태를 반영해야 합니다.그러나 다음과 같은 실무적 요구사항과 문제가 발생했습니다:다건 작업 트래킹: 여러 작업을 동시에 처리 중인 사용자가 각 작업별 상태를 실시간으로 받아야 함진행률 상태 역주행 이슈: 이전에 전송된 진행률보다 낮은 값이 수신되는 경우 사용자 혼란 야기SSE 전송 누락/지연: 순차 처리 없이 push할 경우, 병렬 작업 간 race condition 발생수천 개의 법령 작업에 대한 상태 정합..

API Gateway 구조와 동작 원리로 본 근본 원인 분석대규모 서비스에서 간헐적인 504 Gateway Timeout은 흔한 장애 유형 중 하나입니다. 특히 “특정 요청만” 실패할 때, 많은 개발자들이 Gateway의 부하나 단순 네트워크 문제로 치부하고 넘어가기 쉽습니다.하지만 Gateway 구조를 면밀히 들여다보면, 원인은 서비스 간 라우팅 구조, 인증/플러그인 처리 흐름, 그리고 타임아웃 설정 간 mismatch로 좁혀질 수 있습니다. 이번 포스팅에서는 API Gateway의 구조적 원리를 기반으로, 왜 특정 요청만 실패하고, 어떤 조건에서 지연이 발생하는지에 대한 기술적 원인을 탐색합니다. 1. API Gateway의 기본 구조- Reverse Proxy로서의 역할 API Gateway는 클라..

1. 장애의 시작: Gateway를 바꾸면 모든 게 나아질 줄 알았다기존에 Go 기반 자체 Gateway(이하 Go Gateway)를 사용하고 있었다.필요한 라우팅 로직만 얹어 경량화된 구조였지만, 다음과 같은 한계에 부딪혔다. 동적 라우팅 관리의 부재인증/권한/로깅 플로우 중복버전 관리가 힘든 직접 코드 관리 구조 이러한 요구사항을 해결하기 위해 우리는 Apache APISIX로 전환을 시도했다.APISIX는 오픈소스 고성능 API Gateway로서 Nginx + Lua 기반, 플러그인 시스템을 제공하며레이트 리밋, 인증, 서비스 디스커버리, 로깅 등 다양한 기능을 유연하게 다룰 수 있었다. 기능만 놓고 보면 “완벽한 선택”이었다. 2. 그러나, 우리는 너무 빨랐고 느렸다전환 초기, APISIX는 문제..

좋은 코드의 기준, 정말 '주관적'일까요?좋은 코드의 기준이 있을까요? 깔끔한 코드? 읽기 쉬운 코드? 아름다운 코드?좋은 코드의 기준이 이런 주관적인 것 밖에 없을까요?팀장과 나의 코드 기준이 다른가요?동료들의 코드를 리뷰할 때 나는 어떤 이야기를 해줄 수 있을까요?본 밋업에서는 코드의 품질을 좀더 객관적으로 판단할 수 있는 기준들을 제시합니다.그러나, 그 기준을 단순히 제시하는 것에 그치기보다는, 그 기준을 이끌어내기 위해 어떤 질문들을 던졌는지어떤 사고 과정을 거쳤는지를 공유하고 각자가 스스로 고민하고 판단할 수 있는 기회를 제공하고자 합니다.그래서, 각자가 다른 사고 과정을 거치더라도 보편적인 기준에 도달할 수 있다는 것을 함께 경험하기를 바랍니다.사실 이 밋업을 듣는다고 해서 갑자기 매일 좋은 ..

Elasticsearch 색인(Index) 구조 완전 정복 1. 서론 – Elasticsearch를 이해하려면 Lucene부터Elasticsearch는 강력한 분산 검색 엔진이지만, 그 핵심에는 Apache Lucene이라는 라이브러리가 있습니다. Elasticsearch는 데이터를 검색하기 위해 Lucene을 내부적으로 사용하며, 색인(index)과 검색(search)과 관련된 대부분의 기능은 Lucene의 구조 위에 구축되어 있습니다.따라서 Elasticsearch의 동작 원리를 정확히 이해하려면 Lucene이 데이터를 어떻게 색인하고 검색하는지를 먼저 알아야 합니다.2. Lucene의 색인 구조와 Elasticsearch 내부 동작2.1 문서 색인과 Flush문서가 색인될 때, Lucene은 해당 ..

🛠 Elasticsearch 아키텍처 완전 정복: 클러스터, 노드, 인덱스, 샤드, 레플리카Elasticsearch는 대용량 분산 검색 엔진으로, 고성능 검색과 실시간 로그 분석 등에 강력한 성능을 발휘합니다.이번 글에서는 Elasticsearch의 핵심 아키텍처인 클러스터, 노드, 인덱스, 샤드, 레플리카의 개념과 이들 간의 관계를 실무적인 시각으로 자세히 살펴봅니다.📌 전체 구성 요소 한눈에 보기구성 요소설명클러스터 (Cluster)Elasticsearch 전체 시스템 단위노드 (Node)클러스터에 참여하는 서버 한 대인덱스 (Index)문서(Document)들의 논리적 집합샤드 (Shard)인덱스를 물리적으로 분할한 단위레플리카 (Replica)샤드의 복제본, 고가용성 보장🔧 1. 클러스터 (..

🔍 Elasticsearch란? 완전 기초부터 핵심까지 한 번에 이해하기데이터의 양이 폭발적으로 증가하는 시대, 빠르고 정확한 검색은 많은 시스템에서 핵심 기능으로 자리잡고 있습니다.Elasticsearch는 이러한 검색 기능을 매우 강력하고 유연하게 제공하는 분산형 검색 및 분석 엔진입니다.이번 포스트에서는 Elasticsearch가 무엇인지, 어떤 구조로 동작하며 어떤 강점을 가지는지 완전 기초부터 핵심 포인트까지 정리해보겠습니다.✅ Elasticsearch란?1. 분산형 RESTful 검색/분석 엔진Elasticsearch는 단순히 텍스트를 검색하는 툴이 아닙니다.다음과 같은 특징을 지닌 다목적 고성능 검색 플랫폼입니다:특징설명분산형 (Distributed)여러 대의 서버에 데이터를 자동 분산 저..

🔍 key={index} vs key={id} 차이점 & 성능 최적화 이유React에서 리스트를 렌더링할 때 각 항목을 구별할 수 있도록 key 속성을 제공해야 합니다.잘못된 key 설정은 불필요한 리렌더링을 유발하고 성능을 저하시킬 수 있습니다.이번 포스팅에서는 key={index}와 key={id}의 차이점을 설명하고, 최적의 방법을 알아보겠습니다.🚨 key={index}의 문제점{data.map((item, index) => ( ))}✔️ index를 key로 사용하면 배열 순서가 바뀔 때 React가 항목을 잘못 인식할 가능성이 큽니다.📌 문제 발생 시나리오1️⃣ 새로운 항목이 리스트 중간에 삽입될 때기존 리스트: [A, B, C]새로운 리스트: [A, NEW, B, C]React는 i..

1. 들어가며최근 프로젝트에서 React 18과 React Query를 활용하여 서버 상태 관리 최적화를 진행했습니다.기존 방식에서는 불필요한 API 요청이 많아 성능 문제가 있었고, 이를 React Query로 개선하면서 어떤 점이 효과적이었는지 공유하려 합니다.특히,✅ React 18의 자동 배치(Auto Batching) 기능이 성능에 미친 영향✅ React Query를 활용한 API 요청 최적화✅ 불필요한 리렌더링을 줄이기 위한 전략에 대해 다룰 예정입니다.2. 실무에서 적용한 핵심 기술2.1 React 18 – 자동 배치(Auto Batching)React 18에서는 여러 개의 setState가 자동으로 하나의 렌더링으로 합쳐지는 자동 배치(Auto Batching) 기능이 도입되었습니다.📌 ..

1. 프로젝트 개요프론트엔드를 담당하면서 React 18, TypeScript, React Query, Hooks를 활용하여 개발을 진행했다. 이 과정에서 겪은 문제들과 해결 과정, 그리고 효율적인 컴포넌트 설계에 대해 공유하고자 한다.2. 기술 개요2.1 React 18 개요React 18은 동시성 렌더링(Concurrent Rendering)과 자동 배치(Automatic Batching) 등의 새로운 기능을 추가하여 성능을 향상시킨 버전이다. 주요 기능은 다음과 같다:Concurrent Rendering: UI 업데이트를 더욱 부드럽게 처리할 수 있도록 함Automatic Batching: 여러 상태 업데이트를 자동으로 배치하여 불필요한 렌더링 방지Transition API: UI 상태 전환을 더욱..

ELK 로그 최적화: 불필요한 로그가 애플리케이션 성능에 미치는 영향과 해결책1. 실무에서 발생한 문제최근 ELK(Elasticsearch, Logstash, Kibana) 스택을 활용하여 애플리케이션 로그를 관리하는 과정에서 불필요한 로그가 과도하게 남겨지는 문제를 경험했다. 특히 Elasticsearch Memory Pool 관련 로그가 지속적으로 기록되었는데, 실제 운영에 중요한 로그는 아니었음에도 불구하고 애플리케이션 성능과 운영 비용에 영향을 줄 가능성이 있었다.이 문제를 해결하기 위해 불필요한 로그를 관리하고 최적화하는 방법을 정리해 보았다.2. 불필요한 로그가 애플리케이션 운영에 미치는 영향1) 성능 저하I/O 부하 증가: 로그가 많을수록 디스크 쓰기(Write) 부하가 증가하여 애플리케이션..

JVM 힙 메모리 개념 정리 및 적절한 설정 방법1. JVM 메모리 구조 개요JVM(Java Virtual Machine)은 여러 개의 메모리 영역을 관리하며, 그중 Heap 메모리가 가장 중요한 역할을 한다.아래는 JVM이 사용하는 주요 메모리 영역이다.메모리 영역 역할 및 설명Heap객체가 저장되는 공간. -Xms, -Xmx 옵션으로 크기 조절 가능.Stack각 쓰레드별 메서드 호출 스택을 저장하는 공간.Metaspace클래스 메타데이터 저장 공간 (-XX:MaxMetaspaceSize로 크기 조절).Code CacheJIT(Just-In-Time) 컴파일된 코드 저장 공간.Direct MemoryByteBuffer.allocateDirect() 같은 네이티브 메모리 사용.2. 서버 전체 메모리(4G..

1. JVM이 서버의 전체 메모리를 다 사용하지 않는 이유서버에 4GB의 물리적 메모리가 있다고 해도 JVM이 이를 전부 사용하지 않는 이유는 운영 체제(OS)와 JVM의 메모리 관리 방식 때문이다.이를 세부적으로 살펴보면 다음과 같다.(1) OS가 사용할 메모리를 남겨둬야 한다JVM이 실행되는 서버는 단순히 JVM만 사용하는 것이 아니라 OS 자체가 동작하고 있다.네트워크, 디스크 I/O, 캐시 관리 등을 위해 일정 메모리가 필요하다.일반적인 리눅스 서버의 경우, 최소한 500MB~1GB 정도의 메모리를 OS가 자체적으로 사용한다.만약 JVM이 4GB를 전부 차지하면 OS가 원활하게 동작하지 못하고, 전체적인 시스템 성능이 저하될 수 있다.(2) JVM의 Heap 외에도 많은 메모리가 필요JVM이 사용..

JVM 힙 메모리 크기 개념 정리 및 실무 적용 사례서론: JVM 메모리 설정, 왜 중요할까?JVM 기반의 애플리케이션을 운영하다 보면 OutOfMemoryError(OOM) 가 발생하거나, GC(Garbage Collection) 튜닝이 필요한 경우가 많다.이럴 때 JVM 메모리 구조를 제대로 이해하고 적절한 설정을 하면 애플리케이션 성능 최적화와 안정적인 운영이 가능하다.이번 포스팅에서는 JVM 힙 메모리 개념과 설정 방법을 실무 경험을 바탕으로 정리하고, 적절한 메모리 설정값과 실무 적용 사례를 공유하려 한다.1. JVM 메모리 구조 살펴보기JVM이 사용하는 메모리는 크게 다음과 같이 구분할 수 있다.메모리 영역 역할 및 설명Heap애플리케이션이 생성하는 객체 저장 공간 (-Xms, -Xmx 로 설..

반정규화를 활용한 성능 최적화: 실무 경험과 해결 방안본 게시글은 실무 경험을 기반으로 작성되었으나, 회사의 실제 데이터 모델 및 프로젝트 내용과는 무관하며 일부 내용을 각색하였습니다. 보안 및 기밀 유지 정책을 준수하기 위해 특정 기술적 세부 사항이 변경되었음을 알려드립니다.1. 서론대규모 데이터를 다루는 시스템에서 정규화(Normalization)는 데이터 무결성을 유지하고 중복을 최소화하는 핵심 원칙이다. 하지만 조회 성능 최적화가 필요한 경우 반정규화(Denormalization)를 적용하여 데이터 접근 속도를 개선할 필요가 있다.이번 포스팅에서는 직원 관리 시스템 성능 최적화 과정에서 반정규화를 적용한 실무 경험을 공유하며, 반정규화의 장점과 단점, 그리고 발생한 문제를 어떻게 해결했는지를 정리..