어느 날부터 화면이 느려집니다.피크 타임만 되면 p95가 튀고, DB CPU가 90%에 붙고, 슬로우 쿼리가 늘어납니다.이런 문제는 종종 “버그”가 아닙니다.읽기(read) 트래픽이 커지면서 생기는 구조적 한계인 경우가 많습니다.왜 읽기가 먼저 터질까?쓰기(write)는 데이터를 “만듭니다”.읽기(read)는 데이터를 “소비합니다”.서비스가 성장하면 이 소비량이 훨씬 더 빨리 커집니다.콘텐츠 1개 생성(write)수천, 수만 명이 조회(read)읽기:쓰기 비율은 보통 10:1로 시작해서, 콘텐츠 서비스는 100:1 이상도 흔합니다. 이건 “디버깅”으로만 해결이 안 된다읽기 병목은 결국 물리 한계와 맞닿습니다.CPU는 처리량에 한계가 있고메모리는 크기가 한정돼 있고디스크 I/O는 장치 속도에 묶입니다그래서..

status 인덱스가 카디널리티가 낮아도 잘 먹히는 이유부터 복합 인덱스, LIMIT과 ORDER BY, covering index, 그리고 (created_at, status)가 더 좋은 케이스까지 Batch Job Queue를 운영하다 보면 결국 자주 만나게 되는 쿼리가 있습니다.SELECT idFROM job_queueWHERE status = 'PENDING'ORDER BY created_atLIMIT 50;대기 중인 작업(PENDING) 중에서 오래된 것부터 몇 개 가져오는 패턴이죠. 이건 거의 모든 배치/큐 시스템의 기본 동작입니다.그런데 status 컬럼은 보통 값 종류가 몇 개 없습니다. (PENDING, RUNNING, COMPLETED…)그래서 이런 질문이 자연스럽게 나옵니다.statu..

쿠버네티스를 운영하다 보면 환경 변수, API 키, 인증 토큰처럼 절대 코드에 포함되면 안 되는 시크릿(secret) 들을 관리해야 합니다.기본적으로 Kubernetes Secret 객체를 사용할 수 있지만, 시간이 지나면 다음과 같은 문제들이 생기기 쉽습니다:여러 서비스에서 동일한 비밀 정보를 반복해서 관리해야 함운영자가 수작업으로 Secret 값을 수정해야 함GitOps 파이프라인에 시크릿을 넣지 못해서 구성 관리가 꼬임외부 Vault(AWS, GCP, HashiCorp)와 연동이 어렵거나 불편함이 문제를 깔끔하게 해결해주는 오픈소스 프로젝트가 바로 External Secrets Operator(ESO) 입니다.External Secrets Operator란?External Secrets Operat..

사내에서 Bazel을 도입하게 되어 학습 및 팀원 교육 자료로 만든 자료를 블로그에도 공유합니다 공식문서에 Bazel 개념관련 문서가 있지만 한국 자료뿐만 아니라 영어자료 조차도 부족한 상황이라본인처럼 Bazel을 처음 접한사람이 이해하기 어려운 면이 별도로 문서로 해서 정리한다.ConceptsWorkspace우리가 보통 서비스 리포지토리 단위로 생각하는 개념을 Bazel 에서 WORKSPACE 라고 한다 Bazel 은 monorepo 를 위해 만들 Bazel 로 구성된 프로젝트의 루트에는 WORKSPACE 라는 파일이 존재하는데 여기서 프로젝트 공용으로 빌드에 필요한 의존성들을 추가한다. (e.g go, python, java 빌드에 필요한 의존성들)PackageBazel 에서 소스코드를 소프트웨어 모..

MySQL 파티션 테이블 가이드들어가며: 파티션의 필요성대규모 데이터베이스를 운영하다 보면 마치 거대한 도서관을 관리하는 것과 같은 어려움을 겪게 됩니다. 수백만 건의 데이터를 하나의 테이블에서 관리한다면, 책장 전체를 뒤져야 하는 것처럼 검색 시간이 오래 걸리고 관리도 어려워집니다. 이러한 문제를 해결하기 위해 MySQL은 파티셔닝이라는 강력한 기능을 제공합니다.파티션 테이블의 이해파티션 테이블은 마치 도서관의 책을 주제별로 나누어 관리하는 것과 같습니다. 하나의 큰 테이블을 여러 개의 작은 물리적 조각(파티션)으로 나누어 저장하지만, 사용자 입장에서는 여전히 하나의 테이블처럼 사용할 수 있습니다.예를 들어, 온라인 쇼핑몰의 주문 내역을 연도별로 파티셔닝한다고 생각해봅시다:-- 주문 내역 테이블을 연도..