사례2건

2건 중 1~2번째

1. IL-0312 max_connections 를 올리려고 재시작한 주 PostgreSQL 데이터베이스가 다시 올라오지 않아 Gadget 의 모든 앱 요청이 멈췄다

   Gadget2024

   증상

   2024-12-13 11:25 AM EST 에 Gadget 은 커넥션 한도를 올리려고 주 Postgres 데이터베이스를 그 자리에서 재시작했는데, 서버가 내려간 뒤 다시 올라오지 않았다. 그동안 Gadget 앱으로 오는 모든 요청이 실패했다.

   서비스 중단지연 시간 증가

   촉발

   Gadget 은 플랫폼이 커지며 Postgres 의 max_connections 한도에 닿아 생기던 짧은 장애를 끝내려고, 이 값을 올리는 긴급 설정 변경을 결정했다. max_connections 는 서버를 재시작해야만 바뀌므로 11:25 AM EST 에 데이터베이스를 그 자리에서 재시작했다.

   원인

   용량 한계

   구성 요소

   데이터베이스리눅스 커널데이터베이스 프록시와 커넥션 풀러

   기여 요인

   미검증 가정스테이징 불일치자동화 증폭과도한 영향 범위

   감지

   Gadget 은 11:25 AM EST 에 재시작한 데이터베이스가 기대대로 다시 올라오지 않는 것을 11:26 AM 에 확인했다.

   조치

   • 데이터베이스 서버를 하드웨어 리셋해 메모리 조각화를 없앴고, 11:50 AM EST 에 데이터베이스가 다시 올라왔다.
   • 데이터베이스가 멈춘 동안 오토스케일러가 줄인 컴퓨트를 당시의 거의 4배로 다시 띄웠고, 이 확장은 성공했지만 서비스 저하가 20분 더 이어졌다.

   후속 조치

   • 이번처럼 중단을 일으키는 데이터베이스 작업은 앞으로 replica 를 만들어 장애 조치하는 방법으로만 한다. 새 replica 를 먼저 띄우면 넘어가기 전에 운영 인프라 안에서 동작을 확인할 수 있다.
   • Black Friday 와 Cyber Monday 전의 용량 계획을 훨씬 공격적으로 세워 부하 6배 증가에 대비하고, 충분한 시간을 두고 종합 부하 시험을 해서 준비가 됐는지 확인한다.
   • 계획된 중단은 상태 페이지와 커뮤니티 Discord 로 미리 알리고, 계획된 점검과 서비스 장애의 차이를 분명히 알리도록 표준 운영 절차를 다듬는다.
   • 계획해 온 데이터베이스 샤딩 프로젝트를 끝내 Gadget 앱마다 다른 데이터베이스를 쓰게 한다. 그러면 데이터베이스 설정 변경에 카나리 배포와 블루/그린 구성을 써서 고객 앱에 닿기 전에 충분히 시험하고, 장애 범위도 좁힐 수 있다.
   • 이미 진행 중인 무중단 데이터베이스 장애 조치 시스템을 완성해 어떤 앱도 멈추지 않고 데이터베이스 크기와 설정을 바꿀 수 있게 한다.
   • 오토스케일러의 최소 규모를 크게 높였다. 앞으로 장애가 나도 컴퓨트가 훨씬 덜 줄어 복구가 빨라진다.

   교훈

   Gadget 은 그 자리에서 재시작하는 방법을 고른 것을 판단 착오로 보았다. 확신할 수 없고 겪어 본 적 없는 상태로 시스템을 몰아넣은 위험한 선택이었다는 것이다. Gadget 은 모든 실패 상태를 미리 알 수는 없어도 처음 보는 실패 상태로 들어가는 일은 대개 피할 수 있다고 했다. Black Friday 와 Cyber Monday 의 용량 계획이 두 배로 잡혀 거의 5배의 부하를 감당하지 못했다. 제대로 계획했다면 점검 시간을 미리 잡고 스테이징에서 연습할 수 있었다. 새 데이터베이스 설정을 사용자에게 영향 없이 운영과 비슷한 환경에서 시험할 방법도 없었다. 통합 테스트는 합성 Postgres 데이터베이스와 쿠버네티스 인프라에서 돌기 때문에, 몇 달 동안의 운영 부하가 만드는 메모리 조각화나 메모리 사용 문제를 재현하지 못한다.

   사례 보기
2. IL-0578 HAProxy 로드 밸런서를 거치는 정적 콘텐츠 전송이 수십 초씩 늦어졌다

   GMO Pepabo2020

   증상

   운영 환경에서 정적 콘텐츠 전송이 수십 초 단위로 늦어졌다.

   지연 시간 증가

   원인

   용량 한계

   구성 요소

   HAProxy리눅스 커널클라우드 로드 밸런서

   기여 요인

   기본 설정 방치

   조치

   • 동료 엔지니어가 sysctl net.ipv4.tcp_mem 을 조정해 정적 콘텐츠 전송 지연을 가라앉히고 장애를 복구했다.

   교훈

   net.ipv4.tcp_mem 의 기본값은 부팅 때 RAM 크기로 정해지므로 RAM 이 작은 VM 에서는 한계가 낮게 잡힌다. tcp_mem 은 시스템 전체의 TCP 소켓에 걸리는 페이지 단위의 값이고, 소켓 하나의 버퍼 크기를 바이트 단위로 정하는 net.ipv4.tcp_rmem, net.ipv4.tcp_wmem 과는 다른 설정이다. TCP: out of memory 로그가 가리키는 TCP oom 은 프로세스를 SIGKILL 로 끝내는 OOM Killer 와 관계가 없다. TCP oom 로그가 나왔을 때는 송수신 제한도 함께 일어나고 있다. 문제를 찾거나 감시할 때는 /proc/net/sockstat 의 TCP mem, /proc/net/protocols 의 press, /proc/net/netstat 의 TCPMemoryPressures, TCPMemoryPressuresChrono, TCPAbortOnMemory, OfoPruned, PruneCalled, TCPRcvQDrop, TCPAbortFailed 를 본다.

   사례 보기

원인별1