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

잠시 정리하는 차원에서 그려본 현재 개발중인 맵 엔진의 서버측의 구조입니다. 아직 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를 재기동함

이미지 기반과 벡터 기반 지도 서비스의 적용 범위

이 글은 지도 서비스 방법으로 이미지 방식과 벡터 방식에 대한 장단점과 이런 장단점으로 인해 각각의 적당한 적용분야에 대한 개인적인 생각을 써본 글입니다.

초기 지도 서비스는 서버에서 클라이언트로 데이터를 전송해줄 때 좌표를 던져줌으로써 이 좌표를 이용해 지도를 화면상에 그려냈습니다. GIS의 초창기에는 이런 벡터 방식이 주류를 이루었으나, 지금은  이미 만들어 준비된 지도 이미지를 서버가 클라이언트에게 던져주고, 클라이언트는 이 이미지를 화면에 뿌려주는 방식이 대세가 되었습니다. 구글맵이 그렇고.. 콩나물, 네이버, 다음, 야후, MS 등등, 모두가 이미지 방식입니다. 그렇다면 이유는 무엇일까요?

  1. 속도가 빠르다.
  2. 클라이언트 개발이 간편하다.
  3. 클라이언트에 별도의 프록그램 설치(특히 말도 탈도 많다는 ActiveX)가 필요없다.
  4. Web2.0(특히 AJAX 기술)의 트렌드를 충족시킨다.

가장 중요한 것이… 이미지 기반은 벡터 기반에 비해 속도가 빠릅니다. 속도라 함은 클라이언트가 보고자 하는 지역의 좌표(MBR)를 넘겨주면 서버가 해당 지역에 대한 데이터를 찾아 전송해주고 클라이언트가 화면상에 그려주는데까지 얼마나 빨리 처리할 수 있느냐입니다. 벡터 기반의 경우 이런 처리에 대한 전체 흐름은 다음과 같습니다.

  1. 클라이언트는 원하는 지역의 좌표와 지역의 크기(이를 MBR이라 함)를 서버로 전송한다.
  2. 서버는 해당 지역의 데이터를 수집하는데, 데이터는 복잡한 공간검색(R-Tree나 Grid-File과 같은 공간검색 알고리즘 이용)을 사용하며 이 검색 방식은 많은 시간이 소모된다.
  3. 서버는 수집한 데이터를 클라이언트로 빠르게 전송하기 위해 데이터의 크기를 줄일 목적으로 데이터를 압축한다.
  4. 서버가 보낸 데이터가 압축되었다면 클라이언트는 받은 데이터를 압축해제 한다.
  5. 클라이언트는 받은 데이터(좌표, 속성 등)를 이용하고 지도 이미지를 직접 만들어 그린다.
  6. 클라이언트 측의 사용자는 자신이 요청했던 지도를 본다.

다음으로 이미지 기반의 처리 과정을 살펴보면 다음과 같습니다.

  1. 클라이언트는 원하는 지역의 좌표와 지역의 크기(이를 MBR이라 함)를 서버로 전송한다.
  2. 서버는 해당 지역에 대한 이미지를 찾는데, 해당되는 지역에 대한 파일의 찾기는 매우 단순하며 빠른다.
  3. 서버는 이미지를 바로 클라이언트로 전송한다.
  4. 클라이언트는 받은 이미지를 바로 그린다.
  5. 클라이언트 측의 사용자는 자신이 요청했던 지도를 본다.

처리 과정만을 살펴보더라도 벡터 기반에 비해 이미지 기반의 지도 서비스가 당연히 빠를 수 밖에 없다는 것을 알수 있지요.

그렇다면 이처럼 성능 좋은 이미지 기반의 지도 서비스가 아닌 벡터 기반의 서비스가 할 수 있는 기능은 무엇일까요..? 즉, 이미지 기반의 지도 서비스에서는 불가능한, 아니 매우 어려운 기능은 무엇일까요?

  1. 새로운 건물이 생겼을 때나 형태가 변경되었을 경우, 클라이언트에서 지도 편집
  2. 화면상에 표시된 지도에서 원하는 건물을 찍어 그 건물의 상세 내용을 살펴보는 기능
  3. 플롯터와 같은 출력기를 통해 큰 용지(A4 이상)에서 높은 품질의 지도 출력하기
  4. 건물을 제외하고 도로만을 화면상에 보는 것과 같은 원하는 지도 스타일 만들기.
  5. 건물 전용면적이 200평방 이상인 건물만을 화면상에 표시하여 지도 보기.
  6. 지도의 특정 주제를 가지는 요소 그룹을 사용자가 원하는 색상이나 형태로 표시하는 기능.
  7. 등등…

위의 기능이 왜 이미지 기반에서는 거의 불가능하고 벡터 기반에서는 가능한 이유는 무엇일까요? 그것은 단지 현재 보이는 지도에 대한 정보를 이미지 기반은 “이미지”로써만 가지고 있기 때문입니다. 이에 반해 벡터 기반은 지도에 대한 실제 정보로써 “지도 좌표”를 가지고 있다는 점입니다.

이러한 이미지 기반과 벡터 기반의 서로간의 장단점을 놓고 볼때.. 이미지 기반은 클라이언트 PC에 별도의 프로그램 설치 없이 원하는 지역을 빠르게 보여주는 서비스에 적당하며, 벡터 기반은 사용자가 원하는 지역에 대해서 좀더 다양한 기능, 즉 이미지 기반이 제공할 수 없는 기능, 좀더 전문적으로 말해 지도를 좀더 높은 수준에서 활용하고 응용하는 영역, GIS에 적당하다고 할 수 있습니다.

왠,,,, 메모리릭,,, @_@;

실행시에 실행되지도 않는 코드인데, 이 코드가 들어가면 메모리 누수가 발생합니다. 허걱… @_@;; 이 코드를 빼고 컴파일하고 실행하면 누수가 발생하지 않습니다. 분명 이 코드가 실행되지 않아도, 이 코드를 넣고 컴파일 했다는 이유 하나만으로 메모리 누수가 발생합니다. 누구 크기는 1Byte. 개발툴의 메모리 누수 탐지기의 버그로 판단하고 패스… 이것 원인 규명하려고 낭비한 시간이 다소 아깝습니다.

아.. 회사에서 개발자를 구합니다. 기반기술팀의 구성원으로써, 개발에 대한 남다른 열정을 가진 분으로…. 조만간에 구체적으로 글을 올릴 생각입니다.

간단한 예로 살펴본, OpenMP

필자가 OpenMP이라는 단어를 처음 들었을때는, 보다 안정적인 멀티 스레드 프로그래밍에 대한 갈증이 한창일 때였습니다. XGE 개발 초기에 데이터 요청과 데이터 가시화를 별도의 스레드로 두고, 다시 데이터 요청을 레이어 단위로 나누어 다시 레이어를 별도의 스레드로 분리시켜야할 필요성에서였는데요. 그러다가 찾은 것이 OpenMP 이였습니다. 처음 접하는 기술인지라… 실제 프로젝트에 적용하지 않고 일단 머리속에 북마크만 해 두었지요.

최근에 다시 모 잡지에서 OpenMP라는 단어를 접하게 되었는데, 요즘 CPU가 죄다 듀얼코어니, 쿼드코어니… 얼마후에는 옥타코어와 같이 하나의 CPU가 2개, 4개, 8개의 CPU의 성능을 낼 수 있는 컴퓨팅 환경이고, 이런 컴퓨팅 리소스를 100% 활용하기 위해 병렬 프로세싱, 다중 스레드, 다중 프로세싱 개발 기법을 속속들이 적용하고 있고, 이 기법이라는게 역사라 불리는 시간에서 지금에 이르기까지 존재하는 스레드를 이용한 방법입니다. 여기에 간단히 스레드를 직접 사용하지 않고 간단/명료한, 하지만 아직은 섬세하지는 않는 멀티 프로세싱 방법인 OpenMP라는 기술이 수년전에 나타났는데, 이 글은 간단한 예로 OpenMP를 접해 보도록 하겠습니다.

먼저 고객으로부터 받은 하나의 요청을 예로 OpenMP의 기능을 느껴보는 것이 가장 좋은 접근법 같습니다. 요청은 테일러급수를 이용해 자연로그에서의 e와 파이(3.1415~)를 구하고 이 둘의 값을 합해 보는 것입니다. 왜 이런것이 필요한지는 생각하지 말고 말입니다. ^^; 이 예는 http://www.kallipolis.com/openmp/1.html 의 OpenMP의 Tutorial에서 가져왔음을 명확히 합니다. 위의 문제를 해결하기 위해서는 먼저 e를 구하고 다음으로 phi를 구한후에 마지막으로 e와 phi를 합하면 끝납니다. 모두 3단계로 나눠지는데, 바로 아래와 같이 말입니다.

  1. e를 구한다.
  2. phi를 구한다.
  3. e와 phi를 합한다.

위의 3 단계를 자세히 살펴보면, 3단계는 1단계와 2단계가 반드시 이뤄져야 하지만, 1단계와 2단계는 완전히 서로 독립적이라는 점입니다. 바로 여기서 1단계와 2단계를 2개의 스레드로 분리해 성능을 높일 수 있다는 것일 알 수 있습니다. 2개의 스레드로 분리하는 방법은 직접 개발자가 스레드 API를 사용해서 분리시킬 수 있는 방법과 OpenMP를 사용해서 그 분리 작업을 맡기는 방법이 있습니다. 여기서는 물론~ OpenMP를 사용해 두개의 스레드로 분리해 보겠습니다.

#include "stdafx.h"
#include  
#include  
 
#define num_steps 20000000 

int main(int argc, char *argv[])
{
    double start, stop;
    double e, pi, factorial, product;
    int i;

    start = clock();

    #pragma omp parallel sections num_threads(2)
    {
        #pragma omp section
        {

            printf("e started\n"); // 1. 단계: e구하기
            e = 1;
            factorial = 1;

            for (i = 1; i<num_steps; i++) {
                factorial *= i;
                e += 1.0/factorial;
            }

            printf("e(%lf) done\n", e);
        }

        #pragma omp section
        {
            printf("pi started\n"); // 2. 단계: phi 구하기

            pi = 0;
            for (i = 0; i < num_steps*10; i++) {
                pi += 1.0/(i*4.0 + 1.0);
                pi -= 1.0/(i*4.0 + 3.0);
            }

            pi = pi * 4.0;
            printf("pi(%lf) done\n", pi);
        }
    }
    product = e + pi; // 3. 단계: e와 phi 합하기

    stop = clock();

    printf("Reached result %f in %.3f seconds\n", 
        product, (stop-start)/1000);

    return 0;
}

먼저 살펴 볼 것이 #pragma omp parallel sections num_threads(2)인데, 이 #pragma는 2개의 스레드(num_threads(2))로 실행 구역(section)을 나누겠다는 의미입니다. 그 실행 구역이라는 것이 다름 아닌 e와 phi를 구하는 것인데, 이 실행 구역, 즉 section을 정하는 코드가 바로 다음 코드에 2번 나오는 #pragma section 블럭입니다. 이 블럭은 정확히 e와 phi를 구하는 코드입니다.

여기서 중요한 것은 동기화인데, e와 phi를 계산해서 합하는 것이 최종적인 목표이므로 e의 계산과 phi의 계산이 완전이 완료되어야만 e와 phi를 합할 수가 있다. OpenMP는 #pragma omp parallel sections num_threads를 통해 이 전처리가 규정한 블럭의 코드를 자동으로 동기화 시켜줍니다!! ^^ 와우~

여기서 눈치가 빠른 사람이라면, 위의 코드에서 OpenMP와 관련된 코드를 제거해도 동일한 결과를 낸다는 것입니다. 물론, 싱글 스레드로 돌아가므로  수행 속도는 저하되겠지만 말입니다. 즉, 이를 다시 역으로 생각해보면, 기존에 전혀 멀티 프로세싱을 고려하지 않고 개발된 코드에 대해서 OpenMP를 적절하게 적용하면 큰 코드의 변경 없이도 멀티 프로세싱의 잇점을 추가할 수 있다는 점이겠지요. 필자의 추측으로 OpenMP라는 기술은 아마도… 기존의 싱글 스레드로 작동하는 소프트웨어에 대해서, 멀티코어 CPU의 등장으로 그 하드웨어의 성능을 최대한 끌어내기 위해 등장한 기술로 보입니다.

간단하게 예를 들어 OpenMP를 살펴보았습니다. 이글은 OpenMP의 많은 기능 중에 매우 간단하고 기본적인 예를 든 것입니다. 추후 기회가 된다면 더 많은 OpenMP의 정보를 제공할 수 있도록 하겠습니다. 그때까지 참지 못하겠다면, http://www.kallipolis.com/openmp/index.html 를 참고하길 바랍니다.