💰 Google Static Maps API 비용 절감 방안

💡 배경

최근 Google Workspace 관련 TF를 진행하면서 API 비용을 검토하던 중, Google Static Maps API가 상당한 비용을 차지하고 있는 것을 발견했습니다. 단순 일정 조회마다 API가 호출되면서 불필요한 요청이 급증하고 있었고, 생각보다 많은 비용이 발생하고 있는것을 확인 할 수 있었습니다.

이 문제를 해결하기 위해, 어떻게 하면 더 빠르고 안전한 방법으로 비용을 절감하면서도 사용자 경험(User Experience)을 저하시키지 않을까 고민하게 되었습니다.

이에 대한 비용 절감 방안을 고민하였고, 가장 빠르고 효과적으로 줄일 수 있는 방법을 찾아 CloudFront를 활용한 캐싱 전략을 적용해 보았습니다. 🚀

---

🚀 적용 방식

🔹 CloudFront 적용 방식

1️⃣ CloudFront를 중간 캐시 계층(Proxy)으로 설정

• maps.googleapis.com을 Origin으로 설정하여 Google API 요청을 Proxy하도록 구성
• 동일한 요청이 들어오면 CloudFront가 대신 응답하도록 캐시 적용 (Google로 API 발송 X)

2️⃣ CloudFront 캐시 정책(Cache Policy)

• 쿼리 파라미터 기준 캐싱: center, zoom, size, markers 값 기준으로 캐시
• TTL 설정 (캐시 유지 시간 조정)
  • Minimum TTL: 3600초 (1시간) - 이건 늘릴 예정!
  • Default TTL: 86400초 (1일)
  • Maximum TTL: 604800초 (7일)

---

🔹 다른 방식도 고려해봤다! (F.Y.I)

S3를 활용한 CloudFront 캐싱 방식도 고려했습니다. 이 방식은 Google Static Maps API에서 가져온 이미지를 S3에 저장한 후, 이후 동일한 요청이 들어오면 S3에서 데이터를 가져와 CloudFront를 통해 제공하는 방식입니다.

📌 하지만 몇 가지 문제가 있었습니다.

• 서버 코드 수정 필요 → 기존 API 호출 방식 변경해야 함
• 기존 데이터 변환 과정 복잡 → 캐시된 데이터의 TTL을 적절히 설정하고 관리해야 함
• 운영 부담 증가 → 저장된 이미지 관리 및 TTL 설정이 필요
• Cloud Front를 할인을 받고 있음

👉 그래서 빠르게 적용 가능하고 유지 관리가 쉬운 CloudFront 방식을 최종적으로 선택!

---

🔥 CloudFront URL로 자동 치환!

빠르게 적용이 필요하다고 판단하여 우선 Front-end에서 Google 주소를 CloudFront 주소로 치환하여 즉시 배포를 진행하였고, 이후 Back-end에서도 해당 주소를 Config에서 관리할 수 있도록 수정하였습니다. 

Google Map CloudFront는 하나만 운영하며,
리전별로 CF를 생성할 경우 불필요한 Google API 요청 증가 가능성이 있어 단일 운영을 유지하기로 하였습니다.

---

📊 기대 효과

✅ 비용 절감 효과 → Google API 호출 감소로 비용 80% 절감 기대

✅ 서비스 응답 속도 향상(?!) → 캐시된 데이터 제공으로 인해 지연 시간 단축 가능성

• 물론 Google 자체 응답 속도도 빠르지만, CloudFront를 활용하면 더 빠른 응답을 기대해볼 수 있음!

이번 비용 절감 프로젝트는 Google Static Maps API에 한정된 개선 사항이지만, 더 나아가 Google Place API와 같은 다른 API 최적화도 고민해볼 예정입니다! 🚀