Log file based replay system 어떻게 생각하세요?
안녕하세요. 그동안 계속 보기만 하다가 글을 올리게 되었습니다.
제가 그동안 경험해 온 것들에 대한 의견을 듣고 싶습니다. 많은 의견 부탁드립니다.
Log file based replay system 이란 말 그대로 로그파일을 이용해서 프로그램을 똑같이 동작시켜 보자는 것입니다.
아래 부분은 제가 작성하고 있는 문서중에 몇 부분만을 발췌했습니다. 너무 길면 않좋아 하실까봐서요. ^^;;
- 아이디어 배경
Program 개발과정에서 여러 가지 문제로 인해 Program 내부에는 항상 bug가 존재한다. 이러한 Bug를 수정하기 위해서는 Error 상황을 재현해 내는 것이 가장 중요하고 필수적이다. 같은 Error를 재현해 낸다면 문제의 대부분을 해결할 수 있을 것이다.
하지만 현재 Program이 처한 상황은 이러한 Error 재현이 물리적, 공간적으로 힘들다.
서버실의 컴퓨터는 외부의 접속으로부터 차단되어 있고, 각종 보안 규정에 따라 시스템에 접근하기도 힘들다. 또한 지리적으로 해외에 있는 경우에는 방문하기도 쉽지 않다.
운 좋게 문제가 있는 시스템에 접근한다고 하더라도 Error 상황이 발생할 때까지 기다려야 한다. 이런 모든 상황들이 Error 재현에 상당한 방해로 작용을 하고 이 때문에 기업으로서는 상당한 유지보수 비용의 발생을 초래한다.
현재 폰노이만 구조의 컴퓨터에서는 동일 입력이 들어오면 동일한 결과를 출력하도록 되어있다. Program의 동작도 마찬가지로 입력/처리/출력 의 3단계로 볼 때 동일한 입력이 들어오면 항상 같은 출력을 내도록 되어있다. 여기에 착안하여 입력 값을 잘 정리하여 Log file에 쌓아 놓는다면 이를 잘 읽어서 다시 프로그램의 입력으로 집어 넣을 수 있다면 프로그램은 동일한 결과를 보여줄 수 있을 것이다.
- 장점 및 부수 효과
* 극소량의 추가코드 필요 – Log file based replay system을 구현하기 위해서 많은 코드가 필요하지는 않다. 적절하게 Log File을 생성해주고, 이를 이용해서 적절하게 Program의 입력으로 넣어주는 코드만 있으면 기본적인 형태의 Log file based replay system은 구축 가능하다.
* 간편한 Error의 재현 – Error가 발생한 시스템의 로그, 설정파일 등 필요한 파일만 있으면 Lab에서 Error의 재현이 가능하다.
* 개발, 유지보수, 테스트 프로세스의 확립 – Error 상태의 종합적인 관리가 가능해지면서 Error patch의 정확성을 향상시킨다.
* 개발, 유지보수, 테스트 비용의 극적 절감 – 1인당 처리 Error 건수의 비약적인 증가.
* 빠른 고객 대응 – 전체적인 Error 처리 기간이 짧아지게 되므로 고객 불만이 최소화된다.
- 재현되지 않는 Error의 종류 : 메모리 침범 등 실행하는 컴퓨터에 따라 다르게 나타나는 부분에 의한 Error.
이것이 실제로 가능하겠느냐 라고들 많이 말씀하시지만 실제로 구현 가능합니다.
물론 실제로 구현하기 위해서는 좀 더 고민해 보아야 할 것들이 많습니다. 이러한 시스템은 한 번 구현해 보시면 그 편리함에 정말 놀라시게 될 것입니다.
또한 고민의 산물로 몇몇 좋은 기능들도 추가될 수 있구요. 저도 처음에는 로그를 어떻게 남기는 것이 좋을까에서 고민하게 되었습니다.
좋은 생각이지만,
좋은 생각이지만, vmware에 이미 구현되어 있습니다. VM 위에서 실행하면서 record한 후에 그 image file만 있으면 다른 (그렇지만 같은 configuration의) VM에서 replay 할 수 있습니다. (replay하는 중간에 실행을 가로채서 그 이후부터는 image file에 의존하지 않고 실제 유저의 input등에 따라서 실행되게 할 수도 있습니다)
vmware에 구현되어있는 방법의 문제
실제로 vmware에서 작동 중인 에러에 대해서는 이 방법이 좋습니다.
하지만 실제 기계에서 Error가 발생한 사항에 대해서 다시 vmware에서 Error를 발생시켜야 하는 부담이 있습니다.
재현하기 쉬운 Error의 경우 쉽겠지만 그렇지 않은 경우는 어떻게 다시 재현할 것인지 생각을 해봐야겠죠? <- 이럴바에는 그냥 재현하는 방법을 개발자에게 다시 알려주는 편이 훨씬 편합니다.
만약 프로그램을 배포해서 사용자측에서 생긴 Error는 어떻게 처리하실 건가요? 사용자에게 vmware를 통해 에러를 레코드 해달라고 해야할까요? 이런 경우 또한 심히 문제가 됩니다.
특히 요새 문제가 되는 HTS(증권사 홈트레이딩 시스템) 등에서는 어떻게 처리하실 수 있을까요? 이 경우도 vmware를 배포해서 record를 하면서 사용하라고 해야할까요?
또 하나의 문제는 vmware 한대로 구성이 되지 않는 시스템의 경우는 어떻게 하나요? 즉 에러는 웹어플리케이션에서 나지만 재현을 위해서는 웹서버에 접속을 해야 하고 웹서버는 DB에도 접속을 해야합니다.
그렇게 되면 전산실의 모든 컴퓨터를 vmware로 다시 다 구성해야 할지도 모릅니다. 상당히 넌센스겠죠?
VMWare의 재현 방법은 현재 3rd party의 record & replay tool 과 크게 다를 부분이 없습니다. 이 부분에 대한 약점은 사용자 UI 기반입니다. 즉 UI의 object를 구분하여 각 object에 대한 window event를 저장하는 방식입니다. 따라서 UI가 없는 서버 프로그램 같은 경우는 테스트의 대상이 될 수 없습니다.
당연히 가능하고 좋은 아이디어이지만
몇 가지 문제를 고려하셔야 합니다.
저도 비슷한 아이디어를 제가 제작한 센서 네트워크 시뮬레이터에 사용했습니다. 연구중인 프로토콜이 분산 프로토콜이고, 이벤트가 랜덤하게 일어나도록 되어 있어서 프로토콜에 예상치 못한 에러가 있는 경우 일반적인 방법으로 디버깅하기가 힘듭니다. 에러가 언제 일어날지도 모르구요. 모든 입력값을 다 저장해 놓은 뒤 같은 상황에서 플레이백할 수 있도록 해 놓아서 디버깅 혹은 프로토콜을 개선시키기가 훨씬 수월했죠.
그런데 이런 것을 일반화시키기에는 몇 가지 문제가 있는 것 같습니다. 제가 생각할 수 있는 것은
1) 프로그램의 루틴 중 일부가 randomized routine 인 경우 두 가지 중 하나를 보장해야 합니다.
1-1) 동일한 입력 값에 대해서 random-number generator 의 상태에 관계 없이 동일한 출력을 "보장" 하는지;
1-2) 그렇지 않다면 모든 중간 random value 를 저장하여 대체해야 합니다.
1-1 의 예는 (randomized) quicksort 같은 게 있지만, 1-1 이 아닌 경우도 많습니다. 즉 각 세부 루틴이 deterministic 시스템으로 볼 수 있을 때까지는 잘게 쪼개야 합니다.
2) floating point round-off error 가 루틴의 동작에 결정적인 영향을 미치는 경우도 간혹 있습니다.
즉, floating point number 같은 경우 "정확히 저장" 해야 될 필요가 있는 경우가 있습니다. pi 를 3.1416 으로 저장하여 재생시키는 것은 대부분 문제가 없지만, 문제가 될 수 있는 dynamic system 역시 존재합니다.
3) 고려되지 않은 부분에 대한 에러는 기본적으로 재생할 수 없습니다.
이 부분은 짚어 주신 부분입니다. 즉 memory dump 를 모두 저장하지 않는다면 memory 관련 에러는 재생할 수 없는 것입니다. 이것을 일반화시켜 생각하면 "log-based replay system"을 어디까지 모델링하느냐의 문제로 귀결됩니다. 시스템의 많은 부분에 의존하는 복잡한 프로그램에서 이러한 기능을 완전하게 활용하고자 한다면, 시스템의 많은 부분을 "모델링" 하고 기록을 저장하고 그것을 다시 플레이백하는 것을 고안해내야 합니다. 시스템의 거의 모든 부분이 모델링되어야 하는 상황이 되면? 결국 가상 머신을 만들어서 디버깅용으로 프로그램 내부에 심어놓는 것이 됩니다. 결국 프로그램 내부에 vmware 를 심는 꼴이죠.
4) Log-file 을 저장하는 데 드는 system load
만약 저장해야 할게 많아지면? 실시간으로 저장하기 위해서는 시간을 희생해야 하고, lagged logging 을 하려면 메모리를 희생해야 합니다. 특정 서버 어플리케이션의 경우는 결코 사용하고 싶지 않을 지도 모릅니다.
즉, log-based replay system을 실현화시키기 위해서는, 어떤 종류의 어플리케이션에 적용할 수 있는지, 대상이 되는 프로그램의 abstraction 을 어떻게 정확히 모델링할 것인지 등을 고민하셔야 한다고 봅니다.
제 센서 네트워크 시뮬레이터의 경우, 모든 시뮬레이션 파라미터값, 시뮬레이션 중간에 생성되는 랜덤 넘버들, 시뮬레이션 이벤트 큐를 다 저장하고 플레이백했습니다. 각 센서의 state 는 이 값들에 의해 deterministic 하게 결정되기 때문에 저장할 필요가 없었습니다.
이런 문제에 대해 많이 고민해 보셨군요
이 문제를 논의해 보고 싶은 이유가 이런 시스템을 구성한다면 여러가지로 잇점이 많기 때문입니다.
따라서 고민해 볼 가치가 충분하다고 생각됩니다.
예를 들어주신
1) randomized routine의 경우는 저는 1-2) random value를 저장해서 replay할 때는 저장된 random value를 사용하는 방식을 선택했습니다. 이 방법이 프로그램적으로 손쉽기 때문이었습니다.
2) floating point 의 경우의 지적도 말씀하신 부분이 맞습니다.
3) 의 경우는 다른 테스팅 방법으로 코드를 견고하게 하는 방법을 추천드립니다.
static code analysis 라는 방법이 이런 메모리류의 버그를 잡아내는데에 있어서 효율적입니다. 이렇게 코드를 견고하게 해놓으면 메모리 관련에러에 따른 어려움은 어느정도(?) 해결하실 수 있습니다.
4) 이 부분도 지적하신 대로 입니다. 저장할 부분이 많아지면 당연히 부하가 생기기 마련입니다. 제가 아직까지 이렇게 커다란 입력 log를 쌓는 프로그램을 만들어 보진 못했으나 로그만을 저장하는 log redirect 를 만드시거나 입력이 네트웍쪽이라면 미러링을 통해서 다른 머신에서 저장하셔도 될 듯합니다. 이렇게 하시면 일단은 로그를 쌓는 부하로 부터 어느정도 자유로우실 수 있습니다.
문제는 이렇게 부하가 어느정도 생기더라도 이런 시스템을 구축하는 것이 훨씬 잇점이 많다는 것입니다.
더구나 이렇게 입력이 많은 시스템에서 문제가 생긴다면 말 그대로 모래 사장에서 바늘 찾기가 될 공산이 많습니다. 일일히 패킷을 분석하고 프로토콜에 맞는지 검사하는 일또한 만만치 않은 작업이기 때문입니다.
이 밖에도 고려해야 할 사항이 너무나 많습니다.
한가지 더 말씀을 드리면 thread의 경우 입니다. thread A, B 가 있을 경우 cpu를 사용하는 순서가 정해져 있지 않습니다. 즉 A, B가 최초 실행된 순서와 재현시 실행된 순서가 다를 수 있습니다. 이런 경우가 문제가 되는 시스템이라면 이 또한 고민의 대상이 됩니다.
특히나 과거의 에러를 현재 재현할 수 있다는 것, 또한 이것이 close system 상에서 재현이 가능하다는 것, 이러한 것이 충분히 잇점이 있다면 구현해 볼 가치가 있다는 것입니다.
위의 분도 고민 끝에 이런 시스템을 구성해서 많은 도움을 받으신 것 같습니다.
저의 경우 이것을 일반화해서 특정지으려는 것은 절대 아님니다. 책에서는 이런 know-how에 대해서 절대 언급하지 않는 부분이기에 이런 경험을 가져보신 분들의 경험을 공유해서 좀 더 나은 환경에서 작업하시길 바랄 뿐입니다.
상당히 진척된 듯 한 프로젝트가 상당수 있군요.
오늘 아침에 이메일로 온 세미나 리스트를 보다가 마침 우연히도 이에 관한 세미나가 있는 걸 보고 참고하시라고 올립니다.
http://code.google.com/p/chronicle-recorder/
http://code.google.com/p/chronomancer/
시도해보지는 않았는데, 전자는 리코더이고 후자는 GUI 프론트엔드인 듯 합니다. 세미나 abstract 는
"Omniscient debugging" proposes to record a complete program execution and let developers query the recording to debug their programs. Because all program state over all times is immediately available, omniscient debugging can directly support the basic debugging task of tracing effects back to causes. This technology is about to break through into the mainstream, thanks to improved implementation techniques, virtual machines, increases in disk capacity, and increasing processor core count. I will describe the design and implementation of "Chronicle", a prototype which shows that omniscient debugging of large, real-world applications such as Firefox is feasible on commodity hardware. In fact, the real challenge is to design a UI that can take maximum advantage of omniscience. I will demonstrate a prototype UI ("Chronomancer") and argue that "time travel debugging" is too limited a vision; superior debugging experiences can be obtained by integrating information across times into a single view.
BIO: Robert O'Callahan obtained a PhD in programming languages and software engineering tools from CMU. After a few years at IBM Research working on dynamic program analysis, he returned to New Zealand to work on Mozilla full-time. Now he manages a growing team of Gecko developers in Auckland while still trying to write lots of code.
강연자는 모질라 재단에서 일하고, 파이어폭스등에 쓰고 있거나 쓰게 될걸로 보입니다.
이런 종류의 디버깅을 omniscient debugging 이라고 부르나 보군요. 구글로 검색해보면 여러 개의 프로젝트가 존재하는 듯 합니다.
좋은 정보 감사합니다.
그런데 Omniscient debugging 기법은 아래와 같은 단점이 있네요.
- 단점
* 기록에 따른 프로그램의 성능 부담. – 대체로 10배 이상 느려짐.
* 메모리 소비량. ODB는 초당 100MB 정도를 자료를 만들어 낸다. 20초에 약 2GB의 주소 공간이 필요.
* 해결방법
특정 사건들만 기록한다( 실패 몇 초 전부터만, 또는 미리 정해진 메모리를 채울 정도만 등. )
시스템의 특정 부분들만 기록한다( 실행 시점 라이브러리의 사건들은 생략하는 등. )
개별 사건을 압축해서 저장한다.
우선 제가 생각하는 방식과는 다른 관점에서 출발한 Debugging 방법입니다.
이 방법은 프로그램의 실행 history를 아주 세세하게 기록하는 방법입니다. 프로그램의 수행 전체에 대해서 모든 변화(메모리 포함)를 기록하는 방식입니다.
따라서 위에 언급한 엄청난 정보량이 관건이 될 것 같습니다. 이것은 따로 프로그램을 실행시키지 않고서도 과거 실행관점을 세밀하게 살펴볼 수 있는 잇점이 있습니다.
반면에 제가 생각하는 방식은 Omniscient debugging 과는 많이 다릅니다.
우선 (기본적으로)입력값만 기록하고, 실제로 입력값을 프로그램에 넣어서 replay하면서 똑같은 상황을 재현할 수 있도록 하는 것입니다.
따라서 기록에 의한 성능 저하가 Omniscient debugging과는 비교할 수 없을 정로도 작고, 또한 배포용 프로그램 같은 곳에서도 사용할 수 있을 것입니다.
기본적으로 replay하면서 debugging을 할 수 있는 방식입니다.
이 방식의 장점은 첫번째로 구현하기가 상대적으로 상당히 쉽습니다.!!!!
따라서 어떤 종류의 프로그램에서도 적용하기 쉽다는 것입니다. 또한 투자 대비 효과가 훨씬 좋고 비용도 저렴하다는 것입니다.
문제가 되는 메모리쪽 오류, 즉 내 컴퓨터에서는 정상적으로 동작하는데 다른 컴퓨터에서는 오류가 발생하는 류의 오류들의 경우는 다른 효율적인 방법을 선택하실 수 있습니다. 위에서 언급해 드린 static code analysis 방식이 그것입니다.
입력값만 저장하는 방식으로는 한계가 있습니다.
뭐 프로그램 종류에 따라, 입력값만 저장하는 방식으로도 충분한 경우는 있습니다.
하지만, 서버와 같은 경우에는 여러 client의 입력값들이 어떤 타이밍으로 들어왔느냐, 어떤 child process/thread 가 어떤 timing에 context switching 이 일어나면서 어떤 일이 발생했느냐 등등이 매우 중요하게 작용합니다. (항상 그런 것은 아닙니다만, 보통 잡기 힘든 에러들은 이런 곳에 숨어 있습니다.)
이런 경우에는 입력값만 로깅하는 방식으로는 재현하기 무진장 어려워지게 됩니다.
한계를 가지고 있다는 것을 알면...
말씀하신 것에 대해서는 충분히 공감을 하고 있습니다.
그래서 제가 윗글에 thread에 대해서도 고려를 해야 한다고 적어 놓은 것입니다.
입력값의 타이밍에 대한 문제는 들어온 순서에 대해서 기록을 해 놓으면 전혀 문제가 될 것이 없습니다. 하지만 말씀하신 context switching에 관한 문제라면 다른 양상입니다.
이것은 조금만 다르게 생각을 해보면 다른 방법이 있습니다. 예를 들면 제가 전에 테스트해본 1부터 1000까지 출력을하는 2개의 thread 프로그램입니다.
이것은 프로그램에 따라 2가지 결과를 얻을 수 있습니다. 하나는 전혀 출력 결과를 예측하지 못하게 되는 프로그램과 2개의 thread가 교차로 하나씩 출력 시킬 수 있는 프로그램을 작성할 수도 있습니다. 이런 것에 대해서 살펴볼만 한것이 serialized(직렬화)라는 프로그래밍 기법입니다. 실행순서가 문제가 된다면 인위적으로 실행순서를 맞춰주셔야 겠지요?
이럴 경우 2개의 thread가 정확히 교차하면서 하나씩 출력을 하는 프로그램을 작성하는 것이 과연 어려운 것인가?
물론 성능의 차이는 있을 수 있겠습니다만 log를 바탕으로 재현을 해낼 수 있다는 장점이 있다면 충분히 고려해 볼 만한 것이라고 생각합니다.
무념무상
이런 아이디어는 "날아다니는 자동차"와 같습니다.
5초만 생각하면 자동차가 다 날아다니면 도로를 깔 필요도 없고 교통체증도 없고 기술적으로 크게 어려운 것도 아니니 (과연?) 무진장 좋은데 단점은 없는 아주 훌륭한 아이디어가 아닌가라는 생각이 들지만...
대략 5분쯤 더 생각하면 "그럴 리가 있나!"라는 생각이 들게 됩니다. (우리집 지붕 위에서 추돌사고가 나면 어쩔 것이며...)
5초 생각해서 "훌륭한데!"라는 생각이 드는 것의 99%는 누군가 이미 생각하고 구현하고 테스트하고 저널에 논문을 쓰고 창업하고 투자받고 (십중팔구) 망해서 아주 뽕을 다 뽑아놓았습니다. 그런데 널리 쓰이고 있지 않으면 뭔가 한계가 있고 이미 그쪽 전문가들은 다 알고 있을 거라고 생각하시면 대충 맞습니다.
* 더 자세한 문제점은 바로 위의 molla 님에게 물어보세요. (후다다다다다닥~~~)
하늘을 날아다니는 자동차......
제가 남긴 주제가 허황된 것이라고 생각을 하시는것 같습니다. 위의 ODB도 이런 경험을 가진 사람들이 생각해낸 산물이고 이또한 그 자체로 가치가 있다고 생각합니다.
위에 sblade님도 이와 비슷한 아이디어를 도입해서 좋은 결과를 얻으신것 같습니다만, 너무 비관적으로 생각을 하시는 것 같아서 안타깝습니다.
현재 이런 시스템을 도입하고 있는 사례도 있습니다. 방식은 다르지만 oracle DB 같은 경우도 transaction을 그대로 재현해 내는 기능을 가지고 있습니다.
제가 이런 주제를 올린 이유는 제가 실제로 이런 시스템을 개발해서 많은 도움을 얻었기 때문입니다. 전혀 하늘을 나는 자동자가 아닙니다!
물론 모든 시스템에 적용하려면 넘어야할 많은 부분이 존재할 수 있습니다.
문제는 현재 개발자들의 고충을 해결해 보려는 노력이 중요하다고 생각합니다.
제가 보는 문제는, 개발자들이 Error를 해결하기 위해서는 Error의 재현이 반드시 필요하다고 생각하기 때문입니다.
외부에서 접근할 수 없는 시스템에서 Error가 발생하는 경우 어떻게 처리를 해야할까요? 직접 방문해서 Error가 날만한 부분에 다시 Log를 심고 Error를 기다렸다가 해결을 해야할까요?
이런 유지보수해야 할 고객이 외국에 있거나 그 수가 많은 경우는 어떻게 해야할 까요?
혹시 다른 좋은 방법이 있으시면 알려주시면 한 수 배워보도록 하겠습니다.
이것은 생산성의 문제도 포함이 됩니다.
위에 molla 님께서 문제점을 많이 알고 계신듯 한데, 같이 공유하면 같이 고민할 수 있을 것 같습니다.
이런 부분에 대해서 많이 생각해 보신것 같은데 많은 조언 부탁드리겠습니다.
주제가 허황되었다기
주제가 허황되었다기 보다는 이미 있는 연구/프로젝트에 대한 서베이가 좀 부족하고, 프로젝트의 범위(scope)가 불명확해 보입니다.
이런 류의 연구/주제를 deterministic replay라고 하는데, scholar.google.com 에서 검색해 보면 이미 꽤 많은 연구가 되어 있습니다.
그리고 bluesky님께서 UI event만 저장한다고 잘못 생각하고 있는 VMWare의 record&replay의 경우에도 UI event만 저장하는 것이 아니라 non-deterministic한 event를 모두 저장합니다.
게다가 VMWare Player에 자신의 application을 embedding해서 배포하는 것도 어렵지 않고 이미 많은 프로그램들이 그렇게 하고 있습니다. 언급하신 증권사의 HTS의 경우에도 VMWare Player에 embedding해서 배포하면 됩니다. (물론 VMWare의 record&replay가 silver bullet이라는 것은 아닙니다)
프로젝트의 범위에 대해서도, 환경이 뭔지 타겟이 어떤 것들인지가 좀 불명확합니다. Managed environment (Java, C# LLVM 등등...) 을 가정하고 있는건가요, 아니면 Unmanaged environment(C/C++)를 가정하고 있나요? 목표로 하는 것은 어떤 건가요? (예를 들어 Apache Portable Runtime 과 같은 layer를 만들어서 그 API들만을 사용했을 때에는 deterministic replay가 가능하다는 것을 보장해 주는 건가요?) 어떤 non-deterministic 한 event까지 deterministic replay를 보장하며 그렇게 했을 때에 적용 가능한 Application들의 범위는 어떤가요? (예를 들어 unmanaged environment에서 memory에 관련된 버그에 대해 deterministic replay를 보장하지 않는다면 그렇게 크게 소용이 있지 않습니다.)
다른 연구/프로젝트들의 내용을 *제대로* 잘 살핀 후에, 차별화 할 내용이 무엇인지, 그렇게 했을 때 의미가 있는지를 생각해 보는 것이 좋겠습니다. 그렇지 않으면 그냥 ad-hoc한 solution이 되고 맙니다.
범위와 한계 및 효용성
제가 앞서 이런 부분에 대해서 명확히 말씀을 드리지 않은 것 같습니다.
우선 제가 현재 SI가 아닌 Package 프로그램을 전세계로 판매하는 업체에서 일을 하고 있습니다. 물론 서버 프로그램도 있고 client프로그램도 있습니다.
개발은 미국에서 하고 있고 한국법인에서 한국내 판매를 하고있습니다.
한국에서 사용하고 있는 저희 제품에 문제가 생길 경우 저희 조직의 프로세스는 아래와 같습니다.
1. 고객의 이의 제기
2. 한국내 고객센터에서 접수
3. 한국의 엔지니어가 1차 확인
4. 고객의 제품설치 환경을 확인하여 본사에 문제 제기
5. 본사 엔지니어가 2차 확인
6. 코드를 수정해야 하는 버그라면 본사 엔지니어가 본사 개발자에게 문제 이관
7. 개발자가 문제 확인 후 패치 코드 작성
대충 위와 같은 형태로 버그 패치 프로세스가 진행이 됩니다.
현장에서 느끼는 가장 큰 문제는 7번의 개발자에게 패치코드를 받기까지 가장 어려운것이 문제가 있다는 것을 인식시키는 것입니다. 대부분 로그를 전달하는 것이겠지만 이 로그 자체가 명확하게 어느 부분이 잘 못되었다는 것을 집어주지는 않습니다. 보통 짧게는 2~3차례 이와 같은 필요한 로그를 전달하는 과정이 필요하게 됩니다.
따라서 버그가 발생했다는 것을 개발자에게 인식시켜주기까지 너무 많은 시간과 노력이 필요하게 됩니다. 이것은 비단 저희 회사 뿐만이 아닐것이라고 생각됩니다.
이런 과정에서 문제를 개발자에게 가장 빨리 인식시키는 좋은 방법은 같은 에러를 낼 수 있도록 도와주는 것이라고 생각됩니다. 이런 아이디어에서 생각은 출발되었습니다.
SI처럼 개발자가 항상 상주하면서 문제를 해결할 수 있다면 이런 과정이 필요없겠지요.
그래서 좀 더 보편적으로 Error를 쉽게 재현할 수 있는 방법, 즉 언어의 종류에 최대한 구속되지 않고 외부 툴의 의존 없이 이런 환경을 구성할 수 없을까라는 생각을 하게되었습니다. 또한 작성할 코드도 작고 원래 시스템의 성능에 영향을 적게 미치면 좋겠다는 생각도 하게됩니다.
그래서 제가 처음 적어놓았던 부분이 좀 광범위하게 느껴졌을거라 생각됩니다.
다시 정리하자면,
* 목표는 Error를 재현할 수 있는 시스템을 구성해보자.
- 제약사항
1. 언어의 제약이 없는 방법이 좋겠다.
2. 구현 방법을 제한하지는 않는다.
3. 외부 툴의 도움없이 구현할 수 있으면 좋겠다.
4. 원래의 시스템의 성능에 최대한 영향을 적게 미치는 방법이 좋을것 같다.
5. 특정 환경(Lab)에서만 사용 가능한 방법은 피한다.
이 정도가 될 것 같습니다.
윗글에 대한 제 의견을 적어보겠습니다.
VMware의 경우 non-deterministic한 event를 모두 저장한다고 하셨는데 이경우 event의 양에 따라서 적용 여부가 결정될 것 같습니다. 그 예는 ODB도 마찬가지라고 생각됩니다. 또한 Error 상황이 반드시 VMWare에서 레코딩할 때 발생해야 합니다.
HTS의 경우 VMWare Player에 포함시켜서 배포하면 된다고 하셨는데 이건 말 그대로 가능한 수준입니다. 현실에 도입하려면 문제가 많다는 것을 말씀하신 분도 알고 계시리라 생각됩니다.
1. OS를 포함한 배포 VMware의 크기
2. 설치되어 있는 OS의 라이센스 문제
3. 프로그램 기동시간이 오래걸림(OS 부팅 후 다시 프로그램이 구동될 때 까지 걸리는 시간)
4. 문제가 생겼을때 이것을 다시 개발팀으로 보내야 하는 크기.
5. 크기에 따른 전송 비용을 사용자가 부담.(전송하는 동안 컴퓨터를 끄면 안되기 때문에 생기는 전기료 및 인터넷 회선비용 등)
이런 문제를 감수하고라도 VMWare를 이용해서 HTS를 배포할만한 증권사가 실제로 있을까요?
또 가장 의구심이 드는 것은, HTS가 접속하는 서버의 데이타가 계속 바뀌는데 정확한 Replay가 될까요?????
record할 당시의 주가가 replay 당시의 주가와 완전히 다른데 제대로 동작이 가능할까요???? <- 정말 궁금해서 그러는데 아시는 분 계시면 좀 알려주세요~
위에서 이런 류의 연구가 많이 진행되고 있다고 하셔서 저도 찾아보았습니다.
하지만 제생각은 이런 연구가 많다는 것은 사람들이 이런 문제에 대해서 많이 고민을 하고 있다라고 생각되어 반갑습니다.
deterministic replay라는 것이 현재는 정확한 Debug를 위해서 촛점이 맞추어져 있는 것 같습니다.
보다 많은 정보를 저장해서 과거 시점으로 프로그램을 되돌리는 것에 초점을 두고 있습니다. 이것은 개발Lab 내에서는 상당히 필요한 작업입니다.
개발자 입장에서 Error에 대한 판단을 위해서 많은 정보가 필요하기 때문입니다. 하지만 개발Lab에서 가능한 이런 류의 많은 정보 수집 작업은 운용 시스템에서는 무리가 되는 것이 많습니다.
예를 들어, Monitoring 과 Debugging의 차이라고 보시면됩니다.
보통 운용하는 시스템에는 Debugging 시스템을 걸지 않습니다. 단지 Monitoring 시스템을 설치할 뿐이죠.