요즘 면접 질문에도 많이 나온는 주제인 대규모 트래픽에 관한 얘기입니다.
예를들어 하루 평균 접속자 수가 100명인 쇼핑몰에서 그 날 라이브쇼핑이 대박이 난겁니다.
동시접속자 수가 1만명이 되는 순간 서버가 다운되고 말았습니다.
이러면 회사입장에서 손해가 막심할 수 밖에 없습니다. 이러한 현상이 왜 일어나는지
그리고 방지하려면 어떻게 해야하는지 알아봅시다.
발생원인
기본적으로 한 사람이 서버에 접속하게되면 가장 기본적으로 이 사람에 대한
1. 아이디 및 비밀번호를 체크해 로그인을 해야 하고
2. 이 사람이 쇼핑을 할 수 있게 쇼핑몰이 가지고 있는 제품을 보여줘야하고
3. 찜하기, 장바구기 넣기 등의 데이터를 물고있어야하며
4. 결제 시 API요청 해 구매가 되고 구매가의 %의 포인트 및 쿠폰을 지급하며
5. 물건 수량체크 및 배송지에 관한 정보를 받아야 합니다.
이 모든 과정이 클라이언트 < - > 서버간의 통신에 의해 발생됩니다.
평소 접속자가 100명에 맞게 서버 용량 및 네트워크 통신방법을 설정했는데
평소보다 훨씬 많은 요청이 발생하니 처리시간보다 요청이 쌓이는 시간이 더 빨라 서버가 다운됩니다.
그렇다면 이러한 상황을 방지하거나 해결할 수 있는 방법에 대해 알아봅시다.
해결방법
1. 서버 증설과 로드밸런싱 설정
사실 이 방법이 가장 깔끔하고 좋은 방법이다.
다만 증설 비용 및 유지비용이 많이 발생되는 단점이 있다.
클라이언트와 서버 사이에 L7스위치를 두어 트래픽이 몰리면
하나의 서버에 몰리지 않게 적절히 분산을 해주는 것 입니다.
로드밸런싱에 관한 참고 글 : https://steady-snb.tistory.com/42
2. 애플리케이션 자체의 성능 최적화
서버를 늘릴 비용이 없다면 주어진 자원 내에서 최대한 효율적으로 활용하는 편이 좋겠죠?
이 애플리케이션 선능 최적화라는 것은 무수히 많은 방법이 있겠지만 대표적으로
* 중복요청 제거
사이트에 렉이 걸리거나 이상한 사용자가 같은 요청을 여러번 반복하게되면 서버에 부하가 심하게 걸립니다.
같은 요청에 대한 식별은 멱등키를 심는 방법을 통해 방지할 수 있습니다.
API에 멱등키 적용 참고 글 - https://steady-snb.tistory.com/41
* API의 통합 및 분리
API요청에 대한 중복제거는 매우 까다로울 뿐더러 API에 암복호화 기능이 있다면 서버에 부하가 큽니다.
예를들어, 결제를 하게되면 결제 -> 포인트지급 -> 배송지 저장 및 물량관리의 로직을 수행하게 되는데
각각 API가 따로 되어있으면 각 API요청 및 응답을 처리하는데 부하가 걸립니다. 사실 이 로직은 결제를
하는 동시에 순차적으로 이루어지는 과정이라 하나의 API로 통합하는게 효율적입니다. 또한 반대로
포인트 지급에 있어 각 유저별로 포인트 지급률이라던지 복잡한 로직이 들어있는 경우 따로 분리하여
처리하는 편이 좀 더 효울적입니다.
* 로직의 단순화
복잡하게 분기를 태우는 로직을 좀 더 모듈화하여 단순화 시키는 작업이 있습니다.
* DB 인덱스 추가 또는 쿼리 성능개선
조회 시 select * 이나 join, union 등 fullSearch를 하면서 복잡하게 테이블이 엮어있는경우를 제거하고또한 index를 추가하여 좀 더 쿼리수행이 빠르게 수정합니다.
3. 캐싱을 이용
브라우저캐시(쿠키나 로컬 및 세션 스토리지) 활용하여 DB부하 줄이기
브라우저 캐시 참고 글 - https://steady-snb.tistory.com/36
4. 메시지 큐 적용
비동기로 처리 가능한 백그라운드에서 돌아가는 작업이 많다면 메시지큐를 아키텍처에 넣는 것을 고려할 수 있습니다.
대표적으로 RabbitMQ,Kafka 등의 메시지큐가 있습니다.
서버 과부하 방지 방안
1. 모니터링을 통한 자원 할당
AWS 오토스케일링을 통해 서비스 이용 불가 상태 발생 이전에
cloud watch가 계속해서 모니터링을 하여 서버 대수를 늘려주는 방법 또는
netdata를 이용하여 알림설정 및 자원할당을 할 수 있습니다.
2. 로드밸런싱
클라이언트와 서버 사이에 트래픽을 분산시키는 스위치를 둡니다.
3. 블랙스완 프로토콜
어쩔 수 없이 예기치 못하게 서버가 다운될 위기에 놓였을 경우
빠르게 조치할 수 있는 비상체계를 미리 만들어두고 조치하여야 합니다.
예를들어 서버 과부하 시 용량이 많이드는 그래픽적 요소를 모두 제거하고 txt형식으로 바꾼다던지
결제 같이 중요한 API요청에 대한 응답을 잠시 막는 방법이 있겠습니다.
4. 서킷브레이커
서비스 장애를 감지하고, 연쇄적으로 발생하게 되는 에러를 방지하는 기법입니다.
서비스와 서비스 사이에 서킷 브레이커 계층을 두고 미리 설정해준 timeout임계값에 도달하면
서킷 브레이커가 그 이후 추가 호출에 대한 응답을 무조건 에러로 반환하게 되므로써
에러에 대한 다른 시스템에 영향이 가지 않게 막는 방법입니다.
참고: inflearn 강의 'CS 지식의 정석 - 큰돌'
'IT지식 > Computer Science' 카테고리의 다른 글
WIFI(무선랜) 주파수 2.4GHz와 5GHz차이 그리고 대역폭 (0) | 2025.01.21 |
---|---|
TCP/IP 레이어별 네트워크 장치(L1~L7스위치, 허브, 라우터 등)의 역할 (1) | 2025.01.19 |
HTTP메서드 멱등성의 정의와 API에서 멱등성 구현법 (1) | 2025.01.18 |
HTTP메서드 GET, POST의 정의 및 차이점에 대해 알아보자 (0) | 2025.01.18 |
HTTP 상태 코드(1XX~5XX)에 대해 알아보자. (0) | 2025.01.16 |