로드 테스트: 플레이어 프로필 및 트래픽 피크
1) "평균 온도" 가 아닌 모델 프로파일
iGaming 부하에는 폭발물이 많습니다. 프로모션/토너먼트/스트림은 여러 번의 RPS 버스트를 제공하며 동작 분포가 고르지 않습니다 (로그인 → depozit → stavki/vyvod). 테스트는 세그먼트 (초보자, VIP, "보너스 헌터", 모바일) 의 동작을 반영해야합니다. 그렇지 않으면 "녹색 그래프" 및 빨간색 사고가 발생합니다.
주요 SLO (30 일 예):- 로그인: 성공 99 이상. 9%, p95 λ250 ms
- 예금: 성공 99 이상. 85%, p95 λ400 ms
- WS: p95 메시지 RTT 5%
- 게임 출시: 성공 99 이상. 8%, p95 λ800 ms
2) 플레이어 프로필 (행동 시나리오)
A. Newbie (신규 플레이어) -25-40% 피크 트래픽
경로: 등록 → 로그인 → 프로모션보기 → 예금 (소량) → 1-2 슬롯 출시
특징: UX 오류의 비율, 리트레이 결제, 페이지 간 점프
B. 레귤러-40-50%
경로: 로그인 → 빠른 예금/예금 없음 → 3-5 게임 → 드문 인출
기능: 안정적인 세션, WS의 p95> 200ms에 민감
C. 보너스 헌터 (프로모션) -프로모션에서 10-20%
경로: 등록 → 활성화 보너스 → 최소 입찰 → 빠른 철회 시도
특징: '/프로모션/클레임 '으로의 폭발, 남용 재개, 올바른 제한없이 빈번한 429
D. 하이 롤러/VIP-보통 1% 이지만 높은 점검
경로: 로그인 → 큰 예금 → 라이브 게임/높은 스테이크 → 철회
특징: 게임 제공 업체의 지연/파일에 민감하고 중요한 SLA 지불
E. Bettor (스포츠/라이브)- 경로: 인용문에 대한 로그인 → 구독 → "좁은 창" (최대 10-30 초) 의 빈번한 베팅
- 특징: 맥동 WS 부하/계수 캐시, 목표 버스트/VAR
3) 교통 모델 및 타이밍
오픈 vs 폐쇄 모델
공개 (Poisson, 도착/초) -공개 프로모션 및 스트림에 적합합니다 (사용자는 "온다").
문을 닫았습니다 (수정). 안정적인 세션 (VIP, 라이브 게임) 을 위해 생각 시간이있는 가상 사용자 수.
트래픽 패턴:- 램프: 10-20 분 안에 선형 가속 x1 → x5
- 버스트: 30-120 년대 x3-x10 "뱅" (보너스/잭팟/목표 발표)
- 웨이브: 매 5-10 분마다 능선 (스트림/토너먼트 라운드)
- 담그기: 2-12 시간 안정적인 하중 (누출, GC, 설명자, 저하)
4) 중요한 흐름과 지표
인증 및 프로필
'/로그인 ', '/2fa/확인', p95/p99, 오류율, 잠금/인자 제한 여행의 RPS
지불
게임 게이트
슬롯/라이브 테이블 시작: 성공 비율, 타임 투 퍼스트 스핀, 공급자 실패
웹 소켓: 피크 연결, 메시지/초, RTT, 속도 제한/429, 다시 연결/분
프로모션/보너스
'/프로모션/클레임 ', '/프리스핀/활성화': 200/4xx/5xx, 409/경쟁 업데이트 공유, 지갑에 캐스케이드
금고 및 대기열
포화: CPU, DB 연결, 풀 타임 아웃, 대기열 지연, GC 일시 중지
5) 지리와 현실 네트워크
시장 별 지리적 배포 (EU/LatAm/MEA/APAC) 및 ASN 믹스 (모바일 네트워크, 호스팅).
모바일 RTT, 패킷 손실.
A/B: CDN을 사용하고 우회 (원점) - "깨끗한" 백엔드를 평가합니다.
6) 데이터 디자인 테스트
가정 계정, 지역 별 BIN 카드, 통화, KYC 상태.
현실적인 행동 시간: 생각의 시간 1-7 초, 캐주얼, 0. 3–1. 라이브 베팅의 경우 2 초.
비 등식 작업 제어 (인출/침착): PSP 샌드 박스 용 건식 모드, 지갑 플러그.
사기 방지/봇 필터: 테스트 ASN/IP/장치의 화이트리스트, 그렇지 않으면 WAF/anti-bot이 스탠드를 "교살" 합니다.
7) 테스트 계획 (릴리스/프로모션 템플릿)
1. 연기 부하: 피크의 10-20%, 30 분
2. 용량 램프: x1 → 대상 → x1. 목표 피크에서 5, 단계당 10-15 분
3. 버스트 시리즈: 현재 레벨에서 x3-x5에 60-120 초의 3-5 파도
4. 흡수: 60-80% 피크에서 4-8 시간 (누출, 열화)
5. Failover/Chaos: 하나의 PSP/PoP 비활성화, 게임 제공 업체 저하, 하나의 파편 데이터베이스 삭제
6. WS-storm: 2-3 분 안에 질량 재 연결 + 5-10 × 메시지
7. 프로모션 스톰 : /프로모션/클레임 + 등록 + 60 초 "창" 예금
종료 기준: 녹색 영역의 모든 SLO; CPU/연결에 비해 헤드 룸 30% 이상; PSP 할당량을 초과하지 않습니다. 대기열 성장과 테스트 후 p99가 없습니다.
8) 봉우리를 견딜 수있는 인프라 패턴
프로모션 전 사전 스케일 인 따뜻한 풀/프로비저닝 동시성 (기능/컨테이너).
연결 풀링 및 업스트림 제한 (DB/PSP) + 요청 대기열.
예금/웹 후크의 이념성 키.
배압: 429/503, '재생 후', "무거운" 뿌리 저하 (보고/검색).
계수의 캐시/에지 캐시 및 게임의 정적 메타 데이터.
9) 회귀 방지: 처음에 "파괴"
오버플로 DB 풀 → p99 성장 및 타임 아웃
질량 균형 업데이트를위한 지갑 잠금- PSP 속도 제한 → retrays의 눈사태
- 정육점이 아닌 수천 개의 구독을위한 WS 방송
- 로그인/예금에 대한 너무 공격적인 WAF 규칙 → FPR
10) 테스트 중 관찰 가능성
대시 보드 RED/USE + 비즈니스 깔때기 (로그인 → depozit → stavka → vyvod).
느린/오류 쿼리 (100% 샘플 오류) 에 대한 종단 간 추적.
메트릭/로그에서 스테이지 마커 (램프/버스트) 를 테스트합니다.
별도의 PSP/게임 제공 업체 패널, 다시 트레이 대기열, demempotency 적중.
11) 팀과 프로세스
전쟁 실: 성능 엔지니어, 백엔드, SRE, 위험/지불, WAF/보안, 제품.
런북: p99> 대상으로 수행하는 작업, 부하를 줄이는 방법, 공급자로부터 전화를 거는 사람.
보고서: SLO, 대역폭, 병목 현상, 비용, 코드/아키텍처/할당량 권장 사항.
12) Kapasiti 계획: 플레이어 수에서 RPS까지
평가 (예):- 피크에서 동시 플레이어: 50k
- 평균 동작 빈도: 0. 25–0. 플레이어 당 5 req/s (아래 모바일, 위의 라이브)
- RPS 평가 API: 12. 5k-25k + 서비스 요청 (지갑, 공급자, 캐시)
- WS: 30-60k 활성 연결, 테이블 당 3-8 msg/s
- 버스트 및 retrai에 30-50% 헤드 룸 추가
13) 벤치 준비 점검표
- 데이터: 계정/지갑/카드/통화/국가/게임, 가명
- 지불 격리: 웹 후크의 샌드 박스 + 플러그, "실시간" 쓰기 금지
- prod에서와 같이 Edge/CNC/WAF; 테스트 ASN을위한 "소프트" 모드의 안티 봇
- 관찰 가능성: 대시 보드, 경고, 추적 활성화
- Autoscale 및 warm-pool 구성; 풀/연결 제한 문서화
- "무거운" 기능을위한 카나리아 플래그 (보고서, 대량 수출)
14) 도구 (랜드 마크)
발전기: k6, 개틀링, 로커스트 (도/WS), JMeter (웹 소켓 플러그인 포함)
피드 에뮬레이터: 따옴표/게임 제공 업체의 사용자 정의 스크
재생 트래픽: 익명화 및 정규화를 통한 tcpreplay/ingress 미러링
15) 프로필 "프로모션 토너먼트, 시작 60 초 전" (사례) 의 예
Wave-5 min → 0:- 오픈 도착: 400 → 2,500 req/s (로그인/새로 고침)
- '/프로모션/클레임 ': 20 초의 1,000 rps 3 × 버스트
- WS: + 15k 연결, "리더 보드" 에서 + 5 msg/s
- 미리 따뜻하고 따뜻한 수영장 캐시
- 속도 제한 '/프로모션/클레임 ': 10/min IP, 2/min 계정, 30 초 음의 답변 캐시
- 이데올로기 및 보너스 발생 대기열 (배치 50-100/사이클)
- '재시도 후' + UI 진행 상황이있는 "소프트" 429
성공 기준: 로그인/예금 SLO, p95 WS <150 ms, <0의 저하 없음. 5% 청구 오류, 대기열 인플레이션 없음.
요약 다시 시작
iGaming 로드 테스트는 "엔드 포인트 촬영" 이 아니라 동작 모델링입니다. "먼저 SLO 및 플레이어 프로필을 정의한 다음 트래픽 모델 (개방/폐쇄) 을 선택하고 지오 및 PSP 제한이있는 실제 로그인/예금/베팅/프로모션 시나리오를 구축하고 테스트 버스트 및 담그고 관찰 가능성을 높이고 자동 스케일을 준비하십시오. 자본 계획과 런북으로 결과를 수정하십시오. 이렇게하면 놀라움과 전환 손실없이 트래픽 피크가 발생합니다.
