에듀테크의 시즌성 트래픽과 데이터 무결성을
게임 운영 방식으로 관리합니다.
아래 데모에서 각 단계를 직접 눌러 보실 수 있습니다.
👇
문서 소개
강의가 끊기지 않게 하는 운영·모니터링 체계를 정리한 문서입니다.
블레이드&소울 레볼루션 라이브 운영 경험을 바탕으로 쓴 개인 제안서입니다.
몰리는 시점
수능 종료 직후 17시
가채점 기능
평소 서버 이용률
25%
시뮬레이션: 평시 최고치 20, 임계치 80
그래서 문제는
평균이 아니라 봉우리
평균만 보면 서버가 남아 보입니다.
운영 방안
검수를 자동으로
수만 개의 강의·교재 정보를 손으로 보지 않고 규칙으로 걸러냅니다.
봉우리를 나눠 받는다.
한 시점에 몰리는 접속을 대기열과
단계 개방으로 흩어 놓습니다.
불만을 재현 순서로 옮긴다.
'렉 걸려요'를 개발팀이
바로 따라 해 볼 수 있는 단계로 바꿔 적습니다.
서비스 특성
인터넷 강의와 교재를 판매하는 앱은 트래픽이 연중 특정 일자에 집중됩니다.
대표적으로 수능 종료 직후인 17시에 가채점 기능으로 동시 접속이 몰립니다.
이 피크 구간의 트래픽을 어떻게 방어할지,
그리고 강의·교재 데이터 검수와 앱 리뷰 처리를 어떻게 자동화할지 다룹니다.
💡 전략 1. 수작업 데이터 검수 자동화
수만 개의 인강·교재 메타데이터 검수를 엑셀 함수 기반 파이프라인으로 처리해 소요 시간을 줄입니다.
자동화 체크리스트
- ✔️ VOD - 교재 코드 일치 여부 확인
- ✔️ 수강 기간(음수) 오류 검출
- ✔️ 결측치 실시간 하이라이팅
주 40시간 → 10시간은 측정값이 아니라, 반복 확인 작업이 4분의 1로 준다고 가정한 값입니다.
💡 전략 2. 수능 당일 골든타임 트래픽 방어
시험 종료 후 가채점 서비스가 열리는 17:00에 몰리는 동시접속 트래픽. 서버 장애를 어떻게 막을까요?
💡 전략 3. VOC(고객의 소리)를 개발 요건(Jira)으로 번역
학생들의 감정적인 불편 사항을 개발팀이 즉각 이해할 수 있는 '재현 스텝'으로 번역합니다.
"1.5배속 누르면 갑자기 멈추고 렉 걸려요. ㅠㅠ"
"메인 화면 배너 누르면 자꾸 흰 화면만 떠요."
"결제하기 버튼이 키보드에 가려서 안 보여요 ㅡㅡ"
유저 리뷰 카드를 클릭하면 개발팀 언어로 번역된 요건을 확인하실 수 있습니다.
타이틀
완화 곡선에서 줄어든 총량 70이 어디로 갔는지
데모의 폭주 곡선(실측이 아닌 시뮬레이션 값)은 17시(95)와 17시 30분(85)에 서버 임계치 80을 넘습니다.
여기에 더해 곡선 아래 총량과 시간대별 감소율을 보면 완화안이 무엇을 한 것인지가 더 분명해집니다.
| 시각 | 폭주 | 완화 후 | 감소율 | 구간 |
|---|---|---|---|---|
| 15:00 | 12 | 12 | 0% | 배포 전 |
| 16:00 | 15 | 15 | 0% | 배포 전 |
| 16:40 | 30 | 30 | 0% | 배포 전 |
| 17:00 | 95 | 75 | 21.1% | 가채점 오픈 |
| 17:30 | 85 | 50 | 41.2% | 감소폭 최대 |
| 18:00 | 40 | 30 | 25.0% | 25%로 수렴 |
| 19:00 | 20 | 15 | 25.0% | 25%로 수렴 |
폭주 총량
297
평시 102의 2.91배
완화 후 총량
227
평시의 2.23배
사라진 양
70
전체의 23.6%
세로축이 사람 수인지 서버 부하인지에 따라 뜻이 갈립니다.
완화 수단은 무거운 동적 화면 대신 텍스트 기반 가채점 페이지로 우회하는 것입니다.
경량 페이지로 바꿔도 서비스에 들어오는 사람 수는 줄지 않습니다.
줄어드는 것은 요청당 서버가 하는 일입니다.
그런데 전략 설명은 이 값을 동시접속 트래픽이라고 부릅니다.
사람 수라면
70만큼이 서비스를 쓰지 못한 것이 됩니다.
수능 당일 가채점은 대체재가 있으므로,
못 들어온 유저는 다른 서비스로 갑니다.
장애는 막았지만 이용자는 잃은 결과입니다.
서버 부하라면
같은 사람이 가벼운 화면으로 서비스를 받은 것입니다.
아무도 잃지 않고 부하만 23.6% 줄였다는 뜻이므로 제안이 훨씬 강해집니다.
제안의 성격상 후자가 의도일 것입니다.
축 이름을 서버 부하로 적고 동시접속자 수는 폭주와 완화에서 같다는 점을 한 줄 덧붙이면,
같은 그래프가 이용자를 지키면서 장애를 막았다는 뜻이 됩니다.
지금 표기로는 읽는 사람이 반대로 해석할 여지가 남습니다.
감소율이 25%로 수렴하는 것이 경량 페이지의 실력입니다.
시간대별 감소율이 0, 21.1, 41.2, 25.0, 25.0%입니다.
후반 두 구간이 정확히 25%로 같습니다.
상황이 안정된 뒤의 값이므로 이것이 경량 페이지가 실제로 줄이는 부하 비율로 읽힙니다.
17시의 21.1%가 낮은 이유
전환이 막 시작된 시점이라 일부 이용자만
경량 화면을 받은 것으로 볼 수 있습니다.
가장 위험한 순간에 효과가 가장 약한 셈입니다.
17시 30분의 41.2%가 높은 이유
전환이 완료된 데다
밀려 있던 요청이 함께 빠지는 구간이 겹친 것으로 보입니다.
일시적인 값이므로 효과로 제시할 때는 25%를 쓰는 편이 안전합니다.
이 이벤트는 사후 대응이 아니라 사전 배포가 가능합니다.
시뮬레이션은 장애 위험을 감지한 뒤 비상용 웹뷰를 배포하는 순서로 그려져 있습니다.
그런데 수능 종료 시각은 몇 달 전에 공지되는 확정 일정입니다.
폭주 시점을 정확히 아는데 감지를 기다릴 이유가 없습니다.
17시 구간의 감소율이 21.1%에 그친 것도 전환이 그때 시작됐기 때문입니다.
17시 오픈 30분 전에 경량 모드로 미리 전환해 두면 가장 위험한 17시 구간부터 25%가 적용됩니다.
95가 아니라 처음부터 71 수준으로 들어가므로 용량선에 훨씬 여유가 생깁니다.
사후 대응으로 그린 것이 제안을 낮춰 보이게 합니다.
감지 후 대응은 언제 일어날지 모르는 장애에 쓰는 방식입니다.
시각이 정해진 이벤트에는 사전 전환이 맞고, 실행 난이도도 더 낮습니다.
버튼 순서를 사전 전환과 비상 대응 두 가지로 나눠 보여주면 운영 계획을 세울 줄 안다는 점이 함께 전달됩니다.
감지 대응은 예측하지 못한 다른 폭주를 위한 두 번째 장치로 남겨둡니다.
티켓 세 건이 서로 다른 세 조직으로 갑니다.
전략 3의 예시 티켓은 세 건입니다. 담당 영역이 모두 다릅니다.
| 유형 | 내용 | 우선순위 | 담당 |
|---|---|---|---|
| 버그 | 배속 터치 시 프리징 | 높음 | 클라이언트 |
| 버그 | 배너 클릭 시 빈 화면 | 보통 | 웹 앱 개발 |
| 사용성 | 결제 버튼이 키보드에 가려짐 | 보통 | 사용성 · 프론트엔드 |
결제가 막히는 건이 보통으로 잡혀 있습니다.
배속 터치 프리징은 높음, 결제 버튼이 가려지는 건은 보통입니다.
프리징은 사용 불편이고 결제 차단은 매출이 발생하지 않는 상태입니다.
어느 쪽이 급한지는 기준에 따라 갈리는데, 그 기준이 문서에 없습니다.
영향 범위로 볼지 매출 영향으로 볼지 복구 난이도로 볼지를 정해두지 않으면 번역은 되지만 순서는 담당자마다 달라집니다.
번역 다음은 분류 규칙입니다.
세 건의 담당이 모두 다르므로 어디로 보낼지와 어느 순서로 처리할지를 티켓 양식에 미리 넣어야 실제로 돌아갑니다.
전략 3의 재현 스텝은 개발팀이 바로 착수하게 해주지만, 어느 개발팀인지는 아직 사람이 판단합니다.
유형과 화면 위치로 담당을 자동 배정하면 전략 1의 자동화와 같은 성격이 됩니다.
측정할 지표
- • 피크 시점 최대 동시접속과 응답 시간 — 완화 전환 후에도 용량 대비 여유가 유지되는지 봅니다.
- • 전환 시점과 복귀 시점 — 사전 전환이 실제로 피크를 낮추는지 확인합니다.
- • 검수 오류 유출 건수 — 자동화 통과 후 운영 중 발견된 데이터 오류. 절감 시간과 함께 봅니다.
- • 증상별 리뷰 건수 — 같은 문제의 반복 규모. VOC 처리 우선순위의 근거입니다.
- • 재현 성공률 — 작성한 재현 스텝으로 개발팀이 실제 재현한 비율