예외 상황 대비
•
서버에 3000명의 동시 접속자가 특정 시간에 몰릴 것으로 확정되었다.
1.
소스코드를 다듬어서 해결하는 것을 대전제로 생각한다.
2.
절대 지켜야 하는 것들을 정의해야 한다.
a.
읽고 쓰는 동안 문제가 발생해도 문제가 발생하지 않도록 점검
b.
효율 문제로 오래 걸리는 일들은 미리 개선 (C랑 연결됨)
i.
너무 오래 걸린다 싶으면 개선하는 데 시간 쓰기
ii.
성능을 측정할 수 있는 것들을 도입하기
1.
로그성 테이블 작성해서 제일 오래 걸리는 API가 뭔지 모니터링 하는
2.
JMeter
c.
판단 근거가 필요하다.
i.
d.
채팅처럼 소켓을 쓰는 것은 절대 다운되면 안됨
i.
서버가 견딜 수 있는 부하 측정 후 측정한 부하에 맞게 대기열 같은 새로운 시스템을 만들기
ii.
소켓을 어느 정도 유지할 수 있는지 실제로 다운될 때까지 부하 주기, 이를 토대로 가설 세우기
1.
100명만 소켓을 열 수 있도록 유지하려면?
a.
소켓을 연 상태인 인원 수가 몇 명인지 세기 (Redis)
b.
사람이 소켓을 열 때마다 카운트 올려주기
c.
카운트가 가설로 설정해둔 인원 아래인지 확인하기
d.
확인된 사람만 소켓 열어주기
e.
소켓을 초과한 사람들은 줄어드는 숫자인 대기열을 가지고 있을 것.
f.
대기열을 받은 사람들을 특정 시간마다 조회 (js)
g.
대기열이 다 되면 소켓 열기
h.
대기열에서 나간 사람은 redis에서 카운트 내려주기
i.
채팅에서 응답이 없거나 나갔다고 판단이 되는 사람을 골라내는 방법?
i.
•
많은 (ex:3000명 가량의) 사용자가 몰릴 것으로 예상. 3000명의 부하를 버텨보자.
렸을 때 서버에 부하가 갈 걸 방지 하기 위한 서버 분산?
•
대기열을 걸어야 하나?
•
채팅창도 동일한 상황을 가정
◦
서버를 여러 대 운용한다면 RabbitMQ, Redis 같은 외부 메시지 브로커를 사용해야 됨
◦
Redis 캐싱은 필수일듯
서버 부하 관리방법
AWS
•
훈련기간이 끝나도 현 프로젝트 유지 및 개선 예정
⇒ 최종프로젝트 발표 날(2.8.목) 까지 해당 상황에 대한 작업 후에 유저 피드백에 대한 수정 및 추가 기능 들을 작업해 나가는 것에 대해(작업 순서)
튜터님들 언제까지 남아계시는지
최종 발표회
