교통체증 생각하시면 됩니다... 2차선에 차가 지나갈수 있는 대수는 초당 4대인데. 갑자기 초당 10대가 몰리면 속도가 느려지고 결국엔 줄이 길어지죠... 그리고 줄이 길어지면... 점점 길어져서 뒤에 스는 차들은 오랜 시간 대기가 되죠.. 근데 이 줄에도 한계가 있어서... 대기조차 할수없는 차들이 생깁니다.... 터진거죠.
뭐 이제 클라우드가 되면 클러스터링 구축하고 수평확장하면되지 않냐.... 이렇게 할수도 있는데... 일단은 sw도 수평확장을 처리할수 있게 코딩이 되어있어야하고 보통은 부하를 감지해서 자동으로 수평확장하는 웜업하는 시간이 필요합니다.(최소 몇초에서 몇분) 근데 수요예측이 실패하고 서버내에 부하를 유발하는 쿼리, 코드등이 있거나 수평확장하는 속도보다 더 많은 요청이 오면 또 터진는거죠... 물론 수평확장도 리밋이 있습니다.
공부는재밌어
IP 219.♡.240.21
08-12
2022-08-12 10:51:11
·
@lunarc4t님 대기열 만들고 알려주는 거 정도는 아무런 부하가 아니라 생각했는데 더더더더 몰리면 터지는 군요ㄷㄷ. 제가 설계를 했다면 터졌겠네요ㅋㅋ 답변 감사합니다.
이런거 고려없이 솔루션을 사서쓰더라도 누더기로만들면 코로나초반에 ebs 원격수업하려했더니 다 죽어서 수업못듣는경우가 생기는겁니다. 평상시 100명 동접할까말까한 스펙인데 20만이 동접하면 그서버가 접속순번 큐 발행이나 가능할까요? 큐발행도 결국 세션 하나잡고있는거에요. 그래서 서버가 직접하는게아닙니다. 앞에서 번호표나눠줄 놈이 따로있어야하는거죠
공부는재밌어
IP 219.♡.240.21
08-12
2022-08-12 11:13:59
·
@님 100명대 20만명 예를 들어주시니 확실히 이해가 가네요. 그리고 별도 업체를 거친다는 것도 처음 알았습니다. 답변 감사합니다!
배때기
IP 121.♡.62.136
08-12
2022-08-12 11:04:20
·
저도 많이 배워갑니다 ^^
공부는재밌어
IP 219.♡.240.21
08-12
2022-08-12 11:14:11
·
@배때기님 미지의 세계가 정말 많네요 ^^
메티리얼
IP 175.♡.16.30
08-12
2022-08-12 11:14:06
·
가장 일반적인 java, db 기반의 모놀로식 서비스인 경우
서비스 트래픽 증가 -> DB 속도 느려짐 -> 서버 내 대기열 많아지고 메모리 사용율 올라감 -> 메모리 부족에 따른 JVM의 GC 발생 빈도 높아짐 -> GC를 위해 CPU 열일함 -> 대략 CPU 사용률이 80~90% 근처가되면 서버의 응답이 급격히 떨어짐 -> CPU 사용률이 95%가 넘어가면 행이 걸리는 것과 같은 현상 발생
따라서 cpu 사용률을 70%이하로 유지하기 위해 입구컷(트래픽 컨트롤)하는 기능이나 솔루션 도입하는게 일반적인 해결책입니다. 성능을 향상시키고자 하는 경우 캐싱이나 DB 분산정도을 우선 고민하고 장기적으론 클라우드를 도입합니다.
공부는재밌어
IP 219.♡.240.21
08-12
2022-08-12 11:17:15
·
@메티리얼님 덕분에 garbage collection나 적어주신 다른 거 공부하게됐습니다. 답변 감사합니다!
LinkeneitoR
IP 122.♡.198.147
08-12
2022-08-12 11:48:04
·
대기열 만들고 운영하는것도 비용이라서 평상시에는 운용을 안합니다
새로운 댓글이 없습니다.
이미지 최대 업로드 용량 15 MB / 업로드 가능 확장자 jpg,gif,png,jpeg,webp 지나치게 큰 이미지의 크기는 조정될 수 있습니다.
장비가 오래되거나 냉각이 잘 안될때
한계치 이하의 부하에서 이상동작을 하면서 뻗는거죠
로그분석해봐도 딱 보이는 문제가 없을때는 딱히 이거다 하는 문제는 없는게 대부분이더라구요
그리고 부하 분산 설계를 잘 해놔도 한순간 몰리면 가끔 바보 되는 경우도 많습니다
클러스터링 구성을 하면 바보 되는거 바로 감지하고 자동 리셋을 하는데 그런게 안되어 있으면 뻗는거죠
2차선에 차가 지나갈수 있는 대수는 초당 4대인데. 갑자기 초당 10대가 몰리면 속도가 느려지고 결국엔 줄이 길어지죠...
그리고 줄이 길어지면... 점점 길어져서 뒤에 스는 차들은 오랜 시간 대기가 되죠..
근데 이 줄에도 한계가 있어서... 대기조차 할수없는 차들이 생깁니다.... 터진거죠.
뭐 이제 클라우드가 되면 클러스터링 구축하고 수평확장하면되지 않냐....
이렇게 할수도 있는데... 일단은 sw도 수평확장을 처리할수 있게 코딩이 되어있어야하고 보통은 부하를 감지해서 자동으로 수평확장하는 웜업하는 시간이 필요합니다.(최소 몇초에서 몇분)
근데 수요예측이 실패하고 서버내에 부하를 유발하는 쿼리, 코드등이 있거나 수평확장하는 속도보다 더 많은 요청이 오면 또 터진는거죠... 물론 수평확장도 리밋이 있습니다.
서버에서 구현되는게아니라. 별도 업체의 서비스를 거쳤다가 접속하는겁니다. 상시 사용하는게 아니기때문에 비용도 비싸고 이걸 제공하는업체의 구현방식이 다르고 외부솔루션이기때문에 개발단계때부터 어떤솔루션을 쓸지 고려해서 설계해야합니다
이런거 고려없이 솔루션을 사서쓰더라도 누더기로만들면 코로나초반에 ebs 원격수업하려했더니 다 죽어서 수업못듣는경우가 생기는겁니다. 평상시 100명 동접할까말까한 스펙인데 20만이 동접하면 그서버가 접속순번 큐 발행이나 가능할까요?
큐발행도 결국 세션 하나잡고있는거에요. 그래서 서버가 직접하는게아닙니다. 앞에서 번호표나눠줄 놈이 따로있어야하는거죠
서비스 트래픽 증가 -> DB 속도 느려짐 -> 서버 내 대기열 많아지고 메모리 사용율 올라감 -> 메모리 부족에 따른 JVM의 GC 발생 빈도 높아짐 -> GC를 위해 CPU 열일함 -> 대략 CPU 사용률이 80~90% 근처가되면 서버의 응답이 급격히 떨어짐 -> CPU 사용률이 95%가 넘어가면 행이 걸리는 것과 같은 현상 발생
따라서 cpu 사용률을 70%이하로 유지하기 위해 입구컷(트래픽 컨트롤)하는 기능이나 솔루션 도입하는게 일반적인 해결책입니다.
성능을 향상시키고자 하는 경우 캐싱이나 DB 분산정도을 우선 고민하고 장기적으론 클라우드를 도입합니다.