Erlang의 99.9999999 % (나인 나인) 신뢰성

Erlang 은 99.9999999 %의 가동 시간 비율로 20 년 넘게 프로덕션 시스템에서 사용 된 것으로보고되었습니다.

나는 다음과 같이 수학을했다.

20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s

이는 20 년 동안 시스템의 다운 타임이 1 초 미만이라는 것을 의미합니다. 나는 이것의 타당성에 도전하지 않고 단지 0.631 초 동안 (의도적으로 또는 우연으로) 시스템을 종료 할 수있는 방법에 대해 궁금합니다. 대형 소프트웨어 시스템에 익숙한 사람이 우리에게 이것을 설명해 줄 수 있습니까? 감사합니다.

처리 장치 (또는 시스템) 클러스터를 통해 서비스의 중단 시간을 계산하는 방법을 아는 사람이 있습니까?

신뢰성 수치는 (문제가되는 AXD301프로젝트) 의 어떤 부분이 20 년 넘게 종료 된 총 시간을 측정하지 않았습니다 . AXD301시스템이 제공하는 서비스 가 오프라인 상태였던 20 년 동안의 총 시간을 나타냅니다 . 미묘한 차이. Joe Armstrong이 여기에서 말했듯 이 :

AXD301은 NINE nines 신뢰성을 달성했습니다 (예, 99.9999999 %). 이를 맥락에 넣어 보겠습니다. 5 개의 9가 좋은 것으로 간주됩니다 (연간 5.2 분의 다운 타임). 7 개의 나인은 거의 달성 할 수 없지만 9 개를했습니다.

왜 이런거야? 공유 상태가 없으며 정교한 오류 복구 모델이 있습니다.

좀 더 자세히 살펴보면 Erlang의 원저자 인 Joe가 작성한 PhD 논문 (의 사례 연구 포함 AXD301)에서 다음과 같이 읽습니다.

이 장에서 연구 한 프로젝트 중 하나는 고성능의 고 신뢰성 ATM 스위치 인 Ericsson AXD301 입니다.

따라서 스위치가 포함 된 네트워크가 다운 타임없이 실행되는 한 작성자는 "나인 나인 안정성"에 대해 AXD301말할 수 있습니다. 그렇다고 Erlang이 이러한 높은 신뢰성의 유일한 원인이라는 의미는 아닙니다.

편집 : 사실, "20 년"자체는 잘못된 해석처럼 보입니다. Joe는 같은 기사에서 20 년의 수치를 언급했지만 실제로는 (다른 사람들이 언급했듯이) 훨씬 더 짧은 연구에서 나올 수있는 99.999 신뢰도 수치와 실제로 관련이 없습니다.

다른 사람들은 귀하가 요청하는 특정 사례를 다루었지만 귀하의 질문은 오해에 근거한 것 같습니다. 귀하가 질문 한 방식은 시스템이 충돌하거나 유지 보수를 위해 중단 된 후 시스템을 다시 실행하는 수동 프로세스가 있다고 생각하게 만듭니다.

Erlang에는 다운 타임의 원인으로 인간의 작업 시간을 제거하는 몇 가지 기능이 있습니다.

1. 핫 코드 다시로드 . Erlang 시스템에서는 기존 모듈에 대한 대체 모듈을 쉽게 컴파일하고로드 할 수 있습니다. BEAM 에뮬레이터는 분명히 아무것도 중지하지 않고 자동으로 스왑을 수행합니다. 의심 할 여지없이이 전송이 발생하는 시간은 아주 적지 만 인간 시간에 수동으로 발생하는 것이 아니라 컴퓨터 시간에 자동으로 발생합니다. 이를 통해 본질적 으로 다운 타임없이 업그레이드를 수행 할 수 있습니다 . (교체 모듈에 시스템 충돌을 일으키는 버그가있는 경우 다운 타임이 발생할 수 있지만, 이것이 프로덕션에 배포하기 전에 테스트하는 이유입니다.)

2. 감독자 . Erlang의 OTP 라이브러리에는 모듈이 충돌 할 때 시스템이 어떻게 반응해야하는지 정의 할 수있는 감독 프레임 워크가 내장되어 있습니다. 여기서 표준 조치는 실패한 모듈을 다시 시작하는 것입니다. 다시 시작된 모듈이 즉시 다시 중단되지 않는다고 가정하면 시스템에 부과되는 총 다운 타임은 밀리 초에 불과할 수 있습니다. 거의 충돌하지 않는 견고한 시스템은 실제로 수년간의 실행 시간 동안 총 다운 타임의 극히 일부만 누적 할 수 있습니다.

3. 프로세스 . 영구 데이터 저장소를 통하지 않는 한 상태를 공유하지 않는다는 점을 제외하고는 대략 다른 언어의 스레드에 해당합니다. 그 외에는 메시지 전달을 통해 통신이 이루어집니다. Erlang 프로세스는 매우 저렴하기 때문에 (OS 스레드보다 훨씬 저렴) 느슨하게 결합 된 설계를 장려하여 프로세스가 종료되면 시스템의 아주 작은 부분 만 다운 타임을 경험합니다. 일반적으로 감독자는 나머지 시스템에 거의 영향을주지 않고 해당 프로세스 하나를 다시 시작합니다.

4. 비동기 메시지 전달 . 한 프로세스가 다른 것을 말하고 싶을 때 Erlang 언어의 일류 연산자가 있습니다. 메시지 전송 프로세스는 수신자가 메시지를 처리 ​​할 때까지 기다릴 필요가 없으며 전송 된 데이터의 소유권을 조정할 필요가 없습니다. Erlang의 메시지 전달 시스템의 비동기 기능적 특성은 모든 것을 처리합니다. 이는 시스템의 한 부분에서 다운 타임이 다른 부분에 미칠 수있는 영향을 줄이므로 높은 가동 시간을 유지하는 데 도움이됩니다.

5. 클러스터링 . 이것은 이전 시점에서 따온 것입니다. Erlang의 메시지 전달 메커니즘은 네트워크의 시스템간에 투명하게 작동하므로 전송 프로세스는 수신자가 별도의 시스템에 있는지 신경 쓰지 않아도됩니다. 이는 전체 시스템 가동 시간에 해를 끼치 지 않고 개별적으로 다운 될 수있는 여러 머신간에 워크로드를 분할하는 쉬운 메커니즘을 제공합니다.

99.9999999 %의 가용성 수치는 자주 인용되지만 근본적으로 잘못된 통계입니다. AXD-301 팀원 중 한 명인 Mats Cronqvist 는 2010 년 샌프란시스코 Erlang Factory 컨퍼런스에서이 정확한 가용성 통계에 대해 논의한 프레젠테이션 (비디오) (제가 참석했습니다)을했습니다. 그에 따르면 British Telecom이 AXD-301을 사용하여 "5 노드 년"의 시험 기간 (2002 년 1 월부터 9 월까지) 동안 주장했다고합니다. 평가판이 끝날 때까지 14 개의 노드가 실시간 트래픽을 전송했습니다.

Cronqvist는 이것이 전체 AXD-301 역사 또는 일반적으로 Erlang을 대표하는 것이 아니며 Joe Armstrong이 계속해서 이것을 인용하여 Erlang의 신뢰성에 대한 과도한 기대를 불러 일으키는 것에 만족하지 않는다고 명시했습니다. 다른 사람들은 파이브 나인이 더 현실적인 수치라고 썼습니다 .

저는 Erlang의 전문적인 사용이 실제로 매우 가용성이 높은 시스템으로 이어질 수 있다고 믿지만 과대 광고를 줄이고 자하는 열렬한 Erlang 지지자이자 개발자라는 것을 명시해야합니다. 물론 나는 Cronqvist의 사실 표현이 정확하다고 생각하며, 달리 믿을 이유가 없습니다.

이러한 통계에 대한 나의 이해는 생산중인 모든 AXD301 시스템에서 계산된다는 것입니다. AXD301에 심각한 문제가 발생하면 0.631 초 이상 다운 될 것으로 예상 할 수 있습니다. 이 pediod 동안 다른 AXD301이 네트워크 작동을 유지합니다.

그러나 AXD301을 실행하는 모든 시간의 합계를 합산하면 AXD301이 실패한 비율을 계산하면 99.999999 %가됩니다.

그것이 내가이 그림을 이해하는 방법입니다.

이 도움을 바랍니다.