[면접 준비 - Network]대량의 트래픽에 대한 대처방법

목차

 

Scale-Up

 

가장 먼저 생각할 수 있는, 단순하면서도 확실한 방법이다.

 

사용하고 있는 서버 자체의 Cpu, Ram 등을 업그레이드해서 처리 용량과 속도를 올리게 된다.

 

단점 역시 단순한데, 좋은 부품은 비싸며, 출시된 제품의 성능 한계가 명확하다는 점이다.

 

비용 대비 성능 증가폭이 상대적으로 작다.

 

Scale-Out

 

다음으로 생각할 수 있는 방법은 수평 확장이다.

 

서버 하나의 처리속도와 용량을 올리는 것이 아닌, 서버의 대수를 증가시켜 처리 용량을 늘린다.

 

수직 확장에 비해 비용이 비교적 적게 든다. 단순히 대수를 늘리기 때문에 업그레이드에 한계가 없는 듯 보인다.

 

Amdahl's law

 

그러나 이는 정확하게는 처리 용량에만 해당되는 말이고, 처리 속도의 경우는 암달의 법칙에 의해 한계가 뚜렷하다.

 

여기서 암달의 법칙이란 쉽게 말해 병렬 컴퓨팅시 병렬화 불가능한 작업으로 인해 속도 증가에 한계가 존재한다는 법칙이다.

 

Data Consistency

 

또한 분산된 서버가 요청을 나눠 처리하면서 여러가지 데이터의 불일치 문제가 발생할 수 있는데,

 

이를 해결하기 위한 방법에는 크게 아래와 같은 두 가지 방식이 있다.

 

Session Clustering

 

클러스터링은 쉽게 말해 여러 대의 컴퓨터를 하나의 시스템으로 묶는 작업이다.

 

데이터 정합성 관점에서 봤을 땐 마치 하나의 데이터베이스를 쓰는 것과 같은 효과를 노린다고 할 수 있다.

 

여기에도 크게 두 가지 방식이 있는데, 대략 아래와 같다.

 

• All-To-All - 모든 서버가 모든 세션 데이터를 복제해 보유. 뛰어난 안정성을 자랑하지만 중복 데이터에 의한 메모리 낭비와 서버 수에 비례한 입력, 업데이트 시 트래픽 증가 문제가 있다. 4대 이하의 다중 서버에는 효율이 좋다고 한다.
• Primary-Secondary Session Replication - Primay, Secondary 두 대의 서버만 복제 데이터를 가지고 나머지 서버는 세션 아이디만 저장하는 방식. 안정성이 떨어지는 대신 메모리와 트래픽도 덜 잡아먹는, 위와 정 반대의 장단점을 가진다.

 

Session Storage

 

다음으로는 세션 저장소를 따로 두는 방식이다. 서버마다 세션 저장소를 두지 않고 하나로 통합해

 

모든 서버가 그 곳을 바라보고 동기화하도록 하는 방식으로,

 

속도가 중요하기 때문에 주로 Redis와 같은 인메모리 데이터베이스를 많이 사용한다.

 

다만 인메모리 데이터베이스의 경우 휘발성이기 때문에 따로 디스크에 로그를 기록해 안전장치를 마련한다.

 

MSA

 

이어서 생각해볼 수 있는 것은 MSA이다. MSA에 대한 명확한 정의는 없지만

 

대략 하나의 서비스를 하나의 서버에서 처리하도록, 독립적으로 구성하는 것이라 볼 수 있다.

 

서비스에서 트래픽이 많이 발생하는 부분이 특정되어 있다면 전체 서버의 용량을 키울 것이 아니라

 

MSA 방식으로 서비스를 독립시켜 해당 부분의 서버만 포인트로 증설하는 방법이 있을 수 있다.

 

Reduce Http Request

 

Refactoring

 

사용자가 서버로 보내는 요청의 횟수 자체를 감소시킨다.

 

이는 하나의 정보 혹은 페이지를 얻기 위해 발생하는 Http 요청을 적절히 합치는 것으로 구현할 수 있다.

 

영화에 대한 정보 페이지를 가져올 때 평가에 대한 정보가 따로 요청되고 있다면 둘을 합치는 식이다.

 

Bulk Insert with JDBC

 

관계형 데이터베이스를 사용하고, 새로운 입력이 많이 발생하는 서비스의 경우는 Spring Data JDBC를 이용해

 

DB로의 입력 쿼리를 적당히 모아 한 번에 보내는 방법도 생각할 수 있다. 

 

이는 단순히 쿼리의 횟수를 줄이는 것뿐 아니라 속도를 증가시키는 효과도 있는데,

 

대량의 데이터를 저장할수록 그 속도 차는 커지게 된다.