SLASH 21 - SRE 사례 소개

리밸런싱 도중 갑자기 Redis 커맨드 타임아웃이 대량 발생한 사례를 분석한다. 해당 시점에 순간적으로 큰 데이터가 전송된 정황이 있었고, 큰 컬렉션을 가진 키(빅키)가 옮겨질 때 타임아웃이 난 것으로 추측했으며 키 스캔으로 큰 키의 존재를 확인했다. 또 다른 이슈로 간헐적 ASK 관련 에러가 났다. 클라이언트로 Lettuce를 쓰고 있었는데, 에러를 분석하니 최대 리다이렉트 횟수에 도달해 발생한 것이었다. 마이그레이션 중 소스 노드에 키가 있으면 평소처럼 동작하지만, 키가 없으면 목적지에 다시 물어보라는 ASK 리다이렉션이 발생하고 클라이언트는 ASKING 명령을 보낸 뒤 타깃에 재요청한다.

원인을 잡기 위해 두 가설을 세워 검증한다. 첫째, 키가 마이그레이트되는 순간 요청이 들어오면 양쪽 노드 모두 키가 없다고 판단해 에러가 나는 것 아니냐는 가설이다. 재현하려면 마이그레이트가 오래 걸려야 해 리스트 아이템 200만 개의 약 400MB 키를 만들어 테스트했는데, 락으로 인한 타임아웃은 재현됐지만 ASK 에러는 무관함이 확인됐다. 둘째, 슬롯 상태를 바꾸는 순서 때문인가라는 가설인데, 모든 시나리오를 따져도 ASK 에러를 내긴 거의 불가능했고 소스 노드부터 상태를 바꿨을 때 드물게 UNBOUND 리다이렉션만 확인됐다. 결국 막혀서 동료에게 설명하며 실마리가 풀렸는데, 진짜 원인은 Lettuce 버그였다. Lettuce는 노드당 하나의 커넥션을 여러 스레드가 공유해, ASKING 명령과 그 뒤 연속 실행돼야 할 명령 사이에 다른 스레드 명령이 끼어들 수 있었고, 순서가 어긋나면 타깃이 다시 소스로 리다이렉트하고 그게 반복돼 ASK 에러가 났다. 리밸런싱 전 자료를 충분히 읽고, 빅키를 미리 확인하며, 시뮬레이션 클러스터로 리허설하고, Lettuce는 버그가 고쳐진 5.3.1 이상을 쓰라고 당부한다.

다음은 Memcached 장애다. 4대 운영 중 한 대에서 장비 문제가 발생했는데, 클라이언트 spymemcached의 리디스트리뷰트 설정을 켜 둬 정상 노드로 자연스럽게 재분배될 것으로 예상했다. 문제 장비는 행 상태여서 커넥션은 끊기지 않은 상태였다. 대부분 요청은 재분배됐지만 일부는 재분배할 수 없다는 로그를 내며 계속 문제 노드로 향해 타임아웃을 냈다. 코드를 보니 재분배의 핵심인 해시 시퀀스 함수가 약 0.78% 확률로 같은 죽은 노드를 다시 가리키며, 그 경우에도 비활성 상태인 원래 프라이머리 노드를 다시 할당하고 있었다. 랜덤 문자열 테스트로 항상 같은 노드로만 가는 키들이 존재함을 확인하고, iptables로 한 노드를 막아 장애를 재연했다. Ketama 해시 동작을 더 들여다보길 권하며, 대부분 키는 재분배가 잘 되지만 간헐적 타임아웃은 날 수 있으니 타임아웃을 적당히 설정하라고 정리한다. spymemcached는 500ms 타임아웃인데 대부분 응답이 1ms 안쪽이라, 타임아웃 자체를 문제의 징후로 의심할 수 있다는 경험칙도 공유한다.

세 번째 주제 Prometheus로 넘어간다. 특정 서버에서 가끔 Memcached 타임아웃이 나기 시작했고, 응답 시간이 길어지며 Old 영역 증감 패턴이 이상하게 나타났다. 단서를 시간순으로 정리하면, Memcached 타임아웃, 영 GC 시간 증가와 Old 제너레이션 급변, 한쪽 데이터센터에서만 발생, 그리고 1월 17일을 기점으로 시작됐다는 점이다. 그날부터 한쪽에만 적용된 변화를 추적하니 바로 그 시점부터 Prometheus 메트릭 수집이 시작됐음을 알았고, 수집을 롤백하자 GC 패턴이 정상으로 돌아왔다. 원인을 보면 Spring Boot가 Prometheus 메트릭을 StringWriter에 계속 어펜드한 뒤 toString으로 하나의 거대한 문자열을 만들어 반환하는데, 응답이 클 때는 10MB에 가까웠다. 곧 휴멍거스(humongous) 객체 할당이 문제였다. 리전 사이즈의 절반 이상을 차지하는 큰 객체는 힙에 바로 할당되지 못하고 Old 영역에 거대 객체로 할당되는데, 10MB 응답이 계속 만들어지며 Old 영역이 부족해지고 풀 GC까지 유발했다. 불필요한 메트릭을 제거해 응답을 2MB 이하로 줄이자 문제가 사라졌고, 더 근본적으로는 스트림 형식으로 응답을 내보내 큰 객체 자체가 만들어지지 않게 했다. 발표는 문제 분석에 가장 중요한 세 가지로 변화가 언제 발생했는지, 충분한 로그, 풍부한 메트릭을 꼽으며 마무리한다.