Incident Library

IL-0247 Pinterest · 2025-07-16 (게시일)kubernetesaws

쿠버네티스로 옮긴 검색 시스템 Manas 에서 요청 백만 건에 한 건이 평소보다 100배 느려졌다

Pinterest 는 자체 검색 시스템 Manas 를 2017년부터 자체 클러스터 관리 시스템으로 운영했다. 이 관리 시스템이 복잡해지자 2024년 내내 자체 쿠버네티스 플랫폼 PinCompute 위에 새 시스템을 만들었다. 2025년 초 시험 클러스터로 성능 시험을 하자 요청 일부가 꾸준히 타임아웃을 냈다. 운영 장애는 아니었지만, 그대로 두면 Pinterest 의 모든 추천 서비스에 문제가 남고 최악에는 회사 전체의 장애로 번질 수 있다고 보고 이전을 멈췄다. Manas 는 root 노드가 요청을 shard 마다 leaf 노드로 나눠 보내는 구조이고, leaf 노드는 메모리에 매핑한 색인에서 후보를 찾고 순위를 매긴다. 정상이면 60ms 아래여야 할 leaf 노드의 최대 지연이 5s 까지 올랐고, 노드 하나에서는 몇 분마다 지연이 튀었다.

팀은 더 큰 인스턴스, 운영과 같은 AMI, cgroups 제한 제거, 컨테이너 밖 실행, CPU 격리를 차례로 시험했지만 아무 효과가 없었다. 결국 sudo kill -STOP 으로 로그 수집, 통계 파이프라인, 보안, kubelet, Pinterest 전용 데몬을 하나씩 멈췄고, cAdvisor 를 멈추자 지연 급등이 곧바로 사라졌다. perf 로 보니 cAdvisor 가 리눅스 커널의 smaps 를 부르며 메모리 정보를 읽는 데 지나치게 많은 시간을 쓰고 있었다. cAdvisor 에 기본으로 켜진 container_referenced_bytes 지표는 페이지 테이블의 accessed bit 로 프로세스의 작업 집합 크기를 추정한다. 이를 위해 측정할 때마다 페이지 테이블 전체를 훑어 accessed bit 를 세고 모두 지운다. PinCompute 는 cAdvisor 를 30초마다 돌렸다. Manas leaf 노드는 수백 GB 색인 전체를 메모리에 매핑하므로, 메모리를 100GB 쓰는 호스트라면 페이지 테이블 항목이 2,500만 개에 이른다. smaps 와 clear_refs 는 커널의 페이지 구조 전체를 훑는 동안 잠금을 잡고, clear_refs 는 그 과정에서 작업 집합의 모든 페이지를 TLB 에서 내보낸다. 팀은 이 메모리 경합이 요청 약 백만 건에 한 건이 100배 느려진 원인일 가능성이 크다고 보고 조사를 마쳤다. 모든 PinCompute 노드에서 cAdvisor 의 작업 집합 크기 추정을 껐고, 조사에서 배운 것을 cAdvisor 저장소에 GitHub 이슈로 올렸다.

심각도
–
영향 범위
Manas test search cluster on PinCompute during the migration to Kubernetes; the migration was paused
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2025년 초 쿠버네티스 플랫폼 PinCompute 로 옮긴 검색 시스템 Manas 의 시험 클러스터에 트래픽을 보내자, 적지만 꾸준한 비율의 요청이 타임아웃을 냈다.

leaf 노드 전체를 모은 최대 처리 지연은 매우 높았지만 p9999 이하는 정상 범위였다. 정상이라면 최대 지연이 60ms 아래여야 했는데 최대 5s 까지 나와 거의 100배 나빴다.

leaf 노드 하나를 짧은 시간 간격으로 보자 검색 단계와 순위 단계의 P100 지연이 몇 분마다 급격히 튀었고, 그 사이에는 거의 정상으로 돌아왔다. 두 단계는 요청마다 스레드 하나에서 돌므로, 무언가가 스레드를 CPU 에서 떼어 놓거나 작업 자체를 느리게 만들고 있었다. leaf 노드마다 요청을 수만 건씩 보내고 있었으므로, 요청 하나로 보면 백만 번에 한 번 일어나는 일이었다.

팀은 먼저 변수를 줄였다. 색인 전체를 메모리에 올릴 수 있는 더 큰 EC2 인스턴스 유형으로 시험 클러스터를 다시 만들고, 운영 EC2 Manas 클러스터와 같은 AMI 를 쓰고, CPU 와 메모리의 cgroups 제한을 없애고, 컨테이너 밖에서 노드에 직접 Manas 를 돌려 봤다. 어느 것도 효과가 없었다.

perf 로 CPU 스케줄링 이벤트와 선점 비율, 캐시 사용률, 커널 잠금 경합을 운영 노드와 비교했고, taskset 과 cpuset 으로 Manas leaf 프로세스에 노드의 거의 모든 CPU 를 전용으로 할당했다. CPU 를 빼앗기거나 선점되는 흔적은 보이지 않았고, 이를 막으려는 조치도 효과가 없었다. 팀은 사용자 공간의 자원 제약이나 네트워크, 메모리, 디스크 I/O 의 병목은 없다고 판단했다. 문제는 쿠버네티스가 AMI 위에 더한 무언가에 있고, 일시적으로 나타난다고 보았다.

증상 지연 시간 증가간헐적 타임아웃

원인

원인 소프트웨어 결함

구성 요소 텔레메트리 에이전트리눅스 커널
기여 요인 기본 설정 방치
촉발
–

감지

이전을 검증하려고 시험 클러스터에 트래픽을 보내며 성능 시험을 하던 중, 적지만 꾸준한 비율의 요청이 타임아웃을 내는 것을 발견했다.

조치

후속 조치

–

교훈

자원 격리는 까다롭다. CPU 격리를 해도 프로세스가 이웃 프로세스의 영향에서 완전히 벗어나지는 않는다. 문제 범위를 좁히는 일이 중요했다. PinCompute AMI 가 원인이 아님을 확인하자 범위가 좁아졌고, 소득 없는 조사를 많이 피할 수 있었다. 시스템이 제대로 동작하지 않게 될 때까지 하나씩 꺼 보는 단순한 블랙박스 디버깅도 효과가 있었다. 이것도 문제를 반씩 나눠 범위를 좁히는 방법의 하나다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 텔레메트리 에이전트, 리눅스 커널. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.