이미지 리사이징 서버 / Image resize server / thumbor

3줄 요약

---

• 썸네일 서빙이 필요 함
• 이미지 리사이징 서버 Thumbor 구성
• CDN 뒤로 캐시 활용 하도록 구성

문제 인식

---

서비스 중 이미지 로딩 속도가 비교적 느리고, 데이터 사용량도 많다는걸 알았다.
당연하게도 사용자 업로드 이미지, 상품 이미지 원본을 서빙 하고 있었기 때문이다.
살짝 걱정은 하고 있었는데...

의식의 흐름

---

현재 상황

---

• 이미지 서빙은 CDN을 사용 하고 있다. CDN의 origin 파일은 Proxy -> File Server를 바라보고 있다.
• 사용 중인 파일 서버는 REST API를 지원 한다
• 서버 저장 용량이 아직은... 여유가 있다
• 필요 한 썸네일 크기가 아직 미정이다?

방향 설정

---

원본 이미지와 썸네일 이미지를 어떻게 저장/서빙 할 것인가.

1. 원본과 썸네일을 모두 보관 한다

사용자가 업로드 할 때 , 필요한 만큼 리사이징 하여 변경 한다.
장점.

• 이미지 업로드API 만 수정 한다
• 서비스 추가 없음

단점.

• 기존 이미지들을 모두 변환 해야 함
• 필요한 썸네일 스펙 변경에 대응이 어려움
• 썸네일 갯수 N개 만큼 파일을 저장 해야 함
• 썸네일이 파일 이름 규칙도 정해야 함
• 아무튼 이거 장단점 왜 쓴지 모르겠음

2. 원본만 저장 후 썸네일은 그때그때 처리하여 서빙 한다

원본만 파일로 저장 하고, 썸네일은 요청 때 변환 하여 서빙 한다.

장점.

• 기존 이미지 변환 필요 없음
• 썸네일 스펙 변경에 비교적 유연함
• 원본 파일만 보관 함

단점.

• 이미지 처리시 서버 부하 (CPU, RAM)
• 필요에 따라 운영 해야 할 서비스 증가 할 수 있음
• 필요에 따라 별도의 이미지 처리 서버 필요 할 수 있음

결정 : 2. 원본만 저장 후 썸네일은 그때그때 처리하여 서빙 한다

사실 2번 결정하고 1번이 생각 났다. 2번 방법의 단점을 어떤 방법으로 넘어가 볼까.

• 이미지 처리시 서버 부하 (CPU, RAM)
  • CDN을 사용 중이다. 한번 이상 조회 한 이미지는 CDN에 캐싱 되므로 같은 썸네일을 여러번 만들 필요가 없도록 한다
  • URL에 썸네일 스펙(이미지 크기, 포멧 등)이 포함(파일 이름 또는 파라메터) 되어야 하고, CDN 또는 Proxy 에서 이를 인식 할 수 있도록 한다
• 필요에 따라 운영 해야 할 서비스 증가 할 수 있음
  • 언제 지울지 모르는 파리 목숨 같은 썸네일 파일 쌓여서 고민 하는 것 보다 낫다고 생각한다
• 필요에 따라 별도의 이미지 처리 서버 필요 할 수 있음
  • 있다가 생각한다

어떻게 뭘로 구현 할까

---

1. 이미지 리사이징 서버를 만든다
2. API에 이미지 리사이징 기능을 추가 한다
3. 누군가 아름답게 만들어 놓은 이미지 리사이징 서버를 감사한 마음으로 사용한다

1. 이미지 리사이징 서버를 만든다

장점.

• 이미지 리사이징 서버를 만들어 볼 수 있다

단점.

• 시간도 많이 들고
• 이슈 대응 하려다 신규 프로젝트 생기는 기분이고
• 솔직히 이 방법은 생각 안해봄

2. API에 이미지 리사이징 기능을 추가 한다

예상대로 이미지 리사이징 하는 npm 패키지가 있다.
기존 API에 라이브러리를 사용하고 파라메터로 썸네일 스펙(사이즈, 포멧)을 받아 실시간으로 처리 해줌
Sharp

• https://github.com/lovell/sharp
• 코어 기능이 C로 작성 되어있어 빠른 성능을 강조
• Promise, Async/Await 패턴 사용 가능함을 강조
• 리시아징 말고도 다른 많은 기능이 있음을 강조

장점.

• 필요한 기능만 요구 조건에 맞게 만들 수 있음
• 새로운 서버 구성보다 공수가 덜 들어감
• 비교적 유지보수가 편리 함 (버그 없이 잘 만들었을 때)

단점.

• 사용에 편의성, 성능 장담 할 수 없음
• 3번 할꺼여서 잘 생각 안남

3. 누군가 아름답게 만들어 놓은 이미지 리사이징 서버를 감사한 마음으로 사용한다

오픈소스 이미지 서버 찾아본다.
thumbor
https://github.com/thumbor/thumbor

• 리사이즈 뿐만 아니라 다양한 기능이 있음을 강조
• github star 7.9k 임을 강조
• URL 호출로 이미지를 동적으로 변환 가능 함을 강조
• 원본 이미지를 URL 호출이 가능함을 강조

장점.

• 어느정도 검증 된 서비스
• 사용 편의성, 성능이 보장됨
• 생각만 해도 눈물이 남

단점.

• 운영 해야 할 서비스 추가
• PoC 필요. 기대가 크면 실망은 더 크다
• 필요에 따라 서버가 추가로 필요 함
• 버그, 이슈 발생 시 대응이 어려움
• 파이썬 패키지로 구성되어 있음...

걸정 : 3. 누군가 아름답게 만들어 놓은 이미지 리사이징 서버를 감사한 마음으로 사용한다

단점 묻고 3번으로 간다.

• 운영 해야 할 서비스 추가
  • 서비스 한번 잘 올려 놓으면 크게 수정 할 일이 없다. 왜? 서비스 재시작 말고는 할 수 있는게 없다
• PoC 필요. 기대가 크면 실망은 더 크다
  • 묻고 더블로 간다
• 필요에 따라 서버가 추가로 필요 함
  • 기존 API 서버를 쥐어 짜낸다. 마른 수건 짜면 또 나오는 법
• 버그, 이슈 발생 시 대응이 어려움
  • 있다가 생각 한다
  • 파이썬 패키지로 구성되어 있음...
    • 이건 취향 차이인데, 파이썬 패키지로 서비스 올리는 방식을 안좋아 한다. 도커로 간다 !

간단 PoC 소감

• 잘 만들어 놓은 도커 이미지가 많다. 감사하게 쓸 수 있다. 파이썬 의존성 찾아가며 개고생 안해도 된다
• 워커 설정 으로 다중 코어를 지원한다
• 기대보다 기능이 더 많다. smart crop, 자체 캐싱, 업로드 변환 등등...
• 아주 막강하진 않지만 기본적인 보안 지원 한다
• 자체 캐시 기능은 사용 하지 않을 예정. 정적 리소스 캐시는 CDN에서 담당 한다

서비스 구성

---

모든 요청에 대해 실시간 이미지 리사이징을 할 필요는 없다. CDN 캐시를 적극 활용 한다.

몇가지 제약 조건

• Thumbor가 원본 이미지를 요청 할때는 파일서버에 직접 요청 하지 않는다.
  • 1개 원본 이미지에 N개의 썸네일 종류가 있다면, 파일 서버에 원본 이미지를 N번 요청 해야 하므로 원본 이미지도 CDN으로 요청 한다
  • 원본 이미지, 썸네일 모두 1번 이상 요청 했다면, 이후 모든 응답은 CDN이 하게 되므로 뒤에 있는 서버들의 부하를 줄일 수 있다
• 썸네일 URL에 썸네일 스펙(사이즈, 포멧 등)이 URL에 명시 되어 있고, 쿼리 스트링을 사용 한다면 CDN도 설정 해 줘야 한다
  • ex) https://cdn.domain.com/static/image/profile.png?size=100x100,crop

캐시 상황별 시나리오

CDN no cached

1. 사용자가 CDN으로 썸네일을 요청 한다. 이때 썸네일 스펙이 URL에 있다
2. CDN은 캐싱된 썸네일이 없다. Thumbor로 이미지 리사이징을 요청 한다
3. Thumbor는 원본 이미지를 요청한다. 원본 이미지는 CDN으로 요청 한다
4. CDN은 캐싱된 원본 이미지가 없다. 파일서버로 원본 이미지를 요청 한다
5. 파일서버는 CDN으로 원본 이미지를 응답 한다
6. CDN은 Thumbor로 원본 이미지를 응답 한다
7. Thumbor은 요청한 원본 이미지를 썸네일로 변환 후 CDN으로 응답 한다
8. CDN은 사용자에게 썸네일을 응답 한다

CDN cashed original image

1. 사용자가 CDN으로 썸네일을 요청 한다. 이때 썸네일 스펙이 URL에 있다
2. CDN은 캐싱된 썸네일이 없다. Thumbor로 이미지 리사이징을 요청 한다
3. Thumbor는 원본 이미지를 요청한다. 원본 이미지는 CDN으로 요청 한다
4. CDN은 캐싱된 원본 이미지가 있다. CDN은 Thumbor로 원본 이미지를 응답 한다
5. Thumbor은 요청한 원본 이미지를 썸네일로 변환 후 CDN으로 응답 한다
6. CDN은 사용자에게 썸네일을 응답 한다

CDN cashed thumbnail

1. 사용자가 CDN으로 썸네일을 요청 한다. 이때 썸네일 스펙이 URL에 있다
2. CDN은 캐싱된 썸네일이 있다. CDN은 사용자에게 썸네일을 응답 한다

마무리

EOF