AWS에 호구 잡히지 않는 방법 feat. CDN 비용절감 진행기

 

다음 글은 어떤 내용을 적어볼까 고민을 해보다가, 이런 이야기를 했는데, 반응이 좋아서 한번 적어보려고 한다.

 

0.시작하며

내가 담당하고 있는 서버들은 현재 재직중인 회사에서 가장 높은 유저수를 보유한 (1600만..) 서비스들이다.

정확한 트래픽 수치를 알려줄수는 없겠지만 , 월 트래픽이 PB 단위를 넘어가게 된다.

유저수에 기뻐하는것도 잠시, 매달 늘어가는 통신비용 (IDC, AWS CF비용)등에 대한 부담이 점점 커저만 갔다.

 

그리하여, 어찌보면 비용절감TF가 만들어졌고, 클라이언트 개발자분과 함께 여러가지 전략을 세워 나갔다.

결론적으로 예전부터 잘못 사용하고 있던 비용을 절감하여, 전체 통신 비용의 절반을 줄이면서  팀 안에서 '타노스' 라는 별명을 얻게 되었다.

 

 

 

1. 현재를 정확하게 파악해야 비용 절감을 할 수 있다.

---

비용 절감을 시작하기전에 가장 중요한건 현재의 파악이다.

절감을 시작하기 전에 우리가 사용중인 시스템에 대한 현황 파악이 가장 중요하다.

1-1. 우리의 CDN은 어떤 형태의 트래픽 성향을 가지고 있는가?

사용중인 CDN의 성향을 분석 해볼 필요가 있다. 크게 2가지 패턴으로 나누어지는데 그 내용은 아래와 같다.

1. 사용자 개별이 생성 하는 파일이 트래픽이 높은가? 

2. 모든 사용자가 받아가는 파일셋의 트래픽이 높은가? 

 

필자의 경우는  '2. 모든 사용자가 받아가는 파일셋의 트래픽이 높은가?' 스타일의 CDN 트래픽 패턴이었다.

정확히 어떤 파일이라고 이야기를 하긴 힘들지만, 모든 유저들이 하루에 한번 꼭 받아가는 파일들이라고 생각하면 될 것 같다.

 

1-2. 이러한 성향을 파악 하는 방법은 무엇인가?

과연 이러한 사용 패턴을 분석 하는 방법은 무엇이 있을까? 코드를 통해 확인을 해보는 경우도 있겠지만 실제 CDN 업체의 Report를 보는게 가장 정확하다.

 

필자의 경우는 AWS CloudFront를 사용하고 있는데, CloudFront에서 제공 하는 기본적인 Report를 통해서도 CDN 사용 패턴을 쉽게 알아낼수있었다.

 

1-3. CDN 업체별 과금 패턴을 잘 분석하고, 활용하자

트래픽 과금 패턴은 크게 2가지로 이루어진다. 

2가지 패턴에 대한 장/단점을 잘 생각하여, 자신의 제품에 맞는 방식을 선택하여 사용 하도록 하자

 

- 전송량 기준 비용 과금 

전송량 기준의 비용 과금은 말 그대로 이다. 100% 유저가 아침9시에 100kb 짜리 파일을 받아가든,  25%씩 쪼개서 4번 받아가든 청구되는 비용이 같다.

실제 유저에게 전달된 바이트수 만큼 과금이 되는 형태인 것이다. 최근 나오는 Cloud 업체들은 모두 전송량 기준의 비용 과금 모델을 선택하고 있다.

 

유저가 사용한 만큼의 비용을 지불 하기 때문에 흔히 말하는 억울한 비용이 없게 된다.  하지만, 유저 수가 많아져서 실제로 쓰는 트래픽이 많아지면 정말 돈을 많이 사용하게 된다.

 

추정하기로는 외국에서는 일반 사용자의 인터넷 회선도 사용량 기준으로 과금이 되기 때문에 그 모델을 따라 간것이 아닐까 라는 생각이 든다.

 

- 피크 대역폭 기준 비용 과금

피크 트래픽을 기준으로 한 비용 과금 방식은 전송량 기준의 비용과금과 반대인 과금 모델이다.

그 달에서 가장 많이 클라이언트가 동시접속을 하여, 파일을 받아간 시간대의 대역폭을 기준으로 비용이 과금 되는 모델이다.

 

예를 들어보자, 모든 유저가 하루에 한번 받아가는 파일셋이 있다고 가정을 하겠다.

100%의 유저가 아침9시에 파일을 다 받아가게 되면, 아침 9시의 피크 트래픽을 기준으로 그 달의 비용이 과금 된다.

하지만 25%씩 쪼개서 9시, 10시, 11시, 12시 에 받게 되면 25%의 대역폭 사용 비용으로 과금 되게 된다.

 

이러한 모델의 경우는 유저의 엔드포인트에서 전략을 잘 수립하고, 컨트롤 하게 된다면 많은 비용을 절감 할 수 있게 된다.

하지만 이 방식은 CDN 업체에서도 남는 돈이 적어지다보니, 요즘은 없어지는 추세인것 같기도 하다.

2. 계산 하는 습관을 가져봅시다.

---

클라이언트 개발자들의 공통 소양이었으면 좋겠다 싶은 부분이긴하다. 트래픽을 계산하는 습관이다.

어려운 계산식이 아니다.  아래와 같은 기준을 가질때 생기는 계산 방식이다.

 

기준

- 받아가는 파일 사이즈 : 1MB

- GB당 : 0.040

- Active User : 1,000,000

- 과금 방식 : 전송량 기준 과금

(1명이 하루에 소비하는 트래픽) * 유저수

하루의 트래픽 : 1 * 1000000 = 10000000MB (976.5625GB) 

하루에 트래픽 비용 : $39

주간 트래픽 비용 : $273

월간 트래픽 비용  (4주) : $1,092 

 

1메가? 얼마나 되겠어 라고 생각했지만 한달에 해당 파일로만 100만원을 써버렸다.

파일셋을 추가 할때마다, 이러한 계산을 하는 습관이 생겨야 한다.

 

3. 중복된 다운로드를 줄여주세요.

---

(2) 에서 이야기한 내용을 기반으로 계속 이어서 이야기를 해보겠다. (1)에서 이야기 했던 것 처럼, 트래픽 사용 패턴을 분석하는 것이 중요하다. 

알고 봤더니, 클라이언트 개발자 입장에서는 서버가 파일이 바뀐 것을 알 수 없기 때문에 트리거가 돌때마다 무조건 전체를 다운받아서 덮어쓰는 형태로 개발 된 것 이다. 사실 이 파일은 한달에 한번 바뀔수있는 형태의 소비 패턴을 가진 파일이다.

결국은 변경이 일어났을때 $39 달러만 소비되면 되지만, $1,092가 소비 된 것 이다.

이러한 케이스에 가장 추천하는 방식은 클라이언트가 변경 여부를 체크하여, 변경이 되었을때만 변경을 하게 하는 것이다.

 

3-1. 파일 HASH를 통한 중복 다운로드 여부 점검 

혹시나 HASH 라는 개념을 모르는 사람을 위하여, 아래의 글을 한번 읽어 보는 것을 추천한다.

 

해시 함수 - 위키백과, 우리 모두의 백과사전

암튼 어떤 알고리즘을 사용하든  (MD5, SHA1, SHA256)을 사용하든 파일의 유니크한 값을 뽑아낸다면 변경 여부를 점검 할 수 있게 된다.

사실 이렇게만 이야기하면 머리속에 잘 안들어올것 같으니, 예를 들어보자.

 

https://cdn.yangs.kr/app/1/1.exe 라는 파일을 패치하는 윈도우 어플리케이션이 있다고 가정을 세워보겠다.

그리고 1.exe에 대해 파일 SHA256 HASH를 뜬 후, https://cdn.yangs.kr/app/1/1_exe.checksum (64바이트) 파일을 업로드를 하였다.

 

클라이언트가 패치 하는 순서

1. 자신이 가지고 있는 로컬 파일의 SHA256 HASH를 구한다.

2. https://cdn.yangs.kr/app/1/1_exe.checksum 을 다운로드 한다.

3. 자신이 가지고 있는 로컬 파일의 SHA256과 리모트에서 받은 문자열을 비교한다.

3-1 : 문자열이 같은 경우, exe를 다운로드 하지 않는다. (파일의 무결성을 SHA256 파일 HASH를 통해 검증 했기 때문에 다시 받는건 중복)

3-2 : 문자열이 다른 경우, exe를 다운로드 한다.

 

이런 방법론이 적용 되는 경우,  한달에 1번 파일이 바뀌는 경우, $1,092 -> $40 ($39[exe 다운로드] + $1 [0 (checksum 다운로드 비용)])의 비용으로 줄게 되는 것이다.

 

3-2. HTTP 표준 스펙을 통한 변경 여부 체크 

위의 방법이 가장 깔끔한 방법이지만, 업로드 할때도 변경을 해줘야 하고 사람이 단순하게 FTP에 파일을 업로드 하는 구조라면 바로 진행하긴 힘들 것 이다. 하지만, HTTP 표준 스펙에는 생각보다 많은 것이 고려되어 있다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/ETag

ETag

우리가 사용하는 상용 CDN 업체들은 모두 "E-Tag" 스펙을 지원해주고 있다.

필자의 경우는 AWS CloudFront + S3 조합으로 사용중인데, S3 Server에서 해당 하는 스펙을 지원하고 있기에 활용 하기 좋다.

 

 

4. 압축을 해주세요

---

우리에게는 "압축" 이라는 신기술이 있다.

거의 모든 업체는 "전송량" 기반 과금을 하는 곳이 많기 때문에 실제 클라이언트에 전달 되는 데이터가 적으면 적을 수록 적은 비용을 지출 하게 된다.

데이터 압축은 데이터를 더 적은 저장 공간에 효율적으로 기록하기 위한 기술, 또는 그 기술의 실제 적용을 가리킨다.

데이터 압축 - 위키백과, 우리 모두의 백과사전

4-1. HTTP 표준 스펙을 통한 압축

HTTP 프로토콜을 만든 사람들도 데이터 전송량을 어떤 방식을 통해서라도 줄여보려고 했다.

한국은 데이터 전송량이 무제한 이지만, 지금도 유럽이나 미국은 데이터 종량제로 ISP에서 운영 되는 곳이 있기 때문이다.

HTTP에서의 압축

 "데이터 압축" 항목에서 이야기 했던 것처럼 여러가지 방식을 통해 압축을 할 수 있다.

출처 : MDN

'Acceept-Encoding' 을 통해 내가 해석 할 수 있는 압축 방식을 보낸다.

'Content-Encoding' 을 통해 서버가 압축한 압축 방식을 보내주게 된다.

 

쉽게 설명하면 클라이언트 (Chrome, IE)가 "??? : 저는 이런 압축을 해제 할 수 있습니다" 라고 보내면, 서버가 요청 한 타입을 보고 맞춰서 압축을 해주는 것 이다.

 

Amazon CloudFront- 신규 Gzip 압축 기능 제공! | Amazon Web Services

거의 모든 CDN 업체에서 GZIP 관련된 헤더를 제공 하고 있기 때문에 적극적으로 사용 하도록 하자.

웹 브라우저를 기준으로 이야기 했지만, 최근에 나오는 HTTP Client (okhttp3.. Apache Http Client)에서 해당 스펙을 지원하기 때문에 

옵션 여부만 확인 하고, 사용 하면 적은 리소스로 콘텐츠 비용을 줄 일 수 있을 것이다.

 

 

5. Product Team에서 비용 절감을 진행한 후기

---

야생의 개발자가 나타났다.

사실 프로덕트 팀 입장에서는 이런 비용절감 프로젝트를 굉장히 싫어한다. 잘 돌아가고 있는 서비스의 안정성을 엄청나게 건드리는 상황이기 때문이다. 필자가 일하던 회사에서는 다행히도 클라이언트 개발자분과의 긴밀한 협업을 통해 문제 없이 진행을 하기 하였다.

 

개인적으로 비용절감에 대한 리딩을 하면서 느꼈던 점을 간략하게 적어보려고 한다.

 

1. 개발자들 모두에게 실제 비용과 수치를 공유하여, 동기를 유발 시켜주자.

처음에는 클라이언트 개발자들이 그렇게 좋아하지는 않았다. 위에서 이야기 한 내용이 있었기 때문이다.

어떤식으로 설득을 해볼까 하고 고민을 하다가 눈에 보이는 수치를 보여주기로 하였다.

절대적인 수치를 이 블로그에서 공개를 할 수는 없겠지만,

위에 섹션에서 설명 한 것처럼 현재의 상황을 파악 하고, 작업 당 전체 AWS 비용을 이 정도 절감이 가능하다. 라고 이야기 하였다.

그 결과 개발자분들에게 나름 많은 동기 유발을 심어주었다고 생각하고, 이로 인하여 2020년에는 아마도 좋은 성과를 받지 않았을까...? (말을 흐리는 이유는 마지막에 설명 하겠다) 하고 생각이 된다.

 

2. 비용절감 프로젝트는 한번에 모든걸 다하는것보다는 단계를 나누어서 진행하자

이 Product의 개발자 M/M을 100% 다 투입 하여 진행 할 수 있다면, 당연히 좋겠지만 그럴 수 없는 것이 돈을 버는 사기업의 현실이라고 생각 된다. 이럴땐 전체적인 플랜을 가지고 단계적으로 서비스에 적용을 하는 것이 중요하다.

 

- A플랜 (01월 ~ 03월 ) : XX 기능에 대한 비용 최적화 진행
- A플랜 모니터링/결과보고 (출시후 2주) : 출시 이후 트래픽 감소 및 비용 감소 

- B플랜 (04월 ~ 05월 ) : XX 기능에 대한비용 최적화 진행
- B플랜 모니터링/결과보고 (출시후 2주) : 출시 이후트래픽 감소 및 비용 감소 

나누어서 진행 하는것이 중요한건, 개발자 리소스도 있지만, 작업에 대한 결과 보고를 위해서도 중요하다.

'A기능에 대한 비용절감을 진행하여, 어느 정도 비용을 절감 했다 ' 는 주간 회의에서 가장 핫하고, 경영진에서 가장 중요하게 보는 이슈 라고 생각 된다. 또한 해당 지표를 통해 비슷한 작업을 수행시 들어가는 개발자 리소스 대비 어느정도의 비용 절감이 가능 할지도 추정이 가능하게 된다. 

 

여담으로 필자의 경우도 하루라도 빨리 출시 하고 싶은 마음에 2개의 기능이 섞여서 출시한 적이 있는데, 위와 같은 문제로 한창 고생을 했었다.

 

 

 

3. 윗선에 보고를 할때는 10% 정도는 버퍼로 남겨두자.

이게 생각보다 중요하다고 생각한다. 사실 비용절감이 덜 되면 눈치를 보게 되지만, 예상치보다 더 절감되면 어깨를 펴고 다닐 수 있다.

'주간보고', '월간보고' 등으로 진행 상황을 공유 할때는 비용 절감 예상치에서 10% 정도의 버퍼를 두는 센스를 가지자.

 

 

 

여담으로, 클라이언트 개발자분들과 함께 작업을 하면서 하면서 '2021년에는 인센 두둑하게 받나?!' 라는 기대를 하였지만, 사실 필자는 비용절감의 메인 작업을 마치고 바로 이직을 하게 되었다. 아쉽지만 더 중요한 선택을 위한 이직이었기 때문에 후회는 없다.

 

 

 

7. 마치며

---

이 비용절감 프로젝트는 2020년 01월 부터 3명의 작은 인원들로 총 6단계를 걸쳐 진행 하게 되었다.

마지막 단계를 앞두고 필자는 먼저 퇴사를 하게 되어서, 사실 마음에 많이 걸렸다.

 

이 글을 그 분들께서 볼 일이 있을진 모르겠지만, 이 글을 통해   비용절감으로 많이 괴롭혀드렸는데, 힘든 티 없이 비용 절감 프로젝트를 같이 진행 해신 프로젝트 팀원분들에게 감사하다는 이야기를 전하고 싶다.

 

사실 이 글은 2020년 10월부터 조금씩 적었다가, 2021년에 공개를 하는 글이다.

필자 역시 기억을 조금씩 더듬어가면서 적다보니 틀리게 이야기 한 것이 있을 수 도 있다. 

 

잘못 이야기 하거나, 개념상에 오류가 보인다면 댓글로 남겨주면 하나 하나 꼭 확인하여 수정하겠습니다!