클라우드 제공업체 선택 방법

클라우드 제공업체를 선택할 때 브랜드 인지도, 보안 및 스토리지 기능 및 기타 항목을 볼 수 있습니다. 그러나 클라우드 공급자는 우리와 마찬가지로 네트워크에 의존하며 모두 동일하게 생성되거나 구성되지 않습니다.

일반적으로 클라우드를 고려하는 사람들에게는 최종 사용자의 위치와 서비스를 제공할 클라우드 위치를 일치시키는 것이 중요합니다. 또한 클라우드 제공업체를 처음 시작할 때 지속적으로 성능 기준을 설정하는 것을 목표로 해야 합니다. 그러면 성능 문제가 있는 경우 나중에 도움이 될 것입니다.

각 주요 클라우드 제공업체에는 여러 접속 지점이 있으므로 데이터나 앱을 사무실에서 클라우드로 이동할 때 네트워크에 미치는 영향을 고려하는 것이 중요합니다. 이러한 영향을 설명하기 위해 상위 3개 제공업체에 대한 빠른 비교를 설정했습니다.

테스트, 테스트

3대 제공업체의 커버를 살펴보기 위해 몇 가지 테스트를 수행했습니다. AWS, Azure 및 Google Cloud의 3대 퍼블릭 클라우드 제공업체를 위해 북서쪽 접속 지점(정확한 위치는 제공업체에 따라 다름)에 SaaS CRM 데모 시스템을 설정했습니다. 그런 다음 결과가 나오기를 기다렸습니다. 결과는 확실히 흥미로웠습니다.

로스앤젤레스에서 테스트

아래 그래픽은 로스앤젤레스에서 북서부 지역의 주요 공급자로부터 가장 가까운 위치까지의 네트워크 트래픽을 보여줍니다. 북서부에 기반을 둔 CRM에는 실제로 뚜렷한 승자가 없습니다. Google과 AWS는 인접한 오레곤에 위치하고 있으며 Azure는 캘리포니아 북부에 있습니다. 여기에서는 AWS가 승리할 수 있지만 모두 한 달 동안 극도의 변동성을 보입니다(여기서는 낮을수록 좋습니다). 물리적 거리의 차이는 웹 요청에 대한 추가 네트워크 시간으로 완전히 나타나지 않습니다(참고로 국가 간 트래픽의 경우 40ms 소요). 가장 가능성이 높은 것은 라우팅 변경입니다.

로스앤젤레스 → 북서부 지역 | AWS | 하늘색 | 구글

애틀랜타에서 테스트

다음 예는 애틀랜타 기반 모니터에서 북서부 접속 지점 또는 가용 영역까지의 세 공급자의 네트워크 경로를 보여줍니다. AWS는 가장 느린 클라우드 제공업체이지만 세 곳 모두 한 달 동안 변동성을 경험합니다. 합성 사용자와 서버 간의 물리적 분리가 훨씬 더 길기 때문에 네트워크 속도의 작은 변화를 무시할 수 있습니다. 그러나 AWS가 평균 1.5초의 추가 지연 시간을 겪는다는 것은 분명합니다. 원인은 다양할 수 있지만 웹 요청에 최대 2초의 추가 시간이 있으면 사용자 불만 수준이 높아질 수 있습니다. 우리는 또한 트래픽이 경로를 공유하고 일일 정체 문제를 나타낼 수 있음을 나타내는 관찰된 스파이크에서 일부 일관성을 볼 수 있습니다.

우리의 시애틀 기반 배포는 애틀랜타 기반 회사에 이상적이거나 일반적이지 않을 수 있음을 기억하는 것이 중요합니다. 그러나 실리콘 밸리 지역에서 많은 스타트업이 생겨나기 때문에 매일 사용하는 많은 SaaS 앱이 이 장거리 왕복을 하고 있을 가능성이 큽니다.

애틀랜타 → 북서부 지역 | AWS | 하늘색 | 구글

뉴욕에서 테스트

아래의 마지막 예는 뉴욕 영역에서 북서부 기반 CRM까지의 네트워크 경로에 따른 네트워크 성능을 보여줍니다. AWS는 여전히 세 공급자 중 가장 느린 응답 시간을 보여줍니다. Google과 Azure는 1월 말에 관찰된 한 가지 정체 문제를 제외하고 일관되게 더 빠릅니다. 시간이 지남에 따라 인터넷이 이 트래픽의 대부분을 전국적으로 유사하게 라우팅할 것이라고 가정할 수 있기 때문에 AWS 방화벽 뒤의 라우팅이 추가 지연의 원인일 수 있다는 좋은 징후가 있습니다.

뉴욕 → 북서부 지역 | AWS | 하늘색 | 구글

클라우드 테스트에서 발견한 것

샘플 크기가 크지 않고 테스트 배포가 대부분의 최신 앱의 복잡성에 맞게 사용자 지정되지 않았지만 결과는 클라우드 배포를 계획할 때 위치 조사를 수행하는 것이 얼마나 중요한지 상기시켜주었습니다. 서비스와 앱이 클라우드에 있을 때 위치를 확인하려면 지도를 확인하세요. 그런 다음 해당 앱 및 서비스의 사용자가 있는 위치와 일치시킵니다.

국가 한가운데의 피어링 계약이나 방화벽 뒤의 추가 라우팅과 같이 AWS가 빠른 응답을 제공하지 못하는 것처럼 보이는 데에는 여러 가지 이유가 있습니다. 분명한 것은 최종 사용자가 어디에 있느냐에 따라 성능이 달라진다는 것입니다. 이 사실을 알고 있으면 성능과 관련하여 더 나은 결정을 내릴 수 있습니다.

클라우드 제공업체를 테스트하는 것이 우리의 유일한 목적은 아니지만 모든 클라우드 앱용 AppNeta 도구를 사용하여 우리가 수행한(그리고 필요한) 가시성을 얻을 수 있습니다. 이러한 종류의 네트워크 통찰력은 사용자가 속도 저하 또는 중단에 대해 불평하고 성능 저하의 근본 원인을 식별해야 하는 날을 절약할 수 있습니다.