웹 애플리케이션의 100 % 가동 시간

우리는 오늘 고객으로부터 흥미로운 "요구 사항"을 받았습니다.

웹 애플리케이션에서 오프 사이트 페일 오버로 100 % 가동 시간을 원합니다 . 우리 웹 애플리케이션의 관점에서 이것은 문제가되지 않습니다. 여러 데이터베이스 서버 등으로 확장 할 수 있도록 설계되었습니다.

그러나 네트워킹 문제로 인해 어떻게 작동하는지 알 수없는 것 같습니다.

간단히 말해서, 응용 프로그램은 클라이언트 네트워크 내의 서버에서 작동합니다. 내부 및 외부 사람들이 액세스합니다. 그들은 구내에서 심각한 장애가 발생할 경우 즉시 픽업하여 인계 할 수 있도록 시스템의 오프 사이트 사본을 유지하기를 원합니다.

이제 우리는 내부 사람들 (캐리어 비둘기?)을 위해 그것을 해결할 수있는 방법이 전혀 없다는 것을 알고 있지만 외부 사용자가 눈치 채지도 않기를 바랍니다.

솔직히 말해서, 이것이 어떻게 가능한지에 대한 가장 어리석은 생각은 아닙니다. 인터넷 연결이 끊어지면 트래픽을 외부 컴퓨터로 전달하기 위해 DNS 변경을 수행해야 할 것 같습니다. 물론 시간이 걸립니다.

아이디어?

최신 정보

나는 오늘 고객과 토론을했고 그들은 그 문제에 대해 명확히했다.

홍수가 발생하더라도 애플리케이션이 계속 활성 상태 여야한다고 100 % 숫자로 고정되었습니다. 그러나 이러한 요구 사항은 우리가 요구하는 경우에만 시작됩니다. 그들은 애플리케이션이 서버에 완전히 존재한다면 가동 시간 요구 사항을 처리 할 것이라고 말했다. 내 대답을 추측 할 수 있습니다.

다음은 9 가지를 추구하는 위키 백과 의 편리한 차트입니다.

흥미롭게도, 상위 20 개 웹 사이트 중 3 개만 이 2007 년에 신화적인 5 nines 또는 99.999 % 가동 시간을 달성 할 수있었습니다. Yahoo, AOL 및 Comcast였습니다. 2008 년 첫 4 개월 동안 가장 인기있는 소셜 네트워크 중 일부는 그 와 비슷하지 않았습니다.

차트에서 100 % 가동 시간을 추구하는 것이 얼마나 터무니 없는지 분명해야합니다.

그들에게 100 %를 정의하고 어떤 기간 동안 어떻게 측정 할 것인지를 요청하십시오. 그들은 아마도 그들이 감당할 수있는만큼 100 %에 가까운 것을 의미합니다. 그들에게 비용을 줘.

정교하게 나는 몇 년 동안 우스꽝스러운 요구 사항으로 고객과 토론을 해왔습니다. 모든 경우에 그들은 실제로 정확하지 않은 언어를 사용하고있었습니다.

종종 100 %처럼 절대적으로 보이는 방식으로 사물을 구성하지만 실제로는 더 심도있는 조사에서 완화 데이터를 감수하기 위해 비용을 제시 할 때 필요한 비용 / 이익 분석을 수행 할 수있을 정도로 합리적입니다. 가용성을 측정 할 방법을 묻는 것은 매우 중요한 질문입니다. 그들이 이것을 모른다면, 먼저 정의해야한다고 제안해야 할 입장에 있습니다.

다음과 같은 상황에서 사이트가 다운되면 고객에게 비즈니스 영향 / 비용 측면에서 어떤 일이 발생할지 정의하도록 요청합니다.

• x 시간 동안 가장 바쁜 시간에
• x 시간 동안 가장 바쁜 시간에

그리고 그들이 이것을 어떻게 측정 할 것인가.

이러한 방식으로 그들과 함께 '100 %'의 올바른 수준을 결정할 수 있습니다. 나는 이런 종류의 질문을함으로써 다른 요구 사항의 우선 순위를 더 잘 결정할 수있을 것으로 생각합니다. 예를 들어,이를 달성하기 위해 특정 레벨의 SLA를 지불하고 다른 기능을 손상시킬 수 있습니다.

당신의 고객은 미쳤다. 비용이 얼마나 들더라도 100 % 가동 시간은 불가능 합니다. 평범하고 단순합니다-불가능합니다. 구글, 아마존 등을 살펴보십시오. 인프라에 투자 할 돈은 거의 끝이 없지만 여전히 다운 타임이 있습니다. 당신은 그들에게 그 메시지를 전해야하며, 그들이 계속 요구한다면 그들은 합리적인 요구를 제공한다고 주장합니다. 그들이 어느 정도의 가동 중지 시간이 불가피하다는 것을 인식하지 못한다면 , 도랑을 피하십시오.

즉, 응용 프로그램 자체를 확장 / 배포하는 메커니즘이있는 것 같습니다. 네트워킹 부분은 서로 다른 ISP에 대한 중복 업 링크, ASN 및 IP 할당, BGP 및 실제 라우팅 장비를 필요로하므로 IP 주소 공간이 필요한 경우 ISP간에 이동할 수 있어야합니다.

이것은 매우 명백한 답변입니다. 이 정도의 가동 시간을 요구하는 응용 프로그램에 대한 경험이 없으므로 신화적인 100 % 가동 시간에 가까운 곳을 원한다면 전문가가 필요합니다.

글쎄, 그것은 확실히 흥미로운 것입니다. 계약 시간에 100 % 가동 시간을 내고 싶지는 않지만, 다음과 같이 보일 것이라고 생각합니다.

네트워크에서 완전히로드 밸런서의 퍼블릭 IP로 시작하고 둘 중 하나 이상을 장애 조치 할 수 있도록 둘 중 하나 이상을 구축하십시오. Heatbeart와 같은 프로그램은 자동 장애 조치에 도움이 될 수 있습니다.

바니시는 주로 캐싱 솔루션으로 알려져 있지만 매우 적절한로드 밸런싱도 수행합니다. 아마도 이것이로드 밸런싱을 처리하기에 좋은 선택 일 것입니다. 임의로 또는 라운드 로빈의로드 밸런싱을 수행 할 디렉터에 1 ~ n 개의 백엔드가 선택적으로 그룹화되도록 설정할 수 있습니다. 바니시는 모든 백엔드의 상태를 확인하고 건강에 해로운 백엔드가 온라인으로 돌아올 때까지 루프에서 빠져 나갈 수 있도록 똑똑하게 만들 수 있습니다. 백엔드가 동일한 네트워크에있을 필요는 없습니다.

요즘 Amazon EC2의 탄력적 IP를 좋아하기 때문에 다른 지역 또는 적어도 같은 지역의 다른 가용 영역에서 EC2에로드 밸런서를 구축 할 것입니다. 기존 A 레코드 IP를 새 상자로 옮겨야 할 경우 새로드 밸런서를 수동으로 (신 금지) 수동으로 선택할 수 있습니다.

그러나 니스는 SSL을 종료 할 수 없으므로 이것이 우려되는 경우 Nginx와 같은 것을 원할 수 있습니다.

대부분의 백엔드는 클라이언트 네트워크에 있고 하나 이상의 네트워크 외부에있을 수 있습니다. 백엔드의 우선 순위를 정하여 클라이언트 컴퓨터가 모두 비정상 상태가 될 때까지 클라이언트 컴퓨터가 우선 순위를 갖도록 100 % 확신 할 수는 없습니다.

그것이 내가이 일을한다면 시작하고 의심 할 여지없이 그것을 다듬을 수있는 곳입니다.

그러나 @ErikA가 말했듯이, 그것은 인터넷이며 항상 통제 할 수없는 네트워크의 일부가 될 것입니다. 당신은 법이 당신이 통제하는 것들과 만 당신을 연결 시키길 원할 것입니다.

문제 없습니다-계약 문구를 약간 수정했습니다.

... 가동 시간을 100 % 보장합니다 (소수점 0으로 반올림).

Facebook과 Amazon이 할 수 없다면 할 수 없습니다. 그렇게 간단합니다.

Hacker News에서 oconnore의 답변 을 추가하려면

문제가 무엇인지 이해하지 못합니다. 고객은 재난에 대한 계획을 세우기를 원하며 수학 지향적이지 않으므로 100 % 확률의 소리가 합리적이라고 요구합니다. 엔지니어는 엔지니어가하기 쉽기 때문에 클라이언트가 그렇지 않을 수도 있다는 점을 고려하지 않고 prob & stat 101의 첫 날을 기억했습니다. 그들이 이것을 말할 때, 그들은 겨울 핵에 대해 생각하지 않고 Fred가 사무실 서버에 커피를 내 버리거나 디스크가 고장 나거나 ISP가 다운되는 것을 생각합니다. 또한이를 달성 할 수 있습니다. 지리적으로 독특하고 독립적 인 자체 모니터링 서버를 사용하면 기본적으로 다운 타임이 없습니다. 3 개의 서버가 독립적 인 (1) 3 개의 9 개의 안정성으로 작동하고 우수한 페일 ​​오버 모드로 인해 예상되는 다운 타임은 연간 초 미만입니다 (2). 이런 일이 한 번에 발생하더라도 귀하는 여전히 웹 연결에 대한 합리적인 SLA 내에 있으므로 다운 타임이 실제로 존재하지 않습니다. 클라이언트는 여전히 종말 시나리오를 처리해야하지만 Godzilla는 제외하고 "항상"서비스를 제공 할 것입니다.

(1) LA의 서버는 보스턴의 서버와 상당히 독립적이지만 그래, 핵전쟁, 중국 해커가 전력망을 충돌시키는 등의 교차점이 있음을 이해합니다. 귀하의 클라이언트가 이.

(2) DNS 장애 조치에 몇 초가 추가 될 수 있습니다. 클라이언트가 1 년에 한 번 요청을 다시 시도해야하는 시나리오에 있으며, 다시 합리적 SLA 내에 있으며 일반적으로 "정지 시간"과 같은 맥락에서 고려되지 않습니다. 장애 발생시 사용 가능한 노드로 자동 재 라우팅하는 응용 프로그램을 사용하면 눈에 띄지 않을 수 있습니다.

불가능한 것을 요구하고 있습니다.

여기에있는 다른 답변을 검토하고 고객과 함께 앉아 불가능한 이유를 설명 하고 응답을 측정하십시오.

여전히 100 % 가동 시간을 요구하는 경우 정중하게 수행 할 수 없음을 알리고 계약을 거부하십시오. 당신은 그들의 요구를 결코 충족시키지 못할 것이며, 계약이 완전히 빨리 지 않으면 벌칙을 당할 것입니다.

이에 따라 가격을 책정 한 다음 계약에서 SLA 이후의 가동 중지 시간이 지불하는 요율로 환불되도록 규정합니다.

마지막 직장에서 ISP가 그 일을했습니다. 우리는 $ 40 / mo에 대해 99.9 % 가동 시간에 "정규"DSL 회선을 선택했거나 $ 1100 / mo에 대해 가동 시간 99.99 %에 T1의 결합 된 트리오를 선택했습니다. 한 달에 10 시간 이상 가동이 자주 중단되어 가동 시간이 $ 40 / mo DSL보다 훨씬 낮았지만, 시간당 요금 * 시간이 끝나기 때문에 약 15 달러 정도만 환불되었습니다. 그들은 거래에서 도둑처럼 만들었습니다.

100 % 가동 시간으로 한 달에 45 만 달러를 청구하고 99.999 %에 불과한 경우 324 달러를 환불해야합니다. 완전히 분산 된 콜 로스, 다중 계층 1 업 링크, 팬던트 하드웨어 등을 가정하면 99.999 %에 이르는 인프라 비용이 한 달에 45,000 달러 근처에있을 것이라고 확신합니다.

전문가가 99.999 %의 가용성이 실질적으로나 재정적으로 실행 가능한지 여부에 대해 의문을 가지면 99.9999 %의 가용성이 훨씬 덜 가능하거나 실용적입니다. 100 %는 물론입니다.

장기간 100 % 가용성 목표를 달성하지 못할 것입니다. 일주일 또는 1 년 동안이 문제를 해결할 수 있지만 문제가 발생하여 책임을 져야합니다. 유출은 평판 손상 (제공하지 않겠다고 약속 한 것)에서 계약 벌금으로 인한 파산에 이르기까지 다양합니다.

100 % 가동 시간을 요구하는 두 가지 유형의 사람들이 있습니다.

1. 컴퓨터, 컴퓨터 시스템 또는 인터넷에 대한 지식이 전혀없는 사람들. *
2. 고의로 자신의 엉덩이를 만들고있는 사람은 아니오 (Google "오렌지 주스 테스트")를 할 수있는 능력을 테스트하거나 나중에 비용을 지불하기 위해 일종의 계약 SLA 레버리지를 얻으려고합니다.

많은 경우에 이러한 유형의 고객 모두에게 고통을 겪은 나의 충고는이 고객을 받아들이지 않는 것입니다. 그들이 다른 사람을 미치게 만들게하십시오.

* 동일한 사람은 빛보다 빠른 여행, 퍼페 츄얼 모션, 콜드 퓨전 등에 대해 궁금해하지 않을 수 있습니다.

정확히 100 % 가동 시간이 무엇을 의미하는지 고객과 의사 소통하려고합니다. 99 % 가동 시간과 100 % 가동 시간의 차이를 실제로 보지 못할 수도 있습니다. 서버 관리자가 아닌 대부분의 사람들에게이 두 숫자는 동일합니다.

100 % 가동 시간?

필요한 것은 다음과 같습니다.

각 ISP에 적절한 SLA를 사용하여 전 세계 여러 사이트를 가리키는 여러 개의 (및 중복) DNS 서버

TTL을 효과적으로 인식하여 DNS 서버가 올바르게 설정되어 있는지 확인하십시오.

이것은 쉬워요. Amazon EC2 SLA는 다음과 같이 명확하게 설명합니다.

"연간 가동 시간 백분율"은 Amazon EC2가 "지역을 사용할 수 없음"상태 인 서비스 연도 동안 5 분 기간의 백분율에서 100 %를 빼서 계산합니다.

http://aws.amazon.com/ec2-sla/

실제로 가동 시간을 100 % 유지할 수있는 전체 서비스 번들에 상대적으로 '가동 시간'을 정의하면 아무 문제가 없습니다.

또한 SLA의 전체 요점은 귀하의 의무가 무엇이며이를 충족 할 수없는 경우 어떻게되는지 정의하는 것입니다. 고객이 3 9, 5 9, 9 백만 또는 9 백만을 요구하더라도 문제가되지 않습니다. 문제는 고객이 배송 할 수없는 경우에 얻을 수있는 것입니다. 확실한 대답은 청구하려는 가격의 5 배로 100 % 가동 시간 동안 광고 항목을 제공 한 다음 해당 목표를 놓치면 4 배의 환불을받는 것입니다. 당신은 득점 할 수 있습니다!

DNS 변경은 시간이 걸리도록 구성된 경우에만 시간이 걸립니다. 레코드의 TTL을 1 초로 설정할 수 있습니다. 유일한 문제는 DNS 쿼리에시기 적절하게 응답하고 DNS 서버가 해당 수준의 쿼리에 대처할 수 있도록하는 것입니다.

이것이 F5 Big IP에서 GTM이 작동하는 방식입니다. 기본적으로 DNS TTL은 30 초로 설정되며 클러스터의 한 구성원이 인계해야하는 경우 DNS가 업데이트되고 거의 즉시 새 IP가 사용됩니다. 최대 30 초의 정전이 발생하지만 가장 중요한 경우는 평균 15 초입니다.

당신은 이것이 불가능하다는 것을 알고 있습니다.

의심 할 여지없이 고객이 "100 %"를 보는 데 집중하고 있으므로, 귀하가 할 수있는 최선의 방법은 [당신의 잘못이 아닌 모든 합리적인 원인]을 제외하고 100 %를 약속하는 것입니다.

100 %가 가능하다는 것은 의심 스럽지만 Azure (또는 유사한 SLA가있는 것)를 가능성으로 생각할 수 있습니다. 계속되는 일 :

서버는 가상 머신입니다. 한 서버에 하드웨어 문제가있는 경우 가상 머신이 새 머신으로 이동됩니다. 로드 밸런서는 리디렉션을 처리하므로 고객은 중단 시간을 보지 않아야합니다 (세션 상태가 어떻게 영향을 받는지 잘 모르겠습니다).

즉,이 장애 극복에도 불구하고 광기의 99.999와 100 사이의 차이가 있습니다.

다음과 같은 요소를 완전히 제어해야합니다.
-내부 및 외부, 악의와 발기 부전의 인적 요소. 예를 들어 누군가가 서버를 다운시키는 프로덕션 코드로 무언가를 푸시하는 것입니다. 더 나쁜 것은 파괴 행위는 어떻습니까?
-비즈니스 문제. 서비스 제공 업체가 업무를 수행하지 않거나 전기 요금을 지불하지 않거나 충분한 경고없이 인프라 지원을 중단하기로 결정한 경우 어떻게됩니까?
-자연. 관련없는 토네이도가 동시에 백업 용량을 압도하기에 충분한 데이터 센터에 충돌하면 어떻게됩니까?
-완전히 버그가없는 환경. 당신은 확실히 그 자체를 명시하지 않은 여전히 미래에 그렇게 할 수있는 몇 가지 제 3 자 또는 제 3의 코어 시스템 제어 에지 경우가 아닌가요?
-위의 요소를 완전히 제어하더라도 시스템을 점검 할 때이를 모니터링하는 소프트웨어 / 사람이 잘못된 부정을 나타내지 않습니까?

정직하게 100 %는 해킹 공격의 관점에서 최소한 흔들리지 않고 완전히 미쳤다. 최선의 방법은 사이트와 DB를 여러 지리적 위치에있는 여러 서버에 복제 한 지리적 분산 호스팅 솔루션을 사용하여 Google과 Amazon이하는 일을하는 것입니다. 이것은 인터넷 백본이 (종종 발생하는) 지역으로 절단되거나 거의 종말과 같은 중대한 재난을 제외하고는 그것을 보장 할 것입니다.

나는 그런 경우 (DDOS, 인터넷 백본 절단, 묵시적 테러 공격 또는 큰 전쟁 등)에 대한 조항을 넣을 것입니다.

그 외에는 Amazon S3 또는 Rackspace 클라우드 서비스를 살펴보십시오. 기본적으로 클라우드 설정은 각 위치의 중복성을 제공 할뿐만 아니라 실패한 지역 주변으로 리디렉션하는 기능과 함께 트래픽의 확장 성 및 지리적 분포를 제공합니다. 내 이해는 지리적 분포가 더 많은 비용이 든다는 것입니다.

난 그냥 "는 또 다른 목소리를 추가하고 싶었 수 있습니다 (이론적으로) 할 수"파티.

나는 그들이 지불 한 금액에 관계 없이이 계약을 맺지 않았지만 연구 문제로 다소 흥미로운 해결책이 있습니다. 단계를 설명하는 네트워킹에 익숙하지는 않지만 네트워크 관련 구성 + 전기 / 하드웨어 배선 페일 오버 + 소프트웨어 페일 오버의 조합이 일부 구성 또는 실제로는 다른 작업에서 실제로 풀리게됩니다.

구성에 어딘가에 거의 항상 단일 장애 지점이 있지만, 충분히 열심히 노력하면 해당 장애 지점을 "실시간"으로 복구 할 수있는 수준으로 푸시 할 수 있습니다 (예 : 루트 dns가 다운되지만 값은 여전히 ​​캐시 됨) 다른 곳에서는 해결할 수 있습니다.)

다시 말하지만, 그것이 실현 가능하다고 말하지는 않습니다. 나는 단지 하나의 답변이 그것이 "밖으로 나가지 않는다"는 사실을 어떻게 다루지 않았는지-단지 그들이 생각할 때 실제로 원하는 것이 아닙니다.

가용성 측정 방법을 다시 생각한 다음 고객과 협력하여 의미있는 목표 를 설정하십시오 .

대규모 웹 사이트를 실행중인 경우 가동 시간 이 전혀 유용하지 않습니다. 고객이 가장 필요할 때 (트래픽 피크) 10 분 동안 쿼리를 삭제하면 일요일 오전 3시에 한 시간 동안 중단되는 것보다 비즈니스에 더 큰 피해를 줄 수 있습니다.

때때로 대규모 웹 회사는 다음과 같은 메트릭을 사용하여 가용성 또는 안정성을 측정합니다.

1. 서버 쪽 오류 없이 성공적으로 응답 한 쿼리 비율 (HTTP 500).
2. 특정 목표 아래에 대답하는 쿼리의 비율 지연 .
3. 삭제 된 검색어는 통계와 비교해야합니다 (아래 참조).

Pingdom 및 Pingability와 같은 외부 엔티티가보고 할 수있는 샘플 프로브를 사용하여 가용성을 측정 해서는 안됩니다 . 그것에 전적으로 의존하지 마십시오. 올바르게 수행하려면 모든 단일 쿼리가 계산되어야합니다 . 실제로 인식 된 성공을보고 가용성을 측정하십시오.

가장 효율적인 방법은로드 밸런서에서 로그 또는 통계를 수집하고 위의 메트릭을 기반으로 가용성을 계산하는 것입니다.

삭제 된 검색어 의 비율 도 통계와 함께 계산해야합니다. 서버 측 오류와 동일한 버킷에서 설명 할 수 있습니다. 네트워크 또는 DNS 또는로드 밸런서와 같은 다른 인프라에 문제가있는 경우 간단한 수학을 사용하여 손실 된 쿼리 수를 추정 할 수 있습니다 . 요일에 대한 X 쿼리를 예상했지만 X-1000을 얻은 경우 1000 개의 쿼리를 삭제했을 수 있습니다. 분당 (또는 초) 그래프로 트래픽을 플로팅합니다. 간격이 나타나면 쿼리를 삭제 한 것입니다. 사용하여 기본 형상을 당신에게 떨어 쿼리의 총 수를 제공하는 격차의 영역을 측정 할 수 있습니다.

이 방법론을 고객과 논의하고 그 이점을 설명하십시오. 현재 가용성을 측정 하여 기준을 설정하십시오 . 그들에게는 100 %가 불가능한 목표라는 것이 분명해질 것입니다.

그런 다음 기준선의 개선 사항을 기반으로 계약에 서명 할 수 있습니다. 현재 95 %의 가용성을 경험하고 있다면 98.5 %로 상황을 10 배 향상시킬 수 있습니다.

참고 :이 방법으로 가용성을 측정하는 데는 단점이 있습니다. 첫째, 기존 도구를 사용하여 로그를 작성하지 않으면 로그를 수집하고 보고서를 처리하고 생성하는 것이 쉽지 않을 수 있습니다. 둘째, 응용 프로그램 버그로 인해 가용성이 떨어질 수 있습니다. 응용 프로그램의 품질이 낮은 경우 더 많은 오류가 발생합니다. 이에 대한 해결책은로드 밸런서가 생성 한 500 대만 애플리케이션에서 제공되는 것 대신 고려하는 것입니다.

이런 식으로 상황이 조금 복잡해질 수 있지만 서버 가동 시간 을 측정하는 것 이상의 한 단계 입니다.

어떤 사람들은 여기서 100 %가 미쳤 거나 불가능하다고 지적했지만 , 실제로는 요점을 놓쳤다. 그들은 그 이유는 최고의 회사 / 서비스조차도 그것을 달성 할 수 없기 때문이라고 주장했다.

그보다 훨씬 간단합니다. 그것은이다 수학적으로 불가능합니다 .

모든 것은 확률이 있습니다. 서버를 저장하는 모든 위치에서 동시에 지진이 발생하여 모든 서버가 파괴 될 수 있습니다. 아마도 그것은 엄청나게 작은 확률이지만 0이 아닙니다. 모든 인터넷 제공 업체는 동시에 테러 / 사이버 공격에 직면 할 수 있습니다. 다시 말하지만, 가능성은 높지 않지만 0도 아닙니다. 무엇을 제공하든, 전체 서비스를 중단시키는 0이 아닌 확률 시나리오를 얻을 수 있습니다. 이 때문에 가동 시간도 100 % 일 수 없습니다.

통계 샘플링을 사용하여 제조 품질 관리에 관한 책을 읽어보십시오. 이 책에서 관리자가 대학의 일반 통계 과정에 노출되었을 개념에 대한 일반적인 논의는 천만에 1 번의 면제에서 1 만 건에서 1 만 건으로 10 억에서 1이 기하 급수적으로 증가합니다. 본질적으로 100 % 가동 시간을 달성하는 능력은 물체를 빛의 속도로 밀어 올리는 데 필요한 연료량과 같은 거의 무제한의 자금이 필요합니다.

퍼포먼스 엔지니어링 관점에서 나는이 표현이 진정한 요구 사항보다 더 바람직하다는 요구 사항을 테스트 할 수없고 부당한 것으로 거부한다. 네트워킹, 이름 확인, 라우팅, 기본 아키텍처 구성 요소 또는 개발 도구에서 발생하는 결함에 대한 응용 프로그램 외부에 존재하는 응용 프로그램 종속성으로 인해 모든 사람이 100 % 가동 시간을 보장하는 것은 실질적으로 불가능합니다.

고객이 실제로 100 % 가동 시간 또는 99.999 % 가동 시간을 요구한다고 생각하지 않습니다. 그들이 설명하는 것을 보면 유성이 현장 데이터 센터를 꺼내면 중단 된 부분을 가져 오는 것에 대해 이야기하고 있습니다.

요구 사항이 외부 사람들에게 알리지 않아도되는 경우 얼마나 과감해야합니까? Ajax 요청을 재 시도하고 최종 사용자에게 30 초 동안 스피너를 표시하는 것이 허용됩니까?

이들은 고객이 관심을 갖는 종류입니다. 고객이 실제로 정확한 SLA를 생각하고 있다면이를 99.99 또는 99.999로 표현하기에 충분할 것입니다.

내 2 센트 나는 슈퍼 볼 광고를하는 포춘 5 회사의 매우 인기있는 웹 사이트를 책임지고있었습니다. 트래픽 급증 문제를 해결해야했으며 해결 방법은 Akamai와 같은 서비스를 사용하는 것이 었습니다. 나는 Akamai에서 일하지 않지만 서비스가 매우 좋습니다. 특정 노드 / 호스트에로드가 많거나 다운되어 있고 그에 따라 트래픽을 라우팅 할 수 있음을 알고있는 고유 한 스마트 DNS 시스템이 있습니다.

그들의 서비스에 대한 깔끔한 점은 내 데이터 센터에있는 서버의 컨텐츠를 데이터 센터로 복제하기 위해 실제로 매우 복잡한 작업을 수행 할 필요가 없다는 것입니다. 또한 그들과 함께 일하면서 아파치 HTTP 서버를 많이 사용했습니다.

100 % 가동 시간은 아니지만 전 세계에 컨텐츠를 분산시키기위한 이러한 옵션을 고려할 수 있습니다. 내가 알기로, Akamai는 미시간에있을 경우 트래픽 의미를 현지화 할 수있는 능력이 있었고, 미시간 / 시카고 서버에서 컨텐츠를 받았으며 캘리포니아에있는 경우 캘리포니아에있는 서버에서 컨텐츠를 가져 왔습니다.

오프 사이트 장애 조치 대신 내부 및 외부의 두 위치에서 동시에 응용 프로그램을 실행하십시오. 그리고 두 데이터베이스를 동기화합니다. 그러면 내부 직원이 다운되면 내부 직원은 계속 작업 할 수 있으며 외부 사용자는 여전히 응용 프로그램을 사용할 수 있습니다. 내부가 온라인 상태로 돌아 오면 변경 내용을 동기화하십시오. 하나의 도메인 이름 또는 라운드 로빈이있는 네트워크 라우터에 대해 두 개의 DNS 항목을 가질 수 있습니다.

외부 호스팅 사이트의 경우, 가동 시간이 100 %에 가장 근접한 것은 Google App Engine에서 사이트를 호스팅하고 HRD (High Replication Datastore) 를 사용하는 것입니다. 마찬가지로 App Engine 프런트 엔드 서버는 자동 확장 / 복제됩니다.

그러나 Google의 모든 리소스와 세계에서 가장 정교한 플랫폼을 사용하더라도 App Engine SLA 가동 시간 보장은 "월간 시간의 99.95 %"에 불과합니다.

간단하고 직접적인 : 애니 캐스트

http://en.wikipedia.org/wiki/Anycast

이것은 cloudflare, Google 및 기타 대기업이 중복, 낮은 대기 시간, 대륙간 장애 조치 / 밸런싱을 수행하는 데 사용하는 것입니다.

그러나 100 % 가동 시간을 갖는 것은 불가능하며 99.999 %에서 99.9999 %로 이동하는 데 드는 비용이 훨씬 더 크다는 점을 명심하십시오.