Scale Up과 Scale Out은 컴퓨팅 자원의 성능 향상이 필요한 경우 적용할 수 있는 대표적인 두 가지 방법입니다.
서버의 규모가 커지고, 사용자 트래픽이 증가하여 현재 보유한 자원으로는 처리하는 것이 불가능하거나 비효율적일 때
Scale Up이나 Scale Out을 통해 컴퓨팅 자원을 확장하여, 더 나은 서버 퍼포먼스를 기대할 수 있습니다.
Scale Up, 수직 확장
Scale-up is done by adding more resources to an existing system to reach a desired state of performance. For example, a database or web server needs additional resources to continue performance at a certain level to meet SLAs. More compute, memory, storage, or network can be added to that system to keep the performance at desired levels. When this is done in the cloud, applications often get moved onto more powerful instances and ...
Scale Out, 수평 확장
Scaling up makes sense when you have an application that needs to sit on a single machine. If you have an application that has a loosely coupled architecture, it becomes possible to easily scale out by replicating resources. Scaling out a microservices application can be as simple as spinning up a new container running a webserver app and adding it to the load balancer pool. When scaling out the idea is ....
위의 문서를 간단하게 요약하면, Scale up은 기존에 존재하던 컴퓨팅 성능을 향상하는 것을 말합니다.
CPU의 처리량을 향상한다거나, RAM 용량을 키우는 방식 등이있겠네요.
Scale up을 서버에 적용하면, 동일한 시간에 더 많은 일을 처리하는 고성능 서버 환경을 구성할 수 있습니다.
부하가 많이 들어오는 미디어 작업이나 배치 처리, 딥러닝 모델 학습 등의 고성능 컴퓨팅 자원을 요구하는 곳에 알맞은 방식이 되겠죠.
Scale up
Scale out은 동일한 성능의 컴퓨팅 자원을 복제하여 여러 대 설치하는 것을 의미합니다.
Scale out의 방식을 서버에 적용하면, 많은 사용자의 요청이 발생하더라도 네트워크 환경 및 서버 부하를 고려하여
Using the above configuration will enable all-to-all session replication using the DeltaManager to replicate session deltas. By all-to-all, we mean that every session gets replicated to all the other nodes in the cluster. This works great for smaller clusters, but we don't recommend it for larger clusters — more than 4 nodes or so.
문서에 의하면, 세션 클러스터링을 4개보다 더 많은 노드를 가지는 클러스터에 적용하는 것은 권장하지 않는다고 합니다.
이유가 직접적으로 나와있지는 않지만, 세션 클러스터링을 수행하는 방식으로부터 왜 5개 이상의 노드를 가지는 클러스터에서는 세션 클러스터링을 권장하지 않는지에 대해 추론해볼 수 있었습니다.
위의 문서 앞부분을 보면, 세션 클러스터링이 동작하는 방식은, "클러스터에 존재하는 모든 노드들에게 세션을 복제"하는 방식이라고 합니다.
서버가 자신이 가지고 있는 세션을 다른 서버에도 동일하게 갖도록 하기 위해 다른 모든 서버와 1:1 통신을 하면서 세션을 복제하는 것이죠.
서버의 수가 적으면 적은 통신 횟수로도 서버 간 세션 공유가 가능하고, 공유된 세션을 메모리 등 각자의 컴퓨팅 자원에
저장함으로써 세션에 접근하는 비용을 줄일 수도 있지만,
서버의 개수가 늘어날수록 통신의 횟수가 서버 수의 제곱에 비례하여 기하급수적으로 증가할 것이고, 이는 서버가 자체적으로 세션을 소유함으로 인해 얻는 이득보다 더 큰 비용으로 환산될 것임을 예측할 수 있습니다.
그래서, 세션 클러스터링 또한 대규모 트래픽이 발생하는 IT 서비스에 적용하기 적합하지 않은 구조라고 판단하였습니다.
이외에도 세션의 동기화에 걸리는 시간차로 인해 세션 불일치가 발생할 수 있는 점, 동일한 세션의 복제본을 많은 서버에서 공유하기 때문에 효율적인 메모리 관리가 되지 않는 점 등의 단점들이 많다는 점 또한 세션 클러스터링을 적용하기
어려웠던 이유로 작용했습니다.
In-memory Database
마지막으로 찾아본 방식은 별도의 데이터베이스에 세션을 저장하는 방식이었습니다.
물론, 디스크 기반의 데이터베이스를 사용하면 I/O 작업에서 병목이 있을 수 있기 때문에, 그보다 더 나은 성능을 보여주는 메모리 기반의 in-memory DB의 도입을 고려하였습니다.
각 서버가 세션을 소유하는 것이 아니라, in-memory DB에 모두 저장하고 필요할 때 DB에서 조회하는 형태로 세션을 사용한다면 더 이상 세션의 동기화는 문제가 되지 않겠죠. 애초에 하나의 원본 세션만 존재하고, 나머지는 이를 참조하는 형태이니까요.
in-memory DB 기반 세션 인증
또한 세션 클러스터링처럼 서버의 개수가 많아진다 하더라도 서버 간 세션을 공유할 필요가 없기 때문에, 서버의 규모가 클 때에도 성능 저하로 걱정할 필요가 없습니다. 물론, 네트워크 I/O를 통해 세션을 들고 오는 작업에 대한 비용이 발생하겠지만, 서버의 개수가 증가할수록 세션 클러스터링이나 Sticky Session에서 발생하는 성능 저하에 비교하면 훨씬 효율적이죠.
따라서, 여러 가지 상황을 고려했을 때 가장 효율적인 성능을 보여줄 수 있는 것은 in-memory DB라고 생각하여 해당 방식을 도입하였습니다.
In-memory DB, 어떤 것을 사용하면 좋을까요?
AWS에서는 대표적으로 Redis와 Memcached 두 가지 In-memory DB를 소개하고 있습니다.
Redis vs Memcached
현재 상황에 더 적합한 기술을 선택하기 위해, 두 가지를 여러 관점에서 분석하고 어떠한 장단점이 있는지 정리해보았습니다.
Redis
Redis는 다양한 자료구조를 지원하고, in-memory DB의 사용 편의성을 향상하는 다양한 서비스를 제공합니다.
Redis only uses single cores while Memcached utilizes multiple cores. So on average, Redis boasts a higher performance than Memcached in small data storage when measured in terms of cores. Memcached outperforms Redis for storing data of 100k or above. Although Redis has also made some optimizations for storing big data, it is still inferior to Memcached.
Redis는 Single core를 사용하는 반면, Memcached는 Multi cores를 활용하기 때문에 data storage의 크기가 작은 경우에는 Redis가 코어당 성능이 더 좋지만, data storage의 크기가 큰 경우에는 Multi-core를 활용하는 Memcached가 더 유리합니다.
