Zero Configuration: Simple is best는 어렵다.에서 언급한 바와 같이, 현재 제작중인 소프트웨어의 모듈/시스템수는 엄청나게 증가해버렸다. 서로 연동해야하는 모듈이 많으니 이리저리 입력해야하는 네트워크 정보(각 노드의 IP와 Port)가 매우 많다. (제어UI에는 8개정도지만, 세밀하게 조정에 들어가면 셀수 없이 많다.) 이런 상황에서 각 노드들을 효율적으로 관리하려면 어찌해야 할까?
각 노드마다 설정을 전부 해야한다고 생각하면, 그 복잡도는 노드가 추가될 때마다 선형적으로 증가하며, 각 노드에서 필요한 기능-설정이 추가될 때 마다 기하급수적으로 증가한다. 언제까지 이런 설정을 반복하고 있을 수는 없다. 쉽게 생각할 수 있는 해결책은 중앙집중관리노드를 도입해서 실제로 기능을 수행하는 각 노드들이 중앙 노드를 바라보고 있는 Star형 토폴로지를 구현하는 것이다. 이러면, 문제가 해결될 것 같지만 크게 2가지 관점에서 결정적인 단점을 가지고 있다.
- 전체 시스템의 복잡도는 전혀 줄어들지 않으며, 다만 중앙 노드로 압축될 뿐이다.
- 중앙 노드에 장애가 발생할 경우, 전체 시스템이 동작하지 않는다.
이런 단점을 최소화하는 모델이라면, 전화번호부 모델이 있다. Java Jini나 Web Service에서 활용하는 Naming 서비스 혹은 Directory서비스가 대표적인 사례인데, 필요한 노드(서비스)의 위치를 관리하는 Naming 서비스를 도입하여, 각 노드간 통신을 위해 필요한 위치정보를 URL 혹은 그와 유사한 형태로 저장하여 서로 Lookup을 하게 하는 것이다. Respository나 Directory 서비스의 복잡도는 상대적으로 낮은 편이다. 권한이나 인증같은 부분을 제외하고 생각하면, 등록과 조회만 있으면 된다. TCP/IP네트워크에 익숙하다면, DNS를 생각하면 된다.
실제 데이터를 주고 받기 위한 통신 채널은 각 노드사이에서 형성되므로 Naming 서비스는 단지 ‘전화번호부’의 역할만을 수행한다. 각 노드들 역시 Naming 서비스의 위치만 설정해주면 되므로, 설정은 더더욱 간편해진다.
중앙 노드로 압축되는 복잡도의 문제는 어느정도 해소가 가능해졌지만, 중앙 노드의 장애에 대한 문제점은 아직 남아있다. Naming 서비스의 이중화로 해결할 수 있는 문제일 수도 있겠지만, Naming 서비스의 조회결과를 로컬에 캐쉬하는 방법도 있다. 노드들이 급격하게 위치를 변경하는 시스템이라면 독이 될 수 있지만, 위치가 그렇게 급격하게 변하지 않는 다소 정적인 시스템이라면 충분히 위력을 발휘할 것으로 생각된다.
멋져 보이지만, 마지막 결정타가 하나 남아있다. 이건 ‘Zero-Configuration’ 이 아니다. 여전히 사용자는 Naming 서비스의 위치를 ‘설정’해주어야 한다. TCP/IP에는 Broadcasting이라는 멋진 방법이 존재한다. 각 노드들에 Naming 서비스를 설정하지 않아도 Broadcasting으로 Naming 서비스를 찾아낼 수 있다. 물론, 수동 설정도 가능해야 하겠지만 말이다. 🙂
