새벽 2시 18분, 장애 대응용 슬랙 채널에 메시지가 올라왔다.
운영 담당자 수진이 먼저 상황을 알렸다.
“새벽 2시 14분부터 결제 오류율이 올라가고 있습니다.”
여기서 오류율은 전체 결제 요청 가운데 실패한 요청이 차지하는 비율을 뜻한다.
잠에서 깬 서비스 기획자 지민이 휴대전화로 쇼핑몰에 접속했다. 첫 화면은 열렸다. 상품 검색도 됐고 장바구니에도 물건을 담을 수 있었다. 겉으로 보기에는 평소와 다르지 않았다.
“사이트는 열리는데요. 서버가 내려간 건 아닌가요?”
백엔드 개발자 현우가 답했다.
“서버 프로그램은 실행 중이고 기본 헬스 체크도 통과합니다.”
수진이 실패한 요청을 다시 확인했다.
“모든 결제 요청이 실패하는 건 아닙니다. 일부 요청이 오래 걸리다가 타임아웃으로 끝납니다.”
지민은 같은 시간대에 진행 중인 할인 행사를 떠올렸다.
“트래픽이 늘어서 서버가 버티지 못하는 건가요?”
“요청량이 늘어난 시점과 오류가 늘어난 시점은 비슷합니다. 원인인지는 아직 확인 중입니다.”
잠시 뒤 현우가 덧붙였다.
“우리 서버까지 요청이 들어오는지, 외부 결제 서비스의 응답을 기다리다가 끊기는지부터 보겠습니다.”
서버는 살아 있다는데 결제는 왜 실패할까?
이 질문에 답하려면 ‘서버가 살아 있다’는 말이 확인한 범위부터 살펴봐야 한다.
“서버가 터졌다”는 말의 범위
“서버가 터졌다”는 표현은 장애 상황에서 자주 들린다. 무엇인가 크게 잘못됐다는 뜻은 분명하지만, 이 말만으로 실제 실패 상태를 확정할 수는 없다.
서버 프로그램이 멈췄을 수도 있고, 프로그램은 실행 중이지만 요청을 처리하지 못할 수도 있다. 일부 요청만 늦어지거나 특정 기능만 실패하는 경우도 있다. 서버가 연결한 데이터베이스나 외부 서비스의 응답이 늦어졌을 가능성도 남아 있다.
긴급한 상황에서는 이 여러 상태를 짧게 묶어 “서버가 죽었다”거나 “서버가 터졌다”고 말한다. 현상을 빠르게 공유하는 데는 유용하지만, 복구 방향을 정하려면 이 표현을 더 작은 상태로 나눠야 한다.
확인할 대상은 세 갈래로 나뉜다.
- 접속 자체가 되지 않는가?
- 접속은 되지만 응답이 늦는가?
- 전체 서비스가 아니라 일부 기능이나 사용자에게만 문제가 생기는가?
접속 실패라면 서비스에 들어가는 첫 경로부터 살펴야 한다. 응답 지연이라면 요청이 어느 구간에서 오래 머무는지 확인해야 한다. 일부 기능만 실패한다면 정상 기능과 실패 기능이 갈라지는 지점을 찾게 된다.
“서버가 터졌다”는 말을 접속 실패, 응답 지연, 일부 기능 실패로 나누면 어디부터 확인해야 할지 보이기 시작한다.
서버라는 말이 가리키는 범위
이 장에서 다루는 웹서비스의 서버는 사용자의 요청을 받아 처리하고 결과를 돌려주는 역할을 맡는다. 실제 프로그램은 물리적인 컴퓨터나 가상 환경에서 실행된다. 실무에서는 그 프로그램이 실행되는 장비나 환경까지 묶어 서버라고 부르기도 한다.
사용자가 쇼핑몰에서 결제 버튼을 누르면 앱이나 웹 브라우저는 결제를 처리해 달라는 요청을 보낸다. 서버는 요청을 받아 필요한 처리를 진행하고 성공이나 실패 결과를 응답으로 돌려준다.
결제 요청의 기본 흐름은 다음과 같다.
결제 버튼 선택
→ 결제 요청 전달
→ 필요한 처리
→ 성공 또는 실패 응답
실제 결제는 이보다 복잡하다. 회원 상태와 주문 정보를 확인하고, 결제에 필요한 다른 시스템과 정보를 주고받을 수 있다. 1장에서는 세부 구조보다 요청이 출발해 결과가 돌아오는 흐름에 집중한다.
이 흐름이 끝나려면 서버 프로그램이 실행 중인 것만으로는 부족하다. 실제 결제 요청을 받아 처리하고 사용자가 기다리는 동안 결과를 돌려줘야 한다. 프로그램의 실행 여부는 필요한 확인 항목 가운데 하나일 뿐이다.
헬스 체크가 확인한 것
장애 채널에서 현우는 서버 프로그램이 실행 중이고 기본 헬스 체크도 통과한다고 말했다.
헬스 체크는 시스템이 미리 정한 항목에 정상적으로 응답하는지 확인하는 검사다. 어떤 검사를 넣었느냐에 따라 프로그램의 실행 상태, 요청을 받을 준비 상태, 일부 연결 상태 등을 확인한다.
검사 범위는 시스템마다 다르다. 아주 단순한 검사는 프로그램이 정해진 응답을 돌려주는지만 볼 수 있다. 더 넓게 설계된 검사는 요청 처리에 필요한 일부 연결 상태까지 포함할 수 있다. 같은 ‘정상’ 결과라도 실제로 확인한 범위는 다를 수 있다.
결제 서버가 기본 상태 검사에는 응답하면서 실제 결제 과정에서는 데이터 조회나 외부 서비스의 응답을 오래 기다릴 수도 있다. 이때 헬스 체크는 통과하지만 사용자의 결제 요청은 실패한다.
헬스 체크는 검사하도록 설계한 범위에서 유용하다. 결과를 읽을 때는 무엇을 검사했는지 함께 봐야 한다. “헬스 체크는 어느 기능과 연결 상태까지 확인하나요?”라는 질문이 필요한 이유다.
실행 상태 확인 뒤에는 실제 사용자 요청의 성공 여부를 따로 봐야 장애 범위를 좁힐 수 있다.
주방 문이 열려 있어도 주문은 밀린다
식당에서는 손님이 주문하고 주방이 음식을 내보낸다. 온라인 서비스의 요청과 응답도 이 흐름과 닮은 부분이 있다.
손님의 주문은 사용자의 요청에, 주방의 처리는 서버의 작업에, 완성된 음식은 응답에 대응한다. 일정 시간 동안 들어오는 주문량은 트래픽으로 생각할 수 있다.
주방 문이 열려 있고 요리사가 일하고 있어도 모든 주문이 제때 끝나는 것은 아니다. 주문이 갑자기 몰리면 음식이 늦어진다. 특정 재료가 떨어지면 일부 메뉴의 주문만 막히기도 한다. 주방의 조리는 끝났지만 카드 결제 단말기 문제로 계산이 완료되지 않을 수도 있다.
서비스에서도 검색은 되지만 결제가 실패하고, 상품 화면은 열리지만 주문 내역은 나타나지 않는 상황이 생긴다. 이용자는 시스템 안에서 어느 지점이 늦어졌는지 보지 못한다. 화면에 결과가 나타나지 않으면 하나의 기능 전체가 멈춘 것으로 경험한다.
이 비유가 맞는 부분
주문량이 늘면 처리 시간이 길어진다. 주방이 운영 중이어도 일부 메뉴나 주문에서 문제가 생길 수 있다. 손님이 결과를 기다리는 시간에도 한계가 있다.
이 비유가 더 이상 맞지 않는 부분
실제 서비스는 하나의 주방보다 복잡하다. 여러 프로그램과 데이터베이스, 결제·인증 같은 외부 시스템이 연결돼 있다. 어느 연결 지점에서 지연이나 실패가 발생했는지는 관찰 자료를 통해 따로 확인해야 한다.
지연에서 타임아웃까지
서비스가 완전히 멈추지 않았더라도 응답이 지나치게 늦으면 사용자는 정상적으로 이용하기 어렵다.
상품 이미지가 평소보다 조금 늦게 나타나는 상황과 결제 버튼을 누른 뒤 결과가 오랫동안 표시되지 않는 상황은 영향이 다르다. 결제 결과가 늦으면 사용자는 처리가 끝났는지 알 수 없다. 다시 버튼을 누르거나 페이지를 닫고, 구매를 포기할 수도 있다.
기능마다 사용자가 기다릴 수 있는 시간도 다르다. 뉴스 기사 한 페이지가 조금 늦게 열리는 상황과 송금 결과가 오랫동안 확인되지 않는 상황을 같은 기준으로 판단하기는 어렵다. 서비스가 정한 목표와 기능의 성격, 사용자가 처한 상황에 따라 허용 가능한 시간이 달라진다.
응답 지연이 계속되면 어느 시점에는 기다리기를 중단해야 한다. 시스템이 그 경계를 시간으로 정해 둔 것이 타임아웃이다.
타임아웃은 요청이나 작업이 정해진 시간 안에 끝나지 않아 대기를 중단하고 실패로 처리하는 현상이다. 서버가 멈췄을 때만 발생하는 것은 아니다. 서버 내부 처리, 네트워크 연결, 데이터 조회, 외부 서비스 응답 가운데 어느 한 구간이 늦어져도 나타난다.
요청한 쪽이 기다리기를 멈췄더라도 처리하던 시스템의 작업이 즉시 중단된다고 단정할 수도 없다. 사용자 화면에는 실패가 표시됐지만 시스템 안에서는 관련 작업이 잠시 이어지는 경우가 생긴다. 그래서 타임아웃 뒤의 상태를 확인할 때는 화면에 보인 결과만으로 전체 처리 상태를 판단하지 않는다.
타임아웃은 정해진 시간 안에 응답을 받지 못했다는 뜻이다. 어느 구간에서 시간이 지체됐는지는 따로 확인해야 한다.
- 어느 요청에서 타임아웃이 발생하는가?
- 우리 시스템에서 처리하는 중인가, 다른 시스템의 응답을 기다리는 중인가?
타임아웃만 보고 특정 시스템을 원인으로 지목하면 실제 지연 지점을 놓칠 수 있다.
그림의 모든 경로가 한꺼번에 실패해야 장애가 되는 것은 아니다. 결제와 연결된 경로만 늦어져도 사용자에게 분명한 기능 장애가 나타난다. 반대로 한 경로가 실패해도 다른 기능은 계속 작동할 수 있다.
장애 범위는 기능과 사용자마다 다르다
사이트 첫 화면이 열리고 상품 검색도 된다고 해서 결제까지 정상인 것은 아니다. 결제 기능만 실패하거나 특정 결제 수단과 일부 사용자에게만 문제가 나타날 수 있다. 같은 시간대에도 어떤 요청은 성공하고 다른 요청은 실패할 수 있다.
운영 현장에서는 일부 기능·사용자·지역·요청에만 영향이 나타나는 상태를 부분 장애로 구분하기도 한다. 구체적인 기준은 조직마다 다르다. 한 회사는 결제 실패를 별도 장애로 분류하고, 다른 회사는 전체 서비스 영향과 함께 하나의 사고로 관리할 수 있다.
영향받는 사용자가 적더라도 결제나 로그인처럼 핵심 기능이 실패하면 사업 영향은 클 수 있다. 특정 지역에서만 장애가 발생해도 그 지역의 사용자는 서비스를 이용하지 못한다. 사용자 수만으로 심각도를 판단하기 어려운 이유다.
장애 초기에는 다음 세 가지를 확인한다.
- 어느 기능과 사용자가 영향을 받는가?
- 모든 요청이 실패하는가, 특정 조건의 요청만 실패하는가?
- 문제가 계속되는가, 간헐적으로 나타나는가?
이 정보가 모이면 사용자 공지 범위와 대응 우선순위를 정하기 쉬워진다. 전체 장애 공지가 필요한지, 특정 기능만 안내할지, 고객센터에 어떤 설명을 전달할지도 달라진다. 기술팀이 조사할 범위도 넓은 서비스 전체에서 실패 조건이 모이는 구간으로 좁혀진다.
트래픽과 오류가 함께 늘었을 때
장애가 발생한 시점에 트래픽도 늘었다면 둘 사이의 관계를 먼저 의심하게 된다.
행사로 요청량이 급격히 늘면 처리 시간이 길어지고 시스템이 감당할 수 있는 범위를 넘을 수 있다. 그러나 트래픽 증가와 오류 증가가 같은 시간에 나타났다는 사실만으로 원인이 확정되지는 않는다.
사용자가 늘면서 우리 서비스 내부 처리의 한계가 드러났을 수도 있고, 데이터베이스나 외부 결제 서비스가 먼저 처리 한도에 도달했을 수도 있다. 평소에는 드물던 특정 요청이 행사 중에 함께 늘어나면서 그 요청에만 문제가 나타날 가능성도 있다.
요청량 증가는 중요한 단서다. 장애 회의에서는 다음 질문으로 사실을 더 확인한다.
트래픽 증가와 오류 증가가 같은 시점에 시작됐나요?
시간대가 겹친다는 답만으로는 부족하다. 정상 요청과 실패 요청의 조건, 지연이 늘어난 구간을 함께 봐야 원인 후보를 줄일 수 있다. 트래픽은 현상을 설명하는 자료 가운데 하나이며, 원인은 여러 관찰 결과를 모아 판단한다.
이제 다시 들리는 장애 채널
“서버 프로그램은 실행 중이고 기본 헬스 체크도 통과합니다.”
서버의 실행 상태와 정해진 검사 결과는 정상이다. 실제 결제 경로까지 정상인지는 아직 확인되지 않았다.
“일부 결제 요청이 오래 걸리다가 타임아웃으로 끝납니다.”
일부 결제 요청이 정해진 시간 안에 응답받지 못하고 있다. 지연이 발생한 구간은 추가 확인이 필요하다.
“트래픽이 늘어난 시점과 오류가 늘어난 시점은 비슷합니다.”
트래픽 증가는 원인 후보다. 실제로 어느 지점이 한계에 도달했는지는 아직 확정되지 않았다.
장애 회의에서는 다음 세 문장으로 확인 범위를 좁힌다.
1. 현재 어느 사용자와 기능이 영향을 받고 있나요?
2. 요청은 어느 단계까지 정상적으로 처리되고 있나요?
3. 전체 요청이 실패하나요, 일부 조건의 요청만 실패하나요?
장애 대응은 실패한 요청과 사용자 영향 범위를 구체적으로 확인하는 데서 시작한다.
