솔루션과 구조

솔루션의 핵심 시나리오인 실시간 변환구조를 기반으로 문제분석 의 내용을 극복할 수 있다.

Important

스토리지에 저장된 원본이미지로부터 클라이언트가 원하는 이미지를 실시간으로 생성한다.

레거시 구조를 유지한채 점진적으로 안정성을 확보, 전면도입까지의 과정을 알아보자.

Note

디테일한 이미지 가공은 hyperdims 이미지 엔진의 How to use 를 참고한다.

레거시 구조

일반적인 이미지 서비스 플로우는 아래와 같다.

../../_images/asis1.png

기존 백엔드 이미지 처리 프로세스를 수정하지 않고 도입할 수 있어야 한다.

이미지 최적화

테스트시 반드시 검증해야 하는 것이 이미지 최적화이다. 이미지 최적화는 화질은 유지한 상태에서 용량을 절감하는 기법을 의미한다.

../../_images/opt.png

더 작은 이미지는 더 빠르게 고객에게 전달된다.

Important

3가지 이미지 최적화 방안을 제안한다.

도입 구조

M2Live로드밸런서이미지 서버 또는 스토리지 사이에 위치한다.

Note

_L , _M , _500 등 독자적인 이미지 호출규격을 사용해도 전혀 문제가 되지 않는다. urlRewrites 모듈을 이용하면 어떠한 호출규격이라도 hyperdims 이미지 엔진규격으로 변환이 가능하다.

테스트 구조

테스트 목적이라면 라이브 서비스 백엔드에 넣지 않고 타겟 사용자만 hosts 파일 변조등을 통해 접근한다.

../../_images/test1.png

부분도입 구조

전면도입 이전 안정성을 검증하고 싶다면 로드밸런서 를 통해 트래픽을 분산시킬 수 있다.

../../_images/stg1.png

프로덕션 구조

프로덕션에서는 모든 이미지 트래픽이 유입/처리되며 CDN에 응답시 캐싱 정책을 구성할 수 있다.

../../_images/tobe11.png

레거시 시스템은 이제 불필요하여 제거한다.

../../_images/tobe21.png

Scale Out & Fail Over

서비스 규모에 맞추어 M2Live 노드를 증설한다.

../../_images/scaleout1.png

최소 2기가 있어야 무중단 업데이트가 가능하다.

스토리지 사이에 로드밸런서 를 추가할 수도 있지만 M2Live 에는 이미 L7과 동등한 수준의 원본 health 감지 기능이 탑재되어 있어 없어도 무방하다. 대규모 서비스에서는 분산처리를 위해 2-Tier 구조 가 도입되기도 한다.

Note

일반적으로 스케일 업은 32코어까지만 권장하며 이후는 스케일 아웃을 권장한다.