CDN을 사용하는 고 가용성 앱 측정에 대한 권장 사항 찾기

고 가용성 응용 프로그램 (예 : 페이지 간 탐색 시간이 5 초이고 99.5 % 인 응용 프로그램)의 성능과 가용성을 정확하게 측정하는 데 어려움을 겪고있는 Fortune 500 대 기업에서 근무하고 있습니다. 이 가용성 수를 결정하기 위해 예정된 가동 중지 시간과 예정되지 않은 가동 중지 시간을 모두 고려합니다. 그러나 최근 CDN을 믹스에 추가했는데, 이로 인해 메트릭이 약간 복잡해졌습니다. CDN은 이제 트래픽의 약 75 %를 처리하고 나머지는 자체 서버로 보냅니다.

우리는 우리가 "진정한 사용자 경험"이라고 부르는 것을 측정하려고 시도합니다 (즉, 테스트 스크립트는 일반적인 사용자가 응용 프로그램을 클릭하는 것을 에뮬레이트합니다).이 모니터링 스크립트는 네트워크 외부에 위치하여 CDN의 약 75 %를 시간.

경영진은 가용성을 측정하기 위해 최악의 시나리오를 채택하기로 결정했습니다. 따라서 오리진 서버에 문제가 있지만 CDN이 컨텐츠를 제대로 제공하고 있다면 가용성에 여전히 영향을 미칩니다. 다른 방법으로도 마찬가지입니다. "사용자 경험"이 성공하기 만하면 불필요하게 자신을 처벌해서는 안된다고 생각합니다. 결국 CDN은 성능과 가용성을 향상시킵니다.

다른 Fortune 500 대 기업의 가용성 수치 계산 방법에 대해 아는 사람이 있는지 궁금합니다. 예를 들어 apple.com을 보면 다운되지 않는 CDN을 사용하는 상점 첫 화면을 볼 수 있습니다 (주요 제품 발표가 예정되어 있지 않는 한). 우리가 불필요하게 이러한 측정 항목을 다치게해야한다고 믿지 마십시오. 우리 는 이러한 수치를 바탕으로 비즈니스 결정을 내립니다.

그러나 이러한 지표가 경영진에게 가시적이라는 점을 감안할 때 문제가 매우 빠르게 해결되고 해결됩니다 (읽기 : 빨간 테이프를 매우 빨리 삭감합니다). 불행히도 개발자로서 경영진이 생각하기를 원하지 않습니다. 외부 요인 (예 : CDN)이 숫자에 영향을 미치므로 응용 프로그램이 작동 또는 작동 중지 된 것입니다.

생각?

(나는 실수로 StackOverflow 에이 질문을 게시했습니다. 크로스 포스트에 대해 죄송합니다.)

요약하면, "사용 가능"과 "사용 불가능"을 구성하는 요소를 명확하게 정의하고 이에 대해 자신을 측정해야한다고 말하고 싶습니다. 예를 들어, 사이트에 대한 클라이언트 측 성능 SLA를 1 초에서 "배"로, 완전히 렌더링 된 페이지에 대해 3 초를 가질 수 있습니다. 성능 SLA를 충족하지 않으면 해당 기간 동안의 가용성 오류로 간주해야합니다. CDN을 치는지 여부는 중요하지 않습니다. 사용자 경험이 중요합니다.

그러나 5 분마다 측정을 수행하기 때문에 CDN과 마스터 사이트에 대한 적중을 개별적으로 측정하고 CDN에서 75 %의 가용성과 마스터에서 25 %의 가용성을 계산하는 것이 합리적입니다. 여기서 어려움은 75 %가 단지 평균이라는 것입니다. 특정 기간 동안 정확하게 책임을지게하려면 계획된 변경 중 또는 문제가 감지 된 경우 수동 작업 후 또는 다른 사이트가 실제로 고객을 대면하지 않는시기를 알아야합니다. 또한 마스터 사이트 또는 CDN 중 하나가 작동 중지 될 때 발생하는 상황을 고려해야합니다. 고객이 HTTP 500을 받습니까? 아니면 작업 사이트로 투명하게 장애 조치를 수행합니까? 로드 밸런싱 솔루션에 따라 다릅니다. 설명한 "가장 최악의"메트릭은 너무 단순 해 보입니다. 자신에게 물어, "

CDN이 다운되었을 때 "비난"을 받아야하는지 여부에 대해서는 : 절대적으로. 적중의 75 %가 CDN으로 이동하는 경우 고객 경험의 75 %가 이에 영향을받습니다. 고객에게 좋은 경험을 제공하는 것은 귀하의 책임입니다. 따라서 CDN에 문제가있는 경우 엔지니어링 리소스를 사용하여이를 입증하고 공급자와 후속 조치를 취해야합니다.

고려해야 할 또 다른 사항은 마스터 사이트를 오랫동안 사용할 수 없을 때 발생하는 것입니다. 앞에서 설명한 것처럼 CDN은 마스터 사이트에있는 컨텐츠의 정적 사본 인 것 같습니다. 마스터 사이트가 오랫동안 작동 중지되면 CDN이 오래 될 수 있습니다. 따라서 SLA의 일부는 신선해야합니다. 15 초 이하의 컨텐츠로 완전히 렌더링 된 페이지의 경우 1 초에서 "배"까지, 3 초입니다.

user44700에 동의합니다. CDN과 비교하여 서버의 가용성 테스트를 분리하고 독립적으로 두 가지를 추적하는 것이 좋습니다. 실제 가용성은 Server Avail * CDN Avail입니다. 둘 중 하나라도 다운되면 페이지 / 사이트가 다운 된 것으로 간주하기 때문입니다. 또한 모니터링 공급 업체의 비용도 줄어 듭니다.

하나의 브라우저 테스트를 작성하고 실패한 항목을 보지 않고 작동하지만 Catchpoint와 같은 일부 회사는 "콘텐츠 가용성"이라는 개념을 가지고 있습니다.이 경우에는 원하는 것이 아닐 수도 있습니다. 예를 들어 웹 페이지에 404를 제공하는 파일에 대한 CDN 호출이 있다고 가정하면 대부분의 모니터링 솔루션은 이것이 실패라고 말하지만 실제로 CDN이 실패 했습니까? 그 파일도 중요 했습니까? 어쩌면 누군가는 사용자가 알지 못하는 유물 참조를 제거하는 것을 잊었을 것입니다.

더 많은 아이디어를 얻으 려면이 블로그 게시물을 읽을 수 있습니다 : http://blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

SLA보고는 현실을 정확하게 반영해야합니다. 사용자 관점에서 가용성을 측정하고 있고 측정을 수행하는 서버에만 문제가있는 경우 SLA 내에서 해당 문제를보고하면 사용자 경험이 반영되지 않습니다.

소스 정보를 높은 수준으로 유지하기를 원한다는 것을 이해할 수 있습니다. 어쩌면 항상 정확하지는 않지만 이유를 식별하는 메모와 함께보고 할 수 있습니다.

합의에 이르지 못하면 측정 서버의 오류를 줄일 수있는 기술 솔루션이있을 수 있습니다.

정보가 중단으로보고되었지만 그렇지 않은 경우보고는 어떤 가치를 제공합니까?

내 환경에서는 여러 소스에서보고합니다. 외부 관점에서 가용성을보고하고 내부 중단 기록 시스템을보고하는 외부 모니터링 방법론으로, 사람이 입력하고 상황을 가장 정확하게 반영하는 여러 가지 요소를 고려합니다.

Gomez 및 Keynote는 언급 한 메트릭 유형을 수집하기 위해 엔터프라이즈에서 허용되는 솔루션입니다. Gomez에는 google-analytics-esque 자바 스크립트 파일을 소싱하여 최종 사용자 UX를 모니터링하는 서비스도 있습니다.

Pingdom은 좋다 : http://www.pingdom.com/

우리는 CDN 지원 사이트가있는 Fortune 500입니다. 몇 가지를 사용합니다. 다른 것을 감지하려면 다른 것을 측정해야한다고 올바르게 결정했습니다. 앱이 실제로 다운되는시기를 결정하는 데 도움이되는 가용성 숫자 또는 관리를 방해하는 숫자는 명확하게 명확하지 않습니다. 어쨌든...

1. 외부 합성 모니터링-Keynote / Gomez / Webmetrics. 우리는 Keynote를 사용했지만 이제는 Gomez를 사용합니다. 물론 여기에는 CDN 및 기타 외부 구성 요소도 포함됩니다. 이는 전체 SLA를 측정하는 데 좋지만 응용 프로그램의 SLA를 결정하는 데는 좋지 않습니다.

"CDN을 제거"하기 위해 다른 Keynote / Gomez 모니터를 가져 와서 다른 DNS 이름을 사용하여 CDN을 통하지 않고 앱을 가리킬 수 있습니다 . 그러나 여전히 정적 자산이 있으므로 가용성보다 성능에 더 유용합니다. 또한 인터넷 중단, 에이전트 중단 등을 루프에 유지하여 다른 목적이 아닌 일부 목적에 적합합니다.

2. 실제 사용자 모니터링. 네트워크 기반 (Coradiant, Tealeaf) 및 태그 기반 (Jiffy, Gomez)이 있습니다. 우리는 Coradiant를 네트워크 스니퍼로 사용하며 데이터 센터에서 호스팅되는 자산의 실제 사용자가 본 성능, 즉 CDN의 모든 정적 정크가 아닌 실제 애플리케이션을 결정합니다. 그런 다음 앱 오류율과 성능을 결정하기위한 보고서를 작성하고 Apdex (apdex.org)를 파생 메트릭으로 사용했습니다. 경우에 따라 네트워크 기반 (너무 많은 트래픽 또는 네트워크에서 얻을 수있는 위치에 자산이 호스팅되지 않음)을 사용할 수 없으며 태그 기반이 그다지 신뢰할 수 없습니다. 실제 최종 사용자 응답 시간과 오류를 실제로 볼 수 있다는 엄청난 이점이 있습니다. 실제 사용자가하는 모든 경우에 오류가없는 합성 모니터를 쉽게 설정할 수 있습니다.

3. 로컬 합성 모니터링. Nagios / zabbix / sitescope / 100 기타. 앱에서 모니터를 로컬로 가리 키십시오 (CDN을 거치지 마십시오). 실행 가능한 가용성 모니터링 (있는 사람을 깨우기 위해 페이지 보내기)의 경우 이것이 표준입니다. 네트워크 항목을 고려하지 않습니다.

4. 로그 모니터링. 어떤 의미에서 이것은 빈민가 실제 사용자 모니터링입니다. 그러나 실제로 오류가 발생한 것을보고 싶다면 꽤 편리합니다. 실제 사용자 모니터링의 "실제로 이런 일이 발생하지 않았습니다"혜택이 있습니다. 웹 티어에서 시간이 걸리는 경우가 아니라면 가용성 만 제공됩니다.이 경우 서버 종료 시간이 표시됩니다. SLA에 직면 한 사용자에게는 도움이되지 않지만 "어떤 코드에서 작업해야합니까? " splunk를 사용하십시오.

"최종 사용자 스토리"와 "프로그래머가 의지해야 할 내용"을 원하기 때문에이 둘을 모두 사용하지는 않습니다.

BrowserMob 은 훌륭합니다