[Web] 다중 서버에서 세션을 관리해보자 - 1 (feat Scale-up, Scale-out)

 

 

들어가며

세션에 대해 조금씩 이해를 하고 있지만, 세션을 어떻게 활용해야 잘 활용할 수 있는 것인지에 대해 정리해보고 싶었습니다. 세션을 쓸 때 어떤 것들을 고려해야 하는지에 대해 더 늦기 전에, 기초를 쌓고 싶어서 개념을 정리해보고자 합니다. 무지를 반성하는 마음으로 이 글을 적습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

서버를 확장하는 방법?

다중 서버에서 세션을 관리하는 방법에 대해 알아보기 전에, 다중 서버에 대해 먼저 알아보겠습니다. 먼저 서비스를 만든다고 가정해봅시다. 처음에는 10명이 사용하는 서비스였지만, 엄청난 인기 덕에 100000명이 사용하는 애플리케이션을 운영하려고 할 때 서버를 어떻게 구축할 수 있을까요? 만약 서버의 크기가 한정적이라면 서버의 크기를 조절해야 할 텐데, 서버의 크기를 조절하는 방법에는 어떤 것들이 있을까요? 여기에는 스케일 업과 스케일 아웃 방식이 있습니다.

 

 

 

 

 

 

스케일 업(Scale up)

스케일 업이란, 단일 서버의 성능을 증가시켜 더 많은 요청을 처리하는 방법을 의미합니다. CPU 업그레이드 또는 RAM 추가 등으로 하드웨어 장비의 성능을 높이는 접근 방법입니다. 스케일 업은 단순히 하드웨어만 추가/교체하는 작업이기 때문에 구현과 설계가 쉽다는 장점이 있고, 서버를 추가하는 방법이 아니기 때문에 여러 대의 서버를 두는 것보다 데이터 정합성 이슈에서 자유롭다는 장점이 있습니다. 그리고 컨트롤러나 네트워크 인프라 비용(소프트웨어 라이센스 등)이 추가로 발생하지 않습니다. 하지만 용량, 성능 확장의 한계가 찾아온다는 단점이 있습니다. 가장 좋은 CPU와 가장 큰 용량의 RAM을 사용하더라도 그것을 초과하는 성능으로 업그레이드하는 것은 불가능합니다. 그리고 스케일 업의 일정 수준이 넘어가는 순간 성능 증가 폭이 미미해집니다. CPU를 예로 들면 i3 -> i5로 스케일 업 하는 경우 1.5배 이상의 성능 변화가 있는 반면에 i5 -> i7로 스케일 업 하는 경우에는 1.2배의 성능 변화밖에 보이지 못합니다. 그리고 가장 큰 단점으로 하나의 서버가 모든 클라이언트의 트래픽을 담당하기 때문에 해당 서버에 문제가 생길 경우 서버가 복구될 때까지 서비스를 중단해야 하는 상황이 발생할 수도 있습니다. 그럼 스케일 업방식이 아닌 스케일 아웃 방식은 어떠한지에 대해 알아보겠습니다.

 

 

 

 

 

 

 

 

 

스케일 아웃(Scale out)

스케일 아웃이란 동일한 사양의 새로운 서버를 추가하여 성능을 증가시키는 방법입니다. 스케일 업보다는 인프라 재구성에 있어서 다소 유연한 방법입니다. 스케일 아웃을 활용하면 용량, 성능 확장의 한계가 없다는 장점이 있습니다. 하드웨어를 변경하는것이 아닌, 비슷한 성능의 서버를 여러 개 두는 방법이기 때문에 지속적인 확장이 가능합니다. 또한 하나의 서버가 모든 트래픽을 관리하는 스케일 업 방식과 반대로, 여러 개의 서버를 두어 분산 처리하기 때문에 장애 가능성이 감소합니다. 즉, 단일 서버에 작업이 쌓여서 멈춰있는 병목현상을 줄일 수 있습니다. 그리고 마지막으로 스케일 업에 비해 비용이 저렴하다는 장점이 있습니다. 

 

 

 

하지만 여러 개의 서버를 관리해야 하기 때문에 관리 비용이 증가한다는 단점이 있고, 모든 서버에서 데이터의 일관성을 유지해야 하기 때문에 설계 및 관리가 복잡합니다. 일관성이 유지되지 않으면 데이터의 불일치가 발생할 수 있습니다. 위 그림을 보면 다중 서버에서 로그인 요청 시 발생하는 데이터 불일치 문제를 확인할 수 있습니다. User1의 경우 로그인 시, 최초 접속한 서버(WAS_1)의 세션 저장소에 세션을 생성하고 로그인 정보를 저장합니다. 이후에 세션 ID를 클라이언트에게 발급하게 되고, 이를 클라이언트의 쿠키 저장소에 저장하여 다음 요청을 보낼 때마다 이를 꺼내서 HTTP 요청 헤더에 실어서 보내게 됩니다. 이는 단일 서버에서는 문제없이 동작하지만, 서버가 2대 이상 늘어난다면, WAS_1에서 발급받은 세션 ID를 WAS_2에서 인증하게 되면 WAS_2에는 존재하지 않는 세션이므로 인증이 처리되지 않습니다. 즉 데이터 일관성을 유지하기 위한 방식이 필요합니다. 그리고 병렬 컴퓨팅 환경을 구성하고 유지하려면 로드 밸런싱에 대한 높은 이해도가 요구됩니다

 

 

 

 

 

스케일 업과 아웃 중 하나를 고른다면?

만약 한 대의 서버에서 모든 데이터를 처리하고 데이터 갱신이 빈번하게 일어나는 경우 스케일 업 방식을 활용하는 것이 좋고, 모든 서버가 동일하게 데이터를 가지고 있어서 데이터의 변화가 적은 경우 스케일 아웃 방식을 활용하는 것이 좋습니다. 하지만 스케일 업과 스케일 아웃 모두 장점과 단점이 뚜렷하기 때문에 환경에 따라 합리적인 방법을 고려하여 최적의 방법을 선택하는 것이 좋습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

마치며

공부를 하며 그동안 아주 기초적인 것들을 제대로 공부하지 않았다는 것을 깨닫습니다. 좋은 기술을 배우는 것도 좋지만, 기술의 기반이 되는 기초적인 지식을 먼저 쌓는 것이 중요하다는 것을 다시금 깨달았습니다. 기초가 튼튼한 개발자가 되고 싶습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

출처

서버를 확장하는 방법 : 스케일 업 vs 스케일 아웃

다중 서버 환경에서 Session은 어떻게 공유하고 관리할까? - 1편 (Scale-Up / Scale-Out이란?)