Securing High-Concurrency Ticket Sales: A Framework Based on Microservice
본 논문은 피크 시간대의 고동시성 문제를 효과적으로 해결하는 동시에 안정성, 데이터 일관성 및 포괄적인 온라인 예약 경험을 보장하며, Spring Cloud 마이크로서비스 아키텍처를 기반으로 구축된 보안성이 뛰어나고 고성능인 철도 예매 시스템을 제시한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
철도 예매 시스템을 거대하고 인기 있는 콘서트 공연장에 비유해 보겠습니다. 명절 기간에는 수백만 명의 사람들이 정확히 같은 초에 티켓을 사려고 몰려듭니다. 옛날 방식의 시스템은 마치 한 명의 점원이 있는 하나의 거대한 티켓 판매 부스와 같았습니다. 인파가 너무 많아지면 줄이 멈춰 서고, 점원은 과부하 상태가 되며, 때로는 점원이 너무 빨리 처리하려다 보니 서로 다른 두 사람에게 같은 좌석을 중복 판매하는 실수까지 저지르곤 했습니다.
이 논문은 이러한 티격 시스템을 구축하는 새로운 방법인 "마이크로서비스(Microservice)" 접근 방식을 설명합니다. 하나의 거대한 부스 대신, 그들은 수백 개의 전문화된 스테이션이 함께 작동하는 현대적이고 하이테크한 경기장을 구축했습니다. 그들이 어떻게 했는지 아주 쉽게 설명해 드리겠습니다.
1. 전문가 팀 (마이크로서비스)
모든 것을 수행하는 하나의 거대한 컴퓨터 대신, 시스템은 다섯 개의 작고 독립적인 팀(서비스)으로 나뉩니다:
- 멤버십 팀: 당신의 신원과 신분 확인을 담당합니다.
- 티켓 팀: 어떤 열차가 운행 중인지, 어떤 좌석이 비어 있는지 알고 있습니다.
- 주문 팀: 당신의 영수증과 예약 상세 정보를 관리합니다.
- 결제 팀: 돈을 처리합니다 (안전한 계산원처럼 작동합니다).
- 게이트웨이 팀: 입구에서 신원을 확인하고 문제아들을 막는 보안 요원 역할을 합니다.
만약 "주문 팀"이 지치더라도 "티켓 팀"은 계속 작동합니다. 즉, 한 부분이 고장 나더라도 전체 시스템이 무너지지 않습니다.
2. 보안 요원 (교통 제어)
엄청난 인파가 문으로 몰려들 때, 시스템에는 문지기가 필요합니다. 그들은 Sentinel이라는 도구를 사용했습니다. 이것은 초당 얼마나 많은 사람이 입장하려고 하는지 숫자를 세는 스마트한 보안 요원이라고 생각하면 됩니다.
- 너무 많은 사람이 동시에 티켓을 사려고 하면, 보안 요원은 정중하게 대기하도록 안내하거나 경로를 우회시켜 시스템이 압사당하는 것을 방지합니다.
- 이는 한 부분의 느려짐이 건물 전체를 끌어내리는 "연쇄 장애(cascading failure)"를 막아줍니다.
3. 빠른 사서 (캐싱 및 블룸 필터)
시스템은 Redis(사서)라고 불리는 초고속 메모리 뱅크를 사용하여 "A 열차에 좌석이 있나요?"와 같은 질문에 답합니다. 매번 무거운 데이터베이스(메인 아카이브)에 물어보지 않고도 말이죠. 이 덕분에 시스템은 믿을 수 없을 정도로 빨라집니다.
하지만 가끔 사람들이 존재하지 않는 좌석(예: 운행하지 않는 열차의 좌석)에 대해 물어볼 때가 있습니다. 사서가 모르는 내용일 경우, 보통 메인 아카이브까지 달려가 확인해야 하는데, 이는 속도를 늦춥니다.
- 해결책: 그들은 **블룸 필터(Bloom Filter)**를 사용했습니다. 이것은 "그 좌석은 확실히 존재하지 않습니다"라고 아카이브를 확인하기도 전에 즉시 알려주는 마법의 체크리스트라고 상상해 보세요. 이를 통해 시스템이 가짜 요청에 시간을 낭비하는 것을 방지합니다.
4. 완벽한 장부 (데이터 일관성)
고속 환경에서는 좌석을 두 명에게 중복 판매해서는 안 됩니다.
- 문제점: 데이터베이스 업데이트가 느리면, "빠른 메모리"는 좌석이 이미 팔렸음에도 불구하고 여전히 좌석이 있는 것으로 표시할 수 있습니다.
- 해결책: 그들은 Canal이라는 도구를 사용했습니다. Canal은 메인 데이터베이스의 일기(로그)를 지켜보는 초고속 스파이라고 생각하면 됩니다. 일기에서 티켓이 판매되는 순간, 스파이는 즉시 "빠른 메모리"에 알려서 업데이트하도록 합니다. 이를 통해 모두가 즉각적으로 동일한 진실을 볼 수 있게 합니다 именно 합니다.
5. 토큰 버킷 (초과 판매 방지)
두 사람이 정확히 같은 밀리초(ms)에 마지막 티켓을 낚아채는 것을 막기 위해, 그들은 빠른 메모리에 **토큰 버킷(Token Bucket)**을 만들었습니다.
- 버킷 안에 정확히 10개의 티켓(토큰)이 들어있다고 상상해 보세요.
- 누군가 티켓을 사고 싶어 하면, 먼저 버킷에서 토큰 하나를 집어야 합니다.
- 이 버킷은 단 하나의 엄격한 규칙(원자적 연산)에 의해 관리되기 때문에, 한 번에 한 사람만이 토큰을 가져갈 수 있습니다. 만약 버킷이 비어 있다면, 요청은 즉시 거절됩니다. 이는 실제로 존재하는 티켓보다 더 많은 티켓이 팔리지 않음을 보장합니다.
6. 고유 ID 생성기
모든 티켓에는 고유한 번호가 필요합니다. 오래된 시스템은 UUID와 같은 무작위 숫자를 사용했는데, 이는 마치 퍼즐 조각을 바닥에 흩뿌려 놓은 것과 같습니다. 나중에 찾기가 매우 어렵습니다.
- 해결책: 그들은 Snowflake 알고리즘을 사용했습니다. 이 알고리즘은 숫자를 순서대로 정렬된 퍼즐 조각처럼 생성합니다. 이 조각들은 고유하면서도, (1, 2, 3... 처럼) 순서대로 올라가기 때문에 컴퓨터가 이를 찾고 저장하는 속도가 훨씬 빠릅니다.
결과
이 시스템을 구축한 후, 그들은 대규모 접속 상황을 시뮬레이션하여 테스트했습니다.
- 속도: 시스템은 초당 817건의 열차 조회를 처리할 수 있었으며, 평균 대기 시간은 눈 깜빡임보다 빠른 단 **31밀리초(ms)**였습니다.
- 티켓 구매: 초당 265건의 티켓 구매를 처리할 수 있었습니다.
- 안전성: 초과 판매는 0건이었습니다. 존재하지 않는 티켓을 구매한 사람은 단 한 명도 없었습니다.
요약하자면, 저자들은 전문화된 팀, 스마트한 보안 요원, 그리고 마법의 체크리스트를 갖춘 잘 조직된 하이테크 경기장처럼 작동하는 티켓팅 시스템을 구축하여, 가장 붐비는 명절 기간에도 시스템이 빠르고 안정적이며 모두에게 공정하게 유지되도록 만들었습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.