on Hot Code Upgrade in Erlang

1) 재컴파일 %erl -make

2) 업그레이드 >stdlib:upgrade(XXX).

용도는 다음과 같다.

1) 잘못된 패치 수정

서비스중에 업그레이드하는 것은 물론 위험하다.
하지만, 잘못된 패치를 고치기 위해, 전체를 셧다운 시키고, 업그레이드하는 것은 정말 원하는 것이다. 하루에 매출에 24억이라면, 2시간 셧다운은 2억. 심정적인 매출 피해는 그보다 더 할 것이다. 특히, 이벤트로 프로모션중에 전체를 셧다운 시키다면, 프로그래머들은 신뢰를 잃기 쉽다. 신뢰를 잃지 않더라도, 좋은 신뢰를 주긴 어렵지 않겠는가? 책임자 입장에서 할 말이 없고, 핑계만 댈 뿐이다. 
24시간 서비스를 해야하는 커뮤니케이션 시스템을 위해서라면, 특히 필요한 기능이라고 본다.

2) 클라이언트 디펜던시가 없는 서버 업데이트를 런타임에

클라이언트 수정이 필요하다면, 클라이언트까지 업그레이드까지 필요하기 때문에, 추가적인 업그레이드 시스템이 필요할 것이다. 그 문제는 따로 다뤄야 할 것이다.


클라이언트 수정이 필요없는 업데이트라면, 새로운 서비스를 런타임에 추가할 것이다.
물론 위험한 일이다. 왜냐하면, 업그레이드간의 디펜던시가 복잡할 경우에는 기존 서비스가 작동하지 않을 것이기 때문이다.

LPMUD와 같은 시스템은 이런 식으로 업그레이드를 했었던 사례가 있다. LPMUD와 같은 시스템에서는 개발자가 모든 것을 결정했었다. 자신이 결정하고, 자신이 프로그램했다. 그러기에 가능했다.또한, 클라인트는 단순한 tty터미널이었다. LPMUD를 운영해본 사람이라면, 그 매력을 잊을 수 없으리라. 그래서, 이 시스템을 현재의 3D MMOG에도 적용하고 싶을 것이다.

하지만, 요즘과 같이 복잡한 시스템을 런타임에 수정한다는 것은 미친짓 일 것이다. 따라서, 서비스 중에 업그레이드는 하는 것은 꼼꼼히 따져보고 봐야 할 일이고, 생각해 볼 문제이다. 아직 그런 체계를 어떻게 해야 할지는 아직 모르겠다. 프로젝트를 진행해보면서 풀어야 할 문제로 보인다.

다만,최소한 개발팀내에서 개발중의 업데이트는 가능할 것 같다. 크게 메리트는 아닐지 몰라도...

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^