[SNS] Ch04. 대규모 트래픽 시 문제점 분석 및 해결

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

 

지금까지 간단한 SNS 서비스를 개발했다. 이제 이 SNS 서비스에 이용자가 늘어나 트래픽이 증가하면 어떤 문제들이 발생할지 살펴보자.

 

기존 아키텍처 문제점

아래 그림에서 볼 수 있듯이, 기존 아키텍처는 Spring Boot 애플리케이션과 데이터베이스가 IO를 주고받으며 데이터를 처리하는 단순한 구조다. 트래픽이 늘어날 경우 이 구조에서 발생할 수 있는 문제들을 분석해 보자.

문제점 1. Token 인증 시 user 조회 중복

• 토큰 인증 시 한 번의 user 조회 후, 다시 user를 조회하는 구조다. 즉, 두 번의 DB IO가 발생하게 된다. 이 중복된 부분을 줄여서 한 번에 처리할 수 있을까 생각해 본다.

문제점 2. 매번 조회하는 User 정보

• 유저 정보는 일반적으로 변경될 일이 없는 데이터다. 즉, 한 번 생성되면 변경되지 않는 정보인데, 매번 DB에서 가져오는 비효율적인 동작이 반복된다.

문제점 3. Alarm을 생성해야 응답하는 API

• 현재 구조에서는 알람을 생성해야만 응답이 완료되는 형식으로 API가 작성되어 있다.

문제점 4. 새로고침을 해야 갱신되는 알람 목록

• 알람 목록은 페이지를 새로고침해야만 갱신된다. 실시간으로 알람을 확인하려면 주기적으로 API를 호출해야 하며, 이는 서버에 부하를 주게 된다.

문제점 5. Query 최적화 여부

• 현재 JPA를 사용하여 엔티티 기반으로 쿼리가 생성되고 실행된다. 이때 연관관계 설정이 제대로 되어 있어 인덱스가 잘 적용되고, 조인 쿼리가 올바르게 실행되는지 확인해야 한다. 마이바티스처럼 쿼리를 직접 작성하지 않기 때문에, 쿼리 최적화를 신경 쓰지 않으면 대규모 트래픽 상황에서 성능 저하를 겪을 수 있다.

요약

• 코드 비최적화
• 과도한 DB IO
• 기능 간 강한 결합성

해결 방법

이러한 문제점들을 해결하기 위해 아키텍처를 다음과 같이 개선할 수 있다.

1. 캐싱을 이용한 DB IO 감소: 변하지 않는 유저 정보는 매번 DB에서 가져올 필요가 없다. 따라서 Redis를 사용하여 캐싱하고, 이를 통해 DB IO를 줄인다.
2. 비동기 처리: API 응답을 지연시키는 알람 생성 문제를 해결하기 위해, Kafka를 도입하여 느슨한 결합성을 도모한다. Kafka를 이용해 프로듀서와 컨슈머로 역할을 나누고, 알람 처리를 비동기적으로 수행한다.

개선된 아키텍처

이 구조에서는 Kafka를 도입해 이벤트를 비동기적으로 처리하고, Redis를 사용해 캐싱을 통해 데이터베이스 접근을 최소화하는 방식으로 변경되었다. 이렇게 함으로써, 서버 부하를 줄이고 응답 시간을 개선할 수 있다. PostgreSQL은 여전히 주요 데이터 저장소로 사용되지만, 실시간 데이터나 빈번한 조회가 필요한 데이터는 Redis에 캐싱하여 더욱 효율적으로 처리할 수 있다.

 

비동기 처리 시나리오

아래 그림은 좋아요와 댓글 기능의 비동기 처리 시퀀스를 나타낸다. 클라이언트가 요청을 보내면, 서버는 Kafka를 이용해 비동기적으로 이벤트를 처리한다. 데이터베이스 업데이트 역시 Kafka를 통해 비동기적으로 이루어지며, 서버는 이벤트 처리가 완료된 후 결과를 클라이언트에게 응답한다.

이 과정에서 비동기 처리를 통해 서버는 요청을 즉시 처리하고, 이벤트 소비와 DB 업데이트는 백그라운드에서 처리되기 때문에 트래픽 증가에도 서버 부하를 줄일 수 있다.