클라우드 확장성: 언제 스케일업과 스케일아웃을 해야 할까요?

IT 관리자는 자신의 역할에서 확장성 문제에 자주 직면하게 됩니다. 애플리케이션의 성장률, 데이터 스토리지 용량 요구 사항 및 대역폭 수요를 예측하는 것은 결코 쉬운 일이 아닙니다. 워크로드가 용량 한계에 가까워지면 아키텍처를 확장하거나 아키텍처를 확장할 때 어떻게 하면 효율성을 보장하면서 고성능을 유지할 수 있을까요?

예상치 못한 급속한 성장이나 계절적 수요 변동을 수용하기 위해 확장 또는 확장을 통해 클라우드 서비스의 힘을 신속하게 활용할 수 있는 능력은 퍼블릭 클라우드 서비스의 중요한 이점이 되었습니다. 그러나 효과적인 관리 없이는 책임으로 바뀔 수도 있습니다. 몇 분 안에 추가 인프라에 액세스할 수 있다는 것은 부인할 수 없는 매력입니다. 그러나 이를 효과적으로 수행하려면 수요를 충족하기 위해 어떤 유형의 확장성이 필요한지, 구체적인 사용 사례는 무엇인지, 비용을 꼼꼼하게 모니터링하는 방법은 무엇인지에 대한 결정을 내려야 합니다.

인프라 확장성은 필요에 따라 리소스를 정적으로 추가하거나 제거하여 애플리케이션의 변화하는 요구 사항을 처리함으로써 애플리케이션의 변화하는 요구 사항을 충족합니다. 대부분의 경우 스케일업(수직 확장) 및/또는 스케일아웃(수평 확장)을 통해 처리합니다. 클라우드 확장성에 대한 많은 연구와 아키텍처 개발이 이루어졌으며, 이는 클라우드 확장성의 작동 방식과 새로운 Kubernetes 또는 클라우드 네이티브 애플리케이션을 위한 아키텍처의 많은 영역을 다루고 있습니다. 이 글에서는 먼저 스케일업과 스케일아웃을 비교하는 데 초점을 맞추고자 합니다.

수직 확장이라고도 하는 스케일업은 원하는 성능 상태에 도달하기 위해 기존 시스템에 더 많은 리소스를 추가하는 방식으로 이루어집니다. 예를 들어 데이터베이스나 웹 서버가 서비스 수준 협약(SLA)을 충족하기 위해 특정 수준의 성능을 계속 유지하려면 추가 리소스가 필요합니다. 해당 시스템에 CPU, 메모리, 스토리지 또는 네트워크를 더 추가하여 성능을 원하는 수준으로 유지할 수 있습니다.

클라우드에서 이 작업을 수행할 때 애플리케이션은 종종 더 강력한 인스턴스나 가상 머신으로 이동되며, 다운타임을 최소화하기 위해 다른 호스트로 마이그레이션한 다음 사용하던 서버를 폐기할 수도 있습니다. 물론 이 과정은 고객에게 투명하게 공개되어야 합니다.

소프트웨어에서도 더 많은 스레드, 더 많은 연결을 추가하거나 데이터베이스 애플리케이션의 경우 캐시 크기를 늘리는 방식으로 스케일업을 수행할 수 있습니다. 이러한 유형의 확장 작업은 수십 년 동안 데이터 센터의 온프레미스에서 수행되어 왔습니다. 그러나 특정 시스템을 확장하기 위해 추가 리소스를 확보하는 데 걸리는 시간은 기존 온프레미스 환경에서는 몇 주 또는 몇 달이 걸리는 반면, 클라우드에서는 단 몇 분이면 충분하기 때문에 가격 모델에 영향을 미칠 수 있습니다.

스케일아웃은 일반적으로 분산 아키텍처와 관련이 있습니다. 스케일아웃에는 두 가지 기본 형태가 있습니다.

• 사전 패키지된 인프라 또는 노드 블록에 인프라 용량 추가(예: 하이퍼컨버지드)
• 고객 정보를 검색할 수 있지만 애플리케이션이나 서비스와는 독립적인 분산 서비스를 사용하여 성능 문제를 해결하고 클라우드 컴퓨팅 리소스를 최적화합니다.

두 가지 접근 방식은 오늘날 CSP(클라우드 서비스 공급자)에서 개별 구성 요소(컴퓨팅, 메모리, 네트워크, 스토리지)에 대한 수직 확장(스케일업)과 함께 비용을 절감하기 위해 사용됩니다. 수평적 확장(스케일아웃)을 통해 서비스 공급자는 '성장에 따라 지불하는' 인프라와 서비스를 쉽게 제공할 수 있어 가격 전략에 영향을 미칩니다.

하이퍼 컨버지드 인프라는 프라이빗 클라우드 및 티어 2 서비스 공급자에서도 점점 더 많이 사용되고 있습니다. 이 접근 방식은 다른 형태의 분산 아키텍처만큼 느슨하게 결합되어 있지는 않지만, 기존 아키텍처에 익숙한 IT 관리자가 수평적 확장으로 전환하고 관련 비용 이점을 실현하는 데 도움이 됩니다.

느슨하게 결합된 분산 아키텍처는 아키텍처의 각 부분을 독립적으로 확장할 수 있어 병목 현상을 효과적으로 제거할 수 있습니다. 즉, 소프트웨어 제품 그룹이 함께 작동하여 전체 워크플로를 관리하더라도 독립적인 조각으로 생성 및 배포할 수 있습니다. 각 애플리케이션은 독립적으로 기능하고 작동할 수 있는 추상화된 서비스 모음으로 구성됩니다. 이를 통해 제품 수준은 물론 서비스 수준에서도 수평적 확장이 가능합니다. SLA 또는 고객 유형(예: 브론즈, 실버 또는 골드) 또는 특정 API에 대한 수요 수준이 다른 경우 API 유형별로 더 세분화된 확장 기능을 구분할 수 있습니다. 이렇게 하면 주어진 인프라 내에서 확장성을 효율적으로 사용할 수 있습니다.

서비스 공급자는 성능과 효율성에 중점을 두고 진화하는 고객의 요구 사항을 충족하기 위해 지속적으로 인프라를 맞춤화해 왔습니다. 주목할 만한 예로는 리소스 사용량을 실제 요구 사항에 맞게 조정하여 사용자가 실제로 사용한 만큼만 요금이 청구되도록 하는 AWS Auto-Scaling을 들 수 있습니다. 이 접근 방식은 비용 절감에 상당한 잠재력을 가지고 있지만 복잡한 청구서를 해독하는 것이 어려울 수 있습니다.

바로 이 지점에서 IBM Turbonomic이 클라우드 청구를 간소화하여 지출에 대한 명확한 인사이트를 제공하고, 스케일업 또는 스케일아웃 전략에 대한 올바른 정보에 기반한 의사 결정을 지원하여 더 큰 비용 절감으로 이어질 수 있도록 합니다. Turbonomic은 두 환경에 대한 비용 모델링과 마이그레이션 계획을 제공하여 최적의 워크로드 성능과 효율성을 보장하는 동시에 성능 문제를 완화함으로써 온프레미스 및 오프프레미스 인프라 전반에서 IT 관리를 위한 예산 할당을 간소화합니다.

오늘날의 클라우드 서비스 제공업체에게 느슨하게 결합된 분산 아키텍처는 클라우드에서 확장하는 데 매우 중요하며, 클라우드 자동화와 결합하여 고객에게 비즈니스 요구 사항에 가장 적합한 수직적 또는 수평적 확장을 위한 다양한 옵션을 제공합니다. Turbonomic은 특정 스토리지 시스템 요구사항에 맞춰 클라우드 여정에서 최상의 옵션을 선택할 수 있도록 도와드립니다.