ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 1. Scale Up과 Scale Out 알아보기
    프로젝트 2021. 7. 23. 18:11


      개발 공부를 시작하고 반년이 흘러, 최근 공부한 이론을 바탕으로 배달 서비스 프로젝트를 시작하게 되었다. 프로젝트를 진행하면서 코드만 작성하는 게 다가 아니라는 것을 배우고 있다. 특히 성능을 고려하지 않고 개발을 하는 것은 실제 서비스를 운영할 때 큰 문제가 될 것이다. 후에 문제가 되지 않도록 프로젝트에 이런저런 문제 상황을 가정하고 해결해보기로 했다.

      우리 프로젝트가 현재 서비스 중이고, 사용자가 매우 급증하고 있다고 가정한다면? 서버는 늘어나는 사용자를 감당하지 못해서 점차 느려지고 과부하가 걸리고 말 것이다. 이 같은 상황이 생기지 않도록 우리는 서버를 확장해야 한다. 이때 사용하는 전략이 바로 Scale UpScale Out이다.

     

     


     

    서버 확장 전략: Scale Up & Scale Out


      우선 각 단어의 사전적 의미를 살펴보기로 했다. Scale은 '범위, 크기', Up은 '위로', Out은 '외부로'와 같이 해석될 때가 많다. 합쳐보면 Scale Up은 위로 크기를 키우고, Scale Out은 외부로 범위를 넓게 한다는 뜻이 될 수 있지 않을까? 이 정도로 대강 파악해두고, 아래 그림과 함께 서버 확장 전략에서의 정의와 장·단점을 살펴보면 이해가 더 쉬울 것 같다.

     

     

    출처: docs.microsoft.com

     

    Scale Up이란?

      서버에 디스크를 추가하거나 기존 부품을 더 높은 사양의 CPU, 메모리로 교체하여 서버의 처리 능력을 높이는 것이다. 기존 서버 자체의 처리 능력이 수직으로 업그레이드되므로, 수직 스케일로 불리기도 한다.

     

      그렇다면 Scale Up장점은 어떤 것이 있을까?

    • 부품을 교체하는 것만으로 업그레이드가 가능하므로 편리하다.
    • 한 대의 서버만 관리하면 되므로 관리 편의성이 좋다.
    • 데이터 정합성 측면에서 자유롭다.
    • 소프트웨어 라이선스나 그 외 추가적인 네트워크 인프라 비용이 들지 않는다.

     

      데이터 정합성은 데이터가 서로 모순 없이 일관되게 일치하는 것을 의미한다. Scale Up은 한 대의 서버에서 데이터를 관리하므로 데이터가 모순되거나 불일치하는 문제는 걱정하지 않아도 된다. 이러한 장점으로 인해 데이터 갱신이 빈번하게 발생하는 데이터베이스 서버 같은 경우, Scale Up 전략이 적합할 수 있다.

     

      쉽고 편리한 Scale Up단점은 무엇일까?

    • 성능 확장에 한계가 있다.
    • 하드웨어 장비 업그레이드 비용이 많이 든다.
    • 비용 대비 성능 증가 폭이 일정하지 않다.
    • 서버 자체를 변경해야 할 경우 마이그레이션(한 운영환경에서 다른 운영환경으로 옮겨가는 것) 비용이 든다.
    • 한 대의 서버이므로 장애 영향도가 크다.
    • 향후 확장 가능성에 대비해야 한다.

     

      Scale Up은 서버의 여유 슬롯이 부족하다면 더 이상 새로운 부품을 추가할 수 없다. 현존하는 가장 좋은 사양의 부품을 장착하고 있다면 더 좋은 것으로 교체할 수도 없다. 이러한 점 때문에 Scale Up은 성능을 지속적으로 확장할 수 없다는 한계를 갖는다.

     

      서버 자체를 변경해야 하는 상황이 생길 경우에 발생하는 마이그레이션 비용도 무시할 수 없다. 마이그레이션 작업을 하는 동안 서비스를 제공할 수 없고, 작업 시간이 길어질수록 그로 인한 손실이 커진다. 서버에 문제가 생기는 상황도 마찬가지다. 서버에 문제가 생기면 결국 서비스를 중단해야 하고, 복구 작업 시간이 길어질수록 손실이 커질 수밖에 없다.

     

      향후 확장 가능성 대비도 해야 한다. 예를 들어, 여유 슬롯이 많은 서버를 미리 마련하는 것이다. 하지만 서비스 이용률이 기대 이상으로 급증하여 성능 확장을 위해 마련한 공간이 부족할 수 있다. 반대로 예상과 다르게 서비스 이용률이 미미하다면, 서버의 많은 공간과 서버 마련 비용을 낭비한 셈이 된다.

     

    Scale Out이란?

      서버를 여러 대 추가하여 서버의 처리 능력을 높이는 것이다. 각 서버의 처리 능력을 수평 합하면 총 처리 능력이 되므로, 수평 스케일로 불리기도 한다.

     

      이제 Scale Out장점을 알아볼 차례다.

    • 지속적인 성능 확장이 가능하다.
    • 서버 비용이 비교적 저렴하다.
    • 트래픽 분산으로 전면 장애의 가능성이 적다.
    • 향후 확장 가능성에 대비할 필요 없이 유연한 확장이 가능하다.

     

      Scale Out은 새로운 서버를 계속 추가하면 되므로 지속적인 성능 확장이 가능하다. 비교적 낮은 성능의 서버를 여러 대 두는 경우가 많기 때문에 서버 비용이 저렴하다고 볼 수 있다. Scale Up과 다르게 장애가 발생하더라도, 해당 서버 외 다른 서버들이 계속해서 서비스 제공을 할 수 있다. 성능 확장이 필요하다고 느낄 때 바로 서버를 추가하면 되므로, 확장이 유연한 편이다. 높은 병렬성을 실현하기 쉽고, 데이터의 변경이 적은 웹 서버 같은 경우, Scale Out 전략이 적합할 수 있다.

     

      다음은 Scale Out단점이다.

    • 각 서버에 트래픽을 균등하게 분산시킬 수 있도록 로드 밸런싱 작업이 필수적이다.
    • 여러 대의 서버를 관리해야 하므로 관리 편의성이 떨어진다.
    • 데이터 정합성 측면에서 자유롭지 못하다.
    • 소프트웨어 라이선스나 네트워크 인프라 비용이 추가적으로 들 수 있다.
    • 서버 간 동기화로 지연 현상이 발생할 수 있다.

     

      Scale Out은 여러 대의 서버를 두다 보니 한 대의 서버를 관리하는 것보다는 아무래도 편의성이 떨어지는 것 같다. 트래픽을 분산하는 로드 밸런싱 작업도 해야 하고, 서버 간 데이터 불일치 문제(아래에서 언급되는 세션 불일치 같은 문제를 포함)도 신경을 써야 한다. 데이터가 빈번하게 갱신되는 경우에는 특히 데이터 불일치가 자주 발생할 것이고, 서버 동기화로 인한 지연 현상도 많이 발생할 것 같다.

     

     


     

      우리 프로젝트는 어떤 전략을 사용하면 좋을까? 배달 서비스라는 점을 고려했을 때 Scale Up보다는 Scale Out이 적합할 것 같다. 이유는 크게 두 가지다. Scale Out지속적인 성능 확장이 가능하고, 서버 장애로 인해 서비스가 중단될 가능성이 비교적 낮다는 점 때문이다.

     

      만약 성능 확장에 한계가 있다면 어떻게 될까? 우리 서비스를 이용하려는 고객들이 점점 많아진다고 하더라도, 서버 처리량에는 한계가 있기 때문에 모든 고객을 받을 수 없을 것이다. 그렇다면 고객들은 다른 경쟁사가 제공하는 서비스로 점차 옮겨갈 것이고, 결국 우리 서비스가 성장하는 데에도 한계가 생길 것이다.

     

      서버 장애로 인해 서비스가 중단되는 일이 생긴다면? 위처럼 고객들은 다른 서비스를 이용할 테고, 그런 상황이 잦아진다면 충성 고객들마저 이탈하게 될 것이다. 우리 서비스에 등록한 가게 사장님들은 그만큼 손실을 입게 된다. 우리 서비스에'만' 가게를 등록했다면 그 타격은 더욱 클 것이다. 결국 가게 사장님들까지 다른 경쟁사의 서비스를 찾아 이탈하게 된다면, 거래 수수료를 매출로 삼는 우리는 더 이상 서비스를 이어나갈 수 없을 것이다.

     

      Scale Out 전략을 선택했을 때 위와 같은 치명적인 문제가 생길 가능성은 줄어들지 않을까 하는 생각이 든다. 하지만 Scale Out은 단점이 없는 전략이 아니기 때문에 Scale Out의 단점에 대비해야 할 것이다. 수업 때 배운 예시를 얘기하자면, 로그인을 담당하는 1번 서버에 저장된 세션이 회원정보 수정을 담당하는 2번 서버의 것과 불일치하여, 2번 서버는 해당 회원이 로그인했다고 판단하지 않는 경우가 생길 수 있다고 한다.

     

      이런 세션 불일치 문제는 어떻게 해결하면 좋을까? 해당 내용은 이어지는 글들에서 다루고자 한다.

     

    프로젝트 링크: https://github.com/f-lab-edu/DeliDeli.git

     

    GitHub - f-lab-edu/DeliDeli: (Delicious Delivery) 음식 배달을 제공하는 딜리버리 서비스입니다.

    (Delicious Delivery) 음식 배달을 제공하는 딜리버리 서비스입니다. Contribute to f-lab-edu/DeliDeli development by creating an account on GitHub.

    github.com

    참고:

     

    [DB] DB확장을 하는 두가지 방법- 스케일 아웃(scale out)과 스케일 업 (scale up)

    [DB] DB확장을 하는  두가지 방법- 스케일 아웃(scale out)과 스케일 업 (scale up) 서버를 운영하다보면 이용자의 증가, 서비스의 확장 등의 이유로 더 많은 용량과 성능이 더 필요하게 된다.

    devuna.tistory.com

     

    글루시스 기술 블로그

    A simple yet classy theme for your Jekyll website or blog.

    tech.gluesys.com

    • 한국데이터산업진흥원
Designed by Tistory.