아마존 라이트세일 인스턴스 트래픽 공유

Vultr는 기본 바탕이 쓰레기이기 때문에 트래픽풀이 아니라 트래픽나무를 줘도 안씁니다. ㅎㅎ
실제 인지도 면에서도 Linode와 DigitalOcean에 한참 뒤지는데 (얘네 둘다 트래픽풀 지원합니다)
Vultr 도쿄지점 속도가 그나마 괜찮게 나오는 덕에 한국에서만 인정받는 중이죠...

네. 저희는 얻어걸린 것이긴 하지만.. 트래픽 2테라가 공으로 생겼습니다.
캐시서버가 2테라 짜리인데...

저희는 백업서버를 라이트세일 인스턴스로 구성을 또 했거든요. 처음에는 이 서버 2테라를 그냥 아깝지만 무쓸모다 라고 생각을 했지만 나중에 알아보니 이게 공유가 되는 것 같아 2테라가 캐시서버에서 오버되면 백업서버의 트래픽에서 사용량이 차감될 수 있다는 것을 예상하고 있었죠.

- 차감이라는 표현이 좀 어울리지 않을 수 있네요. 이미 트래픽 두개를 합산해서 과금하고 있으니까요...

기존에도 제가 언급했던 부분인데 트래픽이 모자라면 그냥 인스턴스생성만 하면 되는 그런 아주 심플한 상황입니다.

다만 이게 기술적인 한계로 인해서 발생한 상황으로 추측되므로
기술적인 문제가 극복되면 트래픽풀 정책을 언제든 철회할 가능성도
있겠지요.... 어차피 트래픽풀이라고 공식적으로 인정한 적이 없으니
철회도 쉽겠죠.
기술적인 한계라고 하지만 그게 절대적인 한계는 아닐겁니다.
기존의 트래픽 계산 시스템 방식으로 해결할 수 없는거지
개발하려고 들면 개발 못할건 없겠지요.
트래픽풀때문에 손해보는게 트래픽 계산 시스템을 뜯어고치는
비용보다 더 크다고 하면 그냥 개발하지 않을까요...
개발비용보다는 그냥 트래픽풀 인정해주는게 비용이 덜 드니까
놔두는 것으로 보입니다.
근데 생각해보면 한편으론 우리나라처럼 트래픽이 터무니없이 비싸고
해외트래픽은 더 비싸서 거의 쓰지도 못하는 그런 이상한 나라가
아니고선 트래픽풀 된다고 해서 크게 달라질 것도 없을겁니다.
아마존 EC2쪽 고객이 CloudFront 대신 라이트세일로 이탈할
가능성 정도가있는데 어차피 대형 고객들은 귀찮아서 그런 짓
안할테니 미미한 수준일테구요...

저는 faq 의 안내나 청구서에서 트래픽 사용은 통합 청구, 그리고 사용시간도 같은 플랜은 통합(같은 플랜은 요금이 같기 때문에 사용시간도 통합이 가능합니다.) 통합표시 하는 것으로 보아..

정책적으로는 최소한 같은 플랜에서는 트래픽풀을 인정하고 있다고 봅니다.

물론 지금 링크의 문의처럼 서로 다른 플랜의 경우까지의 안내는 어디에도 없었고 내부적으로 현재 시행중인 것을 답변했을 가능성이 높죠.

개인적인 생각이지만 최소한 같은 플랜에서는 트래픽풀이 사라질 염려는 없다고 보고 있습니다.

nginx의 backend 문법을 사용해서 다른 캐시서버를 우선 체크하도록 하고, 원본서버는 backup; 으로 설정하여 최후의 수단으로만 이용하도록 합니다. 우선 체크하는 캐시서버는 한 대로 몰아줄 수도 있고 서버마다 다르게 설정할 수도 있습니다. 만약 캐싱할 용량이 많다면 (오래된 이미지도 심심찮게 검색되는 사이트라면) 한 대로 몰아주고 거기에 블록스토리지를 추가하면 캐시 효율이 훨씬 높아집니다.