이 포스팅에 기재될 내용은 현업에서는 이미 대부분 검토되고 적용되었을 가능성이 매우 높습니다.
그러므로 단순한 팀 프로젝트 단위에서 생각해볼 수 있는 내용을 담을 예정입니다.
상황
예를 들어 네고왕 콜라보처럼, 마케팅 차원에서 50% 할인을 예고했다면?
심지어 단 하루, 그 중에서도 1시간만 진행이 될 예정이라면?
당연히 트래픽은 몰릴 것이고, 사이트는 뻗을 것이다.
비록 장애 대비를 하고 대처를 하더라도, 완전히 해결하기는 힘들겠지만 그 빈도를 줄일 방법은 있다.
백엔드
캐싱 DB 도입: 자주 사용되는 데이터나 계산 결과를 캐싱하는 데 초점을 맞춘다. 이를 위해 Redis와 같은 인메모리 캐시를 도입하고, 중요한 데이터나 쿼리 결과를 캐싱하여 응답 속도를 향상시킨다.
쿼리 최적화: DB Optimizer의 비용 산정 방식을 이해하고, 로직의 가용성을 높여 부하를 줄인다. 연산자, 인덱스, 클러스터링 및 파티셔닝 등에 따라 비용이 달라짐을 기억하자.
비동기 처리: 기본적으로 Spring은 동기 방식이다. 간단하게는 @Async 어노테이션을 붙임으로서 사용할 수 있지만, 사용 상의 주의사항을 기억하고 사용하자. 예를 들어 private method에는 사용 불가하다는 것과 connection pool의 증가에 따른 초과가 발생할 경우 handling이 필요하다는 것 등이 있겠다.
인프라
1. 온프레미스 환경
다중화: 서버를 다중화하여 가용성을 향상시킨다. 여러 대의 서버를 구성하고, 로드 밸런서를 사용하여 트래픽을 분산시키는 방식을 적용하는 방식.
로드 밸런서 클러스터: 서버가 트래픽이 몰려 과부화 될 수 있듯이, 효율적인 트래픽 분배를 담당해주는 로드 밸런서 또한 과부하가 일어날 수 있다. 이러한 로드 밸런서에 로드 밸런서 클러스터를 구성하여 부하를 분산시킬 수 있다. 여러 개의 로드 밸런서를 그룹으로 묶어 관리하고, 트래픽을 균등하게 분배하여 서버에 가중치를 부여하는 방식.
캐싱: 데이터나 계산 결과를 캐시하여 반복적인 요청에 대한 응답 속도를 향상시킬 수 있다. 인메모리 캐시 서비스인 Redis등을 도입하여 캐싱을 구현할 수 있다.
2. 클라우드 환경
오토 스케일링: EKS, GKE 등의 클라우드 제공 업체의 오토 스케일링 기능을 활용하여 자동으로 서버 인스턴스를 추가하거나 제거하여 트래픽에 대응할 수 있다. 필요한 리소스를 동적으로 조정할 수 있는 것이 장점.
로드 밸런서 서비스: 온프레미스 환경과 달리 직접 로드 밸런서 클러스터를 만들어가며 조율할 필요가 없다. 클라우드 제공 업체가 제공하는 로드 밸런서 서비스를 활용하여 트래픽을 분산시킬 수 있기 때문.
CDN (Content Delivery Network): 트래픽 과부하가 예상되는 지역에서 가까운 물리적 서버에 캐싱을 하는 방법. 캐싱된 서버는 오리진 서버까지 정보를 요청할 일이 없어진다.
