본 문서는 기존 서버 스토리지에 저장되던 이미지를 AWS S3로 이전하는 작업에 대한 회고록입니다. 서버 스펙 : Ubuntu(22.04) + PHP(7.3)
AWS의 EC2 인스턴스에 Nginx와 PHP(FPM)를 설치하여 웹 사이트를 운영하던 중 동시 사용자 수 증가와 스케일 업 효율 감소로 인해 스케일 아웃을 진행해야하는 상황이었습니다.
이미지가 서버 스토리지에 저장되는 상황으로 스케일 아웃 시 이미지를 등록, 수정, 삭제하게될 경우 인스턴스간의 동기화가 되지 않아 스케일 아웃이 불가하여 기존에는 스케일 업으로만 대처하고있었습니다.
더 이상의 스케일 업이 어려운 상황에서 여러가지 방법을 고민했습니다.
- AWS의 S3로 이미지 서버 이전
- AWS의 Lambda를 사용하여 이미지 업로드 시 모든 인스턴스 이미지 저장
- AWS의 EFS를 사용하여 인스턴스의 이미지 저장 폴더 동기화
먼저 이미지 서버 이전의 경우 기존 로컬을 바라보던 이미지 경로 및 이미지 업로드 관련 파일을 모두 수정해야했고 또한 프레임워크나 Composer, Class 등을 모두 사용하지 않는 상황이었기에 작업량이 굉장히 많을 것이라 예상했습니다.
Lambda의 경우 이미지 업로드 시 각 인스턴스에 이미지가 저장되는 시간에 차이가 있어 순간적으로 특정 인스턴스에서 이미지가 출력되지 않는 이슈가 발생할 것으로 예상했습니다.
위 예상들을 근거로 가장 간단하고 안정적인 방법이 3번이라고 판단했고 곧 작업에 착수했습니다.
다음은 인스턴스와 EFS를 마운트하는 방법입니다.
- 이름과 VPC를 선택하여 EFS를 생성합니다.
- 인스턴스에 EFS Mount를 위한 amazon-efs-utils를 설치합니다.
- Mount할 파일 시스템에 들어가 연결 버튼을 눌러 Mount를 위한 명령어를 복사합니다.
- 원하는 위치의 폴더에 마운트합니다.
- 이후 인스턴스 재시동 시 자동으로 마운트 될 수 있도록 fstab, autofs, systemd 등을 이용하여 자동 마운트를 설정합니다.
이렇게 AWS EFS 서비스를 이용하여 이미지 폴더를 네트워크로 공유하게 되었고 의도했던대로 스케일아웃 시 이미지를 공유 할 수 있게 되었습니다.
AWS EFS 서비스를 운영 서버에 적용 후 약 한 달간 운영했을 때 확인한 장/단점입니다.
장점
- 저렴하다.
- 비교적 간단하게 세팅할 수 있다.
- 이미지 서버가 분리되지 않은 환경에서 스케일 아웃을 고려했을 때의 리소스가 적다.
단점
- 네트워크를 통한 마운트이기 때문에 파일 이동 등에 딜레이가 있다.
- 이미지 폴더를 여전히 서버 스토리지에 저장하기 때문에 스토리지 크기가 계속 증가한다.
간단하게 구성하여 오토스케일링을 통해 코앞의 이벤트는 무사히 넘겼지만 계속해서 EFS 서비스에 의존하기에는 예상보다 단점이 너무 컸습니다.
현재 Github Actions를 이용해 운영 브랜치 병합 시 Repo를 압축하여 S3 Bucket에 업로드하고 이후 AWS CodeDeploy 서비스를 사용하여 Bucket에 업로드된 Repo를 EC2 인스턴스에 OVERWRITE 하는 방식으로 배포를 진행하고 있던 상황에서
마운트된 EFS에 배포를 진행하다 보니 운영 서버 배포 시 네트워크 딜레이로 인해 약 1분 간 사이트가 불안정해지는 현상이 발생했습니다.
또한 이미지 리소스가 계속 증가함에 따라 배포 및 리소스 이동 시 많은 시간이 소요되는 문제 또한 예상되었습니다.