근데 생각해보니까 트래픽풀의 가능성이 아예 없는건 아니군요..
뭐가 문제냐 하면 [로드 밸런서]의 문제가 있습니다..
라이트세일은 로드 밸런서 서비스가 있거든요..
상식적으로 추측컨데 트래픽 계산은 게이트웨이에서 하고 있을겁니다.
거기서 인스턴스의 IP로 외부로 나가는 트래픽 총량 계산해서 과금하겠죠.
근데 로드밸런서 서비스가 지원되면 로드밸런서 <-> 인스턴스간 통신은
내부 트래픽이므로 과금이 안됩니다.
그대신 인터넷 <-> 로드밸런서간 통신이 과금 대상이 되겠죠.
무료트래픽이 없는 경우에는 로드밸런서가 중간에 끼어도 과금계산에서 별 문제가 안됩니다.
근데 인스턴스별 무료트래픽이 있다면? 이럼 계산이 정말 애매해지는겁니다.
로드밸런서 <-> 인스턴스 통신에서 인스턴스 별로 트래픽을 따로 나눠서
계산을 하기가 어렵죠.
실제로 linode는 아주 옛날부터 로드 밸런서 서비스가 있었습니다.
그리고 디지탈오션은 2017년초에 로드 밸런서 서비스가 신규로 런칭되었어요.
디지탈오션이 옛날에는 트래픽풀이 아니었던걸 기억해본다면
아마도 로드 밸런서 서비스 런칭과 동시에 트래픽 계산 방법을
트래픽풀 방식으로 바꿨을 가능성이 아주 높습니다.
그리고 제가 기억하는 로드 밸런서가 지원되는 다른 클라우드가 있다면
코노하인데.. 코노하는 아시겠지만 트래픽 무제한입니다.
여기서 추측컨데.. 로드 밸런서 서비스를 하려면 인스턴스별 무료트래픽 용량
정책을 고수하기가 힘들어지고 코노하처럼 무제한하던가 아니면 트래픽풀을
할 수 밖에 없는게 아닌가... 하는 생각이 강하게 듭니다.
로드 밸런서 서비스를 하면서 인스턴스별 무료 트래픽을 따로따로 별개로
줄어들게 한다는건.. 너무 힘든 일이죠. 할려면 하겠지만 구지 그런 시스템을
개발할 필요가 별로 없어요. 그냥 트래픽풀로 합쳐서 계산해버리는게
쉽고 간단한거죠.
물론 이럴 가능성은 있습니다. [로드 밸런서를 적용해야만 트래픽풀로 사용되고
로드 밸런서를 사용하지 않으면 트래픽을 각각 계산한다]
근데 이건 이거대로 문제가 있습니다. 그럼 하나의 인스턴스를 로드 밸런서에
넣었다 뺐다 한다면?? 이걸 도대체 어떻게 해야할까요??? 어떤 원칙으로
계산해야 할지 감도 안오시죠? 실제로 복잡한 과금정책에선 이렇게 원칙
세우기가 애매한 경우가 생깁니다. (ㅋㅋ 제가 이걸로 SKT 과금정책 헛점 하나
찾아서 아주 잘 써먹고 있는 팁이 하나 있지요)
이럴때 로드밸런서를 유지하려면 그냥 트래픽풀 방식을 기본으로 하는 수 밖에 없어요.
그게 제일 심플합니다.
일단 전 다른거 무시하고 같은 플랜의 인스턴트를 삭제하고 새로 만들었을 경우 두개의 드래픽이 연계되는점,
그리고 청구서에 계정의 같은 플랜은 모두 합산해서 계산하고 인스턴트별로 정보를 제공하지 않는 점
두가지만 본다면 사용자 입장에서 인스턴트(서버) 단위로 사용량을 과금면에서는 알 필요가 없기 때문이라고 판단하고 있습니다.
-물론 사용요금이 똑같은 플랜의 인스턴트가 N개 있을 경우입니다. 다른 플랜이 추가되면 청구서에 다시 추가가 될겁니다.
사용량은 합산해서 제공해주고 기본서비스 제공량은 별도로 하겠다라고 한다면,
사용자가 어느 서버에서 얼마나 사용하고 있는지를 확인하는 툴을 만들어서 서버에 붙여야합니다.