리소스 스케일링
클라우드의 중요한 장점 중 하나는 주문형 시스템으로 리소스를 확장할 수 있다는 것입니다. 스케일링 업(더 큰 리소스 프로비저닝) 또는 스케일링 아웃(추가 리소스 프로비저닝)은 용량을 늘리거나 워크로드를 광범위하게 분산하여 사용률을 줄임으로써 시스템의 부하를 줄이는 데 도움이 됩니다.
스케일링은 더 많은 요청을 처리할 있도록 처리량을 늘려 성능을 개선하는 데 도움이 됩니다. 또한 단일 리소스에 대한 최대 부하 중에 줄어든 요청 수가 큐에 대기하므로 최대 부하 중에 대기 시간을 줄일 수 있습니다. 뿐만 아니라 이를 통해 리소스 사용률을 낮추면 리소스 한계점에서 더욱 멀어지므로 시스템의 안정성을 높일 수 있습니다.
클라우드를 통해 새롭거나 더 나은 최신 리소스를 쉽게 프로비저닝할 수 있지만 비용은 항상 고려해야 하는 반대 요소라는 점에 유의해야 합니다. 따라서 스케일 업/아웃이 유리하지만 비용 절감을 위해 스케일 다운/인이 필요한 시기를 인식하는 것도 중요합니다. N 계층 애플리케이션에서는 병목 상태의 정확한 위치와 스케일링할 계층(데이터 계층 또는 서버 계층)을 정확하게 파악하는 것이 중요합니다.
리소스 스케일링은 부하 분산을 통해 쉽게 수행할 수 있으며(이에 대해서는 앞에서 설명), 이렇게 하면 스케일링을 일관적인 엔드포인트 뒤에 숨겨 시스템의 스케일링 측면을 마스킹하는 데 도움이 됩니다.
스케일링 전략
수평 스케일링(스케일 아웃/인)
수평 스케일링은 시스템에 리소스를 추가하거나 아무 관련이 없는 리소스를 시스템에서 제거하는 전략입니다. 이러한 유형의 스케일링은 시스템의 부하가 불규칙하게 변하여 예측할 수 없는 서버 계층에 도움이 됩니다. 부하의 변동성 때문에 항상 부하를 처리할 수 있는 정확한 양의 리소스를 프로비저닝해야 합니다.
이 전략을 사용하기 까다로운 이유는 인스턴스의 스핀업 시간, 클라우드 서비스 공급자의 가격 책정 모델, 시간이 지나도 스케일 아웃을 하지 않아 QoS(서비스 품질) 저하로 인한 잠재적 수익 하락을 고려해야 하기 때문입니다. 예를 들어 다음 부하 패턴을 생각해 봅시다.
그림 6: 샘플 요청 부하 패턴
Amazon Web Services를 사용하고 있다고 가정하겠습니다. 또한 각 시간 단위는 실제 시간으로 3시간과 같으며 5k 요청을 처리하려면 서버 한 대가 필요한 것으로 가정하겠습니다. 16~22시간 단위의 부하를 생각해 보면 부하에 엄청난 변동이 있습니다. 16시간 단위 근처에서 수요가 감소하는 것을 감지하여 할당된 리소스 수를 줄일 수 있습니다. 3시간 동안 요청 수가 약 50k에서 거의 0까지 내려가므로, 이론적으로는 16시간 단위에 발생할 10개 인스턴스 비용을 절감할 수 있습니다.
이제 각 시간 단위가 실제 시간의 20분과 같다고 가정해 보겠습니다. 이 경우에는 20분 후 새 리소스만 스핀업하도록 16시간 단위에서 모든 리소스를 스핀다운하면 비용이 감소하는 것이 아니라 오히려 증가합니다. AWS는 각 컴퓨팅 인스턴스에 시간당 요금을 청구하기 때문입니다.
위의 두 가지 고려 사항 외에도, 서비스 공급자는 요청 용량이 100k가 아닌 90k이면 20시간 단위 동안 QoS 저하로 인해 발생하게 될 손실까지 평가해야 합니다.
스케일링은 웹 서비스에서 생성된 트래픽 및 결과 부하의 특징에 따라 다릅니다. 트래픽이 예측 가능한 패턴을 따르는 경우, 예를 들어 저녁에 웹 서비스에서 영화를 스트리밍하는 것과 같은 사용자 동작을 기반으로 하는 경우에는 스케일링을 예측하여 QoS를 유지 관리할 수 있습니다. 그러나 대부분의 경우 위의 예제처럼 트래픽을 예측할 수 없으며, 스케일링 시스템은 여러 조건에 따라 대응해야 합니다.
수직 스케일링(스케일 업/다운)
서비스 공급자가 다른 부하보다 쉽게 예측 가능한 유형의 부하가 있습니다. 예를 들어 과거의 패턴을 분석하여 요청 수가 항상 10k-15k라는 것을 알 수 있다면 20k 요청을 처리할 수 있는 서버 한 대면 서비스 공급자의 목표를 달성하기에 충분하다고 자신할 수 있습니다. 향후 부하가 증가할 수도 있지만, 일정하게 증가한다면 더 많은 요청을 처리할 수 있는 더 큰 인스턴스로 서비스를 이동하면 됩니다. 트래픽 양이 적은 소형 애플리케이션에 적합합니다.
수직 스케일링의 과제는 가동 중지 시간으로 간주할 수 있는 전환 시간이 언제나 약간은 있다는 점입니다. 모든 작업을 작은 인스턴스에서 더 큰 인스턴스로 이동하는 전환 시간이 단 몇 분이라도 발생하므로 그 시간 동안 QoS가 저하되기 때문입니다.
뿐만 아니라 대부분의 클라우드 공급자는 리소스의 컴퓨팅 성능을 두 배로 높여 컴퓨팅 성능을 향상시키는 컴퓨팅 리소스를 제공합니다. 따라서 스케일 업의 세분성은 수평 스케일링만큼 세밀하지 않습니다. 이러한 이유로 서비스의 인기가 높아지면서 부하를 예측할 수 있고 부하가 꾸준히 증가하더라도 많은 서비스 공급자는 수직 스케일링 대신 수평 스케일링을 선택합니다.
스케일링 시 고려 사항
모니터링
시스템의 어떤 부분을 언제 스케일링해야 하는지 해석하는 데 사용되는 메트릭을 얻을 수 있는 모니터링은 효과적인 리소스 스케일링을 위해 가장 중요한 요소 중 하나입니다. 모니터링을 통해 트래픽 패턴 또는 리소스 사용률을 분석하면 수익을 보전하면서도 QoS를 최대화하려면 리소스를 언제, 얼마나 스케일링해야 하는지 충분한 정보를 바탕으로 평가할 수 있습니다.
리소스 스케일링을 트리거하기 위해 리소스의 몇 가지 측면을 모니터링합니다. 가장 일반적인 메트릭은 리소스 사용률입니다. 예를 들어 모니터링 서비스는 각 리소스 노드의 CPU 사용률을 추적하고 사용량이 지나치게 많거나 적은 경우 리소스를 스케일링할 수 있습니다. 각 리소스의 사용률이 95%를 초과하면 시스템이 과부하 상태이므로 리소스를 추가하는 것이 좋습니다. 일반적으로 서비스 공급자는 리소스 노드의 한계점을 분석하고, 장애가 발생하기 시작하는 시점을 확인하고, 다양한 부하 수준에서 동작을 매핑하여 트리거 지점을 결정합니다. 비용상의 이유로 각 리소스를 최대한 활용하는 것이 중요하지만, 운영 체제에서 오버헤드 활동을 허용할 수 있도록 약간의 여유를 두는 것이 좋습니다. 마찬가지로 사용률이 50% 미만이면 모든 리소스 노드가 필요한 것은 아니며 일부는 프로비저닝을 해제해도 됩니다.
실제로 서비스 공급자는 일반적으로 리소스를 스케일링할 시기를 평가하기 위해 여러 가지 리소스 노드 메트릭 조합을 모니터링합니다. 여기에는 CPU 사용률, 메모리 사용량, 처리량 및 대기 시간이 포함됩니다. Azure는 Azure 리소스를 모니터링하고 이러한 메트릭을 제공할 수 있는 추가 서비스로 Azure Monitor를 제공합니다.
상태 비저장
상태 비저장 서비스 디자인은 확장성 있는 아키텍처에 적합합니다. 상태 비저장 서비스는 기본적으로 클라이언트 요청에 서버에서 요청을 처리하는 데 필요한 모든 정보가 포함되어 있음을 의미합니다. 서버는 인스턴스에 클라이언트 관련 정보를 저장하지 않고 서버 인스턴스에 세션 관련 정보를 저장합니다.
상태 비저장 서비스를 사용하면 후속 요청에 대한 클라이언트 연결의 컨텍스트(상태)를 유지하는 데 필요한 구성 없이도 원하는 대로 리소스를 전환할 수 있습니다. 상태 저장 서비스인 경우 리소스를 스케일링하려면 기존 노드 구성에서 새 노드 구성으로 컨텍스트를 전송하는 전략이 필요합니다. 상태 저장 서비스를 구현하는 기술이 있습니다. 예를 들어 Memcached를 사용하여 네트워크 캐시를 유지하면 컨텍스트를 서버 간에 공유할 수 있습니다.
스케일링 대상 결정
서비스의 특성을 고려하여 요구 사항에 따라 다양한 리소스를 스케일링해야 합니다. 서버 계층의 경우 워크로드가 증가하면 애플리케이션 유형에 따라 CPU, 메모리, 네트워크 대역폭 또는 세 가지 모두 리소스 경합이 늘어날 수 있습니다. 트래픽을 모니터링하면 제약을 받는 리소스를 파악하여 해당 리소스를 적절하게 스케일링할 수 있습니다. 클라우드 서비스 공급자는 컴퓨팅 또는 메모리만 스케일링할 수 있도록 확장성 세분성을 반드시 제공할 필요는 없지만, 컴퓨팅 또는 메모리 집약적 부하에 특별히 리소스를 공급하는 다양한 유형의 컴퓨팅 인스턴스를 제공합니다. 따라서 예를 들어 메모리를 많이 사용하는 애플리케이션의 경우 리소스를 메모리 최적화 인스턴스로 스케일 업하는 것이 좋습니다. 컴퓨팅 또는 메모리를 꼭 많이 사용하지는 않는 수많은 요청을 처리해야 하는 애플리케이션의 경우 여러 표준 컴퓨팅 인스턴스를 스케일 아웃하는 것이 더 나은 전략이 될 수 있습니다.
서비스 성능을 높이기 위해 하드웨어 리소스를 늘리는 것이 항상 최선의 솔루션은 아닙니다. 서비스 내에서 사용되는 알고리즘의 효율성을 높여서 리소스 경합을 줄이고 사용률을 높이면 물리적 리소스를 스케일링할 필요가 없습니다.
데이터 계층 스케일링
데이터베이스 또는 스토리지 시스템에 대한 읽기 및 쓰기(또는 둘 다) 수가 많은 데이터 지향 애플리케이션에서 각 요청의 왕복 시간은 종종 하드 디스크 I/O 읽기 및 쓰기 시간에 의해 제한됩니다. 인스턴스가 클수록 읽기 및 쓰기에 높은 I/O 성능을 허용하므로 하드 디스크 탐색 시간이 향상되고, 결과적으로 서비스 대기 시간이 대폭 개선될 수 있습니다. 데이터 계층에 여러 데이터 인스턴스가 있으면 장애 조치(failover) 중복성을 제공하여 애플리케이션의 안정성과 가용성을 높일 수 있습니다. 여러 인스턴스에 데이터를 복제하면 클라이언트와 물리적으로 더 가까이에 있는 데이터 센터에서 서비스를 제공하는 경우 네트워크 대기 시간을 줄이는 추가적인 장점이 있습니다. 여러 리소스에 걸쳐 데이터를 분할 또는 파티셔닝하는 것은 또 다른 수평 데이터 스케일링 전략으로, 데이터를 여러 인스턴스에 단순히 복제하는 대신 데이터를 여러 파티션으로 분할하여 여러 데이터 서버에 저장합니다.
데이터 계층을 스케일링할 때의 또 다른 과제는 일관성(모든 복제본에 대한 읽기 작업이 동일함), 가용성(읽기 및 쓰기가 항상 성공) 및 파티션 내결함성(장애로 인해 노드 간 통신이 불가능할 때 시스템의 속성을 유지하도록 보장)을 유지하는 것입니다. 이를 CAP 정리라고도 하며, 분산 데이터베이스 시스템에서 세 가지 속성을 온전히 가져오는 것이 매우 어렵기 때문에 시스템에서는 많아봐야 두 가지 속성을 조합하여 나타낼 수 있습니다. 이후 모듈에서 데이터베이스 스케일링 전략 및 CAP 정리에 대해 자세히 설명하겠습니다.