I. 개요
기존 `Map`에 `GeoTiff` 이미지를 렌더링 하는 기술은 성능과 안정성에 매우 취약한 문제점이 있었습니다. 이러한 문제점이 발생하는 원인으로는 렌더링 하는 기술이 불안정한 `Geoserver`에 대한 의존성이 매우 높기 때문입니다.
이러한 문제를 해결하기 위해 여러 방법을 사용을 하고는 있지만 근본적인 안정성이 떨어지는 문제를 해결하기에는 어려움이 있었습니다. 해당 보고서에서는 이러한 문제점이 어떤 부분에서 발생하고 있었는지, 어떠한 방법으로 개선을 했는지 이야기 해보도록 하겠습니다.
II. AS-IS
우선 기존에 서버에 데이터를 저장하는 과정을 도식화 된 그림을 보도록 하겠습니다.
과정 자체를 보게 되면 tiff 파일 자체를 `Client`로 부터 입력을 받게 되면 `Server`는 다시 `GeoServer`에 요청을 하여 데이터를 저장하는 과정을 거치게 됩니다.
그 다음은 저장된 데이터를 표출하는 과정을 도식화를 한 그림입니다.
`Client`가 요청한 데이터를 다시 `GeoServer`가 이미지 렌더링을 하는 과정을 거쳐야 하고 렌더링 되는 과정에서 필요한 `MetaData`는 다시 `Server`에 요청을 하여 호출해야 하는 과정을 거치게 됩니다.
시각적으로 보아도 많은 과정을 거치게 되면서 속도에 대한 이슈를 걱정하게 되는 문제가 있습니다. 특히나, `GeoServer`의 성능이 그렇게 뛰어 나지가 않아 한번에 여러 개의 타일 렌더링 요청 신호를 보내면 많게는 몇 분씩 기다려야 하는 문제점이 존재 하였습니다. 그리고 같은 데이터를 요청을 보내게 되어도 매번 응답을 해주어야 하는 상황이 발생합니다.
`GeoServer`에서는 이러한 속도 부분의 문제점을 해결을 하기 위해 여러 가지 튜닝 방법을 제시하고 있습니다. 첫 번째, 자체적인 `GeoServer Web Cashe`를 활성화 하는 것입니다. 다음은 캐싱을 활성화 하였을 경우의 로직입니다.
최초 호출 시에는 `GeoServer`에 요청을 보내서 해당 데이터를 반환 받고 캐싱을 시켜줍니다. 이후 에는 자신이 캐싱한 데이터를 호출하게 되면 캐시에 있는 데이터를 바로 반환하게 됨으로써 성능적인 부분을 이전보다 향상 시켜 줄 수 있게 됩니다.
하지만 이러한 캐싱의 경우에도 많은 데이터를 유저에게 캐싱 시킬 수는 없다라는 문제점과 시간이 지나면 캐시는 소멸되고 그렇게 되면 다시 `GeoServer`에 호출하여 데이터를 가져와야 하는 반복 적인 작업을 수행하게 됩니다.
두번째 , 방법으로 반복되는 요청의 응답 자체를 캐싱하는 기술을 사용하는 것입니다. 캐싱된 데이터가 존재하여도, 일정 시간이 지나면 이전에 요청하였던 내용을 다시 반환해야 하는 이슈가 발생하고 있습니다. 그렇기 때문에 반복되는 요청에 대한 응답을 서버가 저장을 해두었다가 대신 바로 반환해주는 것입니다.
이렇게 하면 기존에 반복 응답을 해주는 문제를 해결 해 주면서도, 새로운 유저가 같은 요청을 보내게 된다고 하여도 빠른 응답성을 보여줄 수 있습니다.
하지만, 이러한 튜닝 방식을 사용한다고 하여도 근본적인 루틴인 `GeoServer`에 요청을 보내고 받는 것이 `Response Time`이 늘어지는 것에 대한 근본적인 원인이 되기 때문에 이후에 좀 더 빠른 서비스를 제공하기에는 어려움이 존재합니다. 그리고 이렇게 튜닝을 위해 여러가지 방식을 추가로 도입이 되면서 무엇 하나가 조금이라도 잘 못 된다고 하면 서버 전체가 같이 다운이 되어버리는 현상을 접하게 됩니다
III. TO-BE
기존 렌더링 방식은 `GeoServer`가 `GeoTiff` 를 렌더링한 데이터를 받아서 `Map`에 표출하는 방식을 채용하고 있습니다. `GeoServer`가 렌더링 데이터를 생성하는 것을 넘기는 방법이 없는 가에 대한 고민을 하다가 `Leaflet`자체의 메소드인 `ImageOvelay` 를 사용해보는 것에 고민을 해봤으며, 결론적으로 빠른 성능과 안정성을 가질 수 있는 새로운 방식의 렌더링 방식을 찾을 수 있었습니다.
우선, 변경된 `GeoTiff` 저장 방식을 보도록 하겠습니다.
저장로직 자체는 이전보다 많이 복잡해졌습니다. `Client`가 전송한 `Tiff` 데이터를 `PNG` 파일로 변환하여 저장하고, `GeoServer`에 데이터를 저장합니다. 마지막으로는 `GeoServer`에서 `MetaData`를 호출해서 서버에 저장하는 로직을 사용하게 됩니다.
이렇게 복잡한 과정을 거쳐 데이터를 저장하게 되는 장점은 호출에서 나타나게 됩니다. 다음은 호출 시 수행되는 로직입니다.
렌더링하는 데이터를 서버의 폴더에 저장된 png파일을 바로 반환하는 것입니다. 이러한 방식으로 데이터를 반환하게 되었을 때 장점으로는 다음과 같습니다.
- 데이터 호출에도 한번의 `Response`로 끝나기 때문에 서버의 부하가 감소합니다.
- `GeoServer`를 사용지 않음으로써 안정성이 증가합니다.
- 서버에 있는 `Resource`를 사용하기에 빠른 속도를 보장합니다.
특히나, 속도 부분에서 많은 차이가 보이는데 그 이유는 `Map`에서 `Zoom` 을 사용하게 되면 각 사이즈마다 렌더링된 타일링 다시 호출하게 되는데, `Overlay`가 된 이미지는 사이즈에 상관없이 한번의 호출만 되기 때문입니다.
추가적으로, 자주 호출 되는 요청에 대해 미리 캐싱하는 기술을 적용하여 좀 더 서버에 안정성을 높이고 부하를 줄일 수 있습니다.
IV. 결론
새로운 이미지 렌더링 방식은 기존보다 확실히 빠른 결과와 안정성을 제공을 하고 있습니다. 하지만 이러한 방식의 사용은 `Leaflet` 이 최신 버젼을 `Release` 를 하면서 추가가 되었기에 아직 어떠한 문제점을 가지고 있는지 파악이 어려울 수 있고, `Reference`가 부족하여 문제를 해결하는 것도 쉽지 않을 수 있습니다. 그렇기 때문에 발생될 때, 에러나 문제 해결방법을 잘 정리해두어 이후에 같은 문제에 많은 시간을 소비하지 않도록 예방을 하도록 할 듯 합니다.