Incident Library

IL-0462 Shopify · 2021-10-21 (게시일)kubernetesgcpdatabase

GKE 위 MySQL 파드 일부가 시작과 종료에 오래 걸려 KateSQL 인스턴스 교체가 느려졌다

KateSQL 은 Shopify 가 GKE 위에 직접 만든 데이터베이스 서비스 플랫폼이고, 여러 Google Cloud 리전과 많은 GKE 클러스터에서 운영 MySQL 인스턴스 수백 개를 관리한다. 2021년에 인스턴스 교체 작업에서 일부 MySQL 파드의 시작과 종료가 같은 데이터를 가진 다른 파드보다 훨씬 느리다는 것을 알았다. 인스턴스 교체는 새 MySQL 레플리카 파드를 만들고 옛 파드를 멈추는 일을 모든 인스턴스가 바뀔 때까지 되풀이하는 절차다. 오래 돈 노드보다 새 노드가 빨라서, 우선 옛 노드를 cordon 하고 인스턴스 교체로 MySQL 파드를 새 노드로 옮긴 뒤 옛 노드를 drain 해 줄였다.

깊이 조사해 보니 InnoDB 버퍼 풀 초기화 중 메모리 할당이 커널의 mem_cgroup_commit_charge 에서 시간을 썼다. 정상 노드와 문제 노드의 메모리 cgroup 수를 비교하자 문제 노드에는 약 50,000개가 있었다. 팀은 cgroup 누수를 의심했다. 페이지를 charge 할 때마다 많은 cgroup 을 훑어야 한다면 성능이 떨어질 수 있었다. Google 의 리눅스 커널 엔지니어는 cgroup 을 지울 때 slab 메모리를 상위로 넘기는 동작의 또 다른 부작용이라고 확인했다. 근본 원인은 리눅스 커널 메모리 cgroup 컨트롤러의 버그였다.

kubepods cgroup 에 memory.force_empty 를 써 넣자 메모리 cgroup 수가 정상 노드 수준인 약 1800개로 빠르게 줄었고, 그 노드에서 MySQL 파드를 재시작하자 80G InnoDB 버퍼 풀이 5초 만에 초기화됐다. Google 엔지니어와 함께 여러 우회책과 수정을 검토했다. 마침 GKE 를 업그레이드할 시기여서 GKE 1.18 로 새 클러스터를 만들고 새 MySQL 파드를 그 클러스터에 띄웠다. GKE 1.16 에서 1.18 로 올리면 관련 수정이 들어간 리눅스 커널 5.4 를 받는다. 몇 주 동안 InnoDB 버퍼 풀 초기화 시간과 질의 성능이 고르게 유지됐다.

심각도
–
영향 범위
KateSQL instance replacement slowed: MySQL pod creation took 10 to 30 minutes, and affected pods also served slower queries
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

KateSQL 의 인스턴스 교체 작업에서 MySQL 파드 생성 시간이 10분에서 30분까지 들쭉날쭉했다. 일부 MySQL 파드는 데이터가 같은 다른 파드보다 시작과 종료가 훨씬 느렸고, 설정 변경이나 업그레이드 같은 유지 보수 때 MySQL 인스턴스를 빨리 교체하기 어려워졌다.

CPU, 메모리, 스토리지와 데이터가 똑같은 두 파드를 비교하자 katesql-n4sx0 은 초기화에 2120초, 시작에 1104초가 걸렸고 katesql-jxijq 는 초기화 74초, 시작 17초였다. MySQL 오류 로그에 찍힌 InnoDB 버퍼 풀 초기화 타임스탬프로 어느 단계가 느린지 알 수 있었다.

생성이 느린 파드는 시간이 지나며 성능도 서서히 떨어졌다. 임시 메모리 테이블을 쓰는 질의에서 슬로 쿼리가 늘었다.

느린 mysqld 를 strace 로 보면 mmap() 호출 하나가 약 128MB 를 잡는 데 약 100 ms 가 걸렸다. top 으로 보면 버퍼 풀 초기화는 단일 스레드로 CPU 를 약 100% 썼다. perf 플레임그래프에서는 메모리 할당기 jemalloc 이 커널 함수 mem_cgroup_commit_charge 에서 대부분의 시간을 보냈다. slabtop 으로 보면 노드 하나에 파드 약 64개가 도는 상태에서 dentry 캐시가 20GB 안팎으로 비정상적으로 컸다.

빠른 점검에서 새로 만든 노드가 몇 달째 돌던 노드보다 성능이 좋았다. kubelet, 리눅스 커널, Container-optimized OS 버전은 같았고 다른 것은 가동 시간뿐이었다. 스토리지 하위 시스템은 원인에서 뺐다. 커진 dentry 캐시를 의심해 sysdig 의 글을 따라 확인했지만 그 글의 경우와는 달랐다. 그래도 dentry 캐시를 비우자 노드를 재시작한 것처럼 성능이 곧바로 좋아졌다.

증상 느린 파드 시작·종료지연 시간 증가

원인

원인 소프트웨어 결함

구성 요소 리눅스 커널노드 운영체제 이미지데이터베이스
기여 요인 미패치 알려진 버그
촉발
–

감지

KateSQL 인스턴스 교체 작업에서 MySQL 파드 생성 시간이 10분에서 30분까지 들쭉날쭉한 것을 보고 알았다.

조치

후속 조치

–

교훈

이번 조사는 Shopify 데이터베이스 플랫폼 그룹이 한 조사 가운데 가장 오래 걸린 축에 들었다. 문제의 성격, 재현의 어려움, 따를 만한 정해진 방법이 전혀 없었다는 점 때문에 근본 원인을 찾는 데 오래 걸렸다. 그래도 문제를 풀 방법은 여러 가지가 있었다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 리눅스 커널, 노드 운영체제 이미지, 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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