> 서비스바로가기

개요

WMS(Web Map Service) 제공을 위한 데이터 프로바이더 계층에 메인메모리 DBMS를 사용함. 메인메모리 DBMS는 국내 업체인 리얼타임테크의 "Kairos"를 사용하였음. 데이터 프로바이더로써 클라우드서비스가 제공하는 가상서버에 DBMS를 설치하고 PaaS가 제공하는 컨테이너에 WMS 어플리케이션을 적재함.

제조사 홈페이지 바로가기: http://www.realtimetech.co.kr

목적

GIS 응용 서비스 제공을 위하여 메인메모리 DBMS가 Disk DBMS와 비교할 때 어느 정도의 성능향상을 보이는지 확인함

환경구성

1. Server : Linux Container, 가상서버 위에 설치되는 DBMS
2. DBMS : Kairos (제조사:리얼타임테크)
3. WAS(Web Application Server) : Apache Tomcat

개발환경 및 배포

1. 이클립스에서 일반 웹앱을 제작하는 방법을 준수하고, 
   배포서버를 이클립스에 등록된 서버 중 CloudFoundry를 지정하고 연결계정을 등록하여 해당 서버로 배포함
2. 최초 제작된 웹 앱(WMS)을 복사하여 어플리케이션 명칭을 변경하여, 필요한 갯수만큼 클라우드(CloudFoundry)에 배포
   ( 웹 어플리케이션의 수평적 확장 적용)

구현

1. 다양한 데이터프로바이더 수용을 위해 성능제약이 존재하는 지오서버 등의 Pakage SW 사용을 배제하고
2. DBMS가 반환하는  GIS 자료구조( WKB, WKT)를 자바 도형(java.awt.Shape) 으로 변환하여 이미지 렌더링
  (흔히 말하는 GIS 엔진의 사용을 배제 : 이미 공간 DBMS가 훌륭한 GIS 서비스 엔진임)

구현결과

1. 연속지적도(전국 SHP 파일 용량 기준 약 30GB)를 기준으로 8개의 웹 앱으로 클러스터링 했을 경우,
   동일한 환경의 Disk DBMS (PostGIS)  대비 약 10배 이상의 성능 향상을 확인
2. 수평확장되는 웹 앱(WMS)의 갯수만큼 성능이 향상확인 (저비용 서버 확장)

성능향상을 위한 개선 사항

1. 인프라 레벨에서 물리 또는 가상으로 이용될 수 있는 가속장치가 있을 경우,
   렌더링시켜야하는 도면데이터 조회 후 이미지 렌더링 속도 약 20% 향상 가능
2. 데이터 프로바이더(DBMS) 계층의 수평적 확장으로 처리되는 WMS 서버의 갯수를 최적화 시킴으로써 동시에 수용할 수 있는 사용자 증가

적용 및 응용 분야

1. 실시간 변경되는 공간정보의 실시간 서비스 발행
2. 사용자에게 빨리 전달되야 하는 비싼(?) 데이터의 저장 및 서비스 발행에 유용

결론

1. 동일한 환경 조건일 경우, 메인메모리 DBMS가 일반적인 DBMS가 월등한 성능을 보이는 것을 확인
2. 제한적인 메모리의 용량을 고려할 때 메인메모리에 적재되어야 하는 데이터의 식별이 중요함

> 서비스 바로가기

> 서비스 비교 (Disk 기반 웹 맵서비스)

1. Raster Image 와 Vector Graphics의 정의

일부 GIS 웹 사이트를 보게 되면 WMS와 WFS의 선택이 부적절하여 서비스 성능을 떨어뜨리는 경우가 있다. 본 글을 통해 어플리케이션 구성에 있어 WMS와 WFS 선택 기준을 설명한다.

Raster Image는 흔히 Smart Phone의 카메라를 통해 생성되는 JPEG, PNG 등의 형식을 가지는 데이터를 의미한다. 각각의 포맷 별로 저장되고 압축되는 방식의 차이가 존재하지만 기본적으로 흔히 Pixel 이라고 부르는 것에 입력되는 색상으로 표현되는 데이터라고 할 수 있다.
OGC의 WMS(Web Map Service)는 HTTP를 통해 Raster Image를 제공하는 서비스이다.

Vector Graphics는 흔히 좌표라고 부르는 위치를 지정하는 요소의 연결을 통해 구성되는 데이터를 의미한다. GIS 분야에서 GeoJSON, KML, GML, ESRI SHP 등으로 정의되는 형식이라고 할 수 있다.
OGC의 WFS(Web Feature Service)는 HTTP를 통해  Vector Data 를 제공하는 서비스이다.

2. Raster Image 와 Vector Graphics의 특징

Raster Image의 경우 저장되는 포맷에 상관없이 메모리에 풀린 상태라면 가로 1024px, 세로 1024px 크기의 TRUE COLOR ( RED, GREEN, BLUE) 이미지라면 3MB의 크기를 가진다.
즉, 이미지 생성을 위한 원본 데이터의 크기에 상관없이 렌더링 되는 이미지의 가로, 세로 크기만큼만의 사이즈를 가진다. 국가공간정보포털이 제공하는 연속지적도 서울지역 SHP파일의 경우 약 1.5 GB 이지만, 1024px * 1024px * 3Bands (RED, GREEN, BLUE)의 Raster Image로 렌더링되면 결국 3Mb 의 크기만 가질 것이다. 물론 저장되는 포맷에 따라 압축이 됨으로 실제 생성되어 전송되는 크기는 수백KB 일 것이다.

Vector Graphics의 경우 지형을 표현하는 도형이 가지는 좌표 셋을 그대로 반환함으로써 원본 크기만큼의 전송 양을 가지게 될 것이다.
즉, 국가공간정보포털이 제공하는 연속지적도 서울지역 SHP파일의 경우 약 1.5 GB이므로 , 전송되는 데이터 양 또는 이와 같을 것이다.

3. WMS와 WFS의 성능향상을 위한 확장 기법

WMS에서 Raster Image는 지리 공간 상의 도형 형상 좌표를 이미지 픽셀 좌표로 변환하는 과정(AffineTransform)과 컬러링 과정이 요구됨으로 사용자의 서비스 요청 처리에 있어 비교적 많은 Computing Power를 사용한다.
이러한 특징으로 이미지 생성 성능 향상을 위해서는 수직적 확장(CPU 추가, Memory 추가, GPU 주가등)이 우선 고려되어야 한다.

WFS에서 Vector Graphics는 원 데이터 소스가 가지는 지형 도형을 반환 포맷에 맞도록 텍스트 렌더링 과정만 있음으로 비교적 적은 Computing Power를 사용한다.
이러한 특징으로 Vector Data 생성을 위한 성능향상은 사용자 수용 능력 향상 측면에서 접근되며, 이를 위해 수평적 확장 (서버 증설:로드밸런싱, 클러스터링)이 요구된다. 그러나 서버가 많은 데이터를 반환해야 한다면 네트워크 부하가 중요 고려요소가 될 수 밖에 없다.

4. WMS와 WFS의 선택

WMS와 WFS의 선택에서 고려해야 할 것은 

• 렌더링 되야 하는 원본 데이터의 크기로써, 원천 데이터의 크기가 크다면 WMS가 유리할 것이다.
• 사용자 페이지를 기준으로 각 객체에 이벤트가 연동되어야 한다면 어쩔 수 없이 WFS가 선택지 일 것이다. 
• 그러나 위 경우에도 전체 형상 확인을 위해 WMS를 호출하고, 마우스이벤트 등과 연결하여 개별 객체를 호출하는 방식으로 페이지를 구성하는 것이 효율적일 수도 있다. 

개요

PaaS를 구현하는 클라우드 서비스로써 파스타 (CloudFoundry 계열) 플랫폼에서 제공하는 경량 컨테이너에서 동작하는 OGC WMS(Web Map Service)의 GetMap 인터페이스를 Sping Web 과 Java Graphics2D를 이용하여 구현한 후,
이를 클러스터링하여 OpenLayers에 통합하여 서비스 UI를 구현함

목적

클라우드서비스(PaaS)가 제공하는 컨테이너 환경에서 GIS응용어플리케이션이 만족할만한 성능을 제공하는지 확인함

환경구성

1. Server : Linux Container, 가상서버 위에 설치되는 DBMS
2. DBMS : Postgre + PostGIS
3. WAS(Web Application Server) : Apache Tomcat

개발환경 및 배포

1. 이클립스에서 일반 웹앱을 제작하는 방법을 준수하고,
   배포서버를 이클립스에 등록된 서버 중 CloudFoundry를 지정하고 연결계정을 등록하여 해당 서버로 배포함
2. 최초 제작된 웹 앱(WMS)을 복사하여 어플리케이션 명칭을 변경하여, 필요한 갯수만큼 클라우드(CloudFoundry)에 배포
   ( 웹 어플리케이션의 수평적 확장 적용)

구현

1. 다양한 데이터프로바이더 수용을 위해 성능제약이 존재하는 지오서버 등의 Pakage SW 사용을 배제하고
2. DBMS가 반환하는 결과목록을 일반적으로 적용되는 GIS 자료구조( WKB, WKT)로 변환하지않고, 직접 자바 도형(java.awt.Shape) 으로 변환
  (지오서버가 제공하는 WMS 대비 2배 이상의 성능 향상 확인)

구현결과

1. 연속지적도(전국 SHP 파일 용량 기준 약 30GB)를 기준으로 8개의 웹 앱으로 클러스터링 했을 경우,
   맵 타일 제작 과정 없이도 동적 지도서비스가 가능함을 확인
2. 수평확장되는 웹 앱(WMS)의 갯수만큼 성능 향상 확인 (저비용 서버 확장)
3. DBMS(1) + 컨테이너(8)의 구성만으로도 동시 접속자 100명 이상 수용가능함을 확인

성능향상을 위한 개선 사항

1. 인프라 레벨에서 물리 또는 가상으로 이용될 수 있는 가속장치가 있을 경우,
   렌더링시켜야하는 도면데이터 조회 후 이미지 렌더링 속도 약 20% 향상 가능
2. 데이터 프로바이더(DBMS) 계층의 수직적 확장 (가상 코어 증설) 및
   수평확장 (가상 서버 증설) 을 통해 동시에 수용할 수 있는 사용자 증가

적용 및 응용 분야

1. 실시간 변경되는 공간정보의 실시간 서비스 발행
2. 저비용으로 고성능 GIS 응용 서비스 제공

결론

1. 가상서버, 경량 컨테이너를 제공하는 물리서버의 성능 향상으로 클라우드컴퓨팅 환경에서 GIS 서비스가 충분한 성능을 제공함을 확인
2. 경우에 따라 흔히 GIS엔진이라고 하는 패키지SW 사용을 배제하고, 공간DBMS를 이용하는 코드의 최적화만으로 충분한 성능을 제공함을 확임