heic 파일 관련 조사 및 구현

heic → jpg 변경 방법 조사

현재 heic → jpeg, jpg image convert 대표적으로 2가지 방법 존재하는 것으로 확인했습니다. 아마 추가적인 방법이 더 있을 것입니다. 

1. AWS Lambda , AWS S3 Bucket 사용

• AWS Lambda 요금아키텍처 시간 요청 

  x86요금
  처음 6십억GB-초/월	GB-초당 USD 0.0000166667	요청 1백만 건당 USD 0.20
  다음 9십억GB-초/월	GB-초당 USD 0.000015	요청 1백만 건당 USD 0.20
  다음 150억GB-초/월	GB-초당 USD 0.0000133334	요청 1백만 건당 USD 0.20
  Arm 요금
  처음 75억GB-초/월	GB-초당 USD 0.0000133334	요청 1백만 건당 USD 0.20
  다음 112억 5천GB-초/월	GB-초당 USD 0.0000120001	요청 1백만 건당 USD 0.20
  다음 187억 5천GB-초/월	GB-초당 USD 0.0000106667	요청 1백만 건당 USD 0.20

  1백만 건을 넘지 않을 것으로 판단됩니다. 2월 25일 0.20 달러 기준은 한화로 약 258원 정도입니다.

AWS 람다 사용 장점

• 실제 사용량에 대해서만 비용이 청구
• 이벤트 기반의 비용으로, 일정 주기, 조건 등에 함수를 호출하므로 리소스를 낭비하지 않게 되어서 비용이 저렴하다. (AWS Lambda 경우 함수 100만번 실행당 0.2달러)
• 자체 서버 실행하고 관리하는 대신 필요한 만큼 클라우드 기반 컴퓨팅시간에 대해 비용을 지불

2. 애플리케이션의 품질에 집중 가능

• 서버에 신경 쓸 필요가 없어지므로 사용자는 개발하는 애플리케이션의 품질 향상에 좀 더 집중할 수 있다.

3. 높은 가용성과 유연한 확장

• 요청이 들어올때만 실행되고 동적으로 자원을 할당하기 때문에 가용성이 높고 스케일링에 신경 x
• 애플리케이션은 자동으로 확장될 수 있고, 개별 서버 단위가 아닌 사용단위(처리량, 메모리)를 설정/해제하여 용량을 조정
• 동적으로 자원을 할당받아서 단기간 이벤트성 트래픽을 감당하는 경우 효과적

4. 빠른 개발 배포

• 간단한 패키징 및 배포
• 릴리즈 주기 감소
• 높은 생산성
• 유지보수나 기능 추가에 효율적이라 관리보다 개발에 집중

• 1. 비용 절감
• AWS 람다 사용 단점
  • 함수 요청이 없으면 수면 상태로 된다. 즉, request가 와서 함수를 깨우는데 시간이 조금 발생한다.
  • 서버가 항시 요청에 대기하고 있는게 아니여서 Iaas, PaaS 등의 모델보단 요청시간이 느리다.
  • 실시간 서비스에는 적합하지 않음
  • 프로젝트 규모가 작다면 별로 신꼉쓸만한 사항은 아니지만 규모가 커지거나 속도를 요구하면 좋은 선택은 아니다.
  2. 긴 시간을 요하는 작업에 불리함
  • 서버리스는 단순 작업(댓글 쓰기, 이메일 보내기 등) 에는 적합하지만, 긴 시간을 요하는 작업(동영상 업로드, 데이터 백업 등)에는 굉장히 비효율적이다.
  • 서버리스는 함수가 1회 호출 될 때, 사용할 수 있는 메모리 제한이 있다.
  3. 로컬 데이터를 사용할 수 없다.
  • 서버리스는 무상태로 구현되어야 한다.
  • 하나의 작은 기능으로 나뉘어진 함수들은 요청마다 새로 기동되어 호출되기 때문에 전후 상태를 공유할 수 없기 때문이다.
  • 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다.
  4. 클라우드 제공 플랫폼에 심하게 종속적
  • 기존 IaaS, PaaS모델은 플랫폼을 바꾸는게 어렵지 않지만 서버리스는 애플리케이션 구조 자체를 바꾸기 때문에 다른 플랫폼으로 이전하기 힘들다.
  • 클라우드 서비스 업체에 종속적이다.
  • 플랫폼의 가격이나 정책, 서비스 변경에도 민감하게 반응해야됨을 의미한다.1. ColdStart

• 함수 요청이 없으면 수면 상태로 된다. 즉, request가 와서 함수를 깨우는데 시간이 조금 발생한다.
• 서버가 항시 요청에 대기하고 있는게 아니여서 Iaas, PaaS 등의 모델보단 요청시간이 느리다.
• 실시간 서비스에는 적합하지 않음
• 프로젝트 규모가 작다면 별로 신꼉쓸만한 사항은 아니지만 규모가 커지거나 속도를 요구하면 좋은 선택은 아니다.

2. 긴 시간을 요하는 작업에 불리함

• 서버리스는 단순 작업(댓글 쓰기, 이메일 보내기 등) 에는 적합하지만, 긴 시간을 요하는 작업(동영상 업로드, 데이터 백업 등)에는 굉장히 비효율적이다.
• 서버리스는 함수가 1회 호출 될 때, 사용할 수 있는 메모리 제한이 있다.

3. 로컬 데이터를 사용할 수 없다.

• 서버리스는 무상태로 구현되어야 한다.
• 하나의 작은 기능으로 나뉘어진 함수들은 요청마다 새로 기동되어 호출되기 때문에 전후 상태를 공유할 수 없기 때문이다.
• 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다.

4. 클라우드 제공 플랫폼에 심하게 종속적

• 기존 IaaS, PaaS모델은 플랫폼을 바꾸는게 어렵지 않지만 서버리스는 애플리케이션 구조 자체를 바꾸기 때문에 다른 플랫폼으로 이전하기 힘들다.
• 클라우드 서비스 업체에 종속적이다.
• 플랫폼의 가격이나 정책, 서비스 변경에도 민감하게 반응해야됨을 의미한다.

 

저희 회사는 ImageConverter를 사용하지 않기로 하였습니다. 왜냐면 이미 자체적으로 보유한 가용한 서버가 있고, 온프레미스 방식으로 진행중이여서 AWS 사용하지 않고, 플랫폼에 종속적이지 않은 상태로 개발하기로 하였습니다. 

 

파이썬으로 이미지 컨버터를 한 코드가 있는데 추후 블로그에 작성하겠습니다. 

 

2. Docker에 ImageMagick 설치하여 진행

Docker 사용하여 ImageMagick 환경 구축하고, 이를 통한 HEIC → JPG 변환을 수행할 수 있음.

ImageMagick 사용 장점

• 독립적인 환경 제공 - 특정 클라우드 서비스 종속이 없다.
• OS 업데이트와 무관하게 환경 유지 가능 하다.
• 추가적인 비용이 발생하지 않는다.

ImageMagick 사용 단점

• 윈도우 환경에서는 추가 설정 필요(WSL2, Hyper-V등)
• Docker 컨테이너 관리가 필요함
• AWS Lambda 같은 자동 확장 기능 없다.

로컬에서 동작시키기 위한 brew install image magick 설치

brew install imagemagick

 

Dockerfile 수정

RUN apt-get update && apt-get install -y \
    libfreetype6 \
    libfreetype6-dev \
    fonts-dejavu-core \
    fonts-liberation  \
    imagemagick \
    libheif-examples \
    libheif-dev \
    gettext && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

 

 

추가적인 내용 

현재 두 가지 방법으로 각각 개발 서버에서 테스트하여 실질적으로 운영 배포를 ImageMagick을 설치하여 진행하는 데 많은 시행착오가 있었습니다.

프레임이 여러 개라면 1개가 아닌 여러 파일로 서버 디렉토리에 떨어지는 이슈, 실제 개발 서버에서는 배포가 정상적으로 되었으나, 가비아 서버에서는 build 시, 도커 메모리 부족 오류로 빌드가 안되는 문제 등 다양한 에러사항이 있었지만, 현재 정상적으로 반영하였습니다.

앞으로 이러한 문제를 개선하기 위해 Dockerfile에 해당하는 이미지의 OS를 Ubuntu로 바꿔주었습니다. 이때 송금 요청 시, 특정 시간이 지나면 결제를 못 하도록 비즈니스 로직이 설정되어 있는데 KST로 설정되어 있지 않고, UTC로 설정되어 결제가 안 되는 오류가 발생하였습니다.

꼭 이미지를 바꾸면 DATETIME을 확인해 보시길 바랍니다.