Spring에서 대용량 트래픽 처리

간단하게 클라이언트가 있고, Web Application Server가 있고, DB가 있다고 가정하자.

이 어플리케이션은 단순히 게시글을 조회하는 기능을 해주는 어플리케이션이라고 가정하자.

이때 다수의 사용자가 게시글을 조회하게 되면 생기는 문제점은? 

• 정적파일(이미지, 비디오)이 문제가된다.

정적자원을 WAS(Web  Application Server)가 직접관리하게 되면, CPU자원이나 네트워크 트래픽 , 대역폭 같은 문제가 발생한다.

이를 위해서 파일들을 관리하는 서버를 따로 분리한다. 그리고 이에 따라 CDN서버를 따로 둔다.

 

CDN이란?

 

Content Delivery Network의 약자로, 정적파일들에 대한 캐시 서버 역할을 한다.

이를 통해 빠른 응답속도, 네트워크 대역폭, 컴퓨팅 리소스 부하를 줄일 수있다.

---

만약 훨씬 더 많은 사용자요청이 들어온다면?

위 사진처럼 단일 WAS가 처리할수 없다.

WAS를 수평확장 함으로써 해결할 수있다. 단순하게 말하면 WAS를 여러개 두는것이다.

 

이를 Scale Out 이라고 한다. 그러나 클라이언트단과 바로 맞닿아서 Scale out 하는것은 굉장히 어려운 일이다.

늘어난 서버의 주소, WAS가 문제가 생긴경우는 어떻게 처리할지 생각하면 벌써부터 머리가 아프다.

그렇다면 어떻게 해결하지?

 

바로 Load Balancer이다. 구조를 살펴보면 클라이언트와 1대1로 통신을하고 뒷단의 WAS들은 어느 서버로 분산될지 Load Balancer에 의해 결정된다. 그렇다면 Scale out으로 많아진 WAS에 맞춰 뒷단의 DB에 전달하는 쿼리문도 엄청나게 많아질것인데 어떡하지? DB는 늘리는게 WAS처럼 간단한 일이 아니다. 그럼 이것의 해결책은? Cache를 활용하는것이다.

말 그대로 자주쓰고, 잘 변하지 않는 데이터는 여기 넣어두고 사용하겠다는 것이다. 이것도 서버의 일종이다.

In-memory database에 있는 Redis가 이에 속한다! 

여기서 In-memory database란? 메모리에 데이터를 적재하는 것을 의미한다. 응답속도가 빠른 장점이있다.

---

WAS관점에서 Spring mvc는 다수의  OS Thread기반으로 웹 요청을 처리하는 구조이다.

이 말은, thread개수 만큼 메모리자원이 필요하다는 뜻인데, 대용량 트래픽 처리에 있어서 메모리를 빨리 소모할수밖에 없는 구조이다. 만약 스레드에서 DB나 다른 API서버에 외부요청을하면 Blocking(임시대기)이 된다. 이러한 스레드는 외부요청을 더이상 받을수없다.

그렇다면 적은 리소스로 대량의 I/O요청을 처리할수 있는 방법은 없을까?

 

 Spring Webflux

 

Reactor(Reactive Stream이라는 표준에 대한 구현체)라는 라이브러리를 활용해서 이를 해결할 수 있다. Non-Blocking Application을 만들수 있게 도와주는 라이브러리다. Network 비동기 I/O 작업을 처리한 후, Event Loop 기반을 활용해서 작업을 빠르게 처리할수있다. 또한 Event Loop 를위해 적절한 규모의 스레드도 사용하게되는데, CPU 코어개수가 너무 적지 않다면, CPU 코어개수만큼 스레드를 만들고 활용한다.

앞서 Spring mvc 에서 요청개수만큼 스레드개수가 필요한것과 대조가된다.

---

이번에 내가 해볼 실습은 접속자 대기열 시스템 구현이다. 야구경기를 본다던가, 콘서트를 간다던가, 수강신청을 할때 한순간에 엄청난 양의 트래픽이 생긴다. 나는 Redis와 Spring Webflux를 활용해서 그 문제를 어떻게 적은 리소스를 잘 활용해서 프로그램이 돌아가게 할것인지에 대해서 구현해보겠다.

2024.04.01 - [Spring/대용량 트래픽] - Redis를 알아보자!

Redis를 알아보자!