[장애 대응] 부하테스트 선정 및 시나리오

오늘은 콘서트 예약시스템의 부하테스트를 위한 테스트 시나리오에 대해서 설계해봅니다.

 

장애대응, 부하테스트가 중요한 이유?

실제 운영환경에서 대량의 트래픽이 몰려서 서버가 다운되거나, DB Connection 부족으로 장애가 발생할 수 있습니다. 장애가 없는 완벽한 프로그램은 없기에 사전에 부하테스트를 통해서 개선점을 파악할 수 있습니다. 그리고 미리 장애대응 훈련을 하면서 실제로 장애가 발생했을 때 빠르게 조치할 수 있습니다.

 

부하테스트에서 반드시 확인할 것

1. 예상 TPS(Transaction Per Second)

2. 평균/중간/최대 응답시간(P50, P99, P999)

3. 다량의 트래픽 유입시 동시성 이슈 확인

위 3가지에 대해서 성능을 비교하고, 성능이 목표치에 도달하지 못하는 경우 원인을 분석하고 성능을 개선할 방법을 찾습니다. 실제 운영배포 전에 반드시 확인해야할 부분입니다. 

그래서 제가 개발한 콘서트 예약시스템에 대해서 장애가 발생할 수 있는 지점에 대해서 부하테스트 시나리오를 만들었습니다.

 

콘서트 예약시스템에서 장애가 유발될 수 있는 포인트가 어느 지점

 

1. 토큰 발급

수 많은 사용자들이 로그인을 하기 위해서 토큰 발급을 요청을 할 수 있다.

토큰 발급은 아래와 같은 프로세스로 이루어진다.

 

토큰 발급된적 없는 경우 : 토큰발급 API 요청 => 신규 토큰 발급, 사용자 생성 => 토큰 Table Insert, 사용자 Table Insert

토큰 발급된적 있는 경우 : 토큰발급 API 요청 => 토큰이 있는지 테이블에서 조회 => 토큰 및 대기순번 반환

 

신규 로그인을 하는 경우 모든 트래픽이 2개의 테이블에 몰릴 것이다. 그렇게 되면 사용자를 조회하거나 토큰을 조회하여

검증할 때 DB에 부하가 있어서 조회가 느려질 것이라고 판단한다. 물론 이것은 Redis 대기열을 이용해서 DB의 부하를 줄일 수 있다. DB 방식의 대기열에서는 부하가 걸릴 수 있다고 판단된다.

토큰발급에서는 Redis가 죽지 않는이상 장애 가능성이 낮다.

 

2. 좌석 임시 예약 => 장애 가능성 있음

좌석 임시예약에서 사용자들이 많이 몰리면 동시성 이슈가 발생합니다. 1개의 좌석에 대해서 여러 사용자가 좌석에 대해 임시 예약을 하려고 하는 경우 비관적 락이 걸리면서 다른 사용자들의 요청은 대기를 하게 된다. 

그 결과 1명이 락을 획득하고 좌석을 임시 예약하는 시간까지 다른 사용자들은 대기를 하여 대기상태가 걸린다.

 

어떤 이유로 한 사용자의 좌석 예약 요청이 오래 걸린다면, DB Connection을 오래 잡게 된다.

그렇게 되면 다른 사용자들의 API 요청도 대기를 하게 되고, 결국 서버 Connection이 계속 유지되어 부하가 걸리게 된다.

이런 경우 DB 장애가 발생하여 타임아웃이 발생할 가능성이 있습니다. 그래서 저는 좌석 임시예약에 대해서 부하테스트를 진행해보려고 합니다.

 

 

3. 결제 처리

결제처리는 예약시스템에서 트랜잭션이 긴 기능중 하나이다.사용자 조회 => 토큰인증 => 좌석 조회 => 좌석, 예약상태변경 => 결제 5단계에 걸친 작업이 실행된다.Spring Event로 트랜잭션을 분리한다고 해도, 하나라도 오류가 발생하면 롤백이 되어야 한다.만약에 결제처리에서 장애가 발생할 수 있을까??

결제 트랜잭션에서는 DB Connection을 오래 잡는 곳은 없다. 그래서 DB 부하로 인해 장애가 날 가능성은 없어보인다. 

 

 

예상되는 병목지점(Bottle neck)은 어디인가?

- 병목지점은 좌석 임시예약할 때가 가장 큰 병목 현상이 발생할 것으로 보인다.

가장 많은 요청이 들어오고 성공, 실패 내역을 사용자에게 반환해야 하는 지점이다.

그리고 Lock 으로 인해서 좌석 예약시 대기시간이 있는 지점이다.

여기서 DB Connection을 오래 잡고 있으면, 다른 사용자들은 계속 대기하게 된다.

그러면 서버 Connection이 부족해서 장애가 발생할 수 있어보인다.

 

 

Slow Query로 DB에 부하가 되는 지점은 어디인가?

- Slow Query가 발생할 수 있는 부분은 좌석이 많은 경우 

 

[성능 테스트 결과]

위 결과에서 보면

토큰발급, 좌석예약 순서로 시간이 오래 걸린다.

 

원인 분석

1. 토큰 발급

 

 

작성 시간이 조금 부족해서 다시 보완 예정입니다..