스케일 아웃과 스케일 업 - 서버 처리능력 향상의 길

서버의 처리 능력을 증강하는 방법으로는 크게 두 가지가 있다. 스케일 아웃과 스케일 업이다. 양자는 각각 특성이 있어 상호 보완적이다. 양자의 사용구분에 대해 다소 오해하는 일이 있으므로 여기에 정리해 두자. 스케일 업? 스케일 아웃?스케일 업이란 서버 그 자체를 증강하는 것에 의해서 처리 능력을 향상시키는 것이다. 수직 스케일로 불리기도 한다. 전형적으로는 SMP(대칭형 멀티 프로세서)에 대해 프로세서를 추가하는 것이나 프로세서 그 자체를 고성능 모델로 옮겨놓는 것을 가리킨다. 　한편 스케일 아웃이란 접속된 서버의 대수를 늘려 처리 능력을 향상시키는 것이다. 수평 스케일로 불리기도 한다. 전형적으로는 웹 서버 펌으로서 사용되고 있는 랙 마운트 서버군에 서버를 추가하는 것이나 브레이드 서버에 브레이드를 추가하는 것 등이다. 서버의 가상화 기능을 사용하고 하나의 케이스 내에서 가상적으로 복수 서버를 구축해 스케일 아웃과 동등의 효과를 제공할 수도 있다. 이러한 방식을 특히 스케일 위드인 또는 가상 스케일 아웃 등으로 부르기도 한다. 스케일 아웃이 적합한 경우그럼 스케일 업과 스케일 아웃의 사용구분에 대해서 알아보자. 설명의 편의상 스케일 아웃이 유효한 경우에 대해 먼저 검토한다. 　스케일 아웃은 개개의 처리는 비교적 단순하지만 다수의 처리를 동시 병행적으로 실시하지 않으면 안 되는 경우에 적합한데 갱신 데이터의 정합성 유지에 대한 요건이 별로 어렵지 않은 경우에 적절하다. 즉 높은 병렬성을 실현하기 쉬운 경우이다. 　전형적인 것이 앞서 말했던 웹 서버 펌이다. 웹 서빙에서는 네트워크로부터 보내온 다수의 요구를 동시 병행으로 처리할 필요가 있지만 개개의 처리는 비교적 단순하다. 또 기본적으로 읽기전용(데이터로의 액세스는 거의 읽기전용)이다. 그러므로 통상 웹 서빙 환경에서는 랙 마운트 형 서버나 브레이드 서버를 이용하고 비교적 소규모의 서버를 적은 설치 면적으로 다수 가동하는 스케일 아웃에 포커스가 놓여진다. 　또 검색엔진 데이터 분석 처리 VOD(주문형 비디오) 일부의 과학기술 계산 등도 같은 이유에 의해 스케일 아웃에 의한 처리 능력의 향상이 실현되기 쉬운 영역이다. 이러한 애플리케이션에서는 기본적으로 데이터는 읽기전용이기 때문이다. 　이와 같이 읽기전용인 스케일 아웃 환경에 있어서는 처리 능력 향상과 가용성의 증대라는 이점도 있다. 하나의 서버가 장애를 일으켜도 다른 서버로 즉시 처리를 계속할 수 있기 때문이다. 　데이터 갱신이 필요한 경우도 데이타베이스의 분할이 비교적 용이하면 스케일 아웃을 활용할 수 있다. 메일 서버나 게시판 등의 애플리케이션이 이것에 해당한다. 이 경우 메일 유저나 게시판을 그룹으로 나누고 각각 서버를 할당하는 것으로 처리 능력을 향상시킬 수 있다. 그러나 이러한 경우에는 서버를 추가했을 때에 데이타베이스의 분할 작업이 또다시 필요하고 운용상의 부담이 커지는 일이 많다. 　스케일 아웃이 유효한 영역에서 스케일 업의 방법을 적용할 수도 있다. 그러나 일반적으로 스케일 업은 스케일 아웃보다 비용이 높기 때문에 너무 매력적인 선택사항이라고는 말할 수 없다. 스케일 업이 적합한 경우스케일 아웃은 비용이 적고 높은 가용성이 실현될 수 있기 때문에 긍정적으로 평가되지만 스케일 아웃에서는 제대로 처리 능력을 향상할 수 없는 애플리케이션 영역도 존재한다. 즉 하나의 이미지 데이타베이스에 대해서 빈번히 갱신이 발생하는, 이른바 OLTP(온라인 트랜잭션 처리)이다. 　OLTP에서는 데이타베이스의 배타 제어가 실행에 큰 영향을 준다. 배타 제어의 오버헤드가 크면 아무리 강력한 서버를 사용해도 높은 실행률을 실현할 수 없다. 배타 제어를 효율적으로 실시하기 위해서는 갱신 처리를 실시하는 많은 과정이 가능한 한 짧은 지연 시간 안에 통신할 필요가 있다. 같은 조건하에서 지연이 적은 통신을 하려면 메모리 경유의 통신이 최적이라고 할 수 있다. 다른 조건의 네트워크를 경유하는 통신을 하면 지연이 길어져 그것이 처리 전체의 장애가 되어 버린다. 결과적으로 OLTP계의 애플리케이션에 대해 스케일 아웃의 방법으로 서버를 추가해도 처리 능력은 비례하여 증가하지 않는다. 오히려 저하해 버리는 것조차 있을 정도다. 이러한 경우에는 스케일 업의 방법이 필요하다. 　SAP나 오라클 등이 제공하는 엔터프라이즈 애플리케이션 패키지는 시스템적으로 말하면 복잡도가 높은(complex system) OLTP다. 이러한 패키지 제품을 대규모로 전개하기 위해서는 스케일 업의 방법, 즉 대규모 서버가 거의 필수이다. 보다 정확하게 말하면 애플리케이션 서버에서는 스케일 아웃이 가능해도 데이터 베이스 서버에서는 스케일 업이 필요하다. 오라클이 제공하는 RAC(리얼 애플리케이션 클러스터) 등의 공용 캐쉬를 살린 테크놀로지에 의해 많은 시스템에 의한 데이타베이스 갱신 처리 배타 제어의 오버헤드는 비약적으로 저하됐다. 그런데도 스케일 아웃에 의해 성능 향상을 할 수 있는 최대점을 상당한 레벨까지 높여 수백 대의 서버를 사용하고 처리 능력을 수백 배로 한다는 것은 비현실적이다. 　OLTP계의 애플리케이션에 대해서도 데이타베이스를 분할해 스케일 아웃의 방법을 사용할 수 없는 것은 아니다. 그러나 앞서 말한 것과 같이 이러한 방법에서는 처리 능력 증강(서버 추가)마다 데이타베이스 재분할 작업이 필요하고 운용상의 부담이 극히 커지는 위험이 있다. 또 일반적인 업무 애플리케이션에서는 앞선 프로세스로부터 갱신되는 제어 테이블과 같은 공용 데이터 항목이 존재해 데이타베이스를 완전하게 분할하는 것이 곤란한 경우도 많다. 게다가 애플리케이션 패키지 제품을 사용했을 때는 패키지측이 데이타베이스의 분할을 전제로 만들어지지 않았다면 스케일 아웃의 적용은 곤란하다. 역시 스케일 아웃과 스케일 업 모두가 필요저비용의 소규모 서버를 여러 세트 맞춘 스케일 아웃 구성을 취하면 스케일 업 구성, 즉 고가의 대규모 서버는 불필요하다고 주장하는 사람도 있다. 이것은 웹 서빙 등의 특정 처리에는 들어맞지만 모든 타입의 처리에 들어맞는 것은 아니다. 특히 대규모 OLTP에서는 스케일 업적인 방법이 여전히 필요하다. 　스케일 아웃과 스케일 업의 특성상의 상위는 서버내 통신과 서버간 통신의 지연 차이라는 물리적 법칙에 유래하는 것이다. 그러므로 향후에도 장기적으로 스케일 아웃과 스케일 업의 사용구분은 필요할 것이다. 본래 스케일 업이 적합한 영역에 스케일 아웃을 적용하려하거나 그 반대의 경우를 실시하려하는 것으로 근본적으로 부적절한 시스템을 구축하는 것을 피하지 않으면 안 된다. @