[태그:] Service

작성일자

개발중인 맵 엔진의 지도 서비스 서버의 구조

잠시 정리하는 차원에서 그려본 현재 개발중인 맵 엔진의 서버측의 구조입니다. 아직 DataSource를 감시하는 Controller Service의 구현이 아직 않된 것과 각 DBMS별로 DB API가 구현되지 않은 것을 빼고 말입니다. 현재는 MySQL에 대한 DB API만 구현되어져 있습니다.  하지만 곧, 아래의 구조대로 구현되리라 봅니다.

요즘 드는 생각이… 개발중인 맵 엔진이 점차 완성되 가는 중간 단계에서 혼자 서는 하기 벅차다는 생각이 자주 듭니다. 개발중인 맵 엔진의 많은 부분이 분리가 되어져 있어져 있서 함께 분담해서 개발했으면 하는 바램과 아래의 경우처럼 각 DBMS 별로 DB API 개발을 누군가 같이 했으면 하는 바램도 무척 큽니다. 또한 XGE가 어느 정도 완성이 되면 분석기능과 같은개발중인 맵 엔진 단에 붙일수있는 확장 기능의 개발이 이뤄져야 하는데, 그때 과연 저 혼자 개발하여 정해진 시간안에 완전한 지원이 가능할까… 하는 걱정이 커져갑니다. 그래서.. http://www.gisdeveloper.co.kr/400 를 보시고 많은 지원을 해주시길..

  • XGE WebService는 XGE Web Server(IIS)에 별도의 스레드로 동작함
  • XGE DataSource는 XGE WebService의 요청에 대한 데이터를 수집해 전달함
  • XGE WebService는 XGE DataSource와 통신하기 위해 IPC 방법 중 PIPE를 사용함
  • XGE DataSource는 추상화된 DB API를 가짐
  • DB API의 기능은 DBMS 연결, 데이터의 읽기/쓰기임
  • 각 DBMS에 대한 DB API는 DB API에서 제공하는 스펙을 따라야하며, 스펙을 만족할 경우 어떠한 DBMS 든지 쉽게 활용할 수 있음
  • XGE DataSource Controller Service는 주기적으로 XGE DataSource의 상태를 점검함
  • 만약 XGE DataSource가 다운되었을 경우, Controller Service는DataSource를 재기동함
작성일자

윈도우즈를 위한 웹 기반의 XGE 서비스

개발하고 있는 GIS엔진인 XGE에 대한 웹서비스 개발 중간에 정리도 할겸, 글을 올려봅니다. 초반에 방향을 잘못잡아 헤매기는 했지만… 다른 방향을 선택해 개발에 박차를 가하고 있습니다.

윈도우즈 운영체제 기반의 XGE 웹서비스는 IIS를 웹서버로 하는 ISAPI Extension으로 개발 되었습니다. 참고로, 처음에 의도했던 바는 데이터 교환의 표준인 XML을 기반으로 하며 SOAP 프로토콜을 따르는 WebService을 기반으로 개발하려고 하였으나, 1메가 이상의 바이너리 데이터를 Base64 방식으로 XML로 인코딩하는데 소요되는 시간(6초 이상)이 문제가 되어 그 차선책으로 ISAPI를 선택하게 되었습니다.

ISAPI가 최신 기술인 WebService에 비교해 매우 과거의 기술이기는 하지만, 윈도우즈 운영체계에서 웹을 기반으로 하는 서비스 기술중에서는 가장 심플하고 빠른 기술이며, 윈도우즈의 WebService 역시 그 밑바닦은 ISAPI 기술을 이용해 구현되었고, .NET 기술중의 하나인 ASP.NET을 처리하는 모듈 역시 ISAPI로 구현되었습니다.

이러한 상황으로 미루어… 윈도우즈 운영체제 기반이라면, 웹서비스 모듈을 개발하는데 ISAPI를 선택해도 전혀 무리가 없다고 판단되었습니다. 여타 다른, 특히 유닉스 계열의 플렛폼을 지원하지 못한다는 최악의 시나라이오가 있기는 하지만 말입니다.

XGE 웹서비스를 개발할때 고려했던 점은 아래와 같습니다.

  1. 매우 구조가 간단하다.
  2. 어떤 상황에서도 죽지 않는다.
  3. 요청에 대해 빠르게 응답한다.

순서를 뒤집에 이야기 해보면, 요청에 빠르게 응답하기 위해 ISAPI를 선택했으며… XGE의 특성상 지도 데이터를 빠르게 쿼리하는 것이 중요해서, 이미 빠르게 필요한 지역에 대한 데이터를 수집할 수 있도록 개발되어 나름대로 요청에 대해 빠르게 응답(최악의 상황에서도 0.02초 이내)합니다.

그리고 어떤 상황에서도 죽지 않도록 하기 위해 작업 단위를 프로세스 기반으로 적절히 분배했습니다. 즉 ISAPI로 개발한 XGE 웹서비스는 클라이언트의 요청을 받고 이 요청에 대한 데이터 수집을 직접 하지 않고 DataSource라는 별도의 프로세스로 책임을 위임하고 이렇게 수집된 데이터를 다시 받아서 클라이언트로 전송해주는 역활만 합니다. 즉, ISAPI로 개발된 XGE 웹서비스는 다음과 같은 일만을 합니다.

  1. 요청을 받는다.
  2. 요청에 대한 처리를 별도의 프로세스에게 위임한다.
  3. 요청에 대한 처리 결과를 받아 보내준다.

요청을 받고.. 그 결과를 보내주는 것 자체는 ISAPI에 있어서 매우 기본적인 연산입니다. 즉, XGE 웹서비스는 매우 기본적인 연산만을 한다는 것이지요. 이렇게 하면 XGE 웹서비스가 어떤 연산으로 인해 다운되는 일은 거의 없다고 볼 수 있습니다. 별다른 연산은 모두 다른 프로세스에게 위임을 하니까 말입니다. 그리고 연산을 위임받은 DataSource 프로세스는 별도의 실행파일로 만들었습니다. 원한다면 서비스 방식으로 만들어도 되겠지요. 좀더 편리한 UI 제작을 위해 어플리케이션 형태의 실행파일로 만들었고, 이 DataSource가 하는 일은 XGE 웹서비스가 요청한 지도 데이터를 조회해서 바이너리 데이터 덩어리로 묶고(Pack) 다시 XGE 웹서비스로 보내줍니다. 지도 데이터를 조회하는 연산은 내부적으로 다소 복잡한데, 어떤 잘못된 연산으로 DataSource 프로세스가 다운될 수가 있습니다.
위의 그림에서는 언급되지 않았지만, 이럴때를 위해 Monitor 프로세스가 존재하며 이 XGE Monitor 프로세스가 하는 일은 DataSource 프로세스가 살아있는지를 일정한 시간 간격으로 검사하고 죽어있다면 다시 DataSource 프로세스를 살려주는 역활을 합니다. 역활에 따라 적절하게 프로세스로 분리한 이러한 구조로 어떤 상황에서도 죽지 않는다라는 이상적인 목표에 많이 접근할 수 있을 것으로 판단됩니다. 끝으로 XGE 웹서비스는 매우 구조가 간단합니다. 구조가 간단하기에 안정성과 빠른 응답성은 물론이고 확장성의 이점까지 두루 얻을 수있습니다. 일단 위의 그림 역시 매우 간단한 구조인데, 이 그림을 구성하고 있는 XGE 서비스와 DataSource 프로세스에 대한 구조에 대한 그림을 살펴보면, 얼마나 간단한지 알 수 있을겁니다.
위의 그림은 UML 중 Class Diagram입니다. 실제로 개발한 프로젝트에서 사용한 클래스의 모든 것입니다. 물론 기능 확장등으로 몇가지 더 추가되겠지만.. 요청과 그에 대한 처리라는 관점에서 봤을때 새로운 클래스를 추가하는 상황은 최대한 배제하도록 설계가 되었습니다. 이러한 설계의 단순함으로 인해 전체적으로 구조가 간단해졌으며, 앞서 언급한 안정성, 빠른 응답성, 확정성의 이점을 얻을 있겠지요. (참고로 위의 UML은 StarUML로 작성했습니다. 국산 공개 소프트웨어)