서버 확장이 필요한 순간
우리는 종종 서비스에 트래픽이 폭증해 서버가 다운되어 버리는 상황을 보곤 합니다. 주로 큰 이벤트를 한다는 소식에 사용자가 갑자가 엄청나게 몰리는 경우 이런 일이 벌어지는데요. 꼭 이런 경우가 아니라도 서비스가 성장해 사용자가 계속해서 늘어난다면, 기존의 서버만으로는 이 수많은 요청을 감당하지 못해 언젠가 서버가 다운되어 버릴 겁니다.
사이드 프로젝트를 하면서도 가끔 '내 서비스에도 사용자가 급증해서 서버 한번 터져봤으면..'하는 철없는(?) 상상을 해 보곤 합니다. 그런데 한두번이면 몰라도 이런 장애가 반복되면 어떻게 될까요? 게다가 사용자의 돈이 왔다갔다하는 서비스 중에 서버가 다운되어 버린다면? 아무리 획기적인 서비스라도, 서비스는 사용자의 신뢰를 잃게 될거고 금방 다른 대체 서비스에게 사용자를 전부 뺏겨버리게 될겁니다.
따라서 우리는 이렇게 서비스에 사용자가 늘어나는 상황에 대비하기 위해 반드시 서버를 성능을 확장해야 합니다. 그렇다면 서버를 확장하는 방식에는 어떤 것들이 있을까요? 현재 저는 Share My Hobby라는 동네 기반 취미 공유 서비스를 개발하고 있는데요, 제 서비스의 사용자가 급속히 증가하는 행복한 상상을 해보며 서버를 확장하는 두 가지 방식, Scale Up과 Scale Out에 대해 공부한 내용을 공유해보려고 합니다.
※ 이미지 참조 : https://library.gabia.com/contents/infrahosting/1222/
서버 확장하기 : Scale up & Scale out
Scale up
Scale Up (스케일 업)은 현재 사용하고 있는 서버 하드웨어의 사양을 업그레이드 하여 더 많은 요청을 처리할 수 있도록 하는 서버 확장 방법을 말합니다. 즉, 서버에 디스크를 추가로 끼워 넣거나 고성능의 CPU나 RAM으로 교체하여 서버의 성능을 증가시키는 겁니다. Scale up 방식은 단일 서버의 성능을 증강시킨다고 해서 Vertical scaling (수직적 확장)방식 이라고도 합니다.
Scale Out
Scale out(스케일 아웃)은 요청을 처리할 서버를 여러 대 추가하여 서버를 확장하는 방식을 말합니다. 백지장도 맞들면 낫듯이, 비슷한 사양의 서버라도 여러 대가 함께 요청들을 분산시켜 나눠서 처리한다면 더 많은 요청을 처리할 수 있을 겁니다. Scale out 방식은 서버를 추가하고 연결하는 모습에서 알 수 있듯 Horizontal scaling (수평적 확장)이라고도 합니다.
그렇다면 이제 이 두 방식 중 하나를 선택해야할텐데, 그러려면 두 방식의 장단점을 비교해보고 프로젝트에 더 적합만 방식이 무엇인지 분석해보아야 합니다.
장단점 비교하기
※ 이미지 참조 : https://tech.gluesys.com/blog/2020/02/17/storage_3_intro.html
Scale up 방식의 장단점
우선 Scale up 방식은 현재 사용하고 있는 서버 하드웨어의 부품을 추가하거나 교체하기만 하면 되기 때문에 비교적 서버 확장이 쉽다는 장점이 있습니다. 게다가 부품만 준비하면 되기 때문에 서버 자체를 추가해야 하는 Scale out 방식 보다는 필요한 장비도 적고, 운영에 따른 전력 소모도 적을겁니다. 또, 여전히 단일 서버를 운영하는 것이기 때문에 서버 확장에 따른 네트워크 추가 작업이나 로드 밸런싱 등을 신경쓰지 않아도 됩니다. 그리고 무엇보다 여러 서버 간에 데이터 일관성이 깨지는 문제를 해결하기 위해 추가적인 작업을 할 필요없다는 장점이 있습니다.
하지만, 아무리 더 좋은 부품으로 업그레이드를 한다고 하더라도 하드웨어 성능에는 분명 한계가 있기 때문에 확장에도 역시 한계가 있다는 문제가 있습니다. 요청이 계속해서 증가하게 되면 결국 서버 자체를 교체해주는 수밖에 없습니다. 또 하드웨어 부품의 성능이 좋아질수록 비용은 그보다 급격히 증가하는 것도 문제인데요, 쉽게 말해 확장을 하면 할수록 그 가성비가 떨어진다는 겁니다. 그리고 결정적으로 단일 서버 환경의 특성상, 장애에 치명적이라는 문제가 있습니다. 장애가 발생할 때 대신 처리해줄 서버가 없기 때문에 서버가 다시 복구될 때 까지 사용자는 서비스를 이용하지 못하고 하염없이 기다려야 하는거죠.
Scale out 방식의 장단점
한편 Scale out 방식은 확장에 유연하다는 장점이 있습니다. 서비스를 제공하는 기업은 미리 일정 정도의 서버를 마련해두고, 트래픽이 늘어나고 줄어드는 상황에 맞춰 서버를 늘리고 줄임으로써 유연하게 대응할 수 있습니다. 확장에 따른 비용 증가폭이 큰 Scale Up와 달리 Scale out 방식은 서버 한 대 추가한 만큼 비용만 일정하게 증가하고, 서버 한대 만큼의 성능 개선도 보장합니다. 그리고 그렇게 서버를 계속해서 늘려감으로써 지속적인 확장이 가능합니다. 중요한 장점이 하나 더 있는데요, 바로 Scale Up 방식과 달리 서버를 여러 대 운영하기 때문에 하나의 서버에 장애가 나서 다운되더라도 다른 서버를 이용해 서비스를 중단없이 제공할 수 있다는 것입니다.
하지만 Scale out 방식에도 역시 단점은 있습니다. 서버가 여러 대인 만큼 트래픽을 각 서버에 균등하게 분산시켜주는 기능을 하는 로드 밸런서가 반드시 필요합니다. 트래픽 분산이 제대로 이뤄지지 않고 하나의 서버에만 몰리게 된다면 Scale out을 하는 의미가 사라질 겁니다. 서버가 추가될 때 마다 연결 작업을 해주고, 트래픽 분산이나, 각 서버가 정상적으로 동작하고 있는지 모니터링 하는 등 관리 포인트가 늘어날 수 밖에 없다는 점도 고려해야 합니다. 그리고 또 반드시 주의해야할 점은, 각 서버 간에 데이터의 일관성이 유지될 수 있도록 추가적인 작업을 해줘야 한다는 것입니다. 서버가 하나가 아니다보니, 각 서버가 저장하는 데이터가 다르고, 각 서버는 서로의 데이터를 알 방법이 없기 때문에 일종의 데이터 동기화 작업이 필요하다는 것입니다. 이와 관련해 더 자세한 내용은 다음 포스트에서 다뤄 보도록 하겠습니다.
프로젝트에 어떤 방식이 더 적합할까?
모든 기술이 그렇듯, 서버 확장 방식에도 이처럼 trade-off가 존재합니다. 그래서 제가 개발할 서비스의 특성을 고려해 가장 중요한 선택의 기준들을 세워보고, 그에 따라 각 방식을 비교해 보기로 했습니다. 기준은 아래와 같이 정했습니다.
- 서비스가 빠르고 지속적으로 성장하는 환경에 적합한가?
- 장애에 효과적으로 대응할 수 있는가?
- 만약 서버가 여러 대라면, 데이터 불일치 문제를 해결하기 위한 리소스가 얼마나 들어갈 것인가?
결론부터 말하자면, 제가 선택한 방식은 Scale out입니다. 그럼 왜 Scale out 방식을 도입하는 것이 더 적합하다고 생각했는지 위 기준들을 바탕으로 하나씩 적어보겠습니다.
서비스가 빠르고 지속적으로 성장하는 환경에 적합한가?
앞서 언급했듯 저는 서비스 사용자가 지속적으로 급증하는 행복한 상상을 하며 사이드 프로젝트를 진행하고 있습니다. 상상이 현실이 되었을 때, Scale up 방식을 선택한다면 서버를 확장할 때 마다 비싼 비용을 들여 부품을 추가 혹은 교체해야하고, 그 효과마저도 갈수록 떨어질 것입니다. 반면 Scale out 방식을 사용하면 일정한 비용으로 서버를 확장하면서 추가한 서버만큼의 확실한 효과를 기대해 볼 수 있을 겁니다. 또, 서비스가 무한히 성장하더라도 그에 맞춰 서버를 추가해주고 트래픽을 잘 분산시켜주기만 한다면 요청이 몰려 서버가 다운되는 일은 없을 겁니다.
장애에 효과적으로 대응할 수 있는가?
Share My Hobby는 많은 사용자가 사용할 B2C 서비스인 만큼 작은 장애에도 매우 민감합니다. 그래서 서버에 문제가 발생하더라도 서비스는 중단 없이 이뤄져야하는데요, Scale out 방식에서는 여러 서버가 트래픽을 나눠 처리하기 때문에 그 중 하나의 서버에서 문제가 발생하더라도 다른 서버들이 대신 트래픽을 처리해 줄 수 있습니다. 장애 대응은 서비스를 안정적으로 운영하는데 있어 너무나도 중요한 이슈이기 때문에, Scale out의 이러한 장점은 웬만한 다른 단점들을 상쇄시켜 줄 정도로 크다고 생각했습니다.
데이터 불일치 문제를 해결하기 위한 리소스가 얼마나 들어갈 것인가?
Scale out을 선택할 때 가장 이슈가 될 수 있는 부분이 서버 간 데이터 불일치 문제일 것입니다. 하지만 이 문제를 효과적으로 해결할 수 있는 다양한 방법들이 존재합니다. 대표적으로 Redis와 같이 메모리 레이어에 따로 데이터 스토어를 두어 서버들이 이를 통해 데이터를 공유할 수 있도록 아키텍처를 구성하는 방법이 있는데요. Redis를 활용하면 좋은 성능을 유지하면서 큰 리소스를 들이지 않고도 데이터 불일치 문제를 해결할 수 있습니다.
지금까지 제가 사이드 프로젝트를 진행하며 서버 확장과 관련해 공부하고 고민한 내용을 정리해보았습니다. 다음 포스트에서는 Scale out을 도입했을 때 필연적으로 마주하게 될 데이터 불일치 문제를 해결하기 위한 방법들에 대해 좀 더 자세히 다뤄보도록 하겠습니다.
참고자료
- https://library.gabia.com/contents/infrahosting/1222/
- https://tech.gluesys.com/blog/2020/02/17/storage_3_intro.html
프로젝트
