Q) 과연 내 서비스는 언제 죽을까? 한계를 알아보자

 

서비스를 실제로 배포해 오픈한 날 발생한 일 

 

2022-03-31 오전01:28

오픈빨로 대기방에 40명이 동시접속을 하였는데...

글세... cpu 90찍음 !!!!! 

ubuntu 에서 free를 쳐서 나오는 메모리에는

전혀 지장이 없이 평범했다. 

메모리는 Swap을 해서 3G가 되어서 괜찮을 것 같고...

 

그 후 40명 정도의 사람이 플레이를 하고있지만 동시접속이 아니여서 그런지 cpu는 20~30%로 떨어졌다. 그말은 즉 동시접속만 아니라면 분산 플레이로 인해 cpu%에 무리는 없는 걸로 생각된다.

하지만 추후 cpu 부족으로 서버가 터진다면 EC2에서 구매를 해보던지 해야할 것 같다.

 

t2.medium  cpu: 2기가 , memory 4기가 이걸로 사버려? 

 

동접 80명은 받아도 가능하게 EC2 프리티어 변경함

t3.micro 삼 cpu:2기가 , memory 1기가 삼

아까 t2.micro cpu:1기가, memory 1기가 에서는 JMeter로 450명씩 1번 요청시 cpu 사용률이 40~50%까지 올라갔었다.

그런데 t3.micro로 변경후에는                       JMeter로 1000명씩 1번 요청시 cpu 사용률이 15~20%으로 떨어졌다.

많이 성능개선 되었다!!!

 

어? 그런데 서버를 다시 돌려서 8081 포트에서 깃 푸쉬 후 8082로 바뀌어야 하는데 바뀌지가 않고 nohup도 생성되지 않는다... 

뭔가 이상해서 AWS codedeploy 배포에 가보니 상태가 실패로 뜬다... 뭐지?

ubuntu에서 df -hT를 쳐서 봤더니 8G 였던 EC2 용량이 꽉차있다... 

서둘러 nohup 파일과 log 파일들을 파일질라에서 삭제했지만 남은 용량은 500mb 정도뿐... 

이걸로는 안될 것 같아서 

AWS EC2 Elastic Block Store 에서 볼륨을 8기가에서 -> 16GiB로 2배 올렸다.

 

밑에 블로그를 보고 16으로 올려놓음.

https://velog.io/@hyeonseop/ec2-%EC%9A%A9%EB%9F%89-full%EC%9D%BC-%EB%95%8C-%EB%8C%80%EC%B2%98%EB%B2%95

ec2 용량 full일 때 대처법

와 !!! 이제는 16기가의 절반인 8기가의 용량이 남았다!!!

나름 살만하다! 휴~ 

AWS codedeploy 배포도 잘 성공! 역시 용량부족이 문제였나보다... 

 

3/27, 3/28일은 24시간 꼴로 서버가 꺼져서 EC2를 새로 중지 후 시작을 눌러야했다. ubuntu에서 Swap을 통해 메모리를 2기가 늘려주어 총 3기가의 메모리를 갖게되어 서버가 메모리부족으로 꺼지는 것을 개선하였다. 그 후로는 메모리 부족으로 서버가 꺼지는 일은 없었다.

3/29~3/30일은 40명 동시 접속시 cpu가 90%까지 올라가고 하여서 EC2의 cpu를 1기가에서 2기가로 업그레이드 해주었다. 또 EC2의 기본용량이 8기가로 되어있었는데 용량이 꽉차서 codedeploy에서 실패로 떠서 용량을 8 -> 16기가로 늘려주어 해결하였다.

90%에 육박했던 cpu사용률이 10%대로 현저히 낮아진 모습!!!! Good!

많이 안정화되었다. (휴~ 안심이다~)

 

---

Q) 언제 내 서비스가 죽는지 어떤 변화가 생기면은? (2022.04.02)

풀링을 하는이유는 방업데이트를 하기위해서한다. 게임 대기화면에서 새로운 방이 생겼을 때 바로 반영해서 알수있고 대기중인 방이 게임을 시작하였을 때 시작중으로 바뀌는 것을 실시간으로 반영을 하기 위해서이다. 그래서 풀링을 1초에 한번 하였을 때와 2초에 한번 하였을 때를 비교하여 몇명까지 대기페이지에 접속하였을 시 서버가 한계인지 부하테스트를 진행해보았다. 진행은 실제로 접속을 하고 EC2 ubuntu 에서 htop 명령어로 실시간으로 CPU와 Memory를 보면서 체크를 하였다. 전체 실험에서 Memory는 3기가에서 여유가 많이 남고 변화가 거의 없어 따로 기입을 하지 않았다.

<풀링 1초에 한번 : 실제 70명이 한계라고 보면된다>

 

JMeter로 테스트 해본 수치
메인페이지(룸 리스트 조회하기 api만) 1초,100루프 기준 350쓰레드(유저)까지 동접가능  에러율 1% 이하   (360스레드 이상 에러율 50%이상으로 치솓음)

 

풀링 1초에 한번 (1차실험) : 90명까지 가능
실제 창 80개키고 실험해봤을 때 cpu 150~180/200% 그정도가 슬슬 한계라고 봐야지.
실제 창 90개키고 실험해봤을 때 cpu 160~190/200% 이개 한계

풀링 1초에 한번 (2차실험) : 70명까지 가능
실제 창 60개키고 실험해봤을 때 cpu 80~140/200%
실제 창 70개키고 실험해봤을 때 cpu 140~160 이였다가 180대로 유지/200%


<풀링 1.5초는 1초대랑 별 다를게 없었다. 비슷>

 

<풀링 2초에 한번 : 실제 100명이 한계라고 보면된다>
  

JMeter로 테스트 해본 수치
메인페이지(룸 리스트 조회하기 api만) 1초,50루프 기준 360쓰레드까지 동접가능
에러율 1% 이하   (스레드 이상 에러율 50%이상으로 치솓음)
-> 결론 : JMeter로 풀링 1초에서 2초로 변화한 수치를 보고싶어서 루프를 반으로 줄였지만 수치상 별 의미는 없었다.

 

풀링 2초에 한번 (1차 실험)      
실제 창 80개키고 실험해봤을 때 cpu 70~90/200%
실제 창 90개키고 실험해봤을 때 cpu 70~100/200%
실제 창 100개키고 실험해봤을 때 cpu 90~120/200%
실제 창 110개키고 실험해봤을 때 cpu 150~170/200%
실제 창 120개키고 실험해봤을 때 cpu 180대/200%
실제 창 150개키고 실험해봤을 때 cpu 180대/200%
실제 창 160개키고 실험해봤을 때 cpu 170~180/200% 조금 내려간게 수상. 에러때문?
실제 창 170개키고 실험해봤을 때 cpu 170~180/200%
실제 창 180개키고 실험해봤을 때 cpu 170~180/200%
실제 창 190개키고 실험해봤을 때 cpu 170~180/200%
실제 창 200개키고 실험해봤을 때 cpu 170~180/200%     

-> 120개부터 수치의 변화가 없는 것으로 보아 제대로 반영이 안되는걸로 판단 

풀링 2초에 한번 (2차실험)
실제 창 100개키고 실험해봤을 때 cpu 180대/200%
실제 창 110개키고 실험해봤을 때 cpu 180대/200%
실제 창 120개키고 실험해봤을 때 cpu 180대/200%

풀링 2초에 한번 (3차실험)
실제 창 100개키고 실험해봤을 때 cpu 180대/200%

결론: 풀링을 1초 -> 2초로 해서 70 -> 100명으로 한계가 늘긴했지만 풀링의 초를 2초로 늘림으로 인해서 방업데이트에 1초정도 딜레이가 생겨서 이미 시작을 누른방인데 대기방으로 보여서 눌렀을 때 착오가 생기는 등의 문제가 생겨서 현재의 프로젝트 서비스 고객이 70명 이상 접속할 가능성이 낮은 점으로 보아 프론트 분들과 상의 한 끝에 서비스 향상을 위해서 풀링 1초로 하는것으로 결정을 하였다.

 

 

한가지 더 말하고 싶은점은...
이러한 실험 뒤에는 꼭!
Filesystem              Type    Size    Used    Avail    Use%     Mounted on
/dev/nvme0n1p1     ext4     16G    16G       0       100%         /

로그로 인한 용량이 꽉 차기 때문에... 지워주어야 codedeploy가 정상적으로 일을 수행할 수 있다... (빨리 지우러가야겠다...)

 

부하테스트 당시 AWS EC2 CPU사용률(%)이 80% 이상 올라간 모습