ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [aws] image resize(1): s3 batch & lambda
    aws 2021. 5. 16. 19:07

    [들어가며]

    콘텐츠 이미지(width: 930px)
    콘텐츠+여백 이미지(width: 930px)

     

    하욤! 현 회사는 문제, 해설, 정답, 개념 등을 이미지(. png)로 관리하고 이미지는 저화질(width: 310px), 고화질(width: 930px)로 나눠 사용한다. 베스트 프로세스를 꼽는다면 이미지 서버를 두고 고화질 파일만을 저장하고 요청에 따라 저화질 이미지를 내리도록 설계하는 것이지만 우린 이미지 서버를 통해 고화질을 저화질로서 바꿔 사용하는 것이 아닌 애초에 두 종류로 저장하고 있었다. S3 저장 비용은 두 배로 더 나오겠지만 이미지 서버를 구축할 여력이 없는 우리에겐 어쩔 수 없는 선택이라고 들었다. 그러다 충격적인 이슈를 들었는데 아래와 같았다.

     

    "저화질 이미지 용량과 고화질 이미지 용량이 다르지 않다."

     

    곧바로 콘텐츠를 등록하는 사내 시스템을 확인하니 압축을 놀랍게도 하지 않고 크기만 줄였고 우린 여태까지 이걸 저화질이라고 부르고 있었다. 그래서 2.0 개발을 준비하며 기존의 만들어진 저화질을 사용할 이유는 더욱이 없다고 어필했고 2.0을 오픈하며 이를 버리기로 결정했다. 라이브 이전을 준비한 뒤 테스트를 하는데 심각한 이슈가 발생했고 저화질 이미지를 사용하는 웹, 앱 클라이언트에서 이미지가 들쑥날쑥하게 보이기 시작했다. 알고 보니 'width: 930px' 기준은 초창기 이미지엔 적용되지 않았던 것이었다. 초창기의 이미지는 저화질에서도 들쑥날쑥했지만 가로가 그렇게 크지 않다 보니 심각하진 않아서 그대로 서비스하고 있었다.

     

    저화질 이미지: 310px * 150px
    잘못된 저화질 이미지: 270px * 150px
    ------ 가로 40px 차이 -------------

    고화질 이미지: 930px * 450px
    잘못된 저화질 이미지: 810px * 450px
    ------ 가로 120px 차이 ------------

     

    눈앞에 한 줄기 빛이 스쳤다. 들쑥날쑥한 이미지들도 공백을 포함하지 않은 콘텐츠인 규칙이 있었다. 따라서 모든 이미지를 대상으로 공백을 붙여 가로를 930px로 통일하기로 결정됨에 따라서 공사를 시작하였다.

     

     


     

    [local imagemagick]

    2.0 개발을 하며 우린 개발 환경과 라이브 환경이 뒤섞인 콘텐츠를 살리기 위해서 S3의 환경을 분리하기로 했다. 이에 따라서 대규모 이관이 동행되었는데 나의 계획은 이러했다. (추후에 다른 글로서 깊게 다룰 것이니 일단은 넘기자.)

     

    1. 1.0의 망가진 S3으로부터 모든 트리를 로컬로 다운로드한다.
    2. 다운로드된 모든 트리를 2.0의 트리를 변경한다.
    3. 변경된 2.0의 트리를 새로운 환경에 업로드한다.

     

    들어가며 설명했던 것과 같이 위의 작업에서 가로를 930px로 바꾸는 작업이 추가적으로 이뤄져야만 했기에 다음과 같이 플로우를 수정했다. 변경된 나의 계획은 아래와 같다.

     

    1. 1.0의 망가진 S3으로부터 모든 트리를 로컬로 다운로드한다.
    2. 다운로드된 모든 트리를 2.0의 트리를 변경한다.
    3. imagemagick 프로그램을 이용하여 이미지의 가로를 930px로 바꾼다.
    4. 변경된 2.0의 트리를 새로운 환경에 업로드한다.

     

    모든 프로세스를 구성하고 작업을 돌리니 예상치 못한 오류가 나왔다. shell script를 사용해서 imagemagick을 돌리도록 구현하니 컴퓨터의 메모리를 모두 사용하여 컴퓨터가 숨도 못 쉬는 상황이 연출되었다. 그래서 가장 빠른 해결 방법으로 sleep 함수를 사용해서 imagemagick이 연쇄적으로 실행하되 딜레이를 주는 것을 선택했다. 트리가 너무 깊고 노드 또한 너무나 많아서 돌리고 무작정 기다렸다. 3일이 넘도록 끝날 기미가 보이지 않았다. 2.0 배포에 주어진 시간은 24시간... 너무나 턱 없는 시간이었기에 다른 방법을 찾아야만 했다.

     

     


     

    [remote imagemagick]

    결국 우린 방법을 찾았다. S3 Batch Operations 기능을 이용하면 수백, 수백만 또는 수십억 개의 S3 객체를 간단하고 간편한 방식으로 처리할 수 있었다. S3 Batch Operations 기능을 통해서 Lambda를 호출하고 가로가 변경된 이미지를 S3에 저장토록 하였다. 이어진 포스트에서는 이를 구현하는 방법부터 결과를 알려주고 겪었던 문제에 대해서 공유하고자 한다.

     

     


     

    [*imagemagick]

     

    이미지를 새로 만들거나, 고치는 데 사용되는 오픈 소스 소프트웨어이다. 이미지 매직은 대부분의 이미지 형식을 읽고, 변환하거나 쓸 수 있다. 이미지의 외곽을 자르거나, 색을 바꾸는 것을 비록한 다양한 효과를 줄 수 있으며, 이미지의 회전, 합치기, 문자삽입, 선, 다각형, 타원, 베지에 곡선을 그려넣거나, 이미지 늘이기 등의 작업을 할 수 있다.
    wikipedia | https://ko.wikipedia.org/wiki/이미지매직

     

    위에서 언급한 imagemagick는 이미지를 읽고, 변환하거나 쓸 수 있는 프로그램이다. 

     

     

     

     

    ... 다음 장에 이어서 ...

    'aws' 카테고리의 다른 글

    [aws] health check(gray): elastic beanstalk  (0) 2021.05.25
    [aws] image backup(2): lambda & s3 & nas  (0) 2021.05.19
    [aws] image backup(1): lambda & s3 & nas  (0) 2021.05.18
    [aws] image resize(2): s3 batch & lambda  (1) 2021.05.16
    [aws] what is aws?  (0) 2021.05.14

    댓글

Designed by Tistory.