설계 뒤엎기 - Hope is good thing!

오늘 정확히는 어제지. 24시가 지났으니.
fork 정확히 prefork 모델에서 multi-threads 모델로 설계가 바뀌었다.
바뀔수 있다. 많이들 그러니까. 하지만 설계일때나 그렇지.
대략, 개발 50% 정도 나간 상황에서 개발모델을 확 바꿔버리면...
개발자들은 어떻게 하라는 것인가.

"바꾸는 놈들도 우끼지만, 그렇다고 그걸 수용하고 만들겠다는 나도 미친놈'이
되어 버린.. 나는 :-) 훗.

대략 수긍하고 긍정적으로 받아들여야지 하고 맘 먹은 이유는...
이전 모델은 일단 prefork - system queue 에 연결해야 한다.
문제는 어쩔수 없이 db-pool 을 이용해야 하는 상황이 나타나서 시스템이 상당히
복잡해져서 하나의 전문에 queue 를 8번 읽고 써야 하는 형태로 변해버렸다.
저렇게 됐을경우 queue를 상당히 꼼꼼하게 관리해야 하며
분배서버가 없는 상황에서 queue 내부에서 msgtype 으로 프론트단의
서버에 분배도 해줘야 하는 극약 처방을 해야 했다.
물론 설계가 조금 불안정하긴 하지만 :-( 그렇다고 설계를 싹 다 바꿔야 할만큼
엉망이지는 않았다.

thread 모델로 바꾸는 조건은 queue를 없앤다. 그리고 프론트가 엔드단을
중간에 thread가 connectless 방식으로 맺고 끊으며 접근한다.
이렇게 햇을 경우 connection 을 유지 했을때 보다 connection 비용이 좀더 들기는 하지만
상대적인 비용이지 절대적으로 느리지 않다.
(그 비용을 오늘 스트레스 테스트해본 결과 대략 10ms 정도 차이가 난다.)

웅. 그래. 커넥션유지하지 않는 조건엔 연결되어 있을 경우 통신회선 점검을 하지
않고, 그걸 리포트 하지 않는다는 조건과 오픈 일주일 연기를 걸었다.

자. 어쨌뜬.. 그래서 프론트와 엔트를 연결하는 중간 비즈니스 단은 포크 모델에서
멀티 쓰레드 모델로 변경되었고, 지난주 목요일 부터 오늘까지해서
좀더 안정적인 쓰레드 모델을 구성하면서 계속적인 스트레스 테스트를 하고 있다.

포크에 비해 쓰레드가 디버그 비용에서는, 개발자 입장에서는 좀더 많이 들지만,
프리-포크와 시스템 큐를 사용하는, 그것도 큐에 동시에 3개의 프로세스가
한 전문에 8번씩 읽고 써야 하는 골치아픈 상황을 해소시키긴 했다.

이래저래, 시킨대로 해야 나중에 뭐라하지 않는 IT 바닥의 고질적인 문제와 더불어
개발 50% 진행에서 레이아웃을 180도 뒤엎은 이런 상황에서 내가 할 수 있는 말은

"Hope is good thing!" 이다.

좌절 금지.  좋은 경험. 희망은 좋은 것...
그래도 괜찮아. 개발기간 일주일 늘려 줬잖아 :-( 비록 지난 시간의 3/1 이상은
버렸더라도.

어쨌든, 지난 몇일간 바뀐 레이아웃을 위해 미치도록 코딩하고 테스트 하고
고생은 많았다.

이게 unix 데몬이니 망정이지.
내일은  좀더 나아지겠지.
(사실 오늘부터 통합테스트 였는데 역시 일주일 뒤로 밀렸다. 으하하하 :-(