컴퓨팅 리소스 크기 조정
클라우드의 중요한 장점 중 하나는 주문형 시스템으로 리소스를 확장할 수 있다는 것입니다. 강화(대규모 리소스 프로비저닝) 또는 확장(추가 리소스 프로비저닝)은 용량 증가 또는 워크로드의 광범위한 분배로 인한 사용률을 줄임으로써 시스템의 부하를 줄일 수 있습니다.
크기 조정은 더 많은 수의 요청을 처리할 수 있으므로 처리량을 증가하여 응답성(및 사용자 관점에서 인식된 성능)을 향상시킬 수 있습니다. 또한 단일 리소스에 대한 최대 부하 중에 줄어든 요청 수가 큐에 대기하므로 최대 부하 중에 대기 시간을 줄일 수 있습니다. 크기 조정은 리소스 사용률을 줄이고 한계점에 근접하지 않도록 하여 시스템의 안정성을 향상시킬 수 있습니다.
클라우드를 통해 새롭거나 더 나은 최신 리소스를 쉽게 프로비저닝할 수 있지만 비용은 항상 고려해야 하는 반대 요소라는 점에 유의해야 합니다. 따라서 규모 확대 또는 확장이 유리하지만 비용을 절감하기 위해서는 규모를 축소하거나 감축할 시기를 인식하는 것도 중요합니다.
수평 확장(규모 감축/확장)
수평 확장은 시스템에 추가 리소스를 추가하거나 시간이 지남에 따라 외부 리소스를 시스템에서 제거하는 전략입니다. 해당 유형의 확장은 시스템의 부하가 일관되지 않거나 예측할 수 없는 방식으로 변동될 때 서버 계층에 유리합니다. 변동하는 부하의 특성으로 인해 항상 부하를 처리할 수 있는 정확한 양의 리소스를 프로비저닝해야 합니다.
이 과제를 해결하기 위한 몇 가지 고려 사항은 다음과 같습니다.
- 인스턴스의 실행 시간(예: 가상 머신)
- 클라우드 서비스 공급자의 가격 책정 모델
- 제시간에 확장하지 않아 QoS(서비스 품질) 저하로 이어진 잠재적 매출 손실
그림 5: 샘플 부하 패턴입니다.
예를 들어 위의 그림 5에 있는 부하 패턴을 살펴보겠습니다.
Amazon Web Services를 사용하는 경우 각 시간 단위는 실제 1시간과 같으며 5,000개의 요청을 처리하기 위해 하나의 서버가 필요합니다. 시간 단위 6과 8 및 시간 단위 14와 16 사이의 최대 수요 예제로 후자를 살펴보겠습니다. 시간 단위 16에 대한 수요 감소를 감지하고 할당된 리소스 수를 줄이기 시작할 수 있습니다. 계산하면 3시간 동안 약 90,000개에서 10,000개의 요청이 진행되므로 시간 단위 15에 온라인 상태였던 12개 이상의 추가 인스턴스 비용을 절약할 수 있습니다.
그림 6은 인스턴스 수를 빨간색으로 표시한 부하 패턴과 일치하도록 인스턴스 수를 즉시 조정하는 확장 패턴을 보여 줍니다. 최대 수요 시간대에는 트래픽 처리에 필요한 리소스를 제공하기 위해 인스턴스 수를 각각 20 및 18로 확장합니다. 그 외 시간에는 리소스 사용률을 비교적 일정하게 유지하기 위해 인스턴스 수가 감소(감축)됩니다. 각 인스턴스 비용이 시간당 20센트라고 가정하면 24시간 동안 20개의 인스턴스를 실행하는 데 드는 비용은 96달러입니다. 표시된 대로 인스턴스 수를 조정하면 연간 15,000달러가 넘는 절감 비용이 약 42달러로 줄어듭니다. 해당 금액은 거의 모든 IT 예산에 상응하는 금액입니다.
그림 6: 수요에 따른 규모 감축 및 확장
크기 조정은 웹 서비스에서 생성된 트래픽 및 결과 부하의 특징에 따라 다릅니다. 트래픽이 예측 가능한 패턴을 따르는 경우, 예를 들어 저녁에 웹 서비스에서 영화를 스트림하는 것과 같은 사용자 동작을 기반으로 하는 경우에는 스케일링을 예측하여 QoS를 유지 관리할 수 있습니다. 그러나 대부분의 경우 트래픽을 예측할 수 없으며 스케일링 시스템은 다른 기준에 따라 대응해야 합니다.
컨테이너 인스턴스와 VM 인스턴스를 사용하여 규모 감축 및 확장을 수행할 수 있습니다. 워크로드는 일반적으로 VM의 클라우드에서 실행되지만 컨테이너에서 실행하는 것이 점점 더 많이 보편화되고 있습니다. 크기 조정은 VM 수를 늘리고 줄이는 방식으로 VM 기반 워크로드를 통해 수행됩니다. 마찬가지로, 컨테이너 수를 변경하여 컨테이너 기반 워크로드를 크기 조정할 수 있습니다. 컨테이너는 VM보다 더 빠르게 시작되는 경향이 있기 때문에 VM 인스턴스보다 짧은 시간 내에 새 컨테이너 인스턴스를 온라인 상태로 만들 수 있으므로 탄력성은 약간 더 큽니다.
수직 확장(규모 확대 및 축소)
수평 확장은 탄력성을 실현하는 한 가지 방법이지만 유일한 방법은 아닙니다. 웹 사이트에 대한 트래픽이 시간 단위당 약 15,000개의 요청을 초과하고, 20,000개의 요청을 처리할 수 있는 단일 대규모 인스턴스를 프로비저닝한다고 가정해 보겠습니다. 즉, 정상 트래픽을 처리할 수 있을 만큼 충분한 최대치뿐만 아니라 사소한 최대치도 고려합니다. 웹 사이트의 부하가 증가하면 두 배의 CPU 코어와 두 배의 RAM이 있는 서버 인스턴스로 교체하여 트래픽 증가를 합리적으로 수용할 수 있습니다. 이 작업을 규모 확대라고 합니다.
수직 확장의 주요 과제는 일반적으로 중단 시간으로 간주할 수 있는 몇 가지 전환 시간이 있다는 것입니다. 이는 모든 작업을 소규모 인스턴스에서 대규모 인스턴스로 이동하기 위해 전환 시간이 단 몇 분이더라도 해당 간격 동안 서비스 품질이 저하되기 때문입니다.
수직 확장의 또 다른 제한 사항은 세분성이 줄었다는 것입니다. 온라인 상태인 10개의 서버 인스턴스가 있고 용량을 10%씩 일시적으로 늘려야 하는 경우 10개의 인스턴스에서 11개로 확장하여 원하는 결과를 얻을 수 있습니다. 그러나 수직 확장의 경우 다음으로 큰 인스턴스 크기는 일반적으로 이전 인스턴스 용량의 약 2배이며, 트래픽의 10% 증가를 수용하기 위해 인스턴스를 10개에서 20개로 수평 확장하는 것과 같습니다. 즉, 수평으로 확장하는 것보다 비용 효율성이 낮습니다.
수직 확장에 대한 최종 고려 사항은 가용성입니다. 모든 웹 사이트 고객에게 서비스를 제공하는 하나의 대규모 인스턴스가 있고 해당 인스턴스가 다운되면 웹 사이트도 다운됩니다. 이와는 대조적으로 동일한 부하를 처리하기 위해 10개의 소규모 인스턴스를 프로비저닝하고 그중 하나가 다운되는 경우, 성능이 약간 저하될 수 있지만 사용자는 계속해서 사이트에 액세스할 수 있습니다. 결과적으로 서비스의 인기가 높아짐에 따라 부하를 예측할 수 있고 꾸준히 증가하더라도 많은 클라우드 관리자는 수직 확장이 아닌 수평 확장을 선택합니다.
서버 계층 크기 조정
확장성은 단순히 더 많은 리소스를 프로비저닝(확장)하거나 리소스를 늘리는(확대) 것보다 미묘한 차이가 있습니다. 서버 계층에서 수요를 늘리면 CPU, 메모리, 네트워크 대역폭 등의 특정 리소스 유형에 대한 경쟁이 증가할 수 있습니다. 클라우드 서비스 공급자는 일반적으로 컴퓨팅, 메모리 및 네트워크를 많이 사용하는 워크로드에 최적화된 VM을 제공합니다. 워크로드를 파악하고 올바른 유형의 VM을 선택하는 것은 문제에 더 많거나 더 큰 VM을 발생시키는 것만큼이나 중요합니다. CPU를 많이 사용하는 워크로드에 최적화된 VM이 일반 VM보다 20% 더 많은 비용이 들더라도 컴퓨팅이 많은 워크로드를 처리하는 5개의 VM을 사용하는 것이 좋습니다.
서비스 성능을 향상하기 위해 항상 하드웨어 리소스를 늘리는 것이 최선의 솔루션은 아닙니다. 서비스에서 사용하는 알고리즘의 효율성을 높이면 리소스 경합을 줄이고 활용도를 향상하여 물리적 리소스를 확장할 필요가 없습니다.
크기를 조정하는 데 중요한 고려 사항은 상태 저장(또는 부족) 서비스입니다. 상태 비저장 서비스 디자인은 확장 가능한 아키텍처에 적합합니다. 상태 비저장 서비스는 기본적으로 클라이언트 요청에 서버에서 요청을 처리하는 데 필요한 모든 정보가 포함되어 있음을 의미합니다. 서버는 인스턴스에 클라이언트 관련 정보를 저장하지 않으며 서버 인스턴스에 세션 관련 정보를 저장합니다.
상태 비저장 서비스를 사용하면 후속 요청에 대한 클라이언트 연결의 컨텍스트(상태)를 유지하는 데 필요한 구성 없이도 원하는 대로 리소스를 전환할 수 있습니다. 상태 저장 서비스인 경우 리소스를 확장하려면 기존 구성에서 새 구성으로 컨텍스트를 전송하는 전략이 필요합니다. 상태 저장 서비스를 구현하는 기술이 있습니다(예: 네트워크 캐시를 유지 관리하여 컨텍스트를 서버 간에 공유할 수 있음).
데이터 계층 크기 조정
데이터베이스 또는 스토리지 시스템에 대한 읽기 및 쓰기(또는 둘 다) 수가 많은 데이터 지향 애플리케이션에서 각 요청의 왕복 시간은 종종 하드 디스크 읽기 및 쓰기 시간에 의해 제한됩니다. 인스턴스가 클수록 I/O 성능이 향상되어 하드 디스크의 탐색 시간이 향상되고 서비스 대기 시간이 줄어듭니다. 데이터 계층에 여러 데이터 인스턴스가 있으면 장애 조치(failover) 중복성을 제공하여 애플리케이션의 안정성과 가용성을 향상시킬 수 있지만, 여러 인스턴스에서 데이터를 복제하면 클라이언트가 데이터 센터에서 물리적으로 더 가까운 곳에 서비스를 제공하는 경우 네트워크 대기 시간을 줄이는 데 추가적인 이점이 있습니다. 여러 리소스에서 데이터를 분할 또는 파티셔닝하는 것은 또 다른 수평 데이터 확장 전략으로, 여러 인스턴스에서 데이터를 단순히 복제하는 대신 데이터를 세그먼트로 분할하여 여러 데이터 서버에 저장합니다.
데이터 계층을 크기 조정할 때의 또 다른 과제는 일관성 유지(모든 복제본에 대한 읽기 작업이 동일함), 가용성(읽기 및 쓰기 항상 성공) 및 파티션 허용 오차(장애가 노드 간 통신을 방해할 때 시스템의 보장된 특성 유지) 등이 있습니다. 이를 CAP 정리라고도 합니다. 분산 데이터베이스 시스템에서 세 가지 속성을 모두 가져오는 것이 매우 어렵기 때문에 대부분의 속성을 조합하여 나타낼 수 있습니다.1
참고 자료
- Wikipedia. CAP Theorem. https://en.wikipedia.org/wiki/CAP_theorem.