대용량 다운로드 서비스에 라이트세일을 이용하는 시나리오를 계산해보고 있는데 생각보다 가격차이가 안나네요...
애초에 저정도로 서비스가 성장할꺼냐? 부터가 문제지만..사업이 아니라 취미 활동이라 최대 비용에 민감합니다.
단순히 웹페이지를 보여주는 서비스 트래픽 총량이 늘어나는거면 그떄되서 더 좋은 서버로 업글 하면 되는 문제지만 파일 전송 문제는 그리 쉽지 않아서...적당한 솔루션이 있나 대충 찾아봤는데 딱히 맞는것도 없어보이네요.
그래서 이런걸 만들어 볼까 생각 해보았는데요. 웹개발자가 아니라서 웃음밸 같은 허무맹랑한 소릴 수 있습니다. 그렇다고하면 다른 방법을 찾아볼겁니다. 개발 시간 쓰기전에 질문을 드리는거구요. 구현은 node로 개발할 생각입니다
업로드 절차
1. 글 작성중 대용량 파일 업로드 클릭 (200메가 이상)
2. 업로드시 S3로 업로드
3. 업로드가 끝나면 S3접근시 식별할 수 있는 정보받음
4. 웹서버는 컨텐츠 매니저 서버에 게시파일 식별정보와 S3상 식별 정보 전송
5. 컨텐츠 매니저에서 S3에 진짜 업로드가 되었는지 valid 체크
6. 클라이언트에게 작업 완료 통보. 게시글은 비공개로 등록. 이제 클라는 자유에요
7. 컨텐츠 매니저는 계속 작업. 하위노드(라이트 세일 서버)들의 상태를 체크 (용량이라던가..)
8. 하나의 노드를 선택해서 게시파일 식별정보, S3의 경로를 알려주며 복사작업 요청
9. 노드에서 복사가 끝나면 컨텐츠 매니저에 게시파일 식별정보와, 복사완료, 머신 상태 통보
10. 컨텐츠 매니저에서 게시파일 식별정보를 키로 하여 파일의 http URL 저장, 머신의 상태 저장
11. 웹서버로 게시파일의 식별정보를 전송하고 게시글 공개로 설정
다운로드 절차
1. 게시글열람.
2. 비동기로 컨텐츠 매니저에 게시파일 식별정보 전송하며 URL 요청
3. 컨텐츠 매니저 서버에서 게시파일로 DB 탐색 후 URL 반환
4. 다운로드 클릭
5. NODE에 저장된 파일 전송
아 삭제나 수정, 머신 확장에 대한 정책은 깊게 생각을 안했네요... ㅡㅡ; 아예 폐기할 수도 있는 계획이니 의견 들어보고 생각 하겠습니다.
대충 이런 로직을 바탕으로 시나리오를 짜서 비용을 계산해보았습니다. 환율은 편의상 1000원으로 퉁치고 마지막에..
1. S3에 파일이 저장되므로 전체 컨텐츠 량만큼의 용량을 확장 해야하고
2. 라이트세일의 노드개수는 최적의 사양에서 정해진 트래픽을 고려해 확장 하는 원칙을 새웁니다.
시나리오 : 1T의 전체 컨텐츠, 한달 9T의 전송량 (웹서비스와 별개. 순수 파일 위주)
1. 공통비용
1) 사용자로부터 파일을 업로드 받는 S3를 1t까지 확장 합니다. 0.025 * 1000 * 1000 = \25,000
2) 컨텐츠 매니저 서버는 문자열 저장과 반환을 하는 역활이니 일딴 싼걸로 해보겠습니다. 5 * 1000 = \5,000
3) 잡다하게 발생하는 관리비용 크게 잡아 \50,000
총액 == \ 80,000
2. 머신별 시나리오
1)
라이트세일 10달러 모델을 3대 사용 10 * 3 * 1000 = \30,000
라이트세일 용량 확장 880gb 0.1 * 880 * 1000 = \88,000
== \118,000
2)
라이트세일 20달러 모델 3대 사용 20 * 3 * 1000 = \ 60,000
라이트세일 용량 확장 760gb 0.1 * 760 * 1000 = \ 76,000
== \136,000
3)
라이트세일 40달러 모델 2대 사용 40 * 2 * 1000 = \80,000
용량 확장 \68,000
== \148,000
4)
최상위 + 최하위 모델 혼합...
을 생각해봤는데 파일 전송에 높은 CPU 파워는 필요 없으니 오버스펙 같네요..
== 예산 오바
총합 20~ 23만. 환율 고려하면 24에서 28만 까지 나오는군요.
질문 정리
1. 저게 의미있는 짓일까요? 아니면 호작질에 불과할까요?
2. 특별한 연산 없는 서버에서 파일 전송시 사용하는 버퍼(램)은 회선속도에 준한다고 보면 될까요?
그렇다면 위의 방식에서 10달러나 20달러짜리가 1코어/2코어 2gb/4gb니 best fit이라고 봐도 될지....
물론 vcore기 떄문에 더 여유를 줘야 한다는 것은 압니다. 일딴 운영체제나 스크립트등에 의해 오버헤드등의 요인은 제외하고 생각하려구요.
3. iocp같은 소켓통신이나 비동기 메세지 교환방식 통신에만 지식이 있지 웹 프론트엔드나 대용량 통신에 대한 지식은 부족한 편입니다...
쓸데없이 복잡한 것 같습니다.
S3에 저장한 파일을 왜 노드에 복사하지요? 똑같은 파일을 두 군데 저장하면 돈만 두 배로 들 뿐입니다. 아니, 라이트세일 블록 스토리지가 S3보다 4배 비싸니, 돈은 5배가 들겠네요.
사용자에게 파일을 전송해 주는 역할을 하는 노드에서는 최근에 많이 요청받은 파일들 위주로 캐싱만 해두면 됩니다. 라이트세일을 이미지서버로 쓴다는 분들도 모두 이런 방식입니다. nginx의 proxy cache를 사용하면 모두 자동으로 되고, 사용자 인증 등의 기능이 추가로 필요하더라도 약간의 어플리케이션 로직을 추가하면 그만입니다. 파일 하나의 용량이 수십기가씩 되지 않는 이상, 라이트세일 쪽에 블록 스토리지를 추가할 필요는 없다는 얘기입니다. 캐싱 효율만 잘 나와 준다면 S3에서 파일을 다시 받아오는 비용이 블록 스토리지 추가 비용보다 훨씬 적게 들 겁니다.
1테라 용량, 월 9테라 트래픽은 이 바닥에서 아무것도 아닙니다. 동영상 인코딩 등 복잡한 작업이 들어가지만 않는다면 중고 휴대폰에 외장하드 하나만 달아놓아도 충분히 처리할 수 있는 분량이니 어렵게 생각하지 마세요. 실제로 라이트세일을 사용하여 매달 10테라 내외의 트래픽을 처리하는 고객분들이 있는데, 트래픽을 제외한 서버 자원 소모량은 제로에 가깝습니다.
저라면 컨텐츠 매니저 포함해서 라이트세일 10달러짜리 4개 + S3만 쓰겠습니다.
총 $65 + S3 트래픽 비용 + 잡다한 관리 비용 = 끝.
아니면 그냥 Backblaze B2처럼 넘사벽으로 저렴한 곳에 올려놓고 그대로 뿌려버리시죠. ㅎㅎ