•
Client는 Server로 요청을 보내고, Server는 요청에 대해 필요한 작업을 처리한다.
◦
Client: 브라우저, 모바일 앱, 데스크탑 프로그램 등
•
서비스가 활성화되면서 Client의 요청이 많아졌다고 가정해본다. 서버의 리소스 부족으로 인해, 단일 서버, 단일 애플리케이션에서 더 이상 감당할 수 없게 된다.
•
단순히 Scale-up을 고려해볼 수 있지만 이는 한계가 있다. SpringBoot 애플리케이션을 여러 서버에서 동시에 실행하여 분산 처리할 수 있다(Scale-Out)
◦
Scale-Up: 단일 서버의 성능을 향상시키는 것(수직 확장)
◦
Scale-Out: 서버를 추가하여 성능을 향상시키는 것(수평 확장)
•
Client는 이제 3개의 SpringBoot 애플리케이션으로 요청을 분산하여 처리할 수 있으나 서버가 증설될 때마다 Client가 이러한 정보를 모두 알 수도 없고, 알아야 할 필요도 없다.
•
트래픽을 라우팅 및 분산하기 위한 도구로 Load Balancer를 활용할 수 있다. Client는 Load Balancer로 요청을 보내면, Load Balancer는 요청을 적절히 분산하여 서버로 전달한다.
•
Scale-Out은 Load Balancer, Database에 대해서도 처리될 수 있다.
•
Client가 요청을 처리하는 과정이 복잡해질수록 응답은 느려질 수 있다. 더 빠른 성능을 위해 캐시(Cache)라는 기술을 사용할 수 있다.
◦
Cache - 더 느린 저장소에서 더 빠른 저장소에 데이터를 저장해두고 접근하는 기술
•
캐시는 각 구간마다 적절히 적용될 수 있다. 브라우저에서 자체적인 캐시를 활용할 수도 있고, DNS 쿼리 결과를 캐시해둘 수도 있고, 데이터베이스보다 더 빠르게 데이터에 접근하기 위해 캐시를 활용할 수도 있고, CDN 기술에 활용될 수도 있다.
•
캐시도 필요하다면 Scale-Out을 적용하여 단일 서버의 부하를 줄일 수 있다.
•
네트워크는 안전하지 않기에 언제든 순단 가능성이 있고, 서버와 데이터는 시스템 오류 또는 자연 재해 등으로 언제든 중단 및 유실될 수 있다. 또한 지리적으로 서버와 멀리 떨어져 있다면, 응답 시간에 큰 지연이 생길 수도 있다.
•
이러한 문제를 방지하기 위해, 서버를 지리적으로 여러 장소에 구성할 수도 있다. 서버가 설치된 데이터센터를 다중화하는 것이다. 분산된 각 서버에 대한 Client의 라우팅을 위해 DNS를 활용할 수도 있고, 더욱 정밀하고 복잡한 라우팅이 필요한 경우 GSLB 등 다양한 방법을 활용할 수도 있다.
•
단일 애플리케이션은 커질수록 관리가 어려워질 수 있다. 단일 서버가 처리해야 할 트래픽이 너무 많아지면, 리소스가 부족할 수도 있고, 시스템이 커질수록 애플리케이션의 유지보수가 어려워질 수도 있기 때문이다. 따라서 단일 애플리케이션을 기능에 맞는 여러 개의 애플리케이션으로 분리하여 관리할 수 있다. 각 애플리케이션은 담당한 기능에 대해 개별 작업만 처리할 수 있는 것이다.
•
예를 들어 A 애플리케이션은 게시글 기능만, B 애플리케이션은 댓글 기능만 처리한다. 필요하다면, 데이터베이스도 각 기능별로 분리하여 구성할 수 있다.
•
분리된 웹 애플리케이션이 하나의 서비스를 이루려면, 서로 네트워크 통신이 필요할 수 있다. API를 통해 직접적으로 통신할 수도 있지만, 메시지(이벤트)를 통해 간접적으로 통신할 수도 있다.