반응형

제목: 하이젠버그로부터 애플리케이션을 보호하는 방법(Protecting Applications Against Heisenbugs)

저자: Chris Hobbs, Kernel Developer, QNX Software Systems

문서유형: Industry 화이트 페이퍼( 8 페이지), 2010

 

 

잠복해 있는 하이젠버그의 영향을 줄이거나 제거하기 위한 메커니즘을 제안한 자료


 

하이젠버그

  • 테스팅 또는 필드에서 간혹 목격되지만 예외적이고 일시적인 조건(unusual transient conditions)에서 유발되는 버그여서 반복해서 재현하기 어려운 버그
  • 혹 재현이 된다 하더라도 디버그 코드를 추가하면 그 성격이 달라지거나 모습을 감춘다(버그가 수정되어서 사라진 것이 아니라 일시적으로 모습을 감춘 것일 수 있다).
  • 동기화 멀티프로세싱 아키텍쳐(SMP: synchronous multi-processing architectures) 상의 멀티 쓰레드 프로그램에서 주로 발생

 

문제점

 

아래 아키텍쳐에서는 Provider에 하이젠버그로 문제가 생기면 Client가 서비스를 제공받지 못한다.

 

하이젠버그에 대한 Jim Gray의 고찰

하이젠버그는 특정하고 일시적인 조건하에서만 나타나므로, 동일한 작업이 시스템에 다시 요청되면 이전 실행 경로와 달라져서 버그가 나타나지 않을 가능성이 높다. 

 

이 페이퍼는 하이젠버그의 이러한 성격에 기반하여, Provider에 하이젠버그가 발생하는 경우를 대비해 동일한 request를 동일 코드에 다시 요청하는 방식의 메커니즘을 제안함

 

가상-동기화 복제(Virtually-synchronous replication)

  • Provider가 여러 번 복제되고 여러 다른 프로세서상에서 운영된다 (한 프로세서상에 하나 이상의 복제된 Provider가 존재할 수도 있다).
  • Consumer는 여러 복제된 provider가 있는 것을 알지 못한다(하나의 Provider에게 request를 요청하는 방식과 동일하게 작동한다).
  • 미들웨어가 Consumer request를 복제하여 여러 Provider에 전달한다.
  • 각각의 Provider는 다른 복제된 Provider가 존재하는 것을 알지 못한다. 단 하나의 Provider가 존재하는 것과 마찬가지로 request를 처리한 후 결과를 response 한다.
  • 미들웨어는 여러 복제된 Provider response 들을 받아서 Consumer에게 하나만(대개 가장 먼저 도착한 것) 리턴하고 나머지는 버린다.

 

위 메커니즘에서 미들웨어의 중요한 역할 중 하나는 클라이언트로부터 오는 request들을 여러 복제된 Provider들에게 전달하는데 있어서 적절한 순서(ordering)을 유지하는 것이다(애플리케이션 무결성 보장을 위해). 

 

위 메커니즘에서 여러 복제된 Provider가 실제 동기화되어 동작되는 것은 아니다(가상으로 동기화된다). , 각각의 Provider가 자신들 고유의 타이밍과 쓰레딩 환경에서 가동된다. 따라서 특정 Provider에 하이젠버그가 발생하더라도 다른 복제된 Provider에서도 하이젠버그가 발생할 가능성은 적으며, Consumer는 요청한 서비스의 response를 정상적으로 받을 수 있게 된다. 만일 모든 복제된 Provider에서 똑같이 버그가 발생한다면 이건 하이젠버그가 아니고 항상 재현되는 버그인 보흐버그(Bohrbugs)’이다.

 

제안 방법의 단점

 

복제된 Provider의 개수와 애플리케이션에서 요구되는 ordering 정도에 따라 성능 저하가 생긴다.

 

반응형

+ Recent posts