아름다운 네트웍 세상 since 1996.

서버기능장애 !

다이어리|일상 2006/09/04 06:28

서버기능장애 !!

2006년 9월 4일 새벽.

드디어 어제(9월3일) 저녁에 서버동작이 제대로 안되는 현상이 이루어졌다는
메일이 도착했다. 현재는 재기동을 통하여 제대로 동작되고 있지만
그 시점에 서버는 자동복귀도 불가능 형태로 죽었다는 것이다.

서버프로세스가 제대로 기능을 못할때는 프로세스 모니터에 의해서
자동으로 복구되도록 만들어 놓았는데 , 이 부분도 동작 할 수 없는
형태로 서버가 기능동작을 안하게 된것이다.

이러한 문제가 더욱더 많이 나왔으면 하는 바람이다. 실제 서비스가 이루어지기전에..

서버가동후 부터 4개월 정도 만에 발생했다.

해결방안 :

이러한 종류의 문제는 정확한 원인을 찾기가 거의 모래사장에서 바늘찾기라는것이다.
그래서 이러한 문제를 해결하기 위해서 모래사장에서 바늘찾기를 하면 안된다.!

서버프로세스 모니터를 강화하고 , 죽어버린 프로세스 쪽의 모듈을 자동복구가
되도록 수정하려고 한다.

나는 이러한 해결방법을 버그버리기 라고 표현한다.

버그 찾기가 현실적으로 힘들경우 , 버그가 있는 모듈을 싸그리 버려버린다.

문제를 해결할려면 문제를 파악을 해야 한다. 문제를 파악하려면 어느정도
문제가 나오는것을 재현을 해야한다. 하지만 이러종류의 서비스중이며
환경변수가 지속적으로 바뀌고 있는 서버를 수정하는 일은 더 위험한 일이다.
이럴때는 보안을 하는 형태로 문제를 해결하는 유연한 사고가 필요하다.
문제를 해결할때까지 서비스를 중단 시킬수도 없고 문제 파악을 위해서
서버를 마음대로 테스트 할수도 없다. 환경변수가 다른 테스트서버에서의
테스트는 이미 무의미 한다. 그런서버에서는 경우가 애초부터 나오지 않는다.

서버의 테스트와 디버깅이 어려운 이유는 딱 하나이다.
서버의 시스템의 복잡성과 특수성으로 인한
실제환경 변수(접속자수 네트웍환경 프로세스환경)에 따른 영향이 나비효과와
같다.는 것이다.

실제환경 변수가 아닌 곳에서 테스트는 접속자수가 크게 달라지기 시작한 시점부터는
의미가 없어진다.

PS. 불과 몇년전만 하더라도 이러한 문제가 나오면 정확한 원인을 파악하려고
발더둥을 쳤었다. 그 사이 서비스는 그 문제때문에 계속 문제를 일으키고 자신은
자신대로 피폐(?) 해지는 현상이 있었다.
때로는 정확한 문제해결보다는 상황에 맞는 빠른 대처가 중요하다 라는 것을
깨닫고 난다음 조금더 유연해졌다.