Spike Traffic에 대한 고찰 및 처방

들어가며

안녕하세요. 노머스에서 백엔드 개발을 하고 있는 유영기입니다.

저는 이전에 저희가 DynamoDB를 도입하면서 느낀 통찰을 그림으로 표현한 적이 있습니다.

원본에 가까운 처리 전 데이터는 RDB에,
처리 후 소비하기 좋은 형태의 데이터는 NoSQL에
저장하는 것이 효과적이라는 내용이었습니다.

이번에도 NoSQL에 관한 내용인데, 트래픽 관점에서 바라본 실제 적용 사례와 그 효과에 대해 공유하고자 합니다.

RDS Proxy를 사용하고 있지만, 같은 트래픽에서 Lambda는 ECS보다 훨씬 많은 RDS connection을 사용합니다.
저희는 latency가 중요한 서비스에서는 ECS를 사용하지만, 많은 부분 Lambda로 구성되어 있어, 특히 spike 트래픽에서 더욱 불리한 처지였습니다.

이번에 저희는 서로 다른 데이터의 대규모 read spike 트래픽에 해당하는 사용자 데이터를 DynamoDB로 이관하였습니다.
Fromm Channel에는 Artist가 채팅과 함께 Live 방송을 할 수 있는 기능이 있는데,
이때 읽어와야 하는 사용자마다의 고유 정보를 NoSQL로 이관하여, 대용량 트래픽을 분산할 수 있었습니다.

write에는 사용자에게 약간의 지연을 가미해도 사용자 경험이 크게 훼손되지 않는데,
read는 느린 응답이 사용자 만족도에 더 큰 영향을 미칩니다.

이러한 실제 경험을 바탕으로, 대규모 트래픽 상황에서 데이터베이스 선택과 설계에 대한 접근 방식을 살펴보겠습니다.

1. 대규모 트래픽의 일반적인 대처 방안

대규모 트래픽을 read/write와 데이터 동일성 관점에서 구분하고,
제가 생각하는 일반적인 대처 방안을 떠올려 보았습니다.

	read	write
동일한 데이터	Cache	Ignore
서로 다른 데이터	Replication	Queuing

여기서 각 전략에 대해 간략히 설명하자면:

• Cache(캐시): 동일한 데이터를 반복적으로 읽는 경우, 데이터베이스 접근을 줄이기 위해 Redis나 Memcached 같은 인메모리 캐시를 활용합니다. 이는 많은 사용자가 동일한 상품 정보를 조회하는 경우에 효과적입니다.
• Ignore(무시): 동일한 데이터에 대한 중복 쓰기 요청은 일부 무시하거나 병합할 수 있습니다.
• Replication(복제): 서로 다른 데이터를 읽는 경우, 데이터베이스를 여러 노드로 복제하여 부하를 분산시킵니다. 각 사용자가 자신의 고유한 정보를 조회하는 경우에 효과적입니다.
• Queuing(대기열): 서로 다른 데이터에 대한 쓰기 요청이 많을 경우, SQS나 Kafka 같은 메시지 큐를 사용하여 요청을 순차적으로 처리합니다. 이는 많은 사용자가 각자 다른 주문을 생성하는 경우에 유용합니다.

2. 주요 테이블 레코드 수 현황

테이블	row 개수
상품	XXXXX
사용자	XXXXXX
주문	XXXXXXX

상품 < 사용자 < 주문 : 순으로 레코드 수가 많습니다.

이는 비즈니스 도메인의 특성을 반영합니다.
상품 수는 상대적으로 제한적인 반면, 사용자 수는 더 많고, 주문은 시간이 지남에 따라 계속 누적됩니다.
이러한 데이터 특성은 각 테이블에 적합한 데이터베이스 선택과 트래픽 처리 전략에 영향을 미칩니다.

3. 대규모 트래픽에서 주요 테이블의 트래픽 패턴

테이블	read	write
상품	대용량 중복 읽기 (많은 사용자가 동일한 상품 정보 조회)	소규모 생성 트래픽
사용자	대용량 분산 읽기 (각 사용자가 자신의 정보만 조회)	소규모 갱신 트래픽
주문	소규모 조회 트래픽	대용량 분산 쓰기 (많은 사용자가 각자 다른 주문 생성)

각 테이블의 트래픽 패턴을 자세히 살펴보면:

• 상품 테이블: 인기 상품이나 세일 상품은 수많은 사용자가 동시에 조회하는 중복 읽기 패턴이 발생합니다.
• 사용자 테이블: 이런 패턴은 단일 데이터베이스에 부하를 줄 수 있으며, 특히 동시 접속자 수가 급증할 때 문제가 됩니다.
• 주문 테이블: 특별 이벤트 시 짧은 시간에 대량의 주문이 데이터베이스의 쓰기 용량과 동시성 제어 메커니즘에 큰 부담을 줍니다.

4. 서로 다른 데이터의 대규모 트래픽 대응 전략: NoSQL 적용

	read	write
서로 다른 데이터	replication or NoSQL	queuing or NoSQL

앞서 서로 다른 데이터에 대한 대규모 트래픽 처리를 일반적인 방안으로 replication과 queuing으로 정리했습니다.
하지만 이러한 패턴에서는 현재 저희가 사용 중인 DynamoDB 같은 NoSQL 데이터베이스 도입도 효과적인 대안이 될 수 있습니다.

NoSQL의 장점

DynamoDB와 같은 NoSQL 데이터베이스는 대규모 트래픽 처리에 다음과 같은 이점이 있습니다:

• 수평적 확장성 (서버 노드 추가로 용량 확장)
• 자동 샤딩 (데이터를 여러 파티션에 자동 분산)
• 높은 가용성 (여러 리전에 데이터 복제)
• 온디맨드 용량 (트래픽에 따른 자동 용량 조절)

마치며

replication를 사용하더라도, 예측 불가능한 대규모 트래픽에 대비하려면 많은 수의 replica가 필요합니다.
그리고 저희가 즐겨 사용하는 Lambda는 DynamoDB와 비용 관점에서 매우 유리한 조합입니다.

다른 데이터와 Join 되지 않을 수 있고(Key Value 형태로 저장할 수 있고, 사용자끼리 공유하지 않는 데이터),
짧은 시간에 read 혹은 write되는 데이터라면 NoSQL을 고려해 볼 만합니다.

감사합니다.