Incident Library

IL-0454 Woowa Brothers · 2016-12-08databasenetworking

배민 카드사 할인 이벤트가 시작되자 빌링 시스템이 MariaDB 에 새 커넥션을 맺지 못해 결제 요청 일부가 실패했다

우아한형제들의 빌링 시스템은 사용자의 결제 요청을 PG사에 전달하고 응답을 정리해 주문 시스템에 넘긴다. 이 시스템은 Spring boot 애플리케이션 서버 7대와 MariaDB 로 이루어져 있고, mariadb-connector-j 와 JDBC Connection Pool 을 쓴다. 2016년 12월 8일 오후 6시 카드사 할인 이벤트가 시작되자 약 1분 동안 14,000개의 요청 중 140개가 실패했다. 에러 대부분은 PG사가 네트워크 문제로 요청을 받지 못한 경우였다. 나머지 일부는 Unable to acquire JDBC Connection 예외였고, DB 쪽에는 user: ‘unauthenticated’ Aborted connection 경고가 남았다.

Connection Pool 설정과 DB 서버의 skip_name_resolve 에는 문제가 없었다. 같은 팀의 선임이 mariadb-connector-j 를 최신 1.5.5 로 바꾸자 문제가 재현되지 않았다. 팀이 쓰던 mariadb-java-client 1.4.6 은 io.spring.dependency-management 0.5.6 이 자동으로 정한 버전이었다. changelog 와 JIRA 이슈 CONJ-360 을 따라가 보니, 1.4.6 은 handshake 응답 패킷에 pid@hostname 을 넣으려고 InetAddress.getLocalHost().getHostName() 을 불렀다. hostname 이 localhost 가 아니면 getLocalHost() 는 DNS 로 호스트 이름의 IP 주소를 조회한다. 빌링 애플리케이션 서버에서는 이 조회에 약 6초가 걸렸다. 빌링 데이터베이스의 connect_timeout 은 5초였으므로, DB 서버는 인증이 끝나기 전에 커넥션을 끊었다. 이 동작은 JNA 로 pid 만 가져오도록 고쳐졌고, 그 수정은 2016년 10월에 1.5.4 로 이미 릴리스돼 있었다.

심각도
–
영향 범위
Payment requests through the Baemin billing system at the start of the event: 140 of 14,000 requests failed in about one minute
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2016년 12월 8일 오후 6시 카드사 할인 이벤트가 시작되고 얼마 지나지 않아, 빌링 시스템의 Pinpoint 그래프에 에러를 뜻하는 빨간색이 보이기 시작했다. 약 1분 동안 14,000개의 요청 가운데 140개가 에러로 끝났다.

에러 대부분은 빌링 시스템이 보낸 요청을 네트워크 문제로 PG사가 받지 못한 것으로 보였다. 그 가운데 빌링 시스템 쪽 문제로 보이는 애플리케이션 예외가 섞여 있었다. DataAccessResourceFailureException: Unable to acquire JDBC Connection; nested exception is org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection Caused by: java.sql.SQLNonTransientConnectionException: Could not connect to xxx.xxx.xxx.xxx unexpected end of stream, read 0 bytes from 4

같은 시각 DB 에러 로그에는 인증 전에 끊긴 커넥션이 남았다. 2016-12-08 18:00:55 xxxx [Warning] Aborted connection 37170 to db: ‘unconnected’ user: ‘unauthenticated’ host: ‘xxx.xxx.xxx.xxx’ (Unknown error)

에러는 시간이 지나자 저절로 멈췄다. 팀은 먼저 Connection Pool 설정을 의심해 확인했지만 문제를 찾지 못했다. 다음으로 새 DB 커넥션이 인증 단계에서 실패했다고 보고 --skip-name-resolve 옵션을 확인했다. 이 옵션은 MySQL 계열 DB 서버가 새 커넥션을 인증할 때 클라이언트 IP 주소로 hostname 을 알아내는 과정을 건너뛰게 한다. 그러나 skip_name_resolve 는 이미 ON 이었다.

증상 오류율 상승간헐적 연결 실패

원인

원인 소프트웨어 결함

구성 요소 데이터베이스클라이언트 쪽 DNS 리졸버와 캐시
기여 요인 미패치 알려진 버그
촉발
오후 6시에 선착순 1,000명에게 3,000원을 할인해 주는 카드사 이벤트가 시작되면서 약 1분 동안 빌링 시스템에 요청 14,000개가 들어왔다.

감지

할인 이벤트가 열리는 오후 6시에 NewRelic 과 Pinpoint 로 지켜보던 중, Pinpoint 그래프에 에러를 뜻하는 빨간색이 보이는 것을 알아챘다.

조치

후속 조치

–

교훈

에러가 시간이 지나 저절로 멈췄더라도 대수롭지 않게 넘기면 큰 장애로 이어질 수 있다. 라이브러리는 최신 버전을 쓰는 쪽이 낫다. 드라이버를 올리지 않아도 이 문제를 피하는 방법이 있다. hostname 을 localhost 로 두거나, /etc/hosts 에 IP 주소와 hostname 을 등록해 DNS 를 거치지 않고 바로 IP 주소를 얻게 하면 된다.

출처

참고 문서

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 클라이언트 쪽 DNS 리졸버와 캐시. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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