대규모 트래픽을 고려한 서버 확장 방법

요즘 제공되는 거의 모든 IT 서비스들은 네트워크를 통해 서버와 통신을 하여 사용자에게 원하는 데이터를 제공해 줍니다.

이 말을 달리 표현하자면 사용자들의 요청에 비례하여 서버의 처리량은 증가할 수밖에 없습니다.

서버의 처리량 증가라는 말은 서버의 부하가 증가한다는 말과 동일하며 부하를 감당하지 못하는 서버는 사용자가 요청한 정보를 신속하게 처리할 수 없게 됩니다.

이러한 문제점을 해결하기 위한 방안으로 Scale up, Scale out이란 개념이 있습니다.

이후 내용은 제가 토이프로젝트를 하면서 어떻게 고민하고 어떤방식을 도입하였는지 등의 고민들을 함께 나눠 보고자 합니다.

일단 진행하기에 앞서 간단하게 Scale up , Scale out에 대한 개념을 정리해 보고자 합니다.

개념정리

Scale out

방대한 트래픽 요청 등에 따른 문제로 인해 기존의 서버로 요청사항을 처리할 수 없을때, 서버의 대수를 늘려 처리능력을 향상시키는 방식을 말합니다.

Scale up

사용하고 있는 서버 자체의 성능을 증가시키는 방법입니다. 향상시키는 방법으로는 대표적으로 CPU, RAM 등을 업그레이드 하는 방법이 있습니다.

Scale out vs Scale up

	Scale out	Scale up
확장성	지속적인 확장 가능	성능 확장에 한계있음
비용	성능 증가 시 상대적으로 Scale up에 비해 적음	Scale out에 비해 상대적으로 비용이 큼
장애	장애발생 시 해당 서버만 수정하면 됨	서버 한대에 집중되어있으므로 장애발생시 서비스 중단될 수 있음

토이 프로젝트(커리어스)

제가 진행하고 있는 프로젝트에 대해서 간단하게 설명하고 해당 프로젝트에서 어떤 고민들을 하였는지, 어떻게 결론을 내렸는지 공유해 보려고 합니다.

커리어스는 IT현직자들의 인사이트 공유 놀이터 앱 서비스인 커리어리를 기반으로 만든 토이 프로젝트 입니다. 혹시라도 궁금하신 분들을 위해 링크를 달아두겠습니다.

https://github.com/f-lab-edu/careers

Scale out을 사용해볼까?

Scale out의 장점을 프로젝트와 관련지어 생각해보았습니다.

1. 대용량의 트래픽을 감당하기에는 하나의 서버로 처리하는 것 보다 여러 서버를 두어 유연하게 대응할 수 있습니다.
2. 서비스를 제공할때 가장 신경써야 할 부분이 장애발생 시 서비스 중단 즉 SPOF(Single Point Of Failure)를 해결할 수 있습니다.
3. 비용문제에서도 가성비 좋은 서버를 선택하면 크게 문제될 일이 없을 것 같습니다.

음.. 장점만 나열했더니 그냥 Scale out을 사용해도 될 것 같지만 고려사항도 생각해보겠습니다.

1. 서버만 여러개 둔다고 Scale out이 되는게 아니라 로드밸런싱 처리를 하여 여러 서버의 요청 트래픽을 동일하게 분산시키는 작업이 필요합니다.
   • 상황에 맞는 로드밸런싱 알고리즘을 선택해야합니다. (Round Robin, Least Connection 등)
2. 서버가 여러대 임으로 데이터 불일치 현상이 발생할 수 있습니다. (세션 불일치)
3. 서버들에 설치하는 소프트웨어 라이선스 비용이 증가할 수 있습니다.

Scale up을 사용해볼까?

이번에도 역시 Scale up의 장점을 상기시키면서 프로젝트와 연결지어보도록 하겠습니다.

1. 데이터 일관성 처리를 보장합니다.
2. 서버가 많이 필요로하는 Scale out보다 서버의 갯수가 1개인 Scale up이 상대적으로 서버관리 및 인프라적인 고민이 덜 할 수 있습니다.
3. 서버 한개에 대한 소프트웨어 라이선스 비용만 발생함으로 Scale out에 비해 저렴합니다.

그럼 반대로 Scale up을 사용한다고 했을때의 고려사항도 살펴보도록 하겠습니다.

1. 가장 큰 문제인 SPOF를 해결 할 수 없습니다.
2. 서버의 Scale up은 물리적으로 성능 향상의 한계가 있습니다. 만약 서비스가 성공하여 한개의 서버로는 감당이 안될 경우가 발생할 수 있습니다. (메로리 슬롯 제한 등)
3. Scale up을 할 경우 일시적으로 서비스를 중단해야 합니다. 무중단 서비스를 제공할 수 없습니다.

위와같은 문제들로 인해 얼마전에 모바일 게임인 쿠키런 킹덤에서 발생한 접속문제(SPOF)가 발생할 가능성이 높습니다. 또한 이러한 장애사항은 서비스 회사에서는 비용과 직결되기 때문에 크리티컬한 이슈라고 볼 수 있습니다.

결론

위의 내용을 고민하여 일단 제 프로젝트는 Scale out으로 진행하도록 결정을 하였습니다.

Scale out을 선택하는데 가장 큰 부분을 차지한 것은 크게 2가지 입니다.

1. 서버의 구성요소 중 장애가 발생하여 동작하지 않으면 전체 시스템의 동작이 멈춰버리는 SPOF의 문제점을 해결할 수 있다는 것.
2. SNS 서비스는 서비스 시간이 매출로 이뤄지기 때문에 어떠한 경우에도 동작을 해야함으로 무중단 서비스가 가능해야 한다.

Scale out으로 진행하면 로드밸런싱에 따른 세션 불일치 등의 이슈가 발생하겠지만 이는 극복할 수 있는 부분이라고 보았습니다.

• 각각의 WAS에 대한 세션을 세션 클러스터링 설정을 통해서 하나의 세션으로 관리되게 할 수 있습니다. (하지만 톰캣 등 WAS마다 설정방법이 다르고 WAS가 증설될때마다 서버의 ip, port를 설정해줘야 하는 번거로움이 있을 수 있습니다.)
• Redis를 사용하여 별도의 세션서버를 두어 해결할 수도 있습니다.