간단히 말해서 전체 시스템의 이점을 위해 프로그램, 프로세스 및 스레드에 대한 수준을 낮은 수준으로 설계해야합니까?
실패가 발생합니다. 프로세스는 죽는다. 우리는 재난을 계획하고 때때로 그것을 복구합니다. 그러나 우리는 예측할 수없는 프로그램 사망을 거의 설계하고 구현하지 않습니다. 우리는 서비스 가동 시간이 서비스를 계속 유지하기를 원하는 한 오래되기를 바랍니다.
이 개념의 매크로 예는 일부 시나리오에서 AWS 인스턴스를 임의로 종료하는 Netflix의 Chaos Monkey 입니다. 그들은 이것이 문제를 발견하고 더 많은 중복 시스템을 구축하는 데 도움이되었다고 주장합니다.
내가 말하는 것은 저수준입니다. 아이디어는 전통적으로 오래 실행되는 프로세스를 임의로 종료하는 것입니다. 이를 통해 설계에 중복성을 강제하고 궁극적으로보다 탄력적 인 시스템을 생성해야합니다.
이 개념은 이미 이름이 있습니까? 이미 업계에서 사용되고 있습니까?
편집하다
의견과 답변을 바탕으로 내 질문에 명확하지 않은 것 같습니다. 명확성을 위해 :
- 예, 무작위로 의미합니다
- 예, 나는 생산을 의미합니다.
- 아니요, 테스트 용이 아닙니다.
설명하기 위해, 나는 다세포 유기체에 비유하고 싶습니다.
본질적으로 유기체는 많은 세포로 구성됩니다. 세포는 스스로 중복성을 만들어 포크로 죽습니다. 그러나 유기체가 기능하기 위해서는 항상 적절한 종류의 세포가 충분해야합니다. 이 이중화 시스템은 부상을 입을 때 치유를 용이하게합니다. 세포는 죽어서 유기체는 살아 있습니다.
무작위 사망을 프로그램에 통합하면 더 큰 시스템이 중복 전략을 채택하여 실행 가능한 상태로 유지할 수 있습니다. 이 같은 전략이 예측할 수없는 다른 종류의 장애에도 불구하고 시스템을 안정적으로 유지하는 데 도움이됩니까?
그리고 이것을 시도한 사람은 무엇입니까? 이미 존재하는 경우 더 자세히 읽고 싶습니다.
답변
아니.
우리는 프로그램이 이러한 예외적 인 조건을 잘 처리하는지 확인하기 위해 적절한 불량 경로 처리를 설계하고 테스트 사례 (및 기타 프로세스 개선)를 설계해야합니다. 카오스 멍키 (Chaos Monkey)와 같은 것들이 그것의 일부가 될 수 있지만, “무작위 충돌을시켜야한다”라는 요구 를하자마자 실제 무작위 충돌은 테스터들이 버그로 제출할 수없는 것들이된다.
답변
결함 허용 메커니즘 을 테스트하기 위해 소프트웨어 또는 하드웨어에 결함을 도입하는 프로세스를 결함 주입 이라고 합니다.
Wikipedia에서 :
결함 주입 기술은 하드웨어 수준에서 결함을 유도하기 위해 처음 사용 된 1970 년대로 거슬러 올라갑니다. 이러한 유형의 결함 주입을 하드웨어 구현 결함 주입 (HWIFI)이라고하며 시스템 내에서 하드웨어 결함을 시뮬레이션하려고 시도합니다. 하드웨어 결함 주입의 첫 번째 실험은 회로 보드의 연결을 단락시키고 시스템에 미치는 영향을 관찰하는 것 (브리징 결함)에 지나지 않습니다. 주로 하드웨어 시스템의 신뢰성을 테스트하는 데 사용되었습니다. 나중에 특수한 하드웨어가 강한 방사선으로 회로 기판의 특정 영역을 공격하는 장치와 같은이 기술을 확장하기 위해 개발되었습니다. 소프트웨어 기술에 의해 결함이 유발 될 수 있고이 기술의 측면이 소프트웨어 시스템을 평가하는데 유용 할 수 있다는 것이 곧 발견되었다.
답변
예. 아뇨.
주기적 종료는 양날의 칼입니다. 당신은 한쪽 가장자리 또는 다른 쪽 가장자리에 부딪 칠 것입니다. 그리고 두 가지 악 중 작은 것은 상황에 따라 다릅니다.
한 가지 장점은 안정성입니다. 프로그램을 무작위로 (또는 예측 가능하게) 순서대로 강제 종료하면 해당 이벤트를 준비하고 처리 할 수 있습니다. 유용한 작업을 수행 하느라 바쁘지 않으면 프로세스가 종료되도록 보장 할 수 있습니다. 이것은 또한 승인 된 런타임을 넘어서서 나타나는 버그가 생산에서 못생긴 머리를 양육하지 않음을 보장합니다. 이는 좋은 일입니다. Apache HTTPD에는 종료하기 전에 하위 프로세스 (또는 최신 버전의 스레드)가 처리 할 요청 수를 조정할 수있는 설정이 있습니다.
또 다른 장점은 안정성입니다. 프로그램을 오래 실행하지 않으면 시간이 지남에 따라 스스로 나타나는 버그를 찾지 못할 것입니다. 마지막으로 이러한 버그 중 하나가 발생하면 프로그램이 잘못된 답변을 반환하거나 전혀 반환하지 않을 가능성이 훨씬 높습니다. 더구나, 같은 작업의 많은 스레드를 실행하면 시간 또는 카운트로 인한 버그가 한 번에 매우 많은 수의 작업에 영향을 미쳐 오전 3 시까 지 사무실로 이동할 수 있습니다.
동일한 스레드를 많이 실행하는 설정 (예 : 웹 서버)에서 실용적인 해결책은 수용 가능한 실패율을 초래하는 혼합 된 접근 방식을 취하는 것입니다. 100 개의 스레드를 실행하면 99 : 1의 단기 대 장기 비율을 실행하면 하나만 장기 버그를 나타내는 반면 다른 하나는 실패하지 않고 수행하는 모든 작업을 계속 수행합니다. 100 % 오래 실행하면 모든 스레드가 동시에 실패 할 위험이 훨씬 높아집니다.
단일 스레드가있는 경우 다시 시작하는 동안 데드 타임으로 인해 실제 작업이 성공적으로 완료되면 원하지 않는 대기 시간이 발생할 수 있기 때문에 실행하고 실패하게하는 것이 좋습니다.
두 경우 모두 프로세스를 감독하여 무언가를 즉시 다시 시작할 수 있도록하는 것이 중요합니다. 또한 프로세스 실행 기간에 대한 초기 결정을 석재로 주조해야한다는 법률은 없습니다. 운영 데이터를 수집하면 시스템을 조정하여 장애를 허용 가능한 수준으로 낮출 수 있습니다.
임의 종료를 사용하지 않는 것이 좋습니다. 시간 관련 버그를 해결하기가 더 어려워지기 때문입니다. 카오스 몽키 (Chaos Monkey)는 감독 소프트웨어가 작동하도록하기 위해 약간의 문제가있다.
답변
당신은 정말로 무작위를 의미합니까? 소프트웨어가 무작위로 자살하는 것은 끔찍한 생각처럼 들립니다. 그게 무슨 요점입니까?
나는 당신이 정말로 의미하는 바는 오래 실행되는 스레드 / 프로세스에 대해 현실적이어야하며 실행 시간이 길수록 더 많은 종류의 숨겨진 버그가 발생하고 비 기능으로 들어갈 가능성이 높다는 것을 인정합니다. 상태. 따라서 순전히 실용적인 수단으로 프로세스와 스레드의 수명이 제한되어야합니다.
90 년대 후반 아파치 웹 서버는 이와 같은 것을 사용했다고 생각합니다. 그들은 스레드가 아닌 작업자 프로세스 풀을 가지고 있었고 각 작업자 프로세스는 고정 된 수명 후에 종료됩니다. 이것은 병리학 적 상태에 빠진 작업자 프로세스에 의해 서버가 독점되는 것을 막았습니다.
나는 그 지역에서 한동안 일하지 않았으므로 이것이 여전히 사실인지 모르겠습니다.
답변
내가 본 문제는 그러한 프로그램이 죽으면 “아, 그것은 또 다른 임의 종료일뿐입니다. 걱정할 필요가 없습니다”라는 것입니다. 그러나 수정이 필요한 실제 문제 가 있다면 어떨까요? 무시됩니다.
개발자가 mystaykes, 프로덕션 시스템에 버그를 발생시키는 버그, 하드웨어 오류 등으로 인해 이미 “무작위로”프로그램이 실패합니다.이 문제가 발생하면 이에 대해 알고 싶어서 고칠 수 있습니다. 프로그램으로 죽음을 설계하는 것은 실패 할 가능성을 높이고 중복성을 증가 시키게되어 비용이 많이 듭니다.
중복 시스템을 테스트 할 때 테스트 환경에서 무작위로 프로세스를 종료하는 데 아무런 문제가 없지만 프로덕션 환경에서는 그렇지 않습니다. 며칠에 한 번씩 라이브 프로덕션 시스템에서 두 개의 하드 드라이브를 꺼내거나 항공기로 컴퓨터 한 대를 비활성화하여 승객으로 가득 차게 할 수 있습니까? 테스트 시나리오에서-좋습니다. 라이브 프로덕션 시나리오에서는 그렇지 않습니다.
답변
애플리케이션에 임의 종료 코드를 추가 할 필요는 없습니다. 테스터는 응용 프로그램 프로세스를 임의로 종료하는 스크립트를 작성할 수 있습니다.
네트워킹에서는 프로토콜 구현을 테스트하기 위해 신뢰할 수없는 네트워크를 시뮬레이션해야합니다. 이것은 프로토콜에 내장되지 않습니다. 장치 드라이버 수준에서 또는 일부 외부 하드웨어로 시뮬레이션 할 수 있습니다.
외부에서 달성 할 수있는 상황에서는 프로그램에 테스트 코드를 추가하지 마십시오.
이것이 생산을위한 것이라면 그것이 심각하다는 것을 믿을 수 없습니다!
첫째, 프로세스가 갑자기 종료 되어 진행중인 트랜잭션과 휘발성 데이터가 손실되지 않는 한 개념을 정직하게 구현하지는 않습니다. 계획된, 우아한 출구는 무작위로 시간을 정하더라도 실제 충돌을 처리하기 위해 아키텍처를 준비하는 데 적절하게 도움이되지 않습니다.
응용 프로그램에 실제 또는 실제 오작동이 발생하면 실제 오작동과 마찬가지로 경제적 피해를 입을 수 있으며 의도적 인 경제적 피해는 기본적으로 거의 정의에 의한 범죄 행위 입니다.
소프트웨어 작동으로 인해 발생하는 손해에 대해서는 민사상 책임을 면제하는 라이센스 계약 조항을 벗어날 수 있지만, 이러한 손 상이 의도적으로 발생한 경우 형사 책임을 면제하지 못할 수 있습니다.
이와 같은 스턴트에 대해서도 생각하지 마십시오. 가능한 한 안정적으로 작동하고 특수한 빌드 또는 구성에만 가짜 실패 시나리오를 배치하십시오.
답변
내결함성 분산 시스템의 맥락에서 ” 사전 예방 적 복구 “및 ” 회춘 ” 을 검색 하여 임의의 결함 (예 : 프로세스 충돌뿐만 아니라 손상된 데이터 및 잠재적으로 악의적 인 동작)도 처리 할 수 있습니다. 프로세스 (추상적 인 의미에서 실제로 VM 또는 호스트 일 수 있음)를 얼마나 자주 그리고 어떤 조건에서 다시 시작해야하는지에 대한 많은 연구가있었습니다. 직관적으로, 배신자 프로세스보다 죽은 프로세스를 처리하는 것을 선호하는 접근법의 장점을 이해할 수 있습니다 …