커뮤니티토픽게시판

근데 생각해보니까 트래픽풀의 가능성이 아예 없는건 아니군요..
뭐가 문제냐 하면 [로드 밸런서]의 문제가 있습니다..

라이트세일은 로드 밸런서 서비스가 있거든요..
상식적으로 추측컨데 트래픽 계산은 게이트웨이에서 하고 있을겁니다. 
거기서 인스턴스의 IP로 외부로 나가는 트래픽 총량 계산해서 과금하겠죠.
근데 로드밸런서 서비스가 지원되면 로드밸런서 <-> 인스턴스간 통신은 
내부 트래픽이므로 과금이 안됩니다.
그대신 인터넷 <-> 로드밸런서간 통신이 과금 대상이 되겠죠.
무료트래픽이 없는 경우에는 로드밸런서가 중간에 끼어도 과금계산에서 별 문제가 안됩니다.

근데 인스턴스별 무료트래픽이 있다면? 이럼 계산이 정말 애매해지는겁니다.

로드밸런서 <-> 인스턴스 통신에서 인스턴스 별로 트래픽을 따로 나눠서

계산을 하기가 어렵죠. 

실제로 linode는 아주 옛날부터 로드 밸런서 서비스가 있었습니다.

그리고 디지탈오션은 2017년초에 로드 밸런서 서비스가 신규로 런칭되었어요.

디지탈오션이 옛날에는 트래픽풀이 아니었던걸 기억해본다면

아마도 로드 밸런서 서비스 런칭과 동시에 트래픽 계산 방법을

트래픽풀 방식으로 바꿨을 가능성이 아주 높습니다.

그리고 제가 기억하는 로드 밸런서가 지원되는 다른 클라우드가 있다면

코노하인데.. 코노하는 아시겠지만 트래픽 무제한입니다.

여기서 추측컨데.. 로드 밸런서 서비스를 하려면 인스턴스별 무료트래픽 용량

정책을 고수하기가 힘들어지고 코노하처럼 무제한하던가 아니면 트래픽풀을

할 수 밖에 없는게 아닌가... 하는 생각이 강하게 듭니다.

로드 밸런서 서비스를 하면서 인스턴스별 무료 트래픽을 따로따로 별개로

줄어들게 한다는건.. 너무 힘든 일이죠. 할려면 하겠지만 구지 그런 시스템을

개발할 필요가 별로 없어요. 그냥 트래픽풀로 합쳐서 계산해버리는게

쉽고 간단한거죠.

물론 이럴 가능성은 있습니다. [로드 밸런서를 적용해야만 트래픽풀로 사용되고

로드 밸런서를 사용하지 않으면 트래픽을 각각 계산한다]

근데 이건 이거대로 문제가 있습니다. 그럼 하나의 인스턴스를 로드 밸런서에

넣었다 뺐다 한다면?? 이걸 도대체 어떻게 해야할까요??? 어떤 원칙으로

계산해야 할지 감도 안오시죠? 실제로 복잡한 과금정책에선 이렇게 원칙

세우기가 애매한 경우가 생깁니다. (ㅋㅋ 제가 이걸로 SKT 과금정책 헛점 하나

찾아서 아주 잘 써먹고 있는 팁이 하나 있지요)

이럴때 로드밸런서를 유지하려면 그냥 트래픽풀 방식을 기본으로 하는 수 밖에 없어요.

그게 제일 심플합니다.

  • profile

    일단 전 다른거 무시하고 같은 플랜의 인스턴트를 삭제하고 새로 만들었을 경우 두개의 드래픽이 연계되는점,
    그리고 청구서에 계정의 같은 플랜은 모두 합산해서 계산하고 인스턴트별로 정보를 제공하지 않는 점

    두가지만 본다면 사용자 입장에서 인스턴트(서버) 단위로 사용량을 과금면에서는 알 필요가 없기 때문이라고 판단하고 있습니다.

    -물론 사용요금이 똑같은 플랜의 인스턴트가 N개 있을 경우입니다. 다른 플랜이 추가되면 청구서에 다시 추가가 될겁니다.

    사용량은 합산해서 제공해주고 기본서비스 제공량은 별도로 하겠다라고 한다면,

    사용자가 어느 서버에서 얼마나 사용하고 있는지를 확인하는 툴을 만들어서 서버에 붙여야합니다.

  • profile

    아예 트래픽 초과요금 정산을 안 하고 있는 게 아닌가 하는 의심이 듭니다.

    3TB짜리 인스턴스 3대를 사용해서 트래픽 분산을 하고 있는 고객사이트가 있거든요. 로드밸런서는 쓰고 있지 않으니까, 라운드로빈으로 완벽하게 분산된다 해도 월 9TB가 한계입니다. 확인해 보니 지난 달에 9.1TB를 썼습니다. 업로드 트래픽까지 포함하면 9.4TB에 육박하는데, 초과요금이 단 한 푼도 나오지 않았습니다.

    업로드 트래픽은 무료라고 치고... 1월은 31일까지 있으니까 시간당으로 계산하면 0.1TB 정도는 더 쳐주지 않을까 생각할 수도 있겠지만, 트래픽이 서버당 3TB씩 완벽하게 분산되는 것이 아닙니다. 각 서버의 트래픽을 엄격하게 따진다면 최소 한두 군데는 초과되는 게 맞습니다. 여기까지 보면 트래픽풀을 시행하고 있는 것 같지요?

    문제는 지난 12월입니다. 12월에는 트래픽이 부족해서 중간에 서버 대수를 늘렸기 때문에 대략 7.5TB 정도가 한계였습니다. 그런데 8.4TB를 썼습니다. 그 때도 초과요금은 나오지 않았습니다. 이건 트래픽풀만으로는 설명이 되지 않습니다.

    초창기 디지털오션처럼 어느 정도 시장점유율을 확보할 때까지는 트래픽 초과요금 정산을 유보하고 있는 것 같습니다. 해외 업체들은 어차피 남아도는 게 트래픽이라 이런 전략을 종종 씁니다.

    그래도 혹시 몰라서 해당 고객사이트는 현재 12TB까지 쓸 수 있도록 인스턴스 수를 늘려 놓았습니다. 초과요금 정산 여부와 관계없이, 월 20~25TB 정도까지는 라이트세일이 가성비 짱이니까요.

  • profile profile
    아마도 트래픽 카운트가 내부통신과 외부통신 모두 카운트 하기 때문일 것입니다.
    카운트는 하되 정산에서는 빼는 시스템 입니다.
    아웃 바운드만 정산이 되죠.
  • profile ?
    아뇨.. 아마존 라이트세일은 인바운드도 정산합니다.
    이게 대개 다른 대형 클라우드들이 인바운드를 정산안하고 아마존도 EC2는 인바운드는 정산 안하다보니까 라이트세일도 당연히 그럴거라고 생각했는데.. 라이트세일은 [무료 트래픽 범위] 안에서는 인바운드도 무료 트래픽을 깍아먹는다고 홈페이지에 분명히 써있더군요. (작은 글씨로) 다만 무료 트래픽을 다 쓰고나면 그때부터는 인바운드는 무료가 됩니다.
  • profile profile

    그것도 생각해 봤지만, 이미지 캐시서버이기 때문에 내부 통신은 거의 없습니다. 1월에 0.1TB 초과된 건 그렇다 쳐도, 12월에 0.9TB나 초과되었는데 요금이 더 나오지 않은 것은 내부 통신만으로는 설명이 안 되네요.

     

    인바운드는 무료로 퉁치는 부분도 정확히 몇 기가 썼는지 별도로 표시가 됩니다.