분산서버 처리 기술

로드 밸런싱
흔히 L4장비라고 불리우는 로드 밸런싱은 분산서버 처리를 위한 뼈대를 이루는 장치라고 할 수 있겠다. 로드 밸런싱 장비에 IP가 부여가 되며, 이 로드밸런서에 연결되어 있는 N개의 장치 중 한곳으로 라우팅 시킨다. 이 때 서버가 사용할 수 없는 상태인 서버를 회피하여 연결하게 되는데 이로 인해 이용할 수 없는 서버로 라우팅 되는 것을 방지해준다.
AWS를 사용한다면 Elastic Load Balancer를 사용할 것이며 대부분의(모든) 클라우드 서비스 제공 업체가 로드밸런서를 지원하기 때문에 이를 기반으로 N개의 서버를 연결시키게 할 수 있다.

Auto Scaling
대부분의 클라우드 서비스 제공 업체들이 오토스케일링을 지원하며, 작동방식은 비슷하다.
서버의 부하(CPU Load, RAM 여유) 등을 체크하여 서버를 생성하는 방식이다. 이 때 미리 만들어놓은 가상 이미지로 서버를 생성하게 된다. 최근에는 Docker 와 함께 Auto Scaling 서버 구성을 많이 하는 편이다.

Stateless 설계
Stateless 를 간단히 설명하자면 상태가 없다는 의미이다.
다음의 내용을 고려하여 자신의 서비스에 맞는 적용 방법을 만들어보자.

1. 세션을 로컬 파일구조로 사용하지 않는다. 대안방법은 Redis나 MongoDB를 이용하여 세션을 쓰는 방법이 있다.
2. 파일 저장시 로컬에 사용하지 않는다. AWS의 S3를 사용하거나, MongoDB의 GridFS 등이 대안이다.
3.  Apache 는 피하고 보다 Scalable하게 구성할 수 있는 Nginx를 이용한다.
4. 내부 서버에서만 동작하는 서비스(예를 들면 socket.io) 의 stateless 여부를 확인하자(내부적으로 로컬에서 쓰는 부분을 DB를 사용하게 하면 해결된다.) socket.io의  경우 socket.io-redis 나 socket.io-mongodb 패키지를 이용하면 해결된다.
5. 데이터베이스는 분리하여 구성하자.

데이터베이스의 샤딩
웹/앱서버를 분산시켰다고 해서 끝은 아니다. 데이터베이스 또한 확장이 가능한 구조가 필요하다.
대부분의 데이터베이스가 샤딩(Sharding)을 통한 Scale-out 을 지원한다. Mysql 등의 대부분의 상용 및 오픈소스 데이터베이스에서 지원한다.
샤딩을 사용해야 하는 이유는 DB 저장 공간을 scale-out 하게 쓰기위함이다. 더불어, 쓰기 성능 또한 향상된다.
레플리카(Replica)도 거의 필수로 구축을 해야 하는데, 이는 가용성, 무결성, 두가지를 모두 만족시킨다. 즉, 안정적 운영과 함께 잘 안깨지게 구성이 가능하다. 읽기 성능이 좋아지는 것은 레플리카 구축되었을 시의 전리품이다.
처음 서비스 시작할 때는 단일 Master-Slave 구조 또는 레플리카셋(Replica-set) 로 구성한 후에 샤딩이 가능한 구조로 시작하는 편이 비용면에서 이득이다. (DB는 웹서버 보다 오래 버티기에 처음에는 적은 수로 구성해도 문제없다.)

출처  : https://www.devkwon.com/posts/category/%EB%B6%84%EC%82%B0%EC%84%9C%EB%B2%84%EC%B2%98%EB%A6%AC