안녕하세요. 오늘 KTX 경부선 설명절 티켓 예매가 있었죠.

저도 오전 7시에 대기하고 있다가 바로 예매를 신청했는데요.

최대한 빨리 클릭했는데 이 대기 순서가 50만 번대고요. 제 뒤에 거의 뭐 200만 명 정도 이렇게 많은 대기 수가 있네요.

그래서 오늘은 이 대용량 트래픽을 유발하는 이런 어떤 선착순 예매 시스템을 구현하려면 어떤 아키텍처로 설계하면 좋을지 한번 말씀드려 보겠습니다.

참고로 뭐 모든 구체적인 걸 다 말씀드릴 수 없고요.

아키텍처를 크게 세 단계로 나눠서 좀 추상화시켜서 좀 핵심만 말씀드려 보겠습니다.

보통 API의 가장 단순한 모습, 백엔드의 가장 단순한 모습은 이런 형태죠.

사용자가 요청하면 API 한 대가 데이터베이스하고 연동해서 이렇게 값을 반환하는 구조죠.

근데 사용자 수가 많아지면 이 패를 확장하죠.

그리고 앞단에 로드 밸런서나 API 게이트웨이를 두고 사용하고 통신하고 부하를 이렇게 분산하죠.

그런데 이 예매 시스템 같은 경우, 이 설명절 KTX 예매는 굉장히 많은 사람이 동시에 접속하죠.

오전 7시에 시작하면 예매하는 사람은 이때 전부 다 클릭하게 됩니다.

아까 그 대기표에서도 보셨듯이 제가 50만 번대였고요.

제 뒤에 거의 200만 명이 대기하고 있었죠. 이런 트래픽 규모에서는 이 데이터베이스가 견디지 못합니다.

API를 아무리 스케일 아웃해도 결국 예매를 처리하는 데이터베이스, 뭐 좀 분리는 한다 치더라도 DB가 거의 뻗을 확률이 굉장히 높습니다.

그렇다고 DB를 무한정 스케일 아웃하기는 같은 경우는 RDB거든요.

최종 예매 시스템은 데이터 정합성이나 무결성 같은 것들이 잘 보장이 돼야 되기 때문에 NoSQL을 잘 안 쓰죠.

RDB는 스케일 아웃하기도 힘들고 스케일업의 비용은 굉장히 많이 증가하죠.

설령 그렇게 한다고 해도 이렇게 수백만 요청, 동시 요청을 처리하기 힘듭니다.

RDB 가지고는 그래서 새로운 아키텍처가 필요한 거죠.

이러한 대용량 트래픽이 예매 시스템 같은 경우에는 일단 트래픽이 굉장히 많죠.

동시에 수십만, 수백만이 요청을 하죠.

그리고 선착순으로 돼야 되기 때문에 순서가 보장이 돼야 되죠.

먼저 들어온 사람이 먼저 예매할 수 있도록 보장을 해야 되고 그리고 좌석수, KTX의 좌석수를 넘지 않도록 초과 예매가 안 돼야 되죠.

그리고 서로 다른 사람이 같은 자리 혹은 같은 시간대를 예매할 수 없도록 중복 예매가 방지돼야 되죠.

그래서 이런 어떤 대용량 선착순 예매 시스템 같은 경우 어떤 식으로 설계를 하는지 좀 보겠습니다.

다만 제가 구체적으로 하나하나 어떤 집기보다는 이 아키텍처 관점에서 좀 추상화해서 추상화 아시죠?

제가 이전 강의에도 말씀드렸죠.

핵심만 아키텍처 측면에서 핵심만 같이 한번 설계를 어떻게 하는지 한번 보겠습니다.

통상 이런 경우 세 단계로 문제를 분리해서 설계를 합니다.

먼저 모든 요청이 데이터베이스로 바로 가지 못하도록 앞단에 대기열에 먼저 등록을 시켜요.

대기열 등록은 인메모리 시스템에 등록을 시키죠.

이게 1번이고 2번. 그다음에 대기열에서 선착순으로 예매를 할 수 있는 곳으로 입장을 시켜요.

대기열은 계속 쌓여 있겠죠. 수백만이.

그러다가 일부를 예매로 돌립니다. 순서대로. 예. 이게 예매 입장이고요.

그리고 예매 처리. 아, 입장해 가지고 실제 RDB에 들어가도록 예매 처리하는 것. 이렇게 좀 단순화시키면 세 개의 단계로 구분할 수 있습니다.

아, 모든 순간적인 트래픽 동시 요청들이 DB로 바로 갈 수 없도록 대기열을 만드는데요.

요즘은 레디스가 그 대기열에 가장 적합한 어떤 솔루션이라서 많이 사용하고 있어요.

어, API가 이렇게 있죠. 요대.요 요 앞에는 사용자고요.

로드 분배하겠죠. 여기 뒤에 레디스를 넣는 거죠. 이 레디스가 대기열 역할을 합니다.

레디스의 지셋 이게 뭐죠? 정렬 정렬 셋이죠.

정렬 셋이라는 자료 구조를 이용합니다.

처음에 사용자가 예약 시작하면 어 KTX 같은 경우도 처음에 로그인은 안 시키거든요. 바로 로그인이 되지 않은 상태에서 바로 예약 접수라는 버튼을 누릅니다.

그러면 API에서 그걸 받아서 UUID라는 고유값을 만들어서 이게 사용자 식별값이에요.

아직 로그인이 되지 않았기 때문에 아이디라는 식별자 값을 만들어서 레디스에 이 소티드 셋에 저장을 합니다.

그리고 시간 타임스탬프 이렇게 하면 이 타임스탬프로 자동으로 정렬이 되죠.

들어온 순서대로 이 사용자가 이 시간에 들어왔다.

그래서 들어온 순서대로 쭉 정렬이 되죠.

그리고 API는 레디스에 그렇게 놓고 나서 사용자에게 반환합니다. 그리고 사용자는 다음 요청부터는 UUID를 들고 오죠.

그 이후에 사용자 브라우저와 이 API 같은 경우에는 보통 폴링 아니면 SSE, 서버 센트 이벤트죠.

어, 이런 것들 중에 하나를 사용해서 계속 대기열 상태 아까 그 대기표 보셨죠?

그게 계속 업데이트되거든요. 내가 지금 몇 번째 있고 내 몇 번째 있고 계속 줄어들죠.

웹소켓은 혹시나 네트워크 장비 단에서 거부될 가능성도 있어서 그래서 사용자가 엄청난 트래픽을 보내면 API들이 다 받아서 이 레디스 여기도 클러스터로 구성되죠.

단일 서버가 아니고 레디스 클러스터로 다 보내요.

그럼 레디스는 굉장히 빠르잖아요. 메모리 기반으로 움직이기 때문에.

그래서 레디스의 소티드 셋에 타임스탬프와 함께 사용자 유효 아이디를 저장해 둡니다.

그러면 백단에서 스케줄러가 돌아요.

뭐 1초에 한 번씩, 1초에 한 번씩 레디스를, 레디스에 있는 그 대기열에 있는 앞에서부터 몇 명까지 꺼내 가요.

그 몇 명까지의 기준은 어 이 백단에 그 예약 처리하는 시스템이 있을 거잖아요.

그 예약 처리 시스템, 그러니까 RDB는 예약 처리 시스템의 TPS, 초당 어 TPS가 얼마더라.

그래서 그 TPS보다 조금 더 여유 있게 만일에 백단의 어떤 이 예약 시스템이 초당 한 100건 정도 트랜잭션을 처리할 수 있다 그러면 어 뭐 한 7, 80건 뭐 6, 70건 정도를 받도록 한다고 했을 때 스케줄러는 대기열을 주기적으로 체크하면서 앞에서부터 뭐 60건 정도를 한 번에 가져가죠.

이 이 레디스가 좋은 게 이 브라우저 사용자 단한테 내가 몇 번째 있는지 계속 줄여주는 거 있잖아요.

그 연산을 그냥 ZRANK 그리고 전체 대기자 수는 ZCARD로 바로 아주 빠르게 가져갈 수 있고요.

잠시 좀 지웠다가 다시 좀 할게요. 이렇게 사용자가 액티브 유저에 있는 걸 체크되면 예매 API로 리다이렉션, 그니까 요청을 예매 API로 보내죠.

그러면 이 대기열 서버와 또 다른 API 예매 서버에서 예매를 진행하게 됩니다.

어, KTX 같은 경우에는 시간대 별로 해서 예매 수량 n개의 좌석수를 예매하도록 되어 있어요.

그래서 여기에 총 좌석보다 그 예매하는 수량이 초과되지 않도록 동시성 처리를 제어를 해 줘야 되는데요.

어, RDB의 락을 사용할 수도 있지만 어, 그렇다면 또 RDB가 부하를 받을 수 있으니까 이때도 역시 레디스의 어떤 원자적인, 아토믹한 연산을 이용해서 동시성 제어를 하는 게 좋습니다.

보통 루아 스크립트로 로직을 짜서 이 로직이 원자적으로, 그러니까 멀티 스레드 환경에서도 어 중간에 트랜잭션이 개입되지 않도록 원자적 작업을 수행하는 스크립트를 만듭니다.

여기서 어 현재 잔여 좌석을 조회하고 요청 좌석보다 잔여 좌석수가 많거나 같으면 해당 예약 신청자의 자리수, 그러니까 요청 개수죠.

요청 좌석수죠. 자리수만큼이 조건이 성립하면 성공으로 반환하죠.

만일 누군가가 약간 늦어서 그 시간대에 요청 수보다 잔여 좌석수가 부족하게 되면 실패로 처리합니다.

이 루아 스크립트의 실행 과정은 원자적으로 실행되기 때문에 어 멀티스레드 환경에서도 안전하죠.

그리고 이렇게 성공한 어떤 요청은 바로 RDB로, 그 API를 통해서 실제 아키텍처에 있는 RDB 그쪽으로 넣을 수도 있고 아니면 여기서 또 한번 부활을 좀 방지하려면 여기서도 MQ가 들어갈 수도 있어요.

그래서 요청 좌석수가 성공한 요청을 API가 MQ에 쓰고 바로 반환. 그리고 MQ에서는 백단의 워커가 빼서 DB에 저장하고 완료시키는 거죠.

어, 실제 이 과정에서 복잡한 건 최대한 제거하는 게 좋아요. 이 지금 KTX 예약도 보면 결제는 하지 않도록 되어 있어요.

좌석 예매까지만 이렇게 진행하거든요.

문제가 좀 더 심플해지잖아요. 결제까지 하면 중간에 그 예외 사항들이 굉장히 많아져요.

결제했다가 돌아오는 그 과정에서 어떤 뭐 실패 처리 그런 것들.

그래서 어 결제를 뒤로 미루면 결제 같은 경우에는 좌석 수만큼만 요청이 있을 테니까 수백만, 수십만 되지 않을 거잖아요.

그래서 결제는 훨씬 가벼운 시스템이 되는 거죠. 그래서 결제라는 건 제외하고 예매까지만 하는 거고.

그리고 참고로 이 레디스에 이 스케줄러에서 뭐 100명 100개씩 뽑아서 예매 입장 가능하도록 처리할 때도 레디스에 넣을 때 이 타임아웃 시간을 넣어요.

그래서 예매 입장으로 돌렸는데 너무 오래 걸리거나 아무것도 일도 하지 않는 채 떠나간 사람 있죠.

그냥 브라우저 켠 상태로. 그 사람들은 이 제한 시간 내에 어떤 액션 없거나 아니면 절대적인 제한 시간을 줘서 빠져나가도록 자동으로 떨어져 나가도록 하는 것도 추가를 구현합니다.

이 KTX 같은 경우는 3분이더라고요.

3분 사이에 막 뭘 해도 3분이 지나가면 튕겨 버려요. 이 레디스 액티브 유저 할 때 3분 해 놓으면 자동으로 없어지죠.

그러면 이 API 계속 체크할 때 액티브 유저 없으니까 튕겨내 버리면 되는 거죠.

다시 좀 최종 정리를 좀 할게요. 중간에 그 액티브 유저 넣는 부분이 약간 좀 잘린 거 같아요.

1번 대기열에 저장하는 거. 그리고 스케줄러가 입장 처리하는 것.

마지막으로, 실제 예매 처리해서 RDB에 저장하는 것.

먼저 사용자가 7시에 수백만 명이 접수를 해요. 신청을 하죠. 그러면 요청이 쫙 API가 받을 거예요.

그럼 API들이 DB로 보내면 DB가 뻗죠.

그 DB로 안 보내고 일단 대기열 레디스로 다 보냅니다. 그럼 레디스에서는 소티드 셋에 타임스탬프하고 UUID, 사용자 식별값이죠.

UUID하고 타임스탬프를 소티드 셋에 저장합니다.

그럼 자동으로 정리되죠. 레디스 자료 구조에 의해서. 그렇게 계속 쌓이고요.

사용자가 계속 요청하면 계속 쌓입니다. 대기열에는 이 레디스는 클러스터로 구성돼야 되겠죠.

그리고 스케줄러가 백단에서 뭐 1초에 한 번, 뭐 더 짧게 할 수도 있고요, 더 길게 할 수도 있고요.

수백만 동시 접속을 처리하는 예매 시스템 아키텍처 설계

Scripts