Client는 Server로 요청을 보내고 Server는 요청에 대해 필요한 작업을 처리한다.
Server -> Spring Boot
Spring Boot는 Client의 요청을 처리하면서 어딘가에 상태를 관리해야 할 수 있다. 데이터는 데이터베이스에 의해 안전하게 괸리 될 수 있다.
서비스가 활성되면서 Client의 요청이 많아졌다고 가정했을 때, 서버의 리소스 부족으로 인해, 단일 서버, 단일 애플리케이션에서 감당할 수 없는 지경이 된다.
단순히 Scale-Up을 고려할 수 있지만 한계는 존재한다. 애플리케이션을 여러 서버에서 동시에 실행하여 처리를 분산할 수 있다. Scale-Out
Scale-Up : 단일 서버의 성능을 향상시키는 것 (수직확장)
Scale-Out : 서버를 추가하여 성능을 향상시키는 것(수평 확장)
Client는 애플리케이션으로 요청을 분산하여 처리할 수 있다. 하지만 서버가 증설될 때 마다 Client가 이러한 정보를 모두 알 수 없고, 알아야 할 필요도 없다.
트래픽을 라우팅 및 분산하기 위한 도구로 Load Balancer를 활용할 수 있다.
Client는 Load Balancer로 요청을 보내면, Load Balancer는 요청을 적절히 분산하여 서버로 전달한다.
Scale-Out은 Load Balancer, Database에 대해서도 처리될 수 있지만, Client가 요청을 처리하는 과정이 복잡해 질 수록 응답은 느려질 수 있다.
그래서빠른 성능을 위해 캐시(Cache)를 사용한다.
캐시는 각 구간마다 적절히 적용 해 브라우저에서 자제적인 캐시를 활용, DNS 쿼리 결과를 캐시, 데이터베이스보다 빠르게 데이터에 접근, CDN 기술에 활용, 캐시라는 개념을 다양한 구간에 적용될 수 있다.
Cache도 필요하면 Scale-Out을 적용하여 단일 서버의 부하를 줄여줄 수 있다.
안전성에 대한 문제도 있다. 네트워크는 안전하지 않기 때문에 언제든 순단 가능성이 있고, 서버와 데이터는 시스템 오류 또는 자연 재해 등으로 언제든 중단 및 유실될 수 있다. 또, 지리적으로 서버와 멀리 떨어져 있다면, 응답 시간에 큰 지연이 생길 수 있다.
문제를 방지하기 위해, 서버를 지리적으로 여러 장소에 구설 할 수도 있다. 서버가 설치된 데이터센터를 다중화하는 것이다. 분산된 각 서버에 대한 Client의 라우팅을 위해 DNS를 활용할 수도 있고, 더욱 정밀하고 복잡한 라우팅이 필요한 경우 GSLB 등 다양한 방법을 활용할 수도 있다.
단일 애플리케이션은 커질수록 관리가 어려워질 수있다. 서버가 처리해야할 트래픽이 너무 많아지면, 리소스가 부족할 수도 있고, 시스템이 커질수록 애플리케이션의 유지보수가 어려워질 수도 있기 때문이다.
단일 애플리케이션을 기능에 맞는 여러 개의 애플리케이션으로 분리하여 관리할 수 있다. 각 애플리케이션은 담당한 기능에 대해 개별 작업만 처리할 수있는 것이다.
예를 들어 A 애플리케이션은 게시글 기능만, B 애플리케이션은 댓글 기능만 처리한다. 필요하면, 데이터베이스도 각 기능 별로 분리하여 구성할 수 있다.
분리된 웹 애플리케이션이 하나의 서비스를 이루려면 서로 네트워크 통신이 필요할 수 있다. API를 통해 직접적으로 통신할 수도 있지만, 메시지(이벤트) 를 통해 간접적으로 통신할 수도 있다.
이처럼 시스템은 성능, 안전성, 확장성이라는 세 가지 축을 균형있게 고려해야 한다.
단순히 서버를 늘리거나 기능을 분리하는 것만으로 충분하지 ㅇ낳다. 서비스의 특성과 트래픽 패턴에 따라 적절한 캐시 전략, 데이터 분산 방식, 통신 구조(API 또는 메시징 기반)를 설계해야 한다.
또한 각 구성 요소 간의 장애 격리와 복구 절자, 모니터링 체계를 갖추는 것이 중요하다.
마지막으로 이러한 요소들이 조화롭게 결합된 시스템 아키텍처를 살펴보면, 서비스가 어떤 원리로 대규모 트래픽을 안정적으로 처리하고 빠르게 확장할 수 있는지 한눈에 이해할 수 있다.
