이미지 게이트웨이

해결하고 싶은 문제

이미 배포된 이미지 URL과 복잡한 백엔드를 연결하기 위한 명목으로 다양한 시스템이 추가 투입된다. 게이트웨이, 이미지정보 DB/API, 변환시스템, URL 맵핑테이블, 상태관리 DB 등등 점차 확장/운영하기 어려워진다.

솔루션/패턴 설명

레거시 URL규칙을 M2에 이식하여 단일 이미지 게이트웨이를 구축한다.

../../_images/dgm023.png

HTTP/S 가 지원된다면 모든 백엔드 자원을 연결하여 단일 시스템으로 구축/운영이 가능하다.

구현

  • M2 이미지 게이트웨이의 역할로 백엔드 가장 앞단에 배치한다.

  • M2 레거시 이미지 URL규칙을 이식한다.

  • M2 콘텐츠 제작을 위해 연동이 필요한 백엔드를 순차적으로 연결한다. 예제의 Service Call Chain 은 다음과 같이 동작한다.

    1. 호출된 URL 주소의 의미를 해석한다. M2용 Hooking 함수를 작성한다.

    2. 독립된 이미지 정보서버가 존재한다면 API를 연동하여 이미지 정보(위치와 처리방식)을 얻는다.

    3. 이미지를 다운로드 받는다. 꼭 같은 백엔드에 존재할 필요는 없다.

    4. 다운로드된 이미지를 실시간 이미지 가공 한다.

  • M2 고객에게 전달되기 전 서비스 가상호스트에 캐싱한다. 이후 같은 이미지 호출인 경우 즉시 응답한다.

장점/효과

  • 배포된 URL을 수정하지 않는다.

  • 단일 M2플랫폼만으로 파편화된 이미지 정책과 백엔드를 통합한다.

  • 이미지 산출물 뿐만 아니라 모든 연결지점에 캐싱모듈 적용이 가능하다. 예를 들어 API Server 가용량이 부족할 경우 증설하지 않고 캐싱으로 부하를 낮출 수 있다.

  • 분산처리를 통한 병렬처리로 Scale-Out을 지원한다.

주의점

  • 외부 의존성에 대해서는 별도의 가상호스트로 구성해 두면 장애시 빠르게 책임규명이 가능하다.

  • 캐싱정책 및 Default 동작 등을 정해두면 예측할 수 없는 경우라도 대처가 가능하다.

  • 서비스 시나리오가 복잡한 만큼 블랙박스가 되지 않도록 구축/검수시 연결부위를 확인하는 매뉴얼을 작성해둔다.

기타

  • 레거시 URL 처리를 위해 M2는 패턴맵핑과 JavaScript 함수 연동을 제공한다.

  • 실서비스 투입시 플랫폼 전면교체보다는 점진적으로 트래픽을 이전하는 것이 바람직하다. 특히 50:50의 상황에서 자원효율성등 직접적인 비교를 통해 플랫폼 신뢰도를 확보하는 것을 추천한다.