클라우드 서버 벤치마킹: 클라우드 컴퓨팅 내부자 가이드

많은 신규 고객들이 CloudSigma를 처음 사용하기 시작할 때 성능을 테스트하고 싶어 합니다. 이들은 종종 클라우드 서버와 자체 인프라 간의 성능 결과를 벤치마킹하고자 하며, 이는 당연한 일입니다. 리소스별 단순 가격 비교는 전체 상황을 온전히 보여주지 못합니다. 정말 중요한 것은 최종 결과, 즉 특정 컴퓨팅 작업을 수행하는 데 비용이 얼마나 드는가입니다.

주어진 요구사항에 대해 이를 달성하는 데 필요한 리소스의 수는 클라우드마다 크게 다를 수 있습니다. 이는 단순히 가격만 비교하는 것은 효과가 없음을 의미합니다. 반대로 성능만 단독으로 비교하는 것도 나을 것이 없습니다. 의미 있는 비교를 하려면 가격과 성능을 모두 결합하여 컴퓨팅 단위당 비용을 계산해야 합니다. 이 글에서는 당사의 클라우드 서버와 타사 서버를 벤치마킹하며 느낀 몇 가지 생각을 공유하고자 합니다. 또한 유용한 결과를 얻기 위한 몇 가지 팁과 그 결과가 실제로 무엇을 의미하는지도 알려드리겠습니다.

주의 사항

먼저 설명해 드리자면, 저는 일반적으로 벤치마킹에 대해 상당히 회의적입니다. 벤치마킹이 실제 사용 환경에 대한 진정한 통찰력을 제공하는 경우는 드뭅니다. 요약하자면, 플랫폼에서 사용하려는 실제 애플리케이션을 실행해 보는 것을 대체할 수 있는 것은 없습니다. 시간 측면에서 합리적인 비용으로 이를 수행할 수 있다면, 그러한 실행을 대체할 수 있는 것은 없습니다.

또 다른 요인은 클라우드 제공업체가 얼마나 바쁜지(사용량이 많은지)입니다. 클라우드 서버를 벤치마킹하여 우수한 결과를 얻을 수도 있습니다. 하지만 이는 주로 해당 특정 제공업체의 사용량 수준(또는 사용량 부족) 때문일 수 있습니다. 이는 긍정적인 신호가 아닐 수 있습니다. 운영상의 어려움, 고객 이탈, 과거의 가용성 및 신뢰성 문제 등을 반영하는 것일 수 있습니다. 따라서 벤치마크 결과를 해석할 때는 항상 해당 클라우드 제공업체의 과거 장애 이력 및 기타 잠재적인 문제를 조사해야 합니다.

마지막 주의 사항으로, 성능만이 고려해야 할 유일한 요인은 아닙니다. 종종 낮은 성능은 그 이면에 더 견고하고 이중화된 하드웨어 아키텍처가 있음을 반영할 수 있습니다. 따라서 클라우드가 어떤 인프라를 기반으로 구축되었는지 매우 명확하게 이해하는 것이 항상 중요합니다. 그래야 결과를 공정하게 비교하여 의미 있는 구매 결정을 내릴 수 있습니다.

문제 정의

이 글의 뒷부분에서 성능의 다양한 측면과 결과를 해석하는 가장 좋은 방법에 대해 설명하겠습니다. 하지만 벤치마킹을 수행하기 전에 클라우드에서 수행하려는 컴퓨팅의 종류를 특징짓는 것이 중요합니다. 이는 다양한 성능 지표의 상대적 중요성을 결정하기 때문입니다. 예를 들어, 데이터베이스 서버를 배치하려는데 읽기 액세스는 많고 쓰기 액세스는 적은 경우, 클라우드의 디스크 성능, 특히 비순차적 읽기 액세스에 주의를 기울여야 합니다.

따라서 클라우드 서버 벤치마킹을 시작하기 전에 실제로 클라우드에서 좋은 성능이라고 생각하는 기준을 명문화하십시오. 어떤 측면이 핵심이며 실제 컴퓨팅 성능에 불균형적으로 큰 영향을 미치는지 결정해야 합니다. 이에 대한 명확한 개념이 서면 벤치마킹을 시작할 준비가 된 것입니다.

컴퓨팅 성능

순수한 컴퓨팅 성능을 볼 때 우리는 CPU와 RAM을 이야기합니다. 클라우드 간의 순수한 컴퓨팅 수준에서의 성능 차이는 사실 그리 크지 않습니다. 그러나 실제 차이를 만들어내는 몇 가지 요인이 있습니다.

클라우드에서 컴퓨팅 성능에 영향을 미치는 단연 가장 큰 요인은 경합입니다. 퍼블릭 클라우드는 멀티테넌트 환경입니다. RAM과 스토리지는 실제로 초과 할당될 수 없지만(초과 판매될 수는 있음), CPU는 초과 할당될 수 있으며 실제로 그렇게 되고 있습니다. 경합 수준은 상당히 다양하지만, 본질적으로 퍼블릭 클라우드 제공업체는 물리적 호스트의 CPU 용량을 100% 이상으로 판매할 수 있습니다.

일부 대형 제공업체는 3배가 넘는 CPU 경합률을 사용합니다. 이는 동일한 물리적 머신에 있는 모든 가상 서버의 총 ‘판매된’ CPU 용량이 실제 CPU 용량의 3배에 달할 수 있음을 의미합니다. 대부분의 가상 서버가 대부분의 시간 동안 할당된 CPU의 100%에 가까운 용량을 사용하지 않기 때문에 이렇게 하는 것입니다. 그럼에도 불구하고 경합률은 클라우드 서버 성능 벤치마크와 실제 사용에 직접적인 영향을 미칩니다. 경합이 높으면(즉, CPU 할당량이 200% 이상인 경우) 클라우드 서버 성능이 크게 저하됩니다.

간단히 말해, 물리적 머신의 부하가 코어당 1을 초과하면 컴퓨팅 작업이 대기열에 추가되고 해당 가상 머신이 작업을 완료하는 데 걸리는 시간이 더 길어집니다. 대부분의 클라우드가 용량/시간 기준으로 요금을 부과한다는 점을 감안할 때, 이는 해당 클라우드 고객에게 직접적인 비용 영향을 미칩니다.

컴퓨팅 성능에 영향을 미치는 또 다른 중요한 요인은 가상 머신이 액세스할 수 있는 CPU 코어 수입니다. 이것이 모든 애플리케이션에 해당하는 요인은 아니지만, 많은 현대적인 애플리케이션은 멀티스레딩을 지원합니다. 실질적으로 이는 애플리케이션 및/또는 운영 체제가 컴퓨팅 작업을 여러 코어에 분산할 수 있음을 의미합니다. 컴퓨팅 성능을 향상시키는 한 가지 유용한 팁은 애플리케이션이 지원할 수 있는 스레드(즉, 코어) 수와 가상 머신이 액세스할 수 있는 코어 수를 일치시키는 것입니다.

안타깝게도 많은 퍼블릭 클라우드에서는 이것이 불가능합니다. 가상화 플랫폼이 CPU 코어 수준에서의 가상화를 지원하지 않기 때문입니다. 즉, 각 코어는 한 번에 하나의 가상 머신만 사용할 수 있습니다. CPU 코어 가상화를 지원하는 클라우드에서는 전체 CPU 크기를 동일하게 유지하면서 해당 머신의 코어 수를 다양하게 변경하는 실험을 해보아야 합니다.

예를 들어, 2GHz 머신이 있는 경우 사용 중인 코어를 2개에서 4개로 두 배로 늘렸을 때 벤치마킹에 어떤 영향을 미치는지 확인할 수 있습니다. 이렇게 하면 해당 가상 머신에서 실행되는 애플리케이션이 동시에 4개의 코어를 통해 작업을 실행할 수 있습니다. 저희의 경우, 웹 콘솔의 서버 상세 모달에 있는 ‘고급’ 탭을 통해 가상 머신이 사용하는 코어 수를 설정할 수 있습니다. 사용 중인 코어 수를 수동으로 덮어쓰기 전에 항상 클라우드 공급업체의 표준 코어 크기가 얼마인지 확인해야 한다는 점을 기억하세요. 저희의 경우 코어당 2.2GHz이지만 이는 클라우드마다 다릅니다.

클라우드 서버 성능 벤치마킹을 위해 POV-RAY, CoreMark, Dhrystone 또는 Whetstone 등의 사용을 고려해 보실 것을 권장합니다.

스토리지: 실제 클라우드 서버 성능 벤치마크

모든 성능은 병목 현상이 발생하는 가장 취약한 링크에 의해 제한됩니다. 현재 CPU 및 RAM 사용과 관련하여 가상화 분야의 기술이 크게 발전했습니다. 예를 들어, 단일 물리적 머신을 가상화하여 전체 성능 손실을 최소화하면서 여러 클라우드 서버를 가질 수 있습니다. 아쉽게도 스토리지의 경우 아직 개선해야 할 부분이 많습니다. 결과적으로 대부분의 경우 클라우드 가상 서버의 성능은 해당 클라우드 스토리지 솔루션의 성능에 의해 결정됩니다.

요약하자면, 현재 스토리지는 클라우드에서 대부분의 컴퓨팅 작업 성능을 제한하는 요인입니다. 순수 컴퓨팅 작업에 대해 pov-ray 및 기타 벤치마킹이 어떤 결과를 보여주든, 실제로는 가상 서버가 물리적 스토리지 디스크에서 데이터를 검색하고 쓰는 속도가 현재 클라우드 서버의 실제 성능을 결정합니다.

이를 염두에 두면, 클라우드에서 관찰되는 실제 성능 차이는 컴퓨팅 작업과 관련해서도 스토리지 성능의 차이에서 기인하는 경향이 있습니다. 이 글의 앞부분에서 언급했듯이, 컴퓨팅 작업에 따라 고객의 요구 사항은 매우 다양합니다. 이는 스토리지와 관련하여 더욱 그렇습니다. 대용량 순차 데이터 블록(예: 스트리밍 미디어)에 대한 빠른 읽기 액세스가 필요하십니까, 아니면 분산된 소량의 정보(예: 대규모 데이터베이스)에 대한 액세스가 필요하십니까? 주기적으로 대량의 버스트가 발생하는 빠르게 변화하는 데이터에 대해 과중한 쓰기 액세스를 유지해야 합니까? 수많은 시나리오가 존재하며, 동일한 플랫폼이라도 각 시나리오에 따라 성능이 다르게 나타납니다.

근본적으로 성능의 차이는 아키텍처에서 비롯됩니다. 이러한 아키텍처의 차이는 대개 데이터 스토리지의 견고성, 이중화 수준, 그리고 결과적으로 데이터가 복구 불가능하게 손실될 실제 가능성의 차이에서 발생합니다. 상위 수준에서 클라우드는 Storage Area Network (SAN) 형태의 중앙 집중식 데이터 솔루션을 채택하거나, 보다 분산된 로컬 스토리지 솔루션을 채택합니다. 후자의 경우, 스토리지는 각 개별 물리적 머신에 위치합니다.

우수한 SAN은 본질적으로 높은 수준의 이중화가 내장되어 있습니다. 그러나 컴퓨팅 작업을 위해 데이터를 SAN에서 네트워크를 거쳐 가상 머신의 CPU 및 RAM으로 전송해야 하므로 성능이 저하됩니다. 결과적으로 SAN 기반 클라우드는 로컬 분산 스토리지 솔루션을 사용하는 클라우드에 비해 동등한 조건에서 성능이 떨어지는 경향이 있습니다. SAN의 또 다른 단점은 매우 큰 단일 장애점(single point of failure)이 된다는 것입니다. SAN은 매우 안정적입니다. 하지만 심각한 오류가 발생할 경우(실제로 발생한 적이 있음), 대규모 장애와 데이터 손상을 겪게 될 가능성이 큽니다.

SAN을 사용하는 대부분의 클라우드 제공업체는 주로 비용상의 이유로 엔터프라이즈 환경에서 사용하는 것과 같은 완전한 이중화 장애 조치(fail-over) 솔루션을 채택하지 않습니다. 모든 SAN이 동일하지 않다는 점을 인식하고, 클라우드 제공업체가 자사의 SAN에 어떤 수준의 이중화를 적용하고 있는지 이해하는 것이 중요합니다.

로컬 스토리지 기반 클라우드는 디스크 성능이 좋은 경향이 있습니다. 그러나 비지속성(non-persistent) 형태로만 로컬 스토리지를 제공하는 경우가 많습니다. 이는 지속성 스토리지와의 공정한 비교가 아닙니다. 임시 스토리지는 영구 스토리지처럼 장애에 견고할 필요가 없습니다. 의미 있는 결과를 얻으려면 항상 지속성 스토리지를 지속성 스토리지와 비교하는 것이 중요합니다.

분산 로컬 스토리지 솔루션을 사용하는 클라우드를 살펴볼 때는 어떤 이중화 방식을 갖추고 있는지 알아야 합니다. 하드 디스크 드라이브는 고장률이 높기 때문에 스토리지 방식이 매우 중요합니다. 대부분의 제공업체는 일종의 RAID 방식을 사용하지만, 안전성 수준은 매우 다릅니다. 로우엔드 측면에서는 두 개의 디스크가 본질적으로 서로를 미러링하는 RAID1이 있습니다. 이는 대개 성능이 좋습니다. 하지만 디스크 하나가 고장 난 후 교체 디스크가 기존 디스크의 모든 데이터를 복사할 때까지, (부하가 많이 걸린) 두 번째 디스크마저 고장 나면 데이터가 완전히 손실될 위험이 있습니다. 또한 RAID1 어레이를 재구축하는 동안 디스크 성능은 정상보다 훨씬 더 떨어질 가능성이 큽니다.

따라서 많은 제공업체가 RAID5(디스크 1개 고장 감내) 또는 RAID6(디스크 2개 고장 감내)을 사용합니다. RAID6은 로컬 스토리지에 대해 단연 가장 안전한 솔루션을 제공하지만 성능 저하가 큽니다. 당사의 접근 방식은 RAID6을 사용하되 이를 최상급 하드웨어 RAID 컨트롤러 카드와 결합하는 것입니다. 이 카드들은 대용량 메모리 캐시를 탑재하고 있으며 배터리 백업을 지원합니다. 실제로 저희가 사용하는 RAID 컨트롤러 카드는 전체 디스크 어레이보다 훨씬 더 비쌉니다. 따라서 당사는 훨씬 덜 견고한 구성과 비교할 만한 성능을 제공하는 동시에 RAID6 스토리지의 매우 안전한 안전망을 여전히 제공할 수 있습니다. 당사의 cloud infrastructure 구성에 대해 자세히 알아보십시오. 저희는 이에 대해 매우 투명하게 공개하고 있습니다.

디스크 성능 벤치마크에는 IOzone 또는 Bonnie++를 사용할 것을 권장합니다.

따라서 스토리지 벤치마크 결과를 해석할 때는 다음과 같은 정보도 반드시 확인해야 합니다:

• 클라우드가 어떤 스토리지 아키텍처(로컬, SAN, 기타)를 사용하고 있는가?
• 데이터에 대해 어떤 장애 조치(fail-over) 및 이중화 조치가 마련되어 있는가?
• 내가 벤치마킹하고 있는 스토리지가 임시 스토리지인가 아니면 영구 스토리지인가?

이 세 가지 질문에 대한 답변과 벤치마킹 결과를 종합하면 실제 스토리지 성능에 대해 상당히 좋은 통찰력을 얻을 수 있습니다.

네트워킹

네트워킹 성능은 컴퓨팅 및 디스크 성능보다 결정하고 측정하기가 훨씬 더 간단합니다. 네트워킹 성능에는 지연 시간(latency)과 대역폭(bandwidth)이라는 두 가지 핵심 측면이 있습니다.

필요에 따라 클라우드 제공업체가 사용하는 네트워크의 지연 시간이 중요할 수도 있고 중요하지 않을 수도 있습니다. 주로 독립적인 작업을 위해 클라우드를 사용하는 경우 지연 시간이 우선순위가 될 가능성은 낮습니다. 그러나 클라우드 외부의 세상과 상호 작용하는 실시간 애플리케이션을 실행하는 경우 지연 시간은 중요한 성능 결정 요인이 됩니다.

보통 지연 시간의 대부분은 순전한 물리적 거리로 인해 발생합니다. 예를 들어, 런던과 샌프란시스코 사이의 지연 시간 대부분은 실제로 빛이 그 거리를 이동하는 데 걸리는 시간입니다. 지연 시간의 차이는 선택한 경로의 효율성 차이에 의해 결정됩니다. 이 부분이 클라우드마다 다른 점입니다. 경로의 효율성은 클라우드가 직접 연결되어 있는 네트워크 제공업체의 직접적인 결과입니다. 이는 그들로부터 IP 연결을 가져오거나 피어링을 통해 이루어집니다. 지연 시간을 확인할 때는 단순히 클라우드 서버에 핑(ping)을 보내 성능을 확인할 수 있습니다. 그러나 실제 최종 사용자와 클라우드 서버 간의 성능을 확인하는 것이 중요합니다.

대부분의 사용자가 특정 지역에 있거나 주로 회사의 본사에서 접속하는 경우, 해당 위치에서 성능을 테스트하는 것이 중요합니다. 다음과 같은 상용 서비스인 Pingdom은 전 세계의 수많은 일반적인 위치에서 동시에 지연 시간을 확인할 수 있는 비용 효율적인 방법을 제공합니다.

실제 대역폭 또한 클라우드 서버가 달성할 수 있는 매우 중요한 부분입니다. 기존의 호스팅 솔루션과 달리, 클라우드 제공업체는 총 데이터 전송량에 따라 요금을 부과하는 경향이 있습니다. 즉, 24시간 내내 고정된 수준의 연결을 제공하는 Mbit당 방식처럼 시간에 의존하지 않습니다. 그럼에도 불구하고 많은 클라우드 제공업체는 가상 서버의 대역폭을 ‘제한’합니다. 이는 사용자가 그 장벽에 도달하기 전까지는 보이지 않습니다. 대역폭 프로필의 변동 폭이 큰 편이라면 이는 고려해야 할 중요한 성능 요인이 될 수 있습니다.

클라우드 서버의 실제 대역폭을 테스트하려면 상대방 측에서 전송 속도를 제한하지 않는 소스로부터 클라우드 서버로 데이터를 다운로드하는 것이 중요합니다. 저는 사용 가능한 속도를 확인하는 좋은 방법으로 다음과 같은 주요 제공업체로부터 대용량 파일을 다운로드하는 방법을 자주 사용합니다. 예를 들어 Microsoft, Ubuntu 또는 운영체제를 패치하는 것이 훨씬 더 좋은 방법입니다. 이는 다양한 위치에서 동시에 여러 다른 파일을 다운로드하는 경향이 있습니다. 이를 통해 연결 속도를 꽤 잘 체감할 수 있습니다.

저는 보통 Fedora live CD를 그들의 메인 사이트에서 다운로드하여 표준 테스트로 사용하지만, 최소한 몇 가지 다른 파일과 위치로 항상 실험해 보아야 합니다. 자체적인 초고속 기업 네트워크를 고집하신다면, 대신 테스트 삼아 클라우드 서버에서 자체 네트워크로 파일을 다운로드해 볼 수도 있습니다.

이제 결과를 가중 평가하기 위해 가격을 다시 고려하기

위의 방법을 사용하면 다양한 클라우드 서버 제공업체의 성능이 어떠한지 잘 파악할 수 있을 것입니다. 나아가, 귀하의 특정 요구 사항에 가장 중요한 측면이 무엇인지 집중해야 할 부분을 알 수 있게 될 것입니다.

마지막 단계는 벤치마크 결과에 가격 요소를 추가하는 것입니다. 이에 대한 공식은 없습니다. 이는 위에서 언급한 다양한 측면의 상대적인 성능에 따라 달라지며, 이를 결정하는 것은 귀하의 몫입니다. 만약 어떤 클라우드가 (귀하가 결정한 바에 따라) 40% 더 나은 성능을 제공하면서 가격은 30%만 더 비싸다면, 이는 분명히 매력적으로 보일 것입니다. 마찬가지로, 대역폭 요구량이 큰 경우, 낮은 컴퓨팅 성능은 경쟁력 있는 데이터 전송 요금제에 의해 상쇄될 수 있습니다. 올바른 결정을 내리는 핵심은 이 모든 다양한 요소를 종합하는 것입니다.

마지막으로, 벤치마킹은 귀하에게 적합한 클라우드 서버가 무엇인지 결정하는 더 큰 과정의 일부여야 합니다. 여기에는 다른 측면들도 포함되어야 합니다. 예를 들어, 서비스 수준 계약, 데이터/업체 종속 고려 사항, 물리적 위치, 법적 관할권 등이 포함될 수 있습니다. 이 모든 측면을 종합함으로써 귀하는 올바른 클라우드 컴퓨팅 업체를 선택할 수 있는 준비를 갖추게 될 것입니다.