우리는 오늘 고객으로부터 흥미로운 “요구 사항”을 받았습니다.
웹 애플리케이션에서 오프 사이트 페일 오버로 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 내에 있으며 일반적으로 “정지 시간”과 같은 맥락에서 고려되지 않습니다. 장애 발생시 사용 가능한 노드로 자동 재 라우팅하는 응용 프로그램을 사용하면 눈에 띄지 않을 수 있습니다.