Prisma의 과도한 Join이 프로세스를 죽였을 때 쿼리를 분해한 방법
필요한 관계를 ORM의 include에 모두 넣어 한 번의 query로 완성된 응답을 만들었습니다. 코드 한 줄로 풍부한 객체 graph를 얻을 수 있었지만 여러 to-many 관계의 cardinality가 곱해지자 SQL 반환 행이 폭증했고, 이어서 객체 조립에 필요한 메모리도 함께 늘었습니다. 작은 개발 데이터에서는 드러나지 않던 이 문제가 운영 환경에서는…
최근 글
-
-
Kubernetes의 Startup·Readiness·Liveness Probe를 구분해야 하는 이유
처음에는 Startup과 Readiness, Liveness Probe가 같은 health endpoint를 호출해도 충분하다고 생각했습니다. 하지만 초기화가 오래 걸리는 정상 Pod와 외부 DB 연결이 끊긴 Pod가 같은 실패로 처리됐습니다. 그 결과 정상 프로세스가 반복해서 재시작되거나 아직 준비되지 않은 Pod로 요청이 전달됐습니다. 세 Probe가 묻는 질문과 실패 효과를 분리해야 했습니다. 하나의…
-
온프레미스 제품에서 DB 없는 설정과 PostgreSQL 설정을 함께 지원하기
온프레미스 제품을 단일 노드에 설치하려는 환경에서는 애플리케이션 하나를 실행하기 위해 PostgreSQL까지 운영하는 일이 부담이 될 수 있었습니다. 중앙에서 설정을 수정하고 여러 인스턴스가 공유해야 하는 환경에는 데이터베이스가 잘 맞았지만, 설정이 거의 바뀌지 않는 소규모 설치에는 같은 구성이 지나치게 무거웠습니다. 처음에는 기존 Repository에 isOnprem 조건을 추가하면 두 환경을…
-
MongoDB → Redis Streams → PostgreSQL: 유실 없는 데이터 파이프라인 만들기
MongoDB에 원본을 저장하고 PostgreSQL에 조회용 데이터를 만드는 파이프라인을 운영했습니다. 수집 API는 빠르게 응답해야 했고, 조회 API는 복잡한 필터와 통계를 제공해야 했습니다. 두 요구를 한 데이터베이스에 맡기기보다 MongoDB를 원본 저장소로, PostgreSQL을 조회 저장소로 분리했습니다. 처음 구조만 보면 간단합니다. 수집 요청을 받은 서버가 MongoDB에 문서를 저장하고 Redis Streams에…
-
Kotlin 데스크톱 앱을 Windows·Linux·macOS에 배포하며 만난 문제들
Compose Multiplatform으로 만든 데이터 마이그레이션 도구는 개발 환경에서 세 운영체제 모두 같은 UI와 기능을 제공했습니다. 공통 Kotlin 코드가 동작한다는 사실만 보면 배포도 하나의 Gradle 작업으로 끝날 것처럼 보였지만, 사용자가 실제로 설치할 파일을 만드는 순간부터 문제의 성격이 달라졌습니다. 처음에는 개발 머신에서 패키징 작업을 실행해 DMG, MSI, DEB…
-
Goroutine Worker Pool을 Semaphore로 바꾼 이유
파일 저장 API 서버에서 업로드가 끝난 이미지를 후처리해야 했습니다. 원본을 디스크에 기록한 뒤 썸네일과 변환 이미지를 만드는 작업은 CPU 부하가 컸습니다. 요청에 따라 결과를 기다려야 할 때도 있었고, 응답과 무관하게 백그라운드에서 처리해야 할 때도 있었습니다. 처음에는 전형적인 Goroutine Worker Pool을 만들었습니다. 작업 채널에 Job을 넣고, 고정된…
-
Ubuntu Server Ethernet DHCP 활성
-
Terraform에서 MetalLB 설정 시 유의사항
Terraform의 plan 및 apply 전략 상 k8s 클러스터에 설치되어 있지 않은 CRD (CustomResourceDefinitions)를 포함하는 kubernetes_manifest를 사용하는 경우 helm_release로 선행하여 helm chart를 설치하도록 하더라도 CRD를 인식하지 않아 에러가 발생한다. Terraform repo에 이미 이슈로 등록되어 있지만 해결해줄 의지가 없는 것으로 보인다. 문제가 해결되기 전까지는 Helm Chart를 테라포밍하지 말고,…