Erlang의 Let-it-crash 철학-다른 곳에 적용 할 수 있습니까?
방어 적 프로그래밍을 사용하지 말고 프로세스가 충돌하도록하는 Erlang (또는 Joe Armstrong 's?)의 조언 은 (잔해를 추적하려는 불필요한 경비원으로 코드를 오염시키는 대신) 이제는 내가 왜 그렇게 많이 낭비했는지 궁금합니다. 수년 동안 오류 처리에 대한 노력!
내가 궁금한 것은-이 접근 방식이 Erlang과 같은 플랫폼에만 적용됩니까? Erlang에는 프로세스 감독 트리에 대한 간단한 기본 지원이 포함 된 VM이 있으며 프로세스를 다시 시작하는 것이 정말 빠릅니다. 최상위 수준의 예외 처리기, 오류 코드, null 결과 등을 사용하지 않고 감독 트리를 다시 만드는 데 개발 노력을 기울여야합니다 (Erlang 세계에 있지 않을 때).
이러한 접근 방식 변경이 .NET 또는 Java 공간에서 잘 작동 할 것이라고 생각하십니까?
모든 곳에 적용 가능 합니다. "let it crash"패턴으로 소프트웨어를 작성하든 그렇지 않든 상관없이, 예를 들어 하드웨어가 실패 할 때 충돌이 발생합니다. "Let it crash"는 현실을 견뎌야하는 모든 곳에 적용됩니다. Quoth James Hamilton :
하드웨어 오류로 인해 즉각적인 관리 조치가 필요한 경우 서비스는 비용 효율적이고 안정적으로 확장되지 않습니다. 전체 서비스는 사용자의 관리 상호 작용 없이도 실패에서 살아남을 수 있어야합니다. 장애 복구는 매우 간단한 경로 여야하며 해당 경로는 자주 테스트해야합니다. Stanford의 Armando Fox는 장애 경로를 테스트하는 가장 좋은 방법은 서비스를 정상적으로 종료하지 않는 것이라고 주장했습니다. 그냥 열심히 실패하십시오. 이것은 직관적이지 않은 것처럼 들리지만 실패 경로가 자주 사용되지 않으면 필요할 때 작동하지 않습니다.
그렇다고 "가드를 사용하지 않는다"는 의미는 아닙니다. 그러나 충돌하는 것을 두려워하지 마십시오!
예, 모든 곳에 적용 할 수 있지만 어떤 맥락에서 사용되어야하는지 기록하는 것이 중요합니다. @PeterM이 지적했듯이 응용 프로그램 전체가 충돌하는 것은 많은 경우에 치명적일 수 있음을 의미 하지는 않습니다 . 목표는 전체적으로 충돌하지 않지만 내부적으로 오류를 처리 할 수있는 시스템을 구축하는 것입니다. 우리의 경우에는 연간 몇 분 정도의 다운 타임이 예상되는 통신 시스템이었습니다.
기본 설계는 시스템을 계층화하고 시스템의 중앙 부분을 분리하여 작업을 수행하는 다른 부분을 모니터링하고 제어하는 것입니다. OTP 용어로는 감독자 와 작업자 프로세스가 있습니다. 감독자는 작업자가 모든 실제 작업을 수행하는 동안 충돌시 올바른 방법으로 다시 시작하는 것을 목표로 작업자 및 기타 감독자를 모니터링하는 역할을합니다. 기능을 엄격하게 분리하는이 원칙을 사용하여 시스템을 계층으로 적절하게 구성하면 대부분의 오류 처리를 작업자에서 관리자로 격리 할 수 있습니다. 당신은 작은올바른 경우 시스템의 나머지 부분에서 오류를 처리 할 수있는 오류 방지 오류 커널. 이 맥락에서 "let-it-crash"철학이 사용됩니다.
가능한 한 적은 수의 장소에서 실제로 처리한다는 목표로 어디서나 오류와 실패에 대해 생각하는 역설을 얻습니다.
오류를 처리하는 가장 좋은 방법은 물론 오류와 시스템에 따라 다릅니다. 때로는 프로세스 내에서 로컬로 오류를 포착하고 처리하려고 시도하는 것이 가장 좋으며 작동하지 않는 경우 다시 실패하는 옵션을 사용합니다. 여러 작업자 프로세스가 협력하는 경우 모든 프로세스를 중단하고 다시 시작하는 것이 가장 좋습니다. 이것을하는 것은 감독자입니다.
무언가 잘못되었을 때 오류 / 예외를 생성하는 언어가 필요하므로이를 트랩하거나 프로세스를 중단시킬 수 있습니다. 오류 반환 값을 무시하는 것은 같은 것이 아닙니다.
이를 fail-fast라고합니다. 실패에 신속하게 대응할 수있는 팀이 있다면 좋은 패러다임입니다.
NAVY에서는 모든 파이프와 전기가 벽의 외부에 설치됩니다 (더 공용 벽면에 설치하는 것이 좋습니다). 이렇게하면 누출이나 문제가있는 경우 더 빨리 감지 될 수 있습니다. NAVY에서 사람들은 실패에 응답하지 않은 것에 대해 처벌을 받기 때문에 매우 잘 작동합니다. 실패는 빠르게 감지되고 신속하게 처리됩니다.
누군가가 실패에 대해 신속하게 조치를 취할 수없는 시나리오에서는 실패가 시스템을 중지하도록 허용하거나 실패를 삼키고 계속 진행하는 것이 더 유익한 지 여부가 의견의 문제가됩니다.
나는 실제 상황의 데이터에 의존하는 프로그램을 작성하고 충돌하면 물리적 손상에 큰 $$를 초래할 수 있습니다 (수익 손실에 큰 $$는 말할 것도 없습니다). 방어 적으로 프로그래밍하지 않으면 순식간에 직장을 잃을 것입니다.
즉, Erlang은 즉시 다시 시작할 수있을뿐만 아니라 다시 시작된 프로그램이 팝업되고 주변을 둘러보고 "내가했던 일 이었어요!"라고 말할 수있는 특별한 경우 여야한다고 생각합니다.
제 동료들과 저는이 주제에 대해 특별히 기술적 인 측면이 아니라 도메인 관점과 안전에 초점을 맞춘 주제에 대해 생각했습니다.
질문은 "충돌하게하는 것이 안전합니까?"입니다. 또는 더 나은 "Erlang의"let it crash "와 같은 견고성 패러다임을 안전 관련 소프트웨어 프로젝트에 적용하는 것이 가능합니까?"
답을 찾기 위해 우리는 산업적, 특히 의학적 배경을 가진 현실에 가까운 시나리오를 사용하는 소규모 연구 프로젝트를 수행했습니다. 여기 ( http://bit.ly/Z-Blog_let-it-crash )를 살펴보세요 . 다운로드 할 문서도 있습니다. 네가 생각하는 것을 말해줘!
개인적으로 많은 경우에 적용 할 수 있고, 특히해야 할 오류 처리가 많을 때 (안전 관련 시스템) 바람직하다고 생각합니다. 항상 Erlang을 사용할 수는 없지만 (실시간 기능 누락, 실제 내장 된 지원 없음, 고객의 의견 ...), 그렇지 않으면 구현할 수 있습니다 (예 : 스레드, 예외, 메시지 전달 사용). 나는 아직 그것을 시도하지 않았지만 나는 그것을하고 싶다.
IMHO 일부 개발자는 확인 된 예외를 거의 가치가없는 코드로 처리 / 포장합니다. 처리하고 값을 추가하지 않는 한 메서드가 원래 예외를 throw하도록 허용하는 것이 더 간단합니다.
참조 URL : https://stackoverflow.com/questions/4393197/erlangs-let-it-crash-philosophy-applicable-elsewhere
'program story' 카테고리의 다른 글
| Haskell에서 .hs 파일을 가져 오는 방법 (0) | 2020.12.31 |
|---|---|
| Log4j를 사용하여 패키지의 로그 수준을 어떻게 변경합니까? (0) | 2020.12.31 |
| IIS 7.5를 사용하여 ASP.NET MVC에서 Json 결과를 압축하는 방법 (0) | 2020.12.30 |
| jQuery-복잡한 HTML 조각을 만드는 모범 사례 (0) | 2020.12.30 |
| 모듈 및 / 또는 패키지에서 Python 클래스 구성 (0) | 2020.12.30 |