온라인 사진전을 개최하며 겪었던 후일담 -2편

혹시 이전 편을 보지 않으신 분들은 이전 글을 참조 해도 좋을 것 같다. 

 

[프로젝트/개인프로젝트] - 온라인 사진전을 개최하며 겪었던 후일담 -1편

온라인 사진전을 개최하며 겪었던 후일담 -1편

 

왜 이렇게 정적 이미지에 대해서 조회시 금액이 많이 나갔는가?

 

이전편 초입에서 봤듯이 가장 큰 문제는 하루만에 다 쓸정도로 정적이미지 전송량을 도대체 어디서 쓴 걸까? 나는 대략 여러가지를 예상을 했지만, 다음과 같이 요약할 수 있을 것 같다.

 

첫번째, 정말 놀라울 정도로 많은 사람들...

 

전시회 오픈 당일 사용자수.. 800명..;;

 

위의 사진과 같이 일단 첫 오픈에 사람이 정말 물밀듯이 들어왔다는 사실이다. 물론 800명중에서 테스팅과 같이 50명 들어오고 기타등등.. 허수가 좀 섞이긴 했겠지만, 그래도 정말 많은 사람이 몰렸다는 사실이다.  

덕분에 정말 많은 사람들이 전시회를 클릭하고 전시회 사진들을 봤다는 사실이다. 물론 순수 이탈률등을 고려해봐도 많은 사람들이 눌러봤다는 것이 크다. 현재는 평균 100명정도가 왔다 갔다하는 정도의 서비스가 되었지만.. 이러한 계산을 하지도 않고 나는 마구잡이로 설계를 했었는데, 실제로 이러한 비용이 부담되는 것도 사실이었다. 

 

현재는 80~100명 내외정도 사람들이 들어갔다 나왔다한다.

 

 

두번째 어리석은 파일크기

사진전이라는 특징때문에, 나는 하나의 멍청한 신념이 있었는데,  원본에 가까운 파일을 보여줘야 한다는 것이었다. 실제로 디지털 카메라로 촬영한 사진들은 보정작업을 거치고 나면 대체적으로 용량이 큰 편이다. 최대 화질로하면 최대 10~20MB정도 되는 파일을 완성할 수 있다. 이러한 파일들은 실제로 엄청 무겁고... 엄청 크다. 그래서 아무리 캐쉬서버를 둔다해도 이건 다운 받는 사람, 보내주는 서버 입장 둘다 지는 완전한 치킨 게임이라고 생각하질 않았다. (아무리 생각해봐도 나는 진짜 멍청이 같은 생각 이었다.)

 

위의 사진은 처음 요금이 많이 나왔을때 사용했던 파일들의 크기이었다. 이러한 파일들이 넉넉 잡아 100개는 넘게 있었다. 물론 점점 크기는 줄었지만, 그런 걸 감안해도 꽤 큰 사진 용량이었다. 그래서 AWS S3에 CloudFront까지 얹어서 사용했지만, 로딩이 느린 것은 어쩔 수 없었다. 파일크기가 너무 컸으니까, 이러한 파일 크기가 큰 반증은 다음과 같은 지표로도 볼 수 있었다.  

 

 

 

CloudFront 금액만 따로 빼서 비용과 사용량을 체크해봤는데, 3일날 당일날도 이미 26GB를 썼고, 심지어 전시회 당일날에도 225.39GB!!!!나 써버린 것이다. 그래서 요금이 미쳐 날뛰기 시작했다. 하루에 거의 3만원씩 나가는 것이였다. 물론 해결은 했지만 해결방법은 후술하도록하겠다. 

 

세번째 한 번에 많은량의 정보 노출

 

우리 전시회에서 가장 아쉬운 부분은 다음과 같은 것이었다. 예를 들어서 우리 신입생들이 하는 사진이 총 31장정도 되면 데이터를 한번에 다 불러와야했다. Json으로 모든 정보를 다 불러와야만 했고 그래서 버튼 한번에 31장을 모두 노출시키지는 않았지만, 정보 자체는 다 불러와서 안보이게 미리 로딩 시켜놓는 방법이 아닌가 싶었다.

그래서 사용자 입장에서는 한 두장정도만 보고 페이지를 빠져나가도, 실제로 모든 사진 데이터를 불러오는 셈이 된다. 그래서 아무래도 데이터가 생각 외로 많은 양의 데이터가 자꾸 빠지는게 아닌가라는 생각이 든다.

물론, 이게 확실하지는 않다. 어디까지나 추측이고, 아마 그럴것이다라는 생각으로 주관적으로 백엔드 입장에서 서술하는 글이다.

 

이렇게 사진이 30장이 있어도 실제로 페이지에는 1장만 보인다. 좌우로 스크롤할때 사진이 바뀌는 방식이다. 

 

그래서 해결은 어떻게 했었는가?

 

첫번째의 인원 문제야 시간이 지나면서 해결되었지만, 어쨌든 사람들이 많이 보든 적게보든 사진을 보는 만큼 용량이 빠지기 때문에 이 용량을 줄이는 방법을 택했다. 분명히 사진 용량은 비상식적으로 컸고 이 용량을 줄이는 방법을 택했다.

 

사진 용량을 줄일때 1MB까지 해상도를 최대한 화질에 무리 없을 정도로 변경시키면 되겠다는 생각으로 사진 동아리에서 사진에 대한 친구들에 조언을 받고 회장형이 작업을 해줬다. 우리는 평균 10MB정도 되는 사진 파일들을 대부분 1MB로 바꾸었다. 

 

바꾸고 난뒤

 

이렇게 사진 용량을 확 떨어트린 이후의 금액은 정말 많이 감소했다.

 

 

작업하기전과 작업후가 가격 차이가 거의 7배정도 차이난다고 보면된다. 

 

그리고 실제로 이후 금액이 0이 되었는데 이것은 왜 이런 것이나면 다른 작업을 했기때문이다. 이 작업의 경우, 동아리의  활동 금액이다보니, 영수증 처리에 큰 문제가 생길까 싶어서 차라리 동아리 회장의 계정을 만들고 그쪽으로 리소스를 다 돌리면 영수증에 있어서도 명확하게 끊을 수 있겠다는 생각을 했었다. 

거기다가 이정도로 많은 금액이 나올거라고는 생각 안했던터라... 전부에 대해서 일단 결제하고 후처리하는 것도 귀찮았다. 나온 금액에 대해서만 동아리에 대해서 금액처리를 받는게 더 효율적이라고 생각했다.

이후에 정적 파일에 대한 리소스들을 동아리 회장의 계정 S3로 이동시키고 DB에 일치화 시키는 작업을 거쳤다. 

 

 

 

이후에 적당히 S3에서 리소스를 사용하면서 하루에 1$가 안되는 금액으로 꾸준히 이용하면서 사용하고 있는 중이다.  물론 사람이 줄었던것도 있기도하다.

 

시연 영상

• 사진 전시 기능. 사진 전시와 사진에 대한 여러가지 정보들을 같이 노출합니다. 사진의 제목, 작가명, 사진 설명, 사진 메타데이터들을 자동으로 노출시켜줍니다.

 

 

• 방명록 기능 소셜로그인을 통해서 로그인한 유저이름과 소셜로그인 사진으로 방명록 작성을 할 수 있습니다.

 

 

• 소셜로그인 기능: 구글과 카카오를 통한 소셜로그인 기능이 있습니다.

 

 

더 자세한 시연영상은 아래 링크를 참조 해주세요.

 

유튜브 링크

 

마지막으로...

AWS 운용시 예상보다 정적 파일에 대해서 금액이 많이 나올거라고 생각한 사람이 많이 없을 거라고 생각한다.  나도 그랬기때문에... 그래서 이 후기를 보고 혹시나 AWS를 통한 서비스 개발을 할때 이러한 정적 파일들에 대한 금액도 필수적으로 고려해봐야할 대상이라는 걸 알아주면 좋을 것 같다. 어쨌든 필요 이상으로 돈을 사용하는 것보다 적절하게 금액을 사용하는 것이 중요하다고 생각한다.  

 

진짜로 간단한 후기를 적자면, 

 

나는 우리끼리 간소하게 했던 서비스가 이렇게 많은 사람들이 들어올거라고 예상조차하지 못했다.

특히나, 이렇게 정말 많은 사람들이 한번에 몰려서 데이터를 쓰고 그런 데이터에 대해서 모든 금액이 매겨지는 것이 너무나도 당황스러웠다. 분명 오픈하기전까지만 해도 이런 생각을 해본적도 없었다. 하지만, 막상 이런 일이 발생했고, 이러한 문제를 빠르게 해결하기 위해서 나는 내가 뭘 잘 못했는지를 돈이 지출해보면서 깨닿게 된 것 같아서 다행이라고 생각한다.  이러한 실수를 막기위해서 열심히 노력한 것 같아서 다행이라고 생각한다. 

만약 이 프로젝트가 단순히 100명이 보는게 아니라 천명, 만명이 보는 단위에서 이런 실수를 했었더라면... 생각하기 싫다. 그래도 이러한 프로젝트를 통해서 최소한의 가이드라인을 잡을 수 있게 되서 다행이라고 생각한다. 

꽤나 많은 내용을 한번에 보기 쉽게 정리하기가 너무 힘들다. 휴... 후기 끝!