사례2건

2건 중 1~2번째

1. IL-0264 Healthchecks.io 의 로드 밸런서가 연결 슬롯을 다 써서 웹사이트와 핑 엔드포인트의 요청이 느려지거나 타임아웃됐다

   Healthchecks.io2025

   증상

   Healthchecks.io 의 웹사이트 healthchecks.io 와 핑 엔드포인트 hc-ping.com 에 연결이 간헐적으로 안 됐다. 일부 요청은 끝나는 데 몇 초씩 걸렸고, 어떤 요청은 아예 타임아웃됐다. 운영자는 요란한 알림에 잠에서 깼다.

   간헐적 타임아웃지연 시간 증가간헐적 연결 실패

   촉발

   잘못 설정된 클라이언트가 UUID 하나로 핑 요청을 초당 10건에서 초당 300건으로 늘려 계속 보냈다.

   원인

   용량 한계

   구성 요소

   HAProxy

   기여 요인

   자동화 증폭한계 경보 부재

   감지

   운영자가 11월 2일 0시 11분 UTC 에 요란한 알림에 잠에서 깨어 조사를 시작했다.

   조치

   • 문제를 일으킨 클라이언트의 IP 주소를 찾았다. IPv4 주소 하나와 IPv6 /64 서브넷이었다.
   • 이 주소들에서 오는 TCP 요청을 거절하도록 로드 밸런서 설정을 바꿨고, 서비스가 정상으로 돌아왔다.

   후속 조치

   • 비슷한 문제를 막으려고 로드 밸런서의 속도 제한 설정을 바꿔 tarpit 방식을 쓰지 않고 바로 HTTP 429 로 응답하게 했다.
   • HAProxy 설정에 빠져 있던 timeout http-request 5s 를 넣어 Slowloris 공격을 막게 했다. Slowloris 공격도 연결 슬롯을 바닥낼 수 있고, 하기도 쉽기 때문이다.
   • 로드 밸런서에 여유를 더 주려고 HAProxy 설정의 maxconn 값을 올렸다.
   • 로드 밸런서의 속도 제한 규칙이 hc-ping.com 뿐 아니라 hchk.io 엔드포인트에도 걸리게 했다.
   • HAProxy 프론트엔드의 활성 세션 수가 maxconn 보다 한참 낮은 기준값을 넘으면 알리도록 Netdata 에이전트에 알림 규칙을 더했다.
   • 로그를 쓰기 편하도록 HAProxy 로그 형식을 손봤다.

   교훈

   HAProxy 의 속도 제한 방식은 저마다 장단점이 있다. tarpit 은 요청을 차례로 보내는 클라이언트는 늦출 수 있지만, 클라이언트가 요청을 대량으로 동시에 보내면 로드 밸런서를 오히려 무너뜨릴 수 있다. 운영자는 이번 일을 교훈으로 삼아 속도 제한에 걸린 요청을 deny 방식으로 거절하도록 바꿨다.

   사례 보기
2. IL-0550 Bitbucket Cloud 의 웹사이트와 API 가 6시간 동안 느려지고 Pipelines 빌드가 밀렸다

   Atlassian2024

   증상

   2024년 2월 22일 07:22 UTC 부터 Bitbucket Cloud 의 웹사이트와 API 가 느려졌다. 커넥션 풀이 포화되고 응답 시간이 늘었으며, 완전히 타임아웃 나는 요청이 점점 늘었다.

   지연 시간 증가커넥션 풀 고갈간헐적 타임아웃처리량 저하

   원인

   용량 한계

   구성 요소

   데이터베이스PostgreSQL vacuum

   기여 요인

   한계 경보 부재

   조치

   • Bitbucket Pipelines 에 리소스를 더 넣어 쌓인 잡을 처리했고, 17:30 UTC 에 백로그가 모두 처리됐다.

   후속 조치

   • 쓰기가 많은 데이터베이스 테이블의 vacuum 임계값을 다시 설정한다.
   • 이런 동작을 더 일찍 잡아 영향을 줄이도록 알림 임계값을 조정한다.
   • Pipelines 서비스의 오토스케일링과 로드 셰딩 동작을 조정하고 빌드 러너 용량을 늘린다.

   사례 보기

원인별1