안녕하세요, 인프런과 랠릿 서비스를 운영하는 인프랩의 DevOps 엔지니어 제이크(김재훈)입니다.

AWS re:Invent 2023에서 amazon.com CTO이신 Werner Vogels 박사님의 기조 연설이 있었는데요.
클라우드 제공업체의 CTO로서 이례적으로 알뜰한(Frugal) 아키텍처에 대해 언급하셨습니다.

그 만큼 현대 사회에는 기업의 매출 만큼이나 비용(혹은 매출 원가)이라는 제약 조건을 빼놓고 이야기하기 힘든 시기가 왔습니다.

특히 스타트업이 겪곤 하는 겨울 시즌 과 같은 어려운 시기에는 이러한 고민이 더욱 깊어집니다.

저처럼 클라우드 사용 내역서나 영수증을 보고 매번 놀라시는 분들을 위해 준비했습니다.

이번 글에서는 스타트업을 기준으로 AWS를 저렴하고 효율적으로 이용할 수 있는 여러 비용 최적화 노하우를 공유드릴게요. 간단한 비용 절약 노하우부터, 이를 팀 내 문화로 만들기 위한 노력을 소개해 드리겠습니다.

결론부터 말씀드리자면 인프랩 DevOps 파트는 아래의 FinOps 관련 노력을 통해

• 월간 $25,000(원화로 약 3,325 만 원)를 절약할 수 있었습니다.
• 연간 $300,000(원화로 약 3억 9,900만 원)를 아낀 셈입니다.

개요

• 팀 차원에서 지속적인 관심을 가지기
• Top 10 비용 먼저 분할 정복하기
• 리소스 태깅이 중요한 이유
• 비용 지출이 큰 관리형 서비스를 경계하기
• EC2 스팟 인스턴스를 적극 활용하기
• MSP를 적극 활용하기 (그리고 아쉬운 점)
• 서버리스의 함정에 빠지지 말기
• 적정 기술 선택하기
• 빠르고 저렴한 CDN을 적극 활용하기
• 내부 서비스 호출에는 내부망을 사용하기

팀 차원에서 지속적인 관심을 가지기

어떠한 비용 최적화도 하루 아침 만에 되는 일은 없습니다. 단편적인 예로 비용 최적화를 진행했더라도 지속적으로 관심을 가지지 않으면 더 많은 비용이 청구되거나 서비스 품질에 악영향을 끼칠 수 있습니다.

비용 최적화는 모든 팀 구성원의 노력과 지속적인 관심이 필요한 업무이며, 지속적인 실험을 통해 서비스 영향을 최소화하면서 진행할 수 있도록 노력해야 합니다.

비용 최적화 현황표 만들기

개인의 노력 만으로는 달성하기 어려운 목표이므로, 간단한 제목과 절약한 비용, 날짜를 적은 비용 최적화 현황표를 만들어 모든 구성원의 협조를 구했습니다.

비용을 아낄 수 있는 방법을 Jira 티켓으로 만들었고, 이를 문서에 첨부하면서 다음 작업자도 이러한 노하우를 참고하여 개선할 수 있도록 구성했습니다.

작업이 완료되면, 절약한 비용을 추산하여 표에 기재하고 작업자에게 칭찬을 아끼지 않는 문화를 만들었습니다. 또한 이러한 성과는 지표가 되어 다음과 같은 수식어를 붙이게 될 수 있습니다.

예시) 23년 상반기 동안, 연간 1억 4천만원에 달하는 AWS 클라우드 비용을 절약했습니다.

월별 비용지표 리뷰하기

인프랩 DevOps 파트는 매일 데일리 미팅을 진행합니다. 일정을 관리하고 우선순위에 따라 할 일을 조정하곤 하는데요.

매월 말일이 가까워 질 때마다 한 번씩 AWS, Datadog 등 클라우드 비용 지표를 리뷰하는 시간을 가졌습니다.

전월 대비 몇 %가 증감했는지, 사유는 무엇인지, 어떤 조치를 통해 개선할 수 있을지 논의했고, 이를 Jira 티켓으로 만들어 담당자를 배정합니다.

만약 담당자를 배정하기 어려운 경우 위의 비용 최적화 현황표 하단에 “진행 예정 이슈 목록” 으로 추가합니다.

각 구성원은 상황에 맞게 자신을 담당자로 배정하고, 여유가 없는 팀원의 티켓을 리밸런싱 하기도 합니다.

비고 항목에는 왜 지금 바로 적용하기 어려운지 이유를 기재하여 다음에 작업할 담당자가 작업 우선순위를 쉽게 고려할 수 있도록 돕습니다.

Top 10 비용 먼저 분할 정복하기

클라우드를 사용하다 보면 사용하는 리소스가 많아 복잡하다고 느낀 적이 있으실 건데요.

한 번에 너무 많은 서비스를 고려하다 보면 놓치는 부분이 생기게 되고, 결국 중요한 단서를 찾지 못할 수 있습니다.

클라우드 서비스 중에서 비용이 가장 많이 지출되는 상위 10개 서비스에 대해 먼저 조사했습니다.

후에 서술할 MSP 이용 계약을 맺게 되면 내부 규정에 따라 AWS Cost Explorer를 사용할 수 없게 됩니다.

제공하는 별도의 웹 대시보드를 이용하거나 아니면 엑셀 파일을 다운로드해서 직접 분석해야 하는데요.

MSP에서 제공하는 웹 대시보드의 피벗 테이블 기능을 이용해서 간단히 분석해 보았습니다.

리소스별로 요금이 얼마나 부과되는지 정리해서 내림차순으로 정렬한 다음,
사용하지 않는 리소스를 먼저 제거하는 식으로 비용을 절약했습니다.

이 때에는 SteamPipe라는 도구를 사용해서 PostgreSQL 쿼리로 AWS 자원을 손쉽게 조회할 수 있었습니다.

• 필요하지 않은 인스턴스를 제거

• 오버 프로비저닝된(Over-provisioned, 프로비저닝 과다) 리소스 Scale Down

프로비저닝은 사용자가 요청한 IT 자원을 사용할 수 있는 상태로 준비하는 것을 말합니다.
오버 프로비저닝은 필요치보다 과다하게 자원을 사용할 수 있는 상태로 준비한 상태를 일컫습니다.
Scale down은 자원의 크기를 축소시키는 것을 의미합니다. 예를 들면, “4vCPU 8GiB Mem 서버를 2vCPU 4GiB Mem 서버로 Scale-down 했다” 로 표기할 수 있겠습니다.

위 과정을 반복하면서 점진적으로 비용을 절약할 수 있었습니다.

RDS Aurora PostgreSQL 클러스터의 경우

RDS Aurora 클러스터를 사용하고 있어 Scale-Down 작업은 중단 없이 매끄럽게 진행이 가능했습니다.

다만 새로운 인스턴스를 실행하면 쿼리 캐시를 활용할 수 없어 일시적으로 쿼리 지연 현상이 발생하는데요.

사용자가 비교적 적은 오전 7~8시 경에 rolling-out 방식으로 조금씩 작업을 진행해서 해결했습니다.

쿼리 최적화

슬로 쿼리를 분석하는 방법은 크게 두 가지로 나눌 수 있습니다.

1. 슬로 쿼리 슬랙 알림 보내기

2. Datadog Database Monitoring (DBM) 도입하기

슬로 쿼리 슬랙 알림 보내기

CloudWatch에 RDS 쿼리 로그를 쌓고, Lambda 함수에서 슬로 쿼리를 발견하면 슬랙 알림을 보냅니다.

비교적 쉽고 간단하게 구성할 수 있어 권장하는 방법입니다.

Lambda 함수에서는

• 3초 이상 실행된 쿼리
• 에러 쿼리

들을 감지하면 Slack 채널에 알림을 보내도록 구성했습니다.

자세한 내용은 향로께서 작성하신 아래 글을 참고해 보시면 좋을 것 같습니다.

• AWS RDS PostgreSQL에서 Slow, Error, DDL 쿼리 발생시 Slack 발송하기

Datadog Database Monitoring (DBM)

이 외에도 Datadog DBM(Data Base Monitoring)을 구성하여 애플리케이션 마다 자주 사용되는 쿼리를 분석할 수 있습니다.

이러한 도구를 기반으로 백엔드 파트에서 주기적으로 슬로 쿼리 최적화 작업을 진행해주신 덕분에 원활하게 DB Scale Down 작업을 진행할 수 있었습니다.

RDS RI 기간이 남았다면

비용 절약을 위해 기존에 RI(Reserved Instances) 구입을 진행한 상황이었고, 아직 기간이 남아 있었습니다.

고심한 끝에 작은 사이즈의 인스턴스를 여러 대 실행하는 전략을 취했습니다.

Aurora PostgreSQL RI의 경우 인스턴스 크기 • 대수에 상관 없이 사용할 용량을 예약하는 개념이기 때문입니다.

예시: r6i.4xlarge 인스턴스 1대 1년 계약 -> r6i.2xlarge 인스턴스 2대로 대체 가능

이후 RI 계약 기간이 만료되면 한 대씩 줄여가면서 Scale-In 작업을 진행할 계획입니다.

리소스 태깅이 중요한 이유

리소스 태깅을 제대로 하지 않아도 기본적인 자원의 비용은 파악할 수 있습니다.

그렇다면 회사에서 운영하는 서비스마다, 제품마다, 부서마다 비용을 파악하려면 어떻게 해야 할까요?

많은 분께서 여러 계정을 사용하고 계정 단위로 비용을 측정하시곤 합니다.

그래도 하나의 계정에서 여러 제품과 서비스를 운영할 수도 있기에 각각 태깅을 잘 해두는 것이 중요합니다.

일부 MSP의 경우 자체 비용 대시보드에서 확인할 수 있는 태그의 이름이 사전에 정해져 있는 경우가 있습니다.

리소스 태깅 정책 수립을 계획하고 계신 분들은 MSP측에 미리 문의해 보시는 걸 추천드립니다.

안 그러면 한 번 더 변경해야 하는 경우가 발생할 수 있습니다. (주륵)

비용 지출이 큰 관리형 서비스를 경계하기

사례 1) AWS Elemental MediaConvert

인프랩은 학습 플랫폼 인프런을 운영하다 보니 강사님들의 영상을 트랜스코딩하기 위해 매니지드 서비스인 AWS Elemental MediaConvert 를 사용하고 있었어요.

이미지 출처: AWS

• AWS Elemental MediaConvert 란?
  • 관리형 비디오 트랜스코더 서비스
  • 복잡한 설정이나 인프라를 관리할 필요 없이, S3 및 Lambda를 이용해 트랜스코딩 파이프라인 구축 가능

서비스 초기에는 빠른 시간 안에 강의 스트리밍 서비스를 구축하는 것이 핵심 목표였기에 빠르고 견고하게, 그리고 AWS의 노하우를 얻을 수 있었습니다.

AWS Solutions Library 에서 소개하는 Video on Demand on AWS 사례를 기반으로 CloudFormation 과 AWS CDK를 활용해 VOD 스트리밍 서비스를 안정적으로 운영해 왔습니다.

다행스럽게도 서비스가 빠르게 성장하면서 매달 더 많은 강의가 출시되었는데요. 강의가 많아질 수록 인코딩해야 할 영상이 많아졌고, 비용이 무시할 수 없을 정도로 커졌습니다.

강의 제출이 많은 달에는 모든 EC2 서버 비용을 합친 금액과 비슷할 정도로 많은 비용이 지출되기도(!!) 했었습니다.

또한 MediaConvert는 비용을 절약하기 위해 최소 1년 단위의 Reserved Queue 및 Reserved Transcode Slots 비용을 지불해야 해서 부담이 되는 부분이 있었습니다. 인프런 플랫폼 특성상 언제 강의가 많이 제출되고 언제 적게 제출될지 예측이 어렵기 때문입니다.

또한 신규 기능으로 AI 음성인식 모델을 활용한 자동 자막 생성 기능이 요구사항으로 검토되면서 비디오 트랜스코딩과 STT 작업이 서로 유연하게 이어져야 했습니다.

이에 고심 끝에 기존 비디오 트랜스코딩 파이프라인을 수정하여 MediaConvert 대신 직접 구축하게 되었습니다.

이 작업은 동료 DevOps 엔지니어 선비께서 진행해 주셨는데요, 간략하게 비용 절약 측면에서 소개드리고자 합니다.

• AS-IS(기존): AWS S3, Lambda, Elemental MediaConverter

• TO-BE(변경): AWS S3, Lambda, Batch, ECS, EC2, Go + ffmpeg

AWS Batch 서비스를 이용하면 트랜스코딩과 자막 생성 작업이 시작되면 필요한 만큼의 서버를 할당해, CPU 코어가 많은 서버를 사용해 트랜스코딩을 최대한 빠르게 끝내거나, 아니면 비용-효율적인 서버를 할당해 최적의 비용으로 트랜스코딩할 수 있도록 설정할 수 있습니다.

AWS Batch 는 ECS 와 마찬가지로 배치 작업을 사용하는데 발생한 컴퓨팅 비용만 청구합니다.

비디오 트랜스코딩을 위해 ffmpeg 를 이용하였고, 최적의 커맨드를 찾기 위해 노력했습니다. 또한 커맨드를 실행하는 Go 코드를 작성해 이를 컨테이너화하여 ECS에서 실행하도록 구성했습니다.

또한 여러 개의 job을 연결하여, 오디오 추출 단계는 비교적 낮은 사양의 서버를 사용합니다.
STT(Speech-To-Text) 모델을 실행하기 위해서는 GPU가 탑재된 서버를 사용합니다.
그리고 비디오 트랜스코딩 단계는 CPU 코어 수가 많은 C 클래스 EC2 인스턴스 타입을 사용하도록 지정했습니다.

그 결과, 적절한 크기의 인스턴스를 필요한 만큼만 사용할 수 있게 되었으며 요구사항에 맞게 커스터마이징해서 사용할 수 있었습니다.

자막 생성 기능이 추가되어 그 비싸다는 GPU 서버를 사용함에도 불구하고 기존 대비 15배~20배 가까운 비용을 절약할 수 있었습니다.

배치 작업의 경우 후술할 EC2 스팟 인스턴스를 활용하면 온디맨드 인스턴스 대비 최대 70% ~ 90%의 비용을 절약할 수 있습니다. 위 수치는 스팟 인스턴스를 사용해 달성할 수 있었던 것입니다.

빠르게 서비스를 출시하기 위해 핵심 기능을 매니지드 서비스로 운영해왔다면,
self-hosted로 전환시 비용을 얼마나 절약할 수 있는지 고려해 보시는 건 어떨까요?

사례 2) CircleCI 대신 Jenkins

인프랩은 CI/CD 파이프라인으로 잘 알려진 대표적인 SaaS 인 CircleCI를 활용해 왔습니다.

다만 SaaS 특성 상 실행 환경의 커스터마이징 어려움이 있었고, 민감정보 유출 이슈 및 잦은 장애로 인한 서비스 개발 주기에 영향을 주었습니다.

CircleCI 장애가 발생하면 개발팀 전체 빌드가 동작하지 않아 릴리즈 주기에 영향을 주었습니다.
또한 문제가 발생하더라도 우리가 직접 고칠 수 있으면 좋겠다는 팀 내 의견이 있었습니다.
원인을 통제할 수 있고 해결하는 과정에서 노하우도 추가로 쌓을 수 있으니까요.

이에 Jenkins Master-Slave 아키텍처를 EC2 환경 기반으로 자체 구축하여 활용하고 있습니다.

결론부터 먼저 말씀드리자면, CircleCI 를 Jenkins 로 이전하면서 최대 4.5배의 비용을 절약할 수 있었습니다.

사무실에 개발팀 공용 빌드 머신을 두고 사용하는 방법도 있는데 AWS 클라우드 상에 젠킨스 파이프라인을 구축한 이유는 무엇일까요?

바로 업무 시간이나 릴리즈 주기에 따라 빌드가 몰리는 피크 타임에 유연하게 대응하기 위해서입니다.

EC2 인스턴스가 필요하면 필요할 때 1~2분 안에 필요한 서버를 확충하고 빌드를 실행할 수 있습니다.

빌드가 종료되면 15분 정도 다음 빌드를 기다리다가 인스턴스를 종료해 빌드 캐시를 최대한 활용할 수 있도록 구성했습니다.

Jenkins EC2 Fleet Plugin을 사용하면 손쉽게 EC2 스팟 인스턴스를 젠킨스 빌드 에이전트로 활용할 수 있습니다.

온디맨드(On-Demand) 인스턴스로 젠킨스를 구축하신 분들이 계시다면 위 플러그인 도입을 추천드려요. CI/CD에 사용되는 EC2 비용을 최대 70% ~ 90%까지 절약할 수 있습니다.

빌드 도중 스팟 인스턴스 중단 공지(Spot Instance Interruption Notice)가 발생하면 알아서 빌드를 재실행해주는 기능도 있습니다. 꼭 한 번 이용해 보세요!

EC2 스팟 인스턴스를 적극 활용하기

위의 두 사례는 SaaS 및 매니지드 서비스를 직접 구축하고 관리함으로써 비용을 각각 최대 20배, 4.5배 절약한 케이스입니다.

이는 모두 컴퓨팅 자원을 활용하는 배치성 작업이었기에 EC2 스팟 인스턴스를 도입해 추가로 비용을 절약할 수 있었습니다.

EC2 스팟 인스턴스는 온디맨드(주문형) 인스턴스와 대비되는 개념입니다.

주문형 인스턴스는 원하는 시점에 시작하고 종료할 수 있는 반면, 스팟 인스턴스는 수요에 따라 자원을 회수하는 대신

비용을 주문형 인스턴스 대비 최대 70% ~ 90%까지 절약할 수 있습니다.

이러한 특성을 잘 활용하면 CI/CD 파이프라인, 비디오 트랜스코딩 같은 배치 작업부터 비상태성 웹 애플리케이션까지 폭넓게 적용해 비용을 절약할 수 있습니다.

MSP를 적극 활용하기

여러분은 AWS 클라우드 계정의 결제 방식을 어떤 형식으로 사용하고 계신가요?

필자는 학생일 때 프리티어를 이용하기 위해 AWS 계정에 직접 체크카드를 등록해서 사용했던 경험이 있는데요.

개인 사용 목적이라면 직접 AWS 계정의 결제 수단을 관리하는 것도 좋겠지만,
MSP 매니저님 말씀에 따르면 여러 초기 스타트업에서 직접 결제 계정을 관리하고 있다고 합니다.

기존에는 MSP의 장점 중 하나가 바로 세금계산서를 발행해준다는 것이었습니다. 다만 2020년 12월부터는 세금 설정 페이지에서 사업자등록번호를 입력하면 부가가치세가 청구되지 않으며 세금계산서 혹은 신용카드 매출전표를 발행해준다고 하니 참고하시길 바랍니다. 링크

2020년 12월 1일 이후, AWS Korea는 대한민국 계정의 모든 클라우드 서비스에 대하여 세금계산서 또는 신용카드 매출전표를 발행합니다.

MSP(Managed Service Provider)와의 이용 계약을 맺으면 다양한 장점이 있습니다.

• 다양한 요금 할인 혜택
• 세금계산서 발행 (일반 고객도 AWS에서 제공)
• PoC(Proof of Concept)를 위한 크레딧 지급
  • 스타트업을 위한 크레딧 제공
  • (Google Cloud Platform에서도 스타트업을 지원하는 유사 프로그램이 있습니다.)
• 컨설팅, 인프라 관리 위탁 등
• AWS 서포트 플랜(support plan)을 구입하면 아마존의 솔루션즈 아키텍트(solutions architect) 분들과 기술적인 논의 및 피드백을 받을 수 있습니다.
• 추가적인 기술지원
  • AWS 서포트 센터와는 별도로 MSP마다 기술지원 부서가 있는 경우 추가적인 지원을 받을 수 있습니다.
  • MSP에서 AWS 서포트 플랜과 별도로 자체 제공하는 MSP 서포트 플랜을 판매하기도 합니다.

잘 알려진 기업으로는 메가존 클라우드, 베스핀글로벌, SK텔레콤, GS네오텍 등이 있는데요.

적극적으로 스타트업을 대상으로 하는 프로모션을 진행하는 업체도 있으니 잘 알아보시는 것을 권해 드려요.

AWS를 제외하고도 GCP, Azure, Datadog 등 여러 서비스도 겸하는 MSP가 많습니다.

약정 할인 혜택, PoC 크레딧 지급 등 다양한 혜택이 있습니다.

RI/SP 구입을 검토하기

MSP 이용 계약을 맺으면 좋은 점 중 하나는, 고객의 입장에서 비용 절약을 돕기 위해 추가적인 할인 혜택을 제공한다는 점입니다.

이를 위해 현재 사용중인 리소스의 비용을 최적화할 수 있는 방안을 제시해 주시곤 합니다.

Reserved Instances(예약 인스턴스)

• RDS, EC2, ElastiCache(Redis) 등

• 인스턴스 당 이용 기간 약정 기준 (1년, 3년)

• 100% 완납, 부분 완납, 분할 납부 등 결제 방법 별 적용 할인율이 달라집니다.

Savings Plan

• EC2, Fargate 등

• 예) 매달 최소 $1,000 ~ $2,000 정도를 사용하겠다! 라는 약정 계약

• RI 대비 비슷하거나 조금 적은 할인율

• 인스턴스 타입 변경시 제약을 받지 않아 유연하게 인프라 구성 가능

원래는 최근 사용량과 워크로드 및 이용 패턴을 직접 분석해서
최선의 비용 절약을 위한 전략을 세워야 하지만,
MSP 매니저님들께 요청하면 각 조직에 알맞는 방법을 제시해 주실 것입니다.

이를 잘 활용하면 고정적인 수요가 있는 EC2 인스턴스를 1년 단위로 약정하여 추가 할인을 받거나,
리소스 제약 없이 비용 단위로 약정을 걸 수 있는 Savings Plan 의 적정 금액 제안을 받을 수 있습니다.

비용 최적화 제안은 모두 최근 사용량을 분석하여 제시해 주시므로 꼭 요청해 보시는 것을 권해드려요.

RI/SP 계약을 통해 고정적인 서버 비용을 약 10% ~ 30%까지 절약할 수 있습니다.

CFRC 계약을 이용한 트래픽 비용 절약

AWS CloudFront를 사용하는 분이라면 CFRC(CloudFront Reserved Capacity)에 대해 들어보신 적이 있을 것입니다.

EC2, RDS의 RI(예약 인스턴스)와 비슷하게 일종의 할인 계약을 통해 트래픽 비용을 절약할 수 있습니다.

월간 10TB 이상의 트래픽을 사용하는 경우 CFRC 계약을 진행할 수 있습니다.

이를 통해 AWS Data Transfer 로 인한 트래픽 비용 발생을 최소화하고 CloudFront 로 데이터 트래픽을 유도하면 트래픽 비용을 더욱 절약할 수 있습니다.

관련해서 베스핀 글로벌의 OpsNow에서 CFRC에 대해 자세히 설명하는 글이 있으니 한 번 참고해보시면 좋을 것 같습니다.

MSP 사용시 고려해야 할 점

MSP를 사용하면 장점도 있지만 분명한 단점도 있습니다.

앞서 MSP를 사용하면 AWS Cost Explorer 기능을 사용하지 못한다고 말씀드렸는데요.

따라서 업체에서 제공하는 비용 대시보드의 기능이 다양한 MSP사를 선택하는 것을 권해 드립니다.

충분한 기간 동안 PoC를 거쳐 사용해보고 여러분의 업무 방식이나 조직에서 원하는 정보를 적재적소에 제공하는지 확인해 보세요.

특히 초과비용 발생, 이상 감지 기능이 제공되는지 확인해보시길 바랍니다.

• 대량의 데이터 분석 등의 작업으로 컴퓨팅 리소스를 사용하고 나서 끄지 않거나
• 해킹 등으로 인해 계정이 탈취되어 급격한 비용이 발생하는 경우

이메일 등으로 알려주는 기능을 AWS Cost Explorer에서는 기본으로 제공하나 MSP 비용 대시보드는 그렇지 않은 경우가 있어 주의해야 합니다.

MSP를 사용중이신 분들도 해당 알림 기능이 있는지, 그리고 꺼져 있지는 않은지 확인해보세요. 실수로 인해 작업이 완료됨에도 사용한 리소스를 끄지 않아 추가 비용이 발생하는 것을 예방할 수 있습니다.

서버리스의 함정에 빠지지 말기

David Heinemeier Hansson 님이 쓴 “서버리스에 속지 마세요”라는 글이 GeekNews에 소개되었습니다. #1

내용을 요약하면 다음과 같습니다.

1. 가끔 실행되는 몇 개의 기능만 필요하다면 서버리스를 사용하는 것도 나쁘지 않다.
2. 다만 24시간 실행해야 하는, 전체 컴퓨팅 기능을 필요로 하는 워크로드의 경우 서버리스는 적합하지 않다.
3. 서버리스에서 클라우드 네이티브 서비스를 사용할수록 벤더 락 인(vendor-lock-in)에 갇히기 쉽다.

위 글과 같이, 서버리스의 장점이 큰 경우에만 도입하는 것을 권해 드립니다.

저희는 몇 가지 사례가 있는데요, 다음과 같이 간략하게 소개드리겠습니다.

AWS RDS Aurora Serverless v2

Amazon Aurora Serverless v2는 초당 수십만 건의 트랜잭션을 지원하는 규모로 데이터베이스를 즉시 확장하고 다중 AZ 배포, 읽기 전용 복제본 및 Global Database와 같은 Aurora의 모든 기능을 지원합니다.

테스트 환경이나 내부 직원을 위한 DB의 경우 t3.medium 타입의 인스턴스를 사용해 왔습니다.

평소에는 사용량이 적다가 가끔씩 사용자가 많아지면 CPU 점유율 스파이크가 발생하는 현상이 있었습니다. 이에 당시 출시된지 얼마 되지 않은 Aurora Serverless v2로 교체를 진행했는데요.

결론적으로는 테스트 환경, 조직 내부 도구 목적에는 Aurora Serverless 대신 t3.medium, t4g.medium이 더 적합하다는 것입니다.

테스트 환경 등에 Aurora Serverless v2를 적용한 결과 대당 $70 ~ $220 정도의 요금이 부과되었습니다.

이를 보고 굳이 AZ간 복제를 할 필요가 없는 경우 Aurora Serverless 대신, RDS PostgreSQL t4g.medium 타입이 더 적합하다고 판단했습니다.

Aurora Serverless는 사실상 서버리스가 아닙니다. 최소 용량이 0.5 ACU 로 고정되어 있어 사용하지 않을 때에는 최소 요금이 발생하기 때문입니다.

쿼리가 급격히 증가하는 형태의 부하가 예측 불가능한 경우 Aurora Serverless를 도입하는 편이 좋겠습니다.

테스트 환경이나 조직 내부 도구를 위한 데이터베이스의 경우 쿼리 수가 일정 수준을 넘지 않는다면 t시리즈 인스턴스를 사용하고 RI(예약 인스턴스)를 구입하는 게 합리적입니다.

AWS Fargate

인프랩은 서비스 초기 워드프레스로 시작하여 2019년부터 AWS의 서버리스 컨테이너 플랫폼인 Fargate를 ECS(Elastic Container Service)에서 실행해 왔습니다.

다음과 같은 장점이 있어 초기 스타트업에 적합한 솔루션으로 자주 거론되곤 합니다.

• 인프라가 아닌 애플리케이션을 관리
• 애플리케이션을 모니터링하여 지표와 인사이트 확보
• 매니지드 서비스
  • 아마존의 보안 기술 노하우를 그대로 적용
  • 아마존의 컨테이너 관리 노하우를 그대로 적용

덕분에 엔지니어 한 명이서도 회원 수가 수십 만이 될 때 까지 안정적으로 서비스를 운영할 수 있었습니다.

EC2 인스턴스와 리눅스 환경 설정으로부터 자유로워지고, 남는 시간으로 애플리케이션 코드 구현에 집중할 수 있었습니다.

그러나 DevOps 엔지니어 4분, 그리고 인턴 2분이 계신 현 시점에는
Fargate의 장점보다 단점이 좀 더 부각되기 시작했습니다.

엔지니어가 늘어나면서 충분히 서버를 관리할 수 있는 능력을 갖추었습니다.
서비스 규모 또한 함께 성장해서 기존보다 많은 트래픽을 처리해야 할 상황에 놓였습니다.

Fargate는 여러 제약 조건이 있습니다.

1. 컨테이너 접근 불가

   • 가끔 실행중인 컨테이너에 접근해 원인을 파악해야 할 때가 종종 있는데요.
   • AWS Systems Manager를 사전에 설정하지 않으면 컨테이너에 접근할 수 없습니다. (SSH 미지원)

2. provisioned 권한 이용 불가

   • 보안 상의 이유로 아마존에서는 Host의 provisioned 권한을 부여하지 않습니다.
   • 따라서 Fargate에서 도커 빌드를 실행하거나, s3fs 같은 가상 드라이브를 마운팅하는 등의 특수한 작업을 수행할 수 없습니다.

3. 커널 파라미터 수정 불가

   • 리눅스 커널 파라미터 튜닝 등으로 성능 최적화를 진행할 수 없습니다.
   • 2023년 8월부터 커널 파라미터 구성을 지원합니다.
   • 다만 해당 옵션을 설정해도 애플리케이션에서 소켓 부족 현상이 발생하는 점은 아쉬웠습니다.

4. EC2와의 성능 차이

   • 외부 자료에 따르면 동일 사양의 EC2 인스턴스 대비 Fargate의 연산 능력이 떨어진다는 것을 알 수 있습니다.

5. 배포 소요시간

   • EC2를 사용하는 경우와 비교하면 컨테이너 프로비저닝 소요시간이 조금 더 오래 걸립니다.
   • Fargate: 1분 15초
   • EC2: 39초
   • 만약 재배포해야 하는 경우 EC2는 서버에 남아 있는 이미지 캐시를 활용할 수 있지만 Fargate는 그렇지 않습니다. 컨테이너 프로비저닝을 다시 진행해야 하기에 더 오랜 시간이 소요됩니다.

Fargate 비용을 EC2와 비교해보면 (2vCPU, 4GiB Mem 기준)

• Fargate: 81.76 USD
• EC2(c7i.large): 73.584 USD
• Fargate가 같은 크기의 EC2 대비 10% 더 많은 비용을 지불해야 합니다.

c7i 계열의 EC2 인스턴스의 사양이 더 높고, EC2 인스턴스 1대에서 여러 컨테이너를 실행하는 점을 고려하면 EC2가 가격 대비 성능 효율적입니다.

팀이 서버를 충분히 관리할 수 있는 경우 비용 측면이나 성능 측면에서도 직접 EC2로 구성된 클러스터를 운영하는게 더 합리적인 것으로 판단했습니다.

이후 Fargate 컨테이너를 모두 EC2에서 실행하는 작업을 진행하고 있으며 이를 통한 비용 최적화도 진행할 수 있었습니다.

Fargate를 사용하면서 월 3000달러 정도의 비용을 지출해 왔는데요.

오버 프로비저닝된 컨테이너에 적은 리소스를 할당하는 Scale-Down 작업과, Fargate -> EC2 전환 작업을 동시에 진행했습니다.

그 결과 월간 약 1500달러 정도의 비용을 절약하면서도 안정적으로 서비스를 운영할 수 있었습니다.

다음 번에 기회가 된다면 실행중인 ECS + Fargate 서비스를 중단 없이 EC2로 이전하는 방법에 대해 기술 블로그를 작성해 보겠습니다.

물론 이 사례의 경우 조직이 성장하면서 팀 규모가 커지고, 서비스 이용 규모도 커졌을 때의 이야기입니다.

소규모 팀이나 서버를 직접 관리하기 어려운 경우 ECS + Fargate는 정말 좋은 조합이라고 생각합니다!

적정 기술 선택하기

여러분은 적정 아키텍처라고 하면 무엇이 먼저 떠오르시나요?

저희는 마이크로서비스 아키텍처가 먼저 떠오르는 것 같습니다.
이를 구축하기 위해서는 서비스 디스커버리, istio 프록시부터 프로메테우스, 쿠버네티스 클러스터, 그리고 심층 분석이 가능한 APM 등 다뤄야 할 도구가 급격히 늘어나는데요.
서비스가 여러 개로 나뉘어 지면서 추가적인 서버 자원을 필요로 하기도 합니다.
이를 다루다 보면 상당히 높은 기술적 숙련도와 시간적, 금전적인 비용을 필요로 하게 됩니다.

매일 늘어나는 트래픽으로 인해 기존 아키텍처로는 더 이상 감당이 불가능한 것이 아니라면 현재의 비즈니스에 집중하는 것을 권해 드리고 싶습니다.

저희 조직은 다음과 같이 적정 기술을 선택해온 바 있습니다.

• 한글 검색엔진으로 ElasticSearch 대신 MongoDB Atlas 선택 (운영 및 관리 비용 절감)
• 당장 마이크로서비스를 도입하는 것 대신 여러 개의 모놀리스 애플리케이션 운영 (인프라 운영 및 관리 비용을 절감)

조직에 적합한 적정 기술을 찾고 이를 잘 활용하는 것 부터 시작하면 비용을 더 효과적으로 절약할 수 있다고 생각합니다.

빠르고 저렴한 CDN을 적극 활용하기

이미지, 동영상과 같은 정적 미디어 콘텐츠를 서빙하는 스타트업이라면 CDN(Contents Delivery Network) 활용은 필수인데요.
캐싱을 통해서 s3, 웹 서버 등의 원본(origin)으로 향하는 반복적인 요청을 줄여 비용을 절약하고 서비스 품질을 개선할 수 있습니다.

인프랩에서는 CDN으로 AWS CloudFront를 사용하며
S3, Application Load Balancer, Lambda Function URL 등의 리소스와 연결하고 있습니다.

최근에는 유저 상세 및 수강평(리뷰) 페이지, og 이미지와 같은 동적 콘텐츠에도 CDN 캐싱을 적용하고 있습니다.
Next.js SSR(Server-Side Rendering) 응답을 CDN에서 짧은 시간동안 캐싱해서 트래픽 스파이크를 최소화하기도 합니다.

예를 들어, 응답하는 데에 1초가 소요되는 유저 상세 페이지가 있다고 가정해 보겠습니다. 유저 상세 페이지의 정보가 자주 변경되지 않는다면 동적 캐싱(Dynamic Caching) 도입을 검토할 수 있습니다.

서버의 Cache-Control 응답 헤더를 다음과 같이 수정합니다.

동적으로 변경되는 페이지는 private, no-cache 등의 옵션으로 CDN에서 캐싱하지 않도록 설정하는 것이 일반적인데요, 위 이미지처럼 Cache-Control 응답 헤더를 수정해서 동적 캐싱을 활성화했습니다.

그러면 맨 처음에 CDN에 캐시가 없을 때에만 서버로 요청을 보내 1초가 소요될 것입니다.
CDN에서는 해당 응답을 캐싱해서 그 이후 요청은 0.01 ~ 0.1초 내외에 응답할 수 있습니다.
CDN에서 캐시가 만료될 때 까지 이러한 현상은 이어집니다.

실제 서버의 사양이 낮거나 코드의 처리 성능이 좋지 않더라도
CDN에서 캐싱된 응답을 받는 사용자는 서비스를 쾌적하게 이용할 수 있을 것입니다.

다만 사용자마다 다른 정보가 출력되어야 하는 페이지는 동적 캐시를 사용할 때 주의해야 합니다.
사용자 세션 쿠키나 JWT 토큰을 구분해서 캐싱하도록 캐시 키(Cache Key)를 설정하면 개인화된 컨텐츠도 동적으로 캐싱할 수 있습니다.

또한 데이터 변경이 잦고 항상 최신의 응답을 해야 하는 경우에는 동적 콘텐츠 캐싱 적용이 어려울 수 있습니다.

public, s-maxage=60, stale-while-revalidate=59 옵션을 ChatGPT에게 설명해달라고 해봤습니다.

1. 이 응답은 공개적으로 캐시될 수 있으며, 공유 캐시(s-maxage)에서는 60초 동안 유효합니다.
2. 상기 시간이 지난 후에도, 최대 59초 동안은 유효성 검증(revalidation)이 이루어지는 동안에도 기존 캐시된 내용을 제공할 수 있습니다.
3. 이를 통해 사용자는 더 빠른 콘텐츠 로딩 시간을 경험할 수 있으며, 동시에 서버는 새로운 콘텐츠로의 업데이트를 준비할 시간을 가질 수 있습니다.

동적 캐싱을 이용하여 CDN에서 일정시간 동안 데이터를 저장함으로써, 서버로의 부하를 줄이고 사용자에게 빠른 페이지 로딩 속도를 제공할 수 있습니다.

비용 측면에서도 서버의 부하 감소로 인해 필요한 서버 자원의 양이 줄어들어 비용 효율성이 증가합니다.

예를 들어 Next.js 서버가 1초에 100개의 요청을 처리할 수 있다면, CDN에 캐싱하게 되면 거의 무한대에 가까운 처리량으로 사용자에게 요청을 서빙할 수 있습니다. 자주 요청하는 페이지가 있을 테니까요.

CDN 서비스는 규모의 경제에 따라 수 많은 Edge 캐시 서버를 운영하고, 사용한 만큼만 비용을 부과합니다.
CDN을 최대한 잘 활용하는 것이 서버 비용을 절약할 수 있는 지름길입니다.

글로벌 사용자를 대상으로 서비스하는 경우 CDN을 활용하면 지역에 따른 지연 시간(latency)을 크게 줄일 수 있습니다.
각 지역에 분산된 CDN 노드들이 사용자와 가장 가까운 위치에서 콘텐츠를 제공하기 때문에, 사용자는 전 세계 어디서든 지역적인 네트워크 지연 없이 빠른 속도로 웹사이트에 접근할 수 있게 됩니다.

구현 과정에서의 세부적인 점을 몇 가지 더 언급하자면, 캐싱 정책 설정에 주의해야 합니다. (위에서 설명한 cache-control 옵션, CloudFront Cache Policy 등)
콘텐츠의 업데이트 주기나 중요도에 따라 적절한 캐시 만료 시간(TTL, Time To Live)을 설정해야 합니다.
사용자 요청에 따라 캐시를 무효화하거나 업데이트하는 메커니즘도 고려해야 합니다.

보안 측면에서도 CDN의 이점은 큽니다.
대부분의 CDN 서비스는 DDoS 공격 방어, SSL/TLS 같은 암호화 프로토콜 등의 보안 기능을 제공하여,
데이터의 안전성을 높이고 보안 위협으로부터 웹사이트를 보호할 수 있습니다.

이렇게 다양한 이점을 고려할 때, CDN은 단순히 콘텐츠 전송 네트워크를 넘어서 사용자 경험을 향상시키고 비즈니스 비용을 절감하는데 중요한 역할을 합니다.

웹 서비스의 성능을 향상시키고 비용을 절감하고자 한다면 적극적인 CDN 도입과 최적화 전략을 고려해보는 것이 좋습니다.

정말 사용하지 않을 이유가 없습니다. 꼭 한 번 도입해 보세요!

내부 서비스 호출에는 내부망을 사용하기

사용자 요청을 서버에서 응답하는 경우가 있다면, 서버 사이에도 통신이 필요합니다.

서비스의 규모가 커질 수록 서버 간 호출에 사용되는 트래픽의 규모도 비례해서 커질 것입니다.

AWS Well-Architected Framework 및 AWS VPC 가이드에 따르면 내부 서버 사이에 통신은 가급적 프라이빗 서브넷(Private Subnet)에서 진행하는 것을 권장하고 있습니다.

만약 개발자의 실수로 내부 IP를 향하는 도메인이 아닌, 공개 IP를 향하는 도메인을 사용해 통신하면 어떻게 될까요?

• 라우팅 정책에 따라 퍼블릭 서브넷에 있는 NAT(Network Address Translation, 네트워크 주소 변환) 게이트웨이 혹은 인터넷 게이트웨이를 거쳐 외부 라우터를 경유하게 됩니다.

• source IP가 NAT 게이트웨이의 IP가 되고, 외부 라우터를 경유해서 지연시간이 길어지게 됩니다.

• 비용도 더 지불해야 합니다. 외부 네트워크로 송신하는 트래픽이 발생해 추가 요금이 발생합니다.

AWS는 같은 가용영역(AZ) 간의 트래픽은 비용을 부과하지 않으므로 내부 IP를 향하는 도메인으로 요청을 보내서 네트워크 비용을 절약할 수 있습니다.

정리하자면 다음과 같습니다.

• 내부 서비스 간 호출시에는 내부 IP(프라이빗 서브넷 IP 대역) 이용

  • internet-facing 대신 internal Load Balancer 사용
  • ALB, S3, PrivateLink를 이용한 내부용(internal) HTTPS 정적 웹사이트 호스팅

• -> 불필요한 지연 시간 & 트래픽 비용 감소

public 네트워크에 공개하면서 프라이빗 서브넷(private subnet)에서도 접근해야 하는 경우 다음과 같이 두 개의 로드 밸런서를 구축하는 것을 권장합니다.

Amazon ECS의 다중 로드 밸런서 연결 기능을 이용해 내부(internal), 외부(external) 서비스 엔드포인트를 같은 DNS 이름으로 사용하는 방법 (AWS 블로그) 문서를 참고해보시면 도움이 될 것입니다.

S3, SNS 등과 같은 AWS 서비스를 호출할 때에도 예외는 아닙니다.

별도의 VPC 엔드포인트를 설정하지 않으면 AWS 서비스를 호출할 때 NAT 및 인터넷 게이트웨이를 거칩니다. 이는 퍼블릭 네트워크를 경유하여 추가 트래픽 비용이 발생하게 되는 원인이 됩니다.

인터페이스 VPC 엔드포인트를 사용하여 AWS 서비스 액세스 문서를 참고해서 VPC Endpoint를 생성할 수 있습니다.

이를 통해 AWS 서비스를 호출할 때 private IP로 요청을 보내 트래픽 비용을 절감할 수 있다는 장점이 있습니다.
이용 시 시간당 사용 요금 및 데이터 처리 요금이 청구될 수 있어 도입시 잘 판단해보시는 걸 권해 드립니다.

• Amazon S3용 게이트웨이 엔드포인트는 무료로 사용할 수 있습니다.

• 동일 AWS 리전에서 Amazon S3, DynamoDB, SES, SNS, SQS, Kinesis, ECR, SimpleDB 및 EC2 인스턴스간에 직접적으로 전송되는 데이터는 무료입니다.

• 다른 AWS 서비스가 데이터 전송 경로에 있는 경우, 관련 데이터 처리 비용이 부과됩니다.

동일 AWS 리전 내 데이터 전송과 관련해 자세한 내용은 AWS 문서를 참고하시면 좋습니다.

마무리

지금까지 스타트업의 DevOps 엔지니어 입장에서 AWS 클라우드 비용을 절약한 경험에 대해 소개해 드렸습니다.
인프랩 DevOps 파트는 월간 $25,000(원화로 약 3,325 만원)를 절약할 수 있었습니다.
연간 $300,000(원화로 약 3억 9,900만 원)를 아낀 셈입니다.

AWS 클라우드 비용을 최적화는 스타트업이나 중소기업 뿐만 아니라 모든 AWS 사용자에게 중요한 과제인데요.
위에서 공유한 여러 전략은 어디까지나 시작점일 뿐 각 조직의 구체적인 상황과 요구사항에 맞게 미세 조정할 필요가 있습니다.

AWS 비용 최적화는 한 번에 끝나는 일이 아닙니다. 지속적인 관심과 개선을 통해 비용 효율과 서비스의 성능 사이 균형을 이루며 성장할 수 있을 것입니다.

이러한 노하우가 여러분의 AWS 비용 최적화 노력에 도움이 되기를 바랍니다.

긴 글 읽어주셔서 감사합니다.