안녕하세요...
지금 서버를 만들고 있는데여...
죽지 않는 서버를 만들때 어떤것들을 염두해 두고 개발을 해야 하는지여?
지금은 Unix Network programming책을 보구 간단하게 만들어 봤는데여..
너무 허접한것 같아서여...
물리적인 것 말구여 프로그래밍상에서 염두해두어야 할 부분에 대해 고수님들의 의견을 듣고 싶습니다.
그럼 좋은 하루되세요..
대부분의 경우 프로그램이 죽는일은 메모리 침범일것 같은데요.
서버에 요청된 페이지의 입력값이 요구되는 형식과 다른 경우..
문자열 파싱도중 잘못된 매칭으로 프로세서가 죽는것 같습니다.
integer 에 string 혹은..이런 경우가 되겠죠
먼저 프로세서에 메모리 누수 부분이 없는지 확인이 된다면..
다양한 스트링으로 서버에 요청을 하여 걸러내지 못하는 부분이 있는지 테스트해보세요.
..다른문제로 죽는일은 없더군요.
하나의 연결요청에 대해서 독립된 프로세스가 생겨서 동작한다면
fork 된 프로세스는 내부오류로 인해 죽더라도,
main 프로세서는 죽지않고 계속 서비스 되지요.
이 방법이 새로운 클라이언트에게는 죽지않고 계속 서비스 되는 것으로
보이지요.
thread 방식은 단일 프로세스 안에서의 동작이므로, thread 하나에서
메모리 참조 에러가 발생하면 프로세스 자체가 죽어 버립니다.
.....
대부분의 경우 프로그램이 죽는일은 메모리 침범일것 같은데요.
서버에 요청된 페이지의 입력값이 요구되는 형식과 다른 경우..
문자열 파싱도중 잘못된 매칭으로 프로세서가 죽는것 같습니다.
integer 에 string 혹은..이런 경우가 되겠죠
먼저 프로세서에 메모리 누수 부분이 없는지 확인이 된다면..
다양한 스트링으로 서버에 요청을 하여 걸러내지 못하는 부분이 있는지 테스트해보세요.
..다른문제로 죽는일은 없더군요.
죽지 않는 대몬을 만든다라는 것이 프로그램 내부 동작과 함께동작 모델
죽지 않는 대몬을 만든다라는 것이 프로그램 내부 동작과 함께
동작 모델도 중요하지요.
fork
prefork
thread
하나의 연결요청에 대해서 독립된 프로세스가 생겨서 동작한다면
fork 된 프로세스는 내부오류로 인해 죽더라도,
main 프로세서는 죽지않고 계속 서비스 되지요.
이 방법이 새로운 클라이언트에게는 죽지않고 계속 서비스 되는 것으로
보이지요.
thread 방식은 단일 프로세스 안에서의 동작이므로, thread 하나에서
메모리 참조 에러가 발생하면 프로세스 자체가 죽어 버립니다.
아시다시피, 모델에 따른 장단점은 있습니다.
말씀하신 책에 잘 나와 있지요.
The Future !!!
사실 완벽한 서버를 만든다는 것은 매우 힘듭니다.
일반적으로 윗분의 말씀대로 메모리침범을 막기 위해서 모든 데이터는 기록시 길이를 항상 체크하여야 하며, 쓰레드 사용시에는 thread safety한지 확인해야 하며, 메모리의 할당/해제시 확실하게 해야 합니다.
그럼에도 불구하고 서버가 죽을 경우를 대비하여 재실행 및 복구가능한 루틴은 꼭 있어야 합니다.
========================================
* The truth will set you free.
지난번에도 한번 나왔던 문제지만..
program이 비정상적으로 동작한다면 core를 내고 죽어야 하는것이 당연한 수순입니다. 그리고 나서 그 처리를 해주고 거기에 따라 재실행 하는 것이 낳겠죠.
죽지않는 서버를 만들수는 있겠지만 어떤 오류가 발생할 지 모르는 상황에서 무작정 안죽는것만이 능사는 아니겠죠.
서버 오동작 -> core 발생 -> 종료 -> 처리 -> 재실행
이런 수순을 밟는것이 낳을것같은데요..
구조에 대한 이야기
서버의 기능을 보면 네트워크 입출력을 관리하는 부분과
서버 본래의 업무를 처리등으로 나뉘어 지는데,
이 둘을 분리해서 구성하는게 좋다고 봅니다.
업무로직은 여러명이서 작업을 하는 경우가 많은데,
그러면, 구성원의 이해도나 능숙도의 차이에 의해서
버그가 존재하기 마련입니다.
하지만 아래와 같은 구조라면,
업무서버만 오류로 죽고 이 오류는 접속서버가 알아채고
클라이언트에 무리없이 오류를 전달할수 있게 됩니다.
또, 업무 서버는 이 들 프로세스를 관리하는 프로세스가 존재해서
다시 재시작 할수 있겠죠.
접속서버 입장에서는 순수하게 네트워크에 관련된 코드만
있으면 구조가 간단해지면서 버그에 대한 위험도 줄어 들껍니다.
그리고, 로드의 분배도 구현이 쉬워 지구요..
울랄라~ 호기심 천국~!!
http://www.ezdoum.com
Re: 지난번에도 한번 나왔던 문제지만..
이부분은 일반적으로 어떻게 구현하나요? (Monitoring 부분...)
조언바랍니다.
모니터링을 구현하는데 있어서..
일반적으로 어느정도까지 모니터할것인가에 따라서 다릅니다만, 가장 간단하고 쉬운 방법으로는 SHM메모리에 각종 프로세스 정보를 기록해두고 있다가, 죽게되면 signal을 받을테고, 이 경우 shm에 자신의 상태를 쓰고 죽어주면 되겠죠.
얼마나 많은 정보가 필요하는가에 따라서 조금씩 다릅니다. 특정 UDP를 받거나 쏘거나 하면서 체크하는 경우도 있고요.
========================================
* The truth will set you free.
죽지않는 프로세스 혹은 죽지않는 서비스라면 inittab 에 등록하세요
죽지않는 프로세스 혹은 죽지않는 서비스라면 inittab 에 등록하세요.
/etc/inittab 에 action 을 respawn 으로 두고 init q 하면 root 가 이 프로세스를 실행시켜 줍니다. 죽더라도 재실행 시키줍니다.
프로세스자체 오류때문에 죽을수 있기 때문에 프로세스 실행시 최초에 무조건 sleep(5) 하는 루틴을 넣으세요. 최악의 경우에 이 프로세스는 무한히 죽었다 살았다를 반복하게 될수도 있으니까!
내 자식들도 나처럼 !!
Re: 지난번에도 한번 나왔던 문제지만..
Monitoring이라기 보다는 Loging에 가깝죠..
프로세스에서 오동작을 발생시에 나오는 시점의 exception과 시그널을 받아서 Loging 하신다고 생각하시면 맞겠네요. 그리고 Loging을 마치고 재기동을 하면 될 것 같네요.
Re: 지난번에도 한번 나왔던 문제지만..
어떻게 시그널을 받으실건가요 (Monitoring 없이)? :wink: :wink:
[quote]하나의 연결요청에 대해서 독립된 프로세스가 생겨서 동작한
단순히 앞뒤 안가린다면 이분 의견에 강력히 한표.. ^^;
머.. 제 허접한 경험상으론 C로 만들었건 머건 첨에 버그 땜시 가끔 죽기도 하지만..
버그 좀 잡고 나면 소프트웨어가 잘못되서 죽는 경운 거의 없었네욤..
머 리소스 문제라든가 에러 핸들링만 잘 해 준다면 말이죠.. ^^
대게의 경우는 하드웨어가 맛탱이 가서.. -_- +
것두 꼭 주말이나 쉬는 날... 짜증..
댓글 달기