본문 바로가기
반응형

분류 전체보기913

AWS SDK S3 소켓 누수: Node.js에서 발생하고 Java에서는 안 보이는 이유 들어가며운영 중인 EKS 서비스에서 S3 파일 조회, 이미지 미리보기, 파일 업로드가 동시에 먹통이 되는 장애가 발생했다. Pod 로그를 확인하니 이런 경고가 반복되고 있었다:@smithy/node-http-handler:WARN - socket usage at capacity=50 and 190 additional requests are enqueued.소켓 50개가 전부 점유된 상태에서 190개 요청이 대기열에 갇혀 있었다. 원인은 단 하나의 메서드 — S3 파일 존재 여부를 확인하는 fileExists() 함수였다.이전에 Java로 같은 작업을 했을 때는 이런 문제를 겪은 적이 없었다. 왜 Node.js에서만 이 문제가 발생하는 걸까?문제의 코드// Node.js AWS SDK v3 — 소켓 누수가.. 2026. 3. 9.
200ms latency- 실시간 개인화 시스템 아키텍처 Deep Dive 넷플릭스 앱을 열었다. 화면이 뜨는 순간 "오늘 이거 어때요?"라는 추천이 이미 펼쳐져 있다. 그 0.2초 동안 벌어진 일: 수십만 개의 콘텐츠를 훑고, AI가 점수를 매기고, 결과를 정렬했다. 이 글은 그 0.2초의 비밀에 대한 이야기다.이 글은 NBC유니버설 글로벌 플랫폼 엔지니어링 부사장 Manoj Yerrasani의 ITWorld 기고를 바탕으로, 실전 아키텍처와 코드 레벨의 해설을 더해 구성했다.1. 왜 하필 200ms인가인간의 뇌는 200밀리초 이내의 응답을 "즉각적"으로 인식한다. 이건 UX 감성이 아니라 인지 심리학의 임계값이다. 응답 시간사용자가 느끼는 것 비즈니스 임팩트0~100ms"바로 나왔네"최적의 경험100~200ms"괜찮은데?"수용 가능200~500ms"좀 느린데…"이탈률 증가.. 2026. 2. 26.
Azure ACR 이미지 삭제했는데 왜 안 지워질까? — Soft Delete 함정과 스토리지 절약법, 레이어 구조부터 ECR과의 차이 Azure Container Registry의 내부 저장 구조를 이해하고, Soft Delete 함정을 피해 효율적으로 비용을 관리하는 방법들어가며CI/CD 파이프라인을 운영하다 보면 Container Registry에 이미지가 계속 쌓입니다. "일단 빌드 잘 되니까"라고 방치하면, 어느 날 스토리지 비용이 예상보다 높거나, 이미지를 삭제하려는데 CLI가 "성공"이라 하면서 실제로는 삭제되지 않는 황당한 상황을 마주할 수 있습니다.이 글에서는 Azure Container Registry(ACR)를 운영하면서 겪은 실제 경험을 바탕으로:ACR이 이미지를 어떤 구조로 저장하는지*레이어 공유(Layer Deduplication)**가 어떻게 작동하는지Soft Delete 기능이 삭제 작업에 미치는 영향SKU별.. 2026. 2. 25.
Docker 사용후 이상하게 용량이 많아 진다? - Docker 컨테이너 로그 관리방법 Docker 컨테이너는 기본적으로 stdout/stderr 출력을 JSON 파일로 저장한다. 별도 설정 없이 운영하면 로그가 무한히 쌓여 디스크를 가득 채우는 주범이 된다.1. Docker 로그 구조로그가 쌓이는 원리컨테이너 stdout/stderr ↓Docker 로그 드라이버 (기본: json-file) ↓/var/lib/docker/containers//-json.log컨테이너 내부에서 console.log(), print(), echo 등으로 출력하는 모든 내용이 이 파일에 JSON 형태로 기록된다.로그 파일 형식{"log":"2026-02-20T07:28:15.123Z INFO Server started on port 8000\\\\n","stream":"stdout","time":".. 2026. 2. 20.
Docker 사용후 이상하게 용량이 많아 진다? - Docker Build Cache 관리방법 Docker 이미지를 빌드하면 각 레이어가 캐시로 저장되어 다음 빌드 시 재사용된다.편리하지만 관리하지 않으면 디스크를 수십 GB씩 잡아먹는 주범이 된다.1. Build Cache란?Docker는 Dockerfile의 각 명령어(RUN, COPY 등)를 레이어 단위로 캐시한다.FROM node:20 ← 베이스 이미지 레이어COPY package.json . ← 캐시 레이어 1RUN npm install ← 캐시 레이어 2 (package.json 변경 없으면 재사용)COPY . . ← 캐시 레이어 3RUN npm run build ← 캐시 레이어 4이전 빌드와 동일한 명령 + 동일한 입력이면 캐시 히트 → 빌드 시간 단축변경이 감지되면 해당 레.. 2026. 2. 20.
브라우저 Ajax 요청의 네트워크 흐름: CORS, OPTIONS, DNS까지 정리 웹 서비스를 운영하다 보면 이런 상황을 자주 만난다.“curl로는 되는데 브라우저에서는 안 됩니다”“OPTIONS 요청이 왜 이렇게 많이 오죠?”“배포했는데 데이터가 바뀌지 않습니다”“로그인은 성공했는데 다음 요청에서 세션이 사라집니다”이 문제들의 출발점은 대부분 Ajax 요청의 동작 구조에 있다.이 글에서는 Ajax의 개념이 아니라,서비스 운영과 장애 대응에 필요한 핵심 동작 흐름을 정리한다.1. Ajax 요청은 어디서 시작되는가?Ajax는 단순히 말하면:브라우저 안의 JavaScript가 서버로 HTTP 요청을 보내는 방식예:fetch("/api/order")중요한 점은:요청은 서버가 아니라 브라우저에서 시작된다브라우저는 일반 HTTP 클라이언트와 다르게 강한 보안 정책을 적용한다2. Ajax 요청의.. 2026. 2. 12.
Chrome 디스크 캐시 정리 방법 — 강력 새로고침으로 안 될 때 배포 후 강력 새로고침(Ctrl+Shift+R)을 해도 이전 버전이 보인다면, 디스크 캐시가 원인일 수 있다. 특히 JavaScript의 fetch()로 가져오는 데이터는 강력 새로고침으로 캐시가 우회되지 않는다.왜 강력 새로고침으로 안 되는가강력 새로고침은 브라우저가 직접 로드하는 리소스만 캐시를 우회한다.요청 유형 강력 새로고침 시HTML 문서O — 서버에서 새로 받음, , 등O — 서버에서 새로 받음JavaScript 코드 내 fetch()X — 디스크 캐시 그대로 사용JavaScript 코드 내 dynamic import()X — 디스크 캐시 그대로 사용React, Next.js, Vue 같은 SPA/SSR 프레임워크는 페이지 로드 후 JS에서 fetch()로 데이터를 가져오는 구조가 많다. 이.. 2026. 2. 12.
웹에서 사용하는 캐시 총정리 — 브라우저부터 서버까지 13가지 배포했는데 반영이 안 된다? 강력 새로고침(Ctrl+Shift+R)으로도 안 풀린다? 웹 캐시가 어디서 어떻게 동작하는지 전체 그림을 알면, 원인을 빠르게 찾을 수 있다. 요청이 서버에 도달하기까지 거치는 캐시 계층사용자가 URL을 입력하고 Enter를 누르면, 요청은 여러 캐시 계층을 순서대로 거친다. 어딘가에서 캐시 HIT가 발생하면 그 아래 계층은 실행되지 않는다. [ 클라이언트 영역 ]순서캐시설명1Memory Cache가장 빠름 (RAM)2Disk Cache (HTTP Cache)가장 흔한 캐시3Service Worker Cache개발자가 직접 제어4Back-Forward Cache뒤로가기 전용5Application CacheJS 런타임 (프레임워크, Storage) [ 네트워크 연결/정책 캐시 .. 2026. 2. 11.
Kafka 4.x 이후 리밸런싱 프로토콜 변화 — 왜 “컨슈머가 파티션을 나누지 않게” 되었나Kafka 4.x에 들어서면서 컨슈머 리밸런싱 모델이 구조적으로 바뀌었다.이 변화의 핵심은 **“리밸런싱 로직을 컨슈머에서 브로커로 옮겼다”**는 점이다.이 글은 Apache Kafka 4.x 이후의 리밸런싱 프로토콜 변화를왜 바뀌었는지 → 무엇이 달라졌는지 → 운영에서 뭐가 좋아졌는지 순서로 정리한다.1. 기존 리밸런싱 모델의 근본적 한계Kafka 3.x까지의 구조 (Classic Consumer Group)컨슈머가 직접 파티션 할당흐름:그룹 코디네이터가 멤버 목록 전달리더 컨슈머가 assignor 실행결과를 다시 브로커에 전달즉,리밸런싱 로직이 “컨슈머 애플리케이션 코드 안”에 있었다이 구조의 문제점1️⃣ 리밸런싱이 컨슈머 상태에 의존GC pause일시적.. 2026. 2. 10.
Kafka 파티션 할당 전략 — Range, RoundRobin, Sticky, CooperativeStickyAssignor까지Kafka를 운영하다 보면 리밸런싱(rebalancing) 때문에 처리 지연이나 순간적인 서비스 흔들림을 경험하게 된다.이 문제의 핵심에는 파티션 할당 전략(Partition Assignment Strategy) 이 있다.이 글에서는 Apache Kafka의 컨슈머 그룹에서 파티션이 어떻게 할당되는지,그리고 왜 CooperativeStickyAssignor가 등장했는지를 흐름 중심으로 설명한다.1. 파티션 할당 전략이란?파티션 할당 전략이란,컨슈머 그룹 내에서 “어떤 컨슈머가 어떤 파티션을 읽을지”를 결정하는 규칙이다.컨슈머 그룹에서 아래와 같은 이벤트가 발생하면 리밸런싱이 트리거된다.컨슈머 추가 / 제거.. 2026. 2. 10.
Azure AKS 요금제와 운영 선택지 정리 AKS는 “요금제 + 운영 방식 + 네트워크”를 함께 선택하는 서비스단순히 “관리형 Kubernetes”를 선택하는 서비스가 아니다.실제로 AKS를 구성할 때는 항상 다음 세 가지를 동시에 결정하게 된다.운영 모델 (기존 AKS vs Automatic)컨트롤 플레인 요금제(SKU)네트워크 방식이 글은 그중에서도 기존 AKS(Basic / Default)를 기준으로요금제와 네트워크, 그리고 운영환경에서의 현실적인 선택 흐름을 정리한다.1. AKS의 큰 구조부터 정리AKS는 먼저 운영 모델로 나뉜다.기존 AKS (Basic / Default)AKS Automatic이 글의 범위는 기존 AKS다.기존 AKS의 핵심 개념은 명확하다.Azure는 Kubernetes 컨트롤 플레인만 관리하고, 노드와 운영 판단은 .. 2026. 2. 5.
왜 여러 회사에서 AKS는 불안정하고 EKS는 안정적으로 느껴졌을까 “왜 AKS는 자잘한 오류가 많고, EKS는 더 안정적으로 느껴질까?”쿠버네티스를 여러 회사에서 운영해 본 엔지니어들 사이에서 자주 나오는 말이 있다.“이상하게 AKS는 자잘한 문제가 많고,EKS는 그냥 조용히 잘 돌아간다.” 1. 반복된 실무 체감: “우연이 아니라 패턴”개인적으로 여러 회사를 거치며 공통적으로 느낀 점은 명확했다.AKS:작은 오류가 잦음“완전히 죽진 않았는데 뭔가 이상한 상태”가 자주 발생운영자가 계속 개입해야 함EKS:평소에는 매우 조용함장애가 아예 없다는 건 아니지만 빈도가 낮음문제가 생기면 비교적 명확한 원인이 드러남이 체감이 여러 조직에서 반복되었다면,이는 개인의 운이나 환경 문제가 아니라 플랫폼 구조의 차이로 보는 게 합리적이다.2. SLA 수준에서 이미 시작되는 차이기본.. 2026. 2. 5.
반응형