도당탕탕

Scale Up과 Scale Out 본문

Architecture

Scale Up과 Scale Out

backlo 2020. 1. 16. 00:46

INTRO

  1. Scale up?
  2. Scale out?
  3. 둘의 장,단점 및 적용법
  4. SPOF?

Scale Up

  • 서버 자체의 성능을 늘려 처리 능력을 올려주는 것이라고 생각하면 된다.
  • 기존 서버에서 고성능의 서버로 변경을 시키는 것을 의미한다.
  • 다른 말로 수직 스케일이라고 불린다.

Scale Up의 장,단점

  • 장점
    • 하드웨어의 성능을 향상시키기 때문에 인프라를 따로 건들 필요가 없어 구축, 설계가 쉽다.
    • 스토리지 컨트롤러나 네트워크 인프라 비용은 별도로 발생하지 않는다.
  • 단점
    • 확정성의 한계가 있다. 즉 추가할 수 있는 디스크나 RAM 용량이 한정되어 있기 때문에 확장에 대해 제약이 있다.
    • 스토리지 컨트롤러가 확장의 한계에 다달았을 경우, 다른 스토리지를 추가할경우 이미그레이션 비용이 발생한다.
    • 가격이 엄청 비싸다.
    • 트래픽 부하로 인한 장애 영향도가 크다.

Scale Out

  • 접속된 서버의 대수를 늘려 처리 능력을 향상시키는 것이라고 생각하면 된다.
  • 전형적으로 랙 마운트 서버나 브레이드 서버를 추가 시키는 것 등이라 보면 된다.
  • 다른 말로 수평 스케일이라고 불린다.
  • 하나의 서버 케이스에 가상으로 복수 서버를 만들어 Scale out과 같은 효과를 보는 방법도 있다. 이를 스케일 위드인, 가상 스케일 아웃이라 부른다.

Scale out의 장,단점

  • 장점
    • 확장에 대해 Scale Up보단 유연하지만 무한정으로 확장이 가능하지 않는다.
    • 분산 처리로 인한 장애 가능성이 작다.
    • Scale Up에 비해 비교적 저렴하다.
  • 단점
    • 다수의 컴퓨터의 병렬 처리로 인해 설계, 구현이 복잡하다. 그리고 이로 인한 관리비용이 별도로 발생한다.
    • 기본적으로 직렬화가 되어야 할 구성요소가 존재한다.
    • 서버 대수(코어 개수)와 성능이 비례하지 않는다. 즉 코어가 증가 하더라도 동시에 대역폭도 증가하기 때문에 지연이 발생한다.
    • 병렬 구조를 가지고 있어 각 서버에 대한 데이터를 어떻게 동기화 해야하는지, 세션은 어떻게 공유를 해야하는지에 대한 기술적인 한계가 있다.

Scale Up & Out 적용 대상

  • Scale up
    • 빈번히 데이터의 갱신이 발생하는 경우 즉 정합성이 어려운 경우에 적합하다.
    • OLTP(온라인 트랜잭션 처리)
    • 대표적으로 데이터베이서 서버
  • Scale out
    • 갱신 데이터의 정합성 유지가 어렵지 않는 경우에 적절하다.
    • 병렬성 처리를 하는 어플리케이션에 적합하다.
    • 대표적으로 웹 서버

SPOF

spof

  • Single Point Of Failure이라 불른다.
  • 시스템 구성 구성요소 중에 어느 한 요소가 장애가 발생했을 경우 전체 시스템이 고장나는 한지점을 말한다.
  • 단일 장애점(고장점, 실패점) 이라 불린다.

SPOF 예

  • Web Browser 에서 Web Server로 요청을 보내는 경우
    • 하나의 Web Server를 둘 경우 오류로 인한 서버와 클라이언트간의 통신이 안된다.
    • 따라서 N대의 Web Server를 두거나 L4 나 L7스위치를 두어 예방한다.
  • WebServer에서 WAS로 요청을 보내는 경우
    • 보통 개발자의 코드로 인한 WAS의 문제점이 발생한다.
    • 따라서 N대의 WAS를 구축해 예방한다.
  • DataBase에서 용량 부족으로 인한 장애가 발생하는 경우
    • RAID : 한개의 데이터베이스 서버를 여러개로 분할시켜 데이터를 분할 저장시키는 방법
    • NAS : 여러개의 데이터베이스 서버를 두는 방법

예방

  • 전체 시스템 구성도에서 복잡한 설계 부분이 어디인지 판별하는 것이 중요하다.
  • 단일 장애점을 파악해 제거를 하는 것이 중요하다.
  • 또한 높은 신뢰성을 가지는 어플리케이션에서 단일 컴포넌트를 가져서는 안된다.
    • 단일 컴포넌트 에러로 인한 치명적인 전체 시스템 셧다운 발생
  • 전체 이중화
    • switch도 다중화 시킨다.

Completely redundant system

정리

  • 어떠한 방식이 좋다고 설명 할 수 없다.
  • 상황에 따라 Scale up이나 Scale out을 사용해 최적의 인프라를 구성하는 것이 좋다.
  • 인프라에서 단일 장애점을 찾고 그에 맞는 대책을 취해야 한다.

그외

  • Scale up & Scale out의 비용과 수용능력간의 관계

cost, capability

Comments