서버 안정화를 위한 조사

이번 포스팅은 이전의 강화학습 모델을 서빙하는 프로젝트에서 서버 이용 가능한 접속자 수를 확인하고 이를 안정화하기 위해 조사했던 것, 알게된 점들을 기록해 보려고 합니다.

 

서버 확장 방법

우선 서버 확장을 위한 방법을 알아보겠습니다.

 

Scale up(수직 확장)

서버에 cpu나 Ram 등을 추가하거나 고성능의 부품으로 서버를 업그레이드 하는 방법

 

→ 컴퓨터 한 대의 처리 능력을 높여준다.

 

장점

• 단순한 서버의 교체이므로 구현이 쉽다.
• 서버를 추가하는 방법이 아니기 때문에, 여러 대의 서버 보다 데이터 정합성 이슈에 자유롭다.

단점

• 서버 한 대에 부하가 집중되므로 장애 발생 시 영향을 받을 가능성이 커진다.
• 서버 운용 비용이 늘어난다.
• 스케일 업의 일정 수준을 넘어가는 순간, 성능 증가 폭이 미미해진다

 

Scale out(수평 확장)

서버를 여러대 추가해서 시스템을 확장하는 방법

 

→ 동일 처리 능력을 보여주는 컴퓨터의 개수를 늘려 부하를 분산한다. (load balancing이 동반돼야 함)

 

장점

• 용량, 성능 확장에 한계가 없다. 하드웨어를 변경하는 것이 아닌 비슷한 성능의 서버를 여러 대 두는 방법이기 때문에, 확장이 무제한 가능하다.
• 하나의 서버가 모든 트래픽을 관리하는 스케일 업과는 반대로, 여러 대의 서버를 두어 분산 처리를 하기 때문에, 장애 가능성이 감소한다.
• 스케일 업에 비해 비용이 저렴하다.

단점

• 모든 서버에서 데이터 일관성을 유지해야하기 때문에 설계 및 관리가 복잡하다.
• 코어가 늘어남에 따라 마냥 성능이 증가하지는 않고, 코어 증가에 따라 대역폭이 증가해 지연이 발행할 가능성이 있다.

 

Request bot을 이용한 test

기존의 serving server에 dummy data를 이용해 request를 보내는 bot을 통해 서버의 안정 수준을 확인해보았습니다.

 

test 할 서버

• 기존의 frontend, backend, db, serving server를 도커 컨테이너로 운용되고 있던 프로젝트
• 이전 프로젝트에서 serving server container를 3대로 늘린 뒤, nginx에서 load balancing을 통해 serving server에 대한 요청을 분산 시키도록 함

위의 두 서버의 각 컨테이너(frontend, backend, db, serving server)는 한 aws 인스턴스 내에 존재합니다. 

 

test 결과

반복	serving server 1개	serving server 3개
request 3 with 3 iteration	약 10초	약 7초
request 4 with 4 iteration	약 15초	약 9초
request 10 with 1 iteration	약 25초	약 16초
request 20이상	약 40초	실행 불가
request 30 with 1 iteration	실행 불가	실행 불가

(결과 값은 각 iteration의 평균값입니다.)

• request가 20개 이하일 경우, 각각의 명령에 대한 처리 속도는 3개의 serving server를 띄우고 load balancing을 통해 각 서빙 서버의 부하를 줄여준 경우가 더 빠르다.
• 하지만 request가 20개 이상으로 많아질 경우, 서빙 서버가 1개 일 때만 동작하게 된다.

 

내가 생각한 결론

기본 전제 사항

• 기본적으로 도커 컨테이너는 호스트 머신의 CPU 자원을 제한 없이 사용할 수 있다. 하지만, aws 인스턴스 내에서 컨테이너가 차지하고 사용할 수 있는 cpu 자원은 한정되어 있다.
• 도커 컨테이너로의 요청은 default로 설정된 docker bridge를 통해 이루어진다. <- 모든 컨테이너로의 요청은 bridge를 거쳐간다.

serving server가 1개일 경우

request를 20개 이상 받게 되면 serving server가 병목현상으로 처리 속도에 영향을 받는다. 하지만 컨테이너 브릿지의 병목현상으로 serving server는 동시에 처리할 request 수가 제한된다. 그래서 동시에 처리되는 request 수는 줄어들어 serving server 컨테이너의 cpu 사용량은 호스트가 견딜 수 있을 정도가 유지되게 된다. → 20개 이상의 request도 느리지만 처리 가능하다.

serving server가 3개일 경우

3~15개의 요청이 올 경우, serving server 3대가 요청에 대해 분산 처리를 하게 된다. 3~15개의 요청의 경우 serving server 3대가 동시에 처리 될 수 있는 정도의 cpu 자원이 있어 serving server가 1개일 경우보다 빠르게 처리된다. 하지만 15개 이상의 요청이 올 경우 동시에 처리해야 하는 cpu자원이 현재 aws 인스턴스 자원(4코어의 cpu, 16GiB 메모리)으로는 처리할 수 없어 컨테이너가 처리를 감당하지 못하고 reboot되게 된다.

 

 

그러므로, 서버를 어떤 방식으로든(scale out, scale up) 확장하지 않는 이상 20~30명 이상의 serving server의 자원 사용량을 견딜 수 없다는 결론을 내렸습니다!