무작위로 스스로를 죽이는 프로그램을 설계해야합니까? [닫은]

간단히 말해서 전체 시스템의 이점을 위해 프로그램, 프로세스 및 스레드에 대한 수준을 낮은 수준으로 설계해야합니까?

실패가 발생합니다. 프로세스는 죽는다. 우리는 재난을 계획하고 때때로 그것을 복구합니다. 그러나 우리는 예측할 수없는 프로그램 사망을 거의 설계하고 구현하지 않습니다. 우리는 서비스 가동 시간이 서비스를 계속 유지하기를 원하는 한 오래되기를 바랍니다.

이 개념의 매크로 예는 일부 시나리오에서 AWS 인스턴스를 임의로 종료하는 Netflix의 Chaos Monkey 입니다. 그들은 이것이 문제를 발견하고 더 많은 중복 시스템을 구축하는 데 도움이되었다고 주장합니다.

내가 말하는 것은 저수준입니다. 아이디어는 전통적으로 오래 실행되는 프로세스를 임의로 종료하는 것입니다. 이를 통해 설계에 중복성을 강제하고 궁극적으로보다 탄력적 인 시스템을 생성해야합니다.

이 개념은 이미 이름이 있습니까? 이미 업계에서 사용되고 있습니까?

편집하다

의견과 답변을 바탕으로 내 질문에 명확하지 않은 것 같습니다. 명확성을 위해 :

• 예, 무작위로 의미합니다
• 예, 나는 생산을 의미합니다.
• 아니요, 테스트 용이 아닙니다.

설명하기 위해, 나는 다세포 유기체에 비유하고 싶습니다.

본질적으로 유기체는 많은 세포로 구성됩니다. 세포는 스스로 중복성을 만들어 포크로 죽습니다. 그러나 유기체가 기능하기 위해서는 항상 적절한 종류의 세포가 충분해야합니다. 이 이중화 시스템은 부상을 입을 때 치유를 용이하게합니다. 세포는 죽어서 유기체는 살아 있습니다.

무작위 사망을 프로그램에 통합하면 더 큰 시스템이 중복 전략을 채택하여 실행 가능한 상태로 유지할 수 있습니다. 이 같은 전략이 예측할 수없는 다른 종류의 장애에도 불구하고 시스템을 안정적으로 유지하는 데 도움이됩니까?

그리고 이것을 시도한 사람은 무엇입니까? 이미 존재하는 경우 더 자세히 읽고 싶습니다.

아니.

우리는 프로그램이 이러한 예외적 인 조건을 잘 처리하는지 확인하기 위해 적절한 불량 경로 처리를 설계하고 테스트 사례 (및 기타 프로세스 개선)를 설계해야합니다. 카오스 멍키 (Chaos Monkey)와 같은 것들이 그것의 일부가 될 수 있지만, "무작위 충돌을시켜야한다"라는 요구 를하자마자 실제 무작위 충돌은 테스터들이 버그로 제출할 수없는 것들이된다.

결함 허용 메커니즘 을 테스트하기 위해 소프트웨어 또는 하드웨어에 결함을 도입하는 프로세스를 결함 주입 이라고 합니다.

Wikipedia에서 :

결함 주입 기술은 하드웨어 수준에서 결함을 유도하기 위해 처음 사용 된 1970 년대로 거슬러 올라갑니다. 이러한 유형의 결함 주입을 하드웨어 구현 결함 주입 (HWIFI)이라고하며 시스템 내에서 하드웨어 결함을 시뮬레이션하려고 시도합니다. 하드웨어 결함 주입의 첫 번째 실험은 회로 보드의 연결을 단락시키고 시스템에 미치는 영향을 관찰하는 것 (브리징 결함)에 지나지 않습니다. 주로 하드웨어 시스템의 신뢰성을 테스트하는 데 사용되었습니다. 나중에 특수한 하드웨어가 강한 방사선으로 회로 기판의 특정 영역을 공격하는 장치와 같은이 기술을 확장하기 위해 개발되었습니다. 소프트웨어 기술에 의해 결함이 유발 될 수 있고이 기술의 측면이 소프트웨어 시스템을 평가하는데 유용 할 수 있다는 것이 곧 발견되었다.

예. 아뇨.

주기적 종료는 양날의 칼입니다. 당신은 한쪽 가장자리 또는 다른 쪽 가장자리에 부딪 칠 것입니다. 그리고 두 가지 악 중 작은 것은 상황에 따라 다릅니다.

한 가지 장점은 안정성입니다. 프로그램을 무작위로 (또는 예측 가능하게) 순서대로 강제 종료하면 해당 이벤트를 준비하고 처리 할 수 ​​있습니다. 유용한 작업을 수행 하느라 바쁘지 않으면 프로세스가 종료되도록 보장 할 수 있습니다. 이것은 또한 승인 된 런타임을 넘어서서 나타나는 버그가 생산에서 못생긴 머리를 양육하지 않음을 보장합니다. 이는 좋은 일입니다. Apache HTTPD에는 종료하기 전에 하위 프로세스 (또는 최신 버전의 스레드)가 처리 할 요청 수를 조정할 수있는 설정이 있습니다.

또 다른 장점은 안정성입니다. 프로그램을 오래 실행하지 않으면 시간이 지남에 따라 스스로 나타나는 버그를 찾지 못할 것입니다. 마지막으로 이러한 버그 중 하나가 발생하면 프로그램이 잘못된 답변을 반환하거나 전혀 반환하지 않을 가능성이 훨씬 높습니다. 더구나, 같은 작업의 많은 스레드를 실행하면 시간 또는 카운트로 인한 버그가 한 번에 매우 많은 수의 작업에 영향을 미쳐 오전 3 시까 지 사무실로 이동할 수 있습니다.

동일한 스레드를 많이 실행하는 설정 (예 : 웹 서버)에서 실용적인 해결책은 수용 가능한 실패율을 초래하는 혼합 된 접근 방식을 취하는 것입니다. 100 개의 스레드를 실행하면 99 : 1의 단기 대 장기 비율을 실행하면 하나만 장기 버그를 나타내는 반면 다른 하나는 실패하지 않고 수행하는 모든 작업을 계속 수행합니다. 100 % 오래 실행하면 모든 스레드가 동시에 실패 할 위험이 훨씬 높아집니다.

단일 스레드가있는 경우 다시 시작하는 동안 데드 타임으로 인해 실제 작업이 성공적으로 완료되면 원하지 않는 대기 시간이 발생할 수 있기 때문에 실행하고 실패하게하는 것이 좋습니다.

두 경우 모두 프로세스를 감독하여 무언가를 즉시 다시 시작할 수 있도록하는 것이 중요합니다. 또한 프로세스 실행 기간에 대한 초기 결정을 석재로 주조해야한다는 법률은 없습니다. 운영 데이터를 수집하면 시스템을 조정하여 장애를 허용 가능한 수준으로 낮출 수 있습니다.

임의 종료를 사용하지 않는 것이 좋습니다. 시간 관련 버그를 해결하기가 더 어려워지기 때문입니다. 카오스 몽키 (Chaos Monkey)는 감독 소프트웨어가 작동하도록하기 위해 약간의 문제가있다.

당신은 정말로 무작위를 의미합니까? 소프트웨어가 무작위로 자살하는 것은 끔찍한 생각처럼 들립니다. 그게 무슨 요점입니까?

나는 당신이 정말로 의미하는 바는 오래 실행되는 스레드 / 프로세스에 대해 현실적이어야하며 실행 시간이 길수록 더 많은 종류의 숨겨진 버그가 발생하고 비 기능으로 들어갈 가능성이 높다는 것을 인정합니다. 상태. 따라서 순전히 실용적인 수단으로 프로세스와 스레드의 수명이 제한되어야합니다.

90 년대 후반 아파치 웹 서버는 이와 같은 것을 사용했다고 생각합니다. 그들은 스레드가 아닌 작업자 프로세스 풀을 가지고 있었고 각 작업자 프로세스는 고정 된 수명 후에 종료됩니다. 이것은 병리학 적 상태에 빠진 작업자 프로세스에 의해 서버가 독점되는 것을 막았습니다.

나는 그 지역에서 한동안 일하지 않았으므로 이것이 여전히 사실인지 모르겠습니다.

내가 본 문제는 그러한 프로그램이 죽으면 "아, 그것은 또 다른 임의 종료일뿐입니다. 걱정할 필요가 없습니다"라는 것입니다. 그러나 수정이 필요한 실제 문제 가 있다면 어떨까요? 무시됩니다.

개발자가 mystaykes, 프로덕션 시스템에 버그를 발생시키는 버그, 하드웨어 오류 등으로 인해 이미 "무작위로"프로그램이 실패합니다.이 문제가 발생하면 이에 대해 알고 싶어서 고칠 수 있습니다. 프로그램으로 죽음을 설계하는 것은 실패 할 가능성을 높이고 중복성을 증가 시키게되어 비용이 많이 듭니다.

중복 시스템을 테스트 할 때 테스트 환경에서 무작위로 프로세스를 종료하는 데 아무런 문제가 없지만 프로덕션 환경에서는 그렇지 않습니다. 며칠에 한 번씩 라이브 프로덕션 시스템에서 두 개의 하드 드라이브를 꺼내거나 항공기로 컴퓨터 한 대를 비활성화하여 승객으로 가득 차게 할 수 있습니까? 테스트 시나리오에서-좋습니다. 라이브 프로덕션 시나리오에서는 그렇지 않습니다.

애플리케이션에 임의 종료 코드를 추가 할 필요는 없습니다. 테스터는 응용 프로그램 프로세스를 임의로 종료하는 스크립트를 작성할 수 있습니다.

네트워킹에서는 프로토콜 구현을 테스트하기 위해 신뢰할 수없는 네트워크를 시뮬레이션해야합니다. 이것은 프로토콜에 내장되지 않습니다. 장치 드라이버 수준에서 또는 일부 외부 하드웨어로 시뮬레이션 할 수 있습니다.

외부에서 달성 할 수있는 상황에서는 프로그램에 테스트 코드를 추가하지 마십시오.

이것이 생산을위한 것이라면 그것이 심각하다는 것을 믿을 수 없습니다!

첫째, 프로세스가 갑자기 종료 되어 진행중인 트랜잭션과 휘발성 데이터가 손실되지 않는 한 개념을 정직하게 구현하지는 않습니다. 계획된, 우아한 출구는 무작위로 시간을 정하더라도 실제 충돌을 처리하기 위해 아키텍처를 준비하는 데 적절하게 도움이되지 않습니다.

응용 프로그램에 실제 또는 실제 오작동이 발생하면 실제 오작동과 마찬가지로 경제적 피해를 입을 수 있으며 의도적 인 경제적 피해는 기본적으로 거의 정의에 의한 범죄 행위 입니다.

소프트웨어 작동으로 인해 발생하는 손해에 대해서는 민사상 책임을 면제하는 라이센스 계약 조항을 벗어날 수 있지만, 이러한 손 상이 의도적으로 발생한 경우 형사 책임을 면제하지 못할 수 있습니다.

이와 같은 스턴트에 대해서도 생각하지 마십시오. 가능한 한 안정적으로 작동하고 특수한 빌드 또는 구성에만 가짜 실패 시나리오를 배치하십시오.

내결함성 분산 시스템의 맥락에서 " 사전 예방 적 복구 "및 " 회춘 " 을 검색 하여 임의의 결함 (예 : 프로세스 충돌뿐만 아니라 손상된 데이터 및 잠재적으로 악의적 인 동작)도 처리 할 수 ​​있습니다. 프로세스 (추상적 인 의미에서 실제로 VM 또는 호스트 일 수 있음)를 얼마나 자주 그리고 어떤 조건에서 다시 시작해야하는지에 대한 많은 연구가있었습니다. 직관적으로, 배신자 프로세스보다 죽은 프로세스를 처리하는 것을 선호하는 접근법의 장점을 이해할 수 있습니다 ...

이것은 실제로 테스트와 다르지 않습니다. 항상 사용 가능한 장애 조치 솔루션 (예 : Netflix)을 설계하는 경우에는 테스트해야합니다. 코드베이스 전체에 뿌려지는 임의의 이탈이 그것을 테스트하는 적절한 방법이라는 것을 모르겠습니다. 실제로 디자인이 발자국을 촬영하는 데 탄력적이라는 테스트를 의도하지 않는 한 코드 주변 환경 을 조작하고 적절하게 작동하는지 확인 하여 테스트하는 것이 더 적절 해 보입니다 .

중복 시스템을 설계하지 않는 경우 아니요-임의의 이탈을 추가했기 때문에 해당 기능을 추가하지 않아야합니다. 무작위 종료를 제거하면 문제가 발생하지 않습니다. 환경이 여전히 실패 할 수 있습니다.이 시점에서 환경을 지원되지 않거나 수정하지 않음으로 분필로 만들거나 해당 실패에 대비하여 코드를 강화하고 테스트를 추가하십시오. 자주 그렇게, 당신은 당신이 실제로 실현하겠습니다 된다 이중화 시스템 설계 - 시나리오 1을 참조하십시오.

어떤 시점에서 어떤 오류가 처리되는지 또는 더 이상 처리되지 않는지 더 이상 결정할 수 없습니다. 이제 무작위로 깔개를 잡아 당겨 고 장점을 감지 할 수 있습니다.

Netflix 예제의 유일한 흥미로운 점은 프로덕션 환경에서 이러한 테스트를 실행한다는 것입니다. 그것은 어느 정도 의미가 있습니다-일부 버그는 실제로 고립 된 환경에서 시뮬레이션하기가 매우 어렵거나 불가능한 것입니다. Netflix가 프로덕션 환경에서이 작업을 수행하기에 충분히 편안해지기 전에 테스트 환경에서 오랜 시간을 보냈다고 생각합니다. 그리고 실제로 그들이하는 일은 업무 시간 동안 충돌이 일어나도록 노력하는 것입니다. 이는 시장에는 어느 정도 의미가 있지만 다른 많은 사람들에게는 그렇지 않습니다.

당신이 찾고있는 용어는 최근 Nassim Nicholas Taleb : Antifragility에 의해 만들어졌습니다. 그의 책 Antifragile은 확실히 좋습니다. IT에 대한 언급은 거의 없지만 무언의 명백한 유사점이 가장 고무적입니다. 그의 아이디어는 깨지기 쉬운 <->의 규모를 깨지기 쉬운 <-> 튼튼한 <-> 안티 깨지기 쉬운 규모로 확장하는 것입니다. 취약 이벤트는 임의 이벤트로 중단되고, 임의 이벤트로 강력한 관리 기능을 제공하며, 임의 이벤트로 취약하지 않은 이익을 얻습니다.

따라 다릅니다. 프로그래머는 다른 모든 것을 무시하고 특정 도메인에 적용되는 기술을 지나치게 일반화하는 경향이 있음을 알게되었습니다. 예를 들어, 모든 버그를 수정하는 비용으로 프로그램을 출시하는 것이 좋을 수 있습니다 ... 항공기 컨트롤러, 원자로 등을 프로그래밍하지 않는 한 "최적화하지 않음-프로그래머 비용이 프로그램 실행 비용보다 높음"이 필요하지 않습니다. 비교적 간단한 프로그램이 몇 개월 동안 클러스터를 차지할 수 있으므로 HPC에 유효합니다 (또는 많은 사용자가 사용하는 인기있는 프로그램). 따라서 회사 X가 매우 좋은 이유로 Y를 수행하더라도 상황이 다를 수 있으므로 발자국을 따를 필요가 없습니다.

일반적으로 오류 처리 루틴은 코드에서 테스트 된 최악의 부분입니다. 메모리가 부족하거나 중요한 파일이없는 것으로 시뮬레이션하기는 쉽지 않습니다. 이런 이유로 나는 유닉스 커널이 일부 시스템 호출을 무작위로 실패하도록 제안한 텍스트를 읽었다. 그러나 간단한 프로그램을 작성하기가 더 어려워집니다 (오류 처리로 귀찮게하고 싶지 않은 경우 2 개의 파일에서 프로그램을 실행하기 위해 3 개의 C ++ 라이브러리를 함께 연결 해야하는 경우). 예외가 있더라도 GC에서는 일관성있는 상태를 유지해야합니다 (연결된 목록에 노드를 추가하는 과정에서 예외를 상상해보십시오).

분산 된 서비스가 많을수록 실패 횟수가 많을수록 "얼마나 자주"인지 "if"인지 "when"인지에 대한 질문입니다. 데이터 센터에서 RAID의 디스크 교체는 예기치 않은 장애가 아니라 내가 아는 일상적인 작업의 일부입니다. 대규모로 작업하는 경우 한 구성 요소의 고장 확률이 작은 경우에도이를 고려해야하며 무언가 실패 할 가능성이 있습니다.

나는 당신이 정확히 무엇을하고 있는지 알지 못하지만 그 가치가 있는지 아는 것은 실패가 당신이 고려해야 할 것 (비용 무시) 또는 분석하기에 너무 비용이 많이 드는 것 (오류를 취하는 것)인지 생각해야합니다 비용 개발 시간을 고려).

IIS 서버는 특정 양의 메모리를 사용한 후 또는 특정 횟수의 요청을 처리 한 후 또는 지정된 시간 동안 활성 상태로 유지 된 후 작업자 프로세스를 자동으로 재활용하는 구성 가능한 기능을 갖추고 있습니다. ( http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx ) 및 ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx? mfr = true )

IIS와 같은 컨테이너가 IIS를 사용하는 경우 불량 프로세스로부터 서버를 보호하는 것이 좋습니다. 그러나 코드를 충분히 테스트 한 경우에는 의미가 없으므로이 기능을 끄는 것이 좋습니다.

우리는 이미 신뢰할 수없는 계층 (하드웨어, 네트워크)에서 작업하므로 스레드 또는 프로세스를 의도적으로 죽이는 코드를 작성하지 않습니다. 랜덤 킬링은 경제적 인 관점에서 나쁜 생각입니다. 내가 무작위로 충돌하도록 프로그래밍했다면 아무도 내 API를 사용하지 않을 것입니다. 마지막으로, API를 사용하거나 무작위로 충돌하는 스레드가있는 시스템을 사용하려면 밤에 평화롭게 잠을 잘 수 있도록 강력한 모니터링 메커니즘을 만들기 위해 많은 돈을 써야합니다.

대신 시스템 또는 API를 개발하는 경우 시스템의 탄력성을 테스트하기 위해 순수하게 스크립트를 작성하거나 하네스를 사용합니다. 그리고 모든 빌드에서 테스트를 실행하여 잘못된 빌드를 식별합니다. 그러나 이것은 필수 테스트이지만 "충분한"테스트 일 수는 없습니다.

이 아이디어와 관련된 문헌 인 Crash-Only 소프트웨어 (Recovery Oriented Computing이라고도 함)가 있으며 2003 년부터 Candea & Fox의이 usenix 논문 으로 시작할 수 있습니다 . 저자는 무작위 처치 대신 시스템 안정성을 향상시킬 수 있다고 주장합니다. 프로그램을 종료하여 프로그램을 중지 시키므로 종료 버튼으로 단일 종료 스위치와 복구를위한 잘 시작된 단일 시작 경로를 사용하십시오.

아이디어가 얼마나 잘 잡혀 있는지 잘 모르겠지만 특정 기술 중 일부는 여전히 유용합니다. 예를 들어, 요청시 소프트웨어를 종료 할 수없고 특수 감독 프로그램 (예 : 감독자 등)을 사용하는 소프트웨어를 신뢰하지 않고 어떤 프로그램 상태가 필수적인지 신중하게 생각하고 설계된 데이터 저장소에 적절한 시간에 기록되도록하십시오. 복구를 가능하게합니다 (예 : SQL 데이터베이스).

정말 무작위 로요 그러나 장기 실행 프로세스 / 스레드가 지정된 간격으로 또는 주어진 (특정 기준에 따라) 지속 시간 동안 유휴 상태에 있거나 특정 종류의 작업을 실행 한 후 종료 / 다시 시작하는 것이 좋습니다. 오래 실행되는 프로세스는 부실한 것들을 포함하여 불가피하게 상태를 구축하고, 아마도 스왑 공간이 해제되는 것을 막는 메모리에 매달릴 수 있습니다. 이는 종료 될 때 정리되거나 가져 와서 일반적인 시스템 안정성을 향상시킵니다.

디자인하는 응용 프로그램의 유형에 따라 다릅니다.

무작위 충돌은 분산 (네트워크) 시스템의 견고성을 테스트하고 향상시키는 좋은 방법입니다.

Netflix 예제에서 프로그램이 제어 할 수없는 여러 가지 이유로 실패 할 수있는 원격 서비스에 의존하는 경우 (하드 디스크의 성능 저하, 전원 손실, 유성 데이터 센터 충돌 등) 그래도 서비스는 계속 어떻게 든 실행되어야합니다.

어떻게합니까? 중복성을 추가하고 확장하는 것이 일반적인 솔루션입니다.

예를 들어, 서버의 전원 케이블을 통해 마우스를 씹는 경우 서비스를 계속 실행할 수있는 솔루션이 있어야합니다. 예를 들어 대신 사용하기 시작하는 예비 백업 서버를 유지할 수 있습니다.

그러나 프로그램이 네트워크에서 작동하지 않는 단일 프로세스 응용 프로그램 인 경우 복구 할 수있는 방법이 없기 때문에 자체적으로 종료하는 것은 아무 것도 테스트하지 않습니다.

다음은 카오스 원숭이 개념에 대한 추가 주석입니다. http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

우주 방사선 으로 인해 임의의 비트 플립이 발생할 수 있습니다. 이 문제는 인식 되었고 비트 뒤집기가 발생하지 않도록 다양한 기술 이 개발되었습니다.

그러나이를 100 % 수정하는 것은 불가능하며 메모리 손상 은 여전히 ​​문제를 일으킬 수 있으며 이러한 문제는 여전히 발생하고 있습니다 ( 확률이 매우 낮음 ).

이제 귀하의 질문에 대답하십시오. 매우 강력한 시스템을 설계해야하는지 여부에 따라 수행중인 작업에 따라 다릅니다. 우주선을 만들어야하는 경우, 우주선을 강력하게 만드는 것이 좋으며 가능한 모든 문제를 고려해야합니다.

일반적인 데스크톱 응용 프로그램을 디자인해야하는 경우 임의의 충돌을 코드의 버그로 봐야합니다.

아이디어가 터무니없는 것 같지 않습니다.

Android OS는 항상 사용자 앱 / 서비스를 임의로 종료하고 다시 시작합니다. 내 경험상 그것은 오류 조건에 대해 더 깊이 생각하고보다 견고한 아키텍처를 설계하는 데 분명히 도움이되었습니다.