대규모 서비스와 부하 분산

서버에 문제가 있는경우의 대부분은 대규모 트래픽이 발생함에 따른 부하의 집중 때문일 것 입니다.

 

서비스 제공자는 집중되는 부하를 어떻게 분산 시켜서 안정적으로 서비스를 제공할 것인가를 계속해서 고민할 수 밖에 없습니다.

 

그렇기에 많은 백엔드개발자들이 많은 트래픽을 처리하는 서비스 회사를 선호하고 대규모 트래픽 처리에대한 경험 쌓기를 희망하고 있습니다.

 

 

 

부하의종류

웹 백엔드 기준 부하는 두곳에서 집중적으로 발생합니다.

웹 서버(WAS)의 연산 부하, CPU부하라고 합니다. 그리고 DB에서의 I/O 부하입니다.

 

CPU부하는 WAS의 CPU사용량이 허용범위를 초과하여 응답속도가 지연되거나 서버가 다운되는 현상입니다. I/O 부하는 하드웨어상 가장 많은 지연이 발생되는 디스크 I/O시에 부하를 뜻하며 데이터베이스에서 허용범위를 초과한 많은 양의 질의를 수행할때 발생합니다.

 

부하 해결 전략 

그렇다면 부하를 해결하려면 어떻게 해야할까요?

 

부하는 하드웨어상 한계에 의해 발생하기 때문에 하드웨어의 성능을 올려주는 것으로 해결할 수 있습니다. 더 좋은 cpu를 사용하고 더 빠른 디스크를 사용하는 것입니다. 이것을 스케일 업 이라고 합니다.

 

다만 조금만 생각해보면 일정수준 이상의 cpu의 가격과 기술의 한계로 인한 I/O속도 한계로 인해 스케일업 방법은 비용부담이 크고 한계가 존재할 수 밖에 없습니다.

 

그래서 성능을 올리는대신 낮은 성능의 컴퓨터를 여러대 사용하여 연산을 나누는 스케일 아웃 방식이 효과적인 방법으로 알려져 있습니다.

 

CPU부하의 경우에는 스케일 아웃으로 부하해결이 쉽습니다. 웹서버를 나누고 로드밸런서를 통해 부하를 분산하는 것입니다. 이때 발생할 수 있는 문제로는 세션공유 문제가 있을 수 있습니다.

 

A서버에 로그인하고 세션이 생성된 상태에서 로드밸런서에 의해 다음 요청이 B서버로 전달된다면 B서버에서는 다시 로그인을 진행해야 할것 입니다.

 

이 문제를 해결하기 위해 JWT를 이용한 세션없는 서버가 주목 받고 있으며 경우에따라 꼭 세션을 유지해야 한다면 서버들 사이에 세션을 관리하는 서버를 두어 세션을 공유 할 수 있습니다. 

 

똑같이 세팅된 서버를 여러대 두고 로드밸런서를 통해 요청을 분산하기면 되는 CPU부하의 분산 전략과는 다르게 I/O 부하는 쉽게 분산하기 어려운 특징을 가지고 있습니다.

 

DB서버를 여러대로 분산하게 된다면 DB자체를 나눌것인지, 도대체 어떤 기준으로 나눌 수 있을지? 읽기 전용의 캐시 서버들을 두겠다면 데이터 동기화는 어떻게 해결할 것인가 등 생각해야할 문제가 한두가지가 아닙니다.

 

앞으로 공부하며 I/O 분산에 대한 전략들을 계속 포스팅하겠습니다.

 

 

부하를 분석하는 방법

현재 내 서버에 문제가 발생했다면 cpu 혹은 i/o 어느 부분에서 부하가 발생했는지 분석할 방법이 필요합니다. 여러 모니터링 툴과 분석 도구를 활용할 수 있지만 이번엔 간단하게 리눅스환경에서 부하지점을 분석할 수 있는 방법을 알아보겠습니다.

 

우선 가장먼저 i/o 에서 문제가 발생하는지 cpu에서 문제가 있는 것인지 판단해야 합니다.

아래 포스팅 을 참고하여 sar 명령어를 통해 병목지점을 크게 cpu 혹은 i/o로 나누어 살펴볼 수 있습니다.

https://blog.cafe24.com/2005

[리눅스] sar 명령어를 이용한 시스템 모니터링

 

상세한 부하 분석 방법 역시 차 후 포스팅으로 다뤄보겠습니다.