Application Architecture

개발자의 입장에서 봤을 때, 서버에서 요청을 처리하려면 개발자가 먼저 코드를 빌드, 배포해야한다.

물론 서버 컴퓨터에도 디스크가 있지만 한계가 있으므로, 데이터베이스처럼 storage를 분리해서 네트워크로 연결시키는 경우가 많고, 이를 distributed storage라고 한다.

사용자 입장에서 보면, 사용자 브라우저가 서버에 요청해서 프론트의 경우 JS 코드를 반환할 거고 백엔드의 경우 API요청을 해서 데이터를 JSON 등의 형태로 받을 것이다.

 

그런데 사용자가 많아진다면, 서버가 병목현상때문에 느려지거나, 메모리 용량에 한계가 있을 수도 있다. 그래서 하나의 해결책으로 해당 서버컴 하나의 CPU나 메모리를 좋게 할 수 있는데, 이를 vertical scaling이라고 한다.

 

하지만, 컴퓨터 한대에는 한계가 있고, 무수한 요청을 해결하기 힘들 것이다.

이를 해결하기 위해 horizontal scaling을 쓸 수 있는데, 각 서버를 좋게 하는 것이 아니라, 서버의 개수를 늘려서 모든 사용자가 한 서버에만 요청하지 않아도 되게 하는 것이다.

 

그렇다면 사용자들이 요청을 할 때 어느 서버로 요청해야 할 지는 어떻게 정할까?

이 역할을 하는 것이 로드 밸런서 (Load Balancer)이다.

로드 밸런서는 가장 트래픽이 적은 서버에 요청을 전달하여, 각 서버들이 균형있게 트래픽을 처리하도록 돕는다.

말그대로 트래픽 로드들을 밸런싱하는 것이다.

 

이외에도 서버와 상호작용하는 외부 서버들도 있다.

또 사용자들의 요청이 잘 처리됐는지 개발자가 확인할 수 있게 로그를 저장하는 곳이 있다.

서버의 각 응답이 잘 이뤄지고 있는지 CPU, 메모리 등 서비스나 자원에 대한 Metrics(변화하는 데이터의 상태)도 저장하는데, 이는 각 요청, 응답 결과처럼 로그로부터 받을 수도 있다 (로그에는 시각 정보가 들어가있다.). 이런 Metrics들은 주로 시계열 차트 (Time Series Charts)들로 시각화된다.

또 서버에 문제가 생겼는지 알기 위해 개발자가 매번 Metrics를 확인하거나, 사용자가 먼저 연락하게 되면 안되기 때문에, Metrics로부터 즉시 개발자에게 알리는 것도 필요하다. 그래서 Metrics에는 Alerts가 연결되어 있고, 트래픽 처리 성공률이 임계치 이하로 내려갈 경우 자동으로 알리게 한다.