AWS 비용절감: 이중 캐싱 서비스 제거
“서버를 줄이니, 비용이 줄었다. 그것도 5대나.”
많은 개발 조직이 ‘늘어난 서버를 유지하는 것’이 당연한 일처럼 받아들이곤 합니다.
하지만 잘 쓰이지 않는 서버, 레거시 캐싱 시스템, 무심코 남겨둔 인프라가 매달 수백~수천 달러의 비용을 야금야금 삼키고 있다는 사실, 알고 계셨나요?
이번 사례는 그런 ‘당연하다고 믿어온 구조’에 의문을 제기하고,
과감하게 5대의 EC2 서버를 제거한 이야기입니다.
이미지 캐싱을 담당하던 Ston Edge 서버 2대
데이터 캐싱용 레거시 EC2 인스턴스 2대
그리고 개발환경으로 쓰이던 서버 1대
이들을 걷어내고도 서비스는 멀쩡히 동작합니다.
아니, 오히려 더 간단하고 유연해졌습니다.
이 글의 두문장 요약
3rd 의존성 제거 및 레거시 서버 5대 제거
월 1,200달러 절감
제거된 비용
추가된 비용
순 절감액: $1,200/월
Ston Edge는 고성능 캐시 기반 웹 프록시 서버입니다. 쉽게 말해 "이미지나 파일 같은 데이터를 빠르게 전달해주는 중간 서버" 역할을 합니다.
이미지, 파일 요청이 많으면 서버가 버거워질 수 있습니다. 트래픽이 과부하될 수 있고 특히 이미지 사용이 많아질 경우 S3에 저장하는 비용이 부담이 될 수 있습니다. 다양한 썸네일을 사용하게 되면 용량이 비록 작더라도 그만큼 저장해야 할 파일 객체가 많아지게 됩니다. 스톤엣지는 이를 앞단에서 받아서 캐싱하고 빠르게 응답해줍니다. 캐시를 사용하므로 트래픽이 분산될 수 있고 썸네일은 스톤엣지에 저장해서 서빙할 수 있습니다.
또한 이미지의 경우 서비스에서 요구하는 사이즈로 썸네일을 만들어야 하거나, 큰 이미지의 라시이징, Rotation 등이 필요할 수 있습니다. 스톤엣지는 리사이징과 변환을 쉽게 지원합니다.
핵심은 클라이언트의 요청을 받았을 때 중간에서 대신 처리하며 꼭 필요한 경우에만 원본 서버에 요청을 보내는 프록시 서버로서의 역할입니다. 아래는 스톤엣지가 동작하는 프로세스입니다.
출처 https://ston.readthedocs.io/ko/latest/admin/intro.html참고로 스톤엣지를 운영하는 WineSOFT에서는 최근에 M2라는 더 발전된 솔루션을 제공하고 있습니다.
저희 조직은 스톤엣지 서버를 오랫동안 써오고 있었습니다. 그리고 최근에는 이미지에는 CloudFront 캐싱을 도입했고, ElastiCache Redis로 데이터를 캐싱하는 아키텍처도 도입되었습니다.
이미지의 경우 스톤엣지와 CloudFront를 같이 쓰게 되면서 캐시 이중화를 사용하고 있었습니다. 즉 아래와 같은 데이터 요청과 응답이 이루어집니다.
요청
클라이언트 → CloudFront → 스톤엣지 → S3
응답
S3 → 스톤엣지 → CloudFront → 클라이언트
데이터캐싱은 ElastiCache를 사용한 이후로 이후에 데이터 캐싱이 필요할 때는 Redis를 활용하고 있었습니다.
이미지 캐싱과 데이터 캐싱을 위해 5대의 서버가 운영되고 있는 상황입니다.
이미지 캐싱은 r6i.2xlarge 2대, 데이터 캐싱은 c6i.xlarge 2대가 운영되고 있었고 개발환경에서는 데이터와 이미지를 통합관리하며 c5.large 1대를 운영하고 있었습니다.
이 상황을 보았을 때 다음과 같은 의문점이 들었습니다.
이미지 이중 캐싱이 의미있게 쓰이고 있는가?
데이터캐싱의 경우 스톤엣지는 단순히 레거시로서 동작하고 있는가?
이미지 캐싱 분석
스톤엣지를 추가로 활용할 경우 CloudFront 대비 다음과 같은 장점이 있습니다.
리사이징 등 이미지 변환 지원을 쉽게 받을 수 있습니다.
사이즈별, 폴더별 등 스톤엣지 서버에서 로직으로 컨트롤할 수 있기 때문에 세밀한 캐시 정책이 지원 가능합니다. 예를 들어 자주 쓰이는 이미지를 판단해 TTL을 길게 적용할 수 있습니다.
비용적인 관점에서는 트레이드오프가 있습니다. 스톤엣지 서버를 내리는 대신 S3로 직접 호출하게 될 가능성이 높아집니다. S3 Origin Fetch 비용이 추가로 발생할 수 있는데 스톤엣지는 그 비용을 줄여줍니다. 단 스톤엣지의 히트율이 높을 때에 한해서입니다.
만약 이미지 이중 캐싱을 제거하고 CloudFront에서만 서빙한다면?
비용관점에서 확실한 이득으로 판단되었습니다. 스톤엣지 이미지 캐싱을 위해 r6i.2xlarge 2대를 사용하고 있었는데 서버 유지 비용을 줄일 수 있게 됩니다.
세밀한 캐시 정책은 매력적인 부분이었습니다. 자주 활용되는 이미지의 TTL을 높여서 관리한다면 스톤엣지에서 원본을 참조하지 않고 굉장히 빠르게 응답이 가능합니다. S3 Origin Fetch 비용과 성능을 둘 다 확보할 수 있습니다.
리사이징의 경우 자체적으로 해결해야 되는 부분입니다. 하지만 이미지 변환하는 로직은 구현하기가 그렇게 어렵지 않습니다.
현황 파악
현재 내부에서 사용하는 용도를 파악했을 때 이런 이미지 별 TTL 관리가 전혀 이루어지고 있지 않은 상태였습니다. 안타깝게도 스톤엣지 서버의 장점이 잘 활용되고 있지 않은 상태였습니다.
그리고 그 결과로 히트율이 평소 3% 아래를 유지하고 있습니다. 이는 100개의 이미지 요청을 받았을 때 97개가 존재하지 않으므로 S3를 참조한다는 얘기입니다.
히트율이 3% 이하로 낮은 것은 CloudFront에서 대부분 캐싱이 잘 처리되고 있다는 얘기이기도 합니다. 해당 이미지를 활용하는 CloudFront의 캐싱률은 80% 정도를 유지하고 있었습니다.
안타깝게도 현재 스톤엣지 이미지 서버는 제 역할을 못하고 비용을 낭비하고 있는 상황으로 판단되었습니다. 따라서 의사결정은 스톤엣지를 제대로 관리해서 성능 및 약간의 비용을 줄일지, 스톤엣지를 제거해서 많은 비용을 절감할지로 귀결되게 됩니다.
결국 스톤엣지를 제거하는 걸로 결정되었습니다.
스톤엣지 이미지서버 제거
스톤엣지 이미지 서버를 제거하기 위해 다음과 같이 아키텍처 변경을 하게 됩니다.
As is
클라이언트 → CloudFront → 스톤엣지 → S3
To be
클라이언트 → CloudFront → Api Gateway → Lambda → S3
Lambda는 리사이징 등 이미지 변환을 처리하기 위해 도입되었습니다. 애초에 EC2 서버를 띄워서 운영할지에 대한 고민이 있었으나 한번 잘 만들어둔 다음에는 관리할 영역이 아니라고 판단되어 Lambda에서 필요할 때마다 호출하도록 했습니다.
Lambda를 적용하면서 몇가지 이슈들을 처리해야 했습니다.
초기에 API Gateway를 쓰지 않고 Lambda Edge를 활용하는 방안을 검토했으나 Lambda Edge의 Response limit이 1mb로 제한되어 있어 활용할 수 없었습니다.
Lambda 역시 6mb의 Response 제한이 있습니다. 다만 이 경우는 Resizing, Quality 변환 (80%), 그리고 webp 확장자로 포맷 변환을 하여 압축률을 높이는 방안을 선택했습니다.
해당 아키텍처를 적용하고 난 뒤 개발 → 운영 배포 단계를 거쳤습니다. 스톤엣지 서버에 엑세스 로그가 더 이상 전혀 없는 것을 파악하고 서버를 안정적으로 제거할 수 있었습니다.
데이터 캐싱 분석
데이터 캐싱에 대한 의사결정은 상대적으로 빨리 이루어졌습니다. 이미지 캐싱보다 아키텍처 변경이 간단했고 ElastiCache라는 별도의 서비스로 신규 캐싱이 이미 진행되고 있었기에 과거에 쓰던 캐싱만 ElastiCache로 변환시키면 됩니다.
스톤엣지 데이터캐싱서버 제거
As is
클라이언트 → BFF 프록시(스톤 데이터 캐싱) → BFF → Biz API
클라이언트 → API Gateway → Lambda → BFF 프록시(스톤 데이터 캐싱) → BFF → Biz API
To be
클라이언트 → BFF → ElastiCache
클라이언트 → API Gateway → Lambda → BFF → Biz API
(데이터 획득 실패시) → BFF→ Biz API
데이터 캐싱의 경우 위와 같이 BFF 프록시가 앞에서 하던 역할을 제거하고 BFF에서 분기 로직을 처리합니다. BFF는 Backend For Frontend로 클라이언트의 모든 API가 들어오는 진입점입니다. ElastiCache에서 데이터 획득을 실패할 경우 Biz API를 호출해 원본 데이터를 받아옵니다. 다만 인증 로직을 비롯해 Lambda를 활용하는 로직이 추가로 있기 때문에 Lambda에서 바라보는 엔드포인트를 BFF 프록시에서 BFF로 변경합니다.
해당 변경은 두 개로 분리되어 있던 캐싱 구조를 ElastiCache로 통합한 과정입니다. 마찬가지로 개발 → 운영 배포 단계를 거쳤고, 액세스 로그를 확인해 더 이상의 로그가 찍히지 않는 것을 보고 안정적으로 서버를 제거했습니다.
제거 후 어떤 것이 변했을까요?
이번 작업은 엄밀히 말하면 2중 캐쉬의 뒷단을 제거한 것으로 성능이 저하될 우려가 있습니다. 그러나 성능의 변화는 크게 체감되지 않습니다. ElastiCache가 제 역할을 충분히 해주고 있고, 이미지서버의 경우 처음부터 히트율이 떨어졌기에 굳이 수치화하자면 2-3% 정도의 이미지가 S3에서 데이터를 받아오게 되는 상황입니다.
비용적으로는 큰 변화가 있습니다. 스톤엣지를 운영하는 라이선스 비용은 물론 서버 5대를 제거하면서 월 약 $1300가 절감되게 됩니다. 물론 API gateway와 Lambda를 사용하는 비용, 그리고 S3에서 데이터를 가져오는 비용이 추가로 들게 되지만 이후 각각의 사용료를 Cost Explorer에서 모니터링했을 때 늘어난 비용은 약 $100 아래로 추산됩니다.
CloudFront는 비용이 증가하지 않습니다. 스톤엣지 서버를 사용하기 전부터 제일 앞에서 클라이언트의 요청을 처리하고 있었고 그 트래픽은 변화가 없기 때문입니다.
비용 측면에서 한가지 주의할 점이 있습니다. Lambda를 사용하게 될 경우 Cloudwatch 로깅을 적용하게 됩니다. 트래픽이 많을 경우 Lambda에서 Cloudwatch로 보내는 비용은 꽤 높습니다. 저희의 경우 하루 약 $35가 로그로 쌓였기 때문에 해당 변화를 모니터링한 후 로깅을 제거했습니다. 특정 이미지가 오류가 나는 상황이 발생했을 때 다시 로깅을 쌓고 해결하는 방식을 택했습니다.
결론
이번 마이그레이션을 통해 레거시 캐싱 서버를 클라우드 네이티브 아키텍처로 성공적으로 전환했습니다. 주요 성과는 다음과 같습니다:
비용 최적화: 월 $1,200의 비용 절감
운영 효율성: 관리해야 할 서버 수 감소, 레거시 아키텍처 제거
현대화: 클라우드 네이티브 서비스 활용
확장성: 서버리스 아키텍처로 자동 확장 가능
Note: 이러한 전환은 각 조직의 상황과 요구사항에 따라 다르게 접근해야 합니다. 충분한 분석과 테스트를 거친 후 진행하시기를 권장드립니다.
용어 설명
Ston Edge: 고성능 캐시 기반 웹 프록시 서버로, 이미지나 파일을 빠르게 전달하는 중간 서버
CloudFront: AWS의 CDN(Content Delivery Network) 서비스
ElastiCache: AWS의 관리형 인메모리 캐싱 서비스
BFF(Backend For Frontend): 프론트엔드 전용 백엔드 API 계층
Lambda: AWS의 서버리스 컴퓨팅 서비스
API Gateway: AWS의 API 관리 및 라우팅 서비스
주의사항과 모범 사례
CloudWatch 로깅 비용 관리
문제점
Lambda의 CloudWatch 로깅이 일일 $35의 예상치 못한 비용 발생
해결방안
평상시에는 로깅 비활성화
문제 해결 시에만 선택적으로 로깅 활성화
Error 로그만 선택적으로 수집하는 방안 고려
마이그레이션 시 고려사항
성능 모니터링
캐시 히트율 지표 수집
응답 시간 모니터링
에러율 관찰
점진적 전환
개발 환경에서 충분한 테스트
트래픽 점진적 전환
롤백 계획 수립
FinOps 커뮤니티에 함께 하실래요?
저는 최근 48%, $36000의 AWS 비용절감을 달성했습니다.
클라우드 비용을 효율화하고 싶은 분들, 비슷한 고민을 나누고 싶다면 제가 운영 중인 AWS-FINOPS-KR Slack 커뮤니티에 참여하세요. 실제 절감 사례, 질문, 전략 공유를 나누실 수 있습니다.
