https://nanta-data.dev/tags/autoscaling/Recent content in Autoscaling on nanta - 데이터 엔지니어링Hugo -- gohugo.ioko© 2026 nantaThu, 05 Mar 2026 00:00:00 +0000https://nanta-data.dev/posts/eks-ai-platform-cost-saving/Thu, 05 Mar 2026 00:00:00 +0000https://nanta-data.dev/posts/eks-ai-platform-cost-saving/AI 플랫폼팀의 서빙 API가 c6i.2xlarge와 m6i.2xlarge 두 종류의 온디맨드 인스턴스에 500개 파드를 항시 고정 배포하고 있었다. 인스턴스 타입 다양화와 Karpenter consolidation을 1차로 적용하고, KEDA cron 트리거 기반 스케줄 스케일링을 2차로 적용했다. 핵심 발견: consolidation 단독으로는 파드 수가 불변이면 효과가 제한적이고, 스케일인과 결합해야 노드 수가 줄어든다.https://nanta-data.dev/posts/flink-in-place-scaling/Tue, 03 Mar 2026 00:00:00 +0000https://nanta-data.dev/posts/flink-in-place-scaling/추천시스템의 Flink 어플리케이션은 지연시간 1분 미만이 요구되어 오토스케일링과 스팟 인스턴스를 적용하지 못하고 있었다. 오토스케일링이나 스팟 회수로 Flink 앱이 재시작되면 실제 처리 시작까지 2~3분이 걸리기 때문이다. Flink 1.18의 adaptive scheduler와 K8s operator 1.8을 활용해 in-place 스케일링을 적용하고, 스케일링 시 컨슈머 랙을 1/5로 줄인 과정을 정리한다.https://nanta-data.dev/posts/emr-on-eks-vpa-review/Fri, 27 Feb 2026 00:00:00 +0000https://nanta-data.dev/posts/emr-on-eks-vpa-review/EMR on EKS 환경에서 Spark executor 리소스를 자동 최적화하려고 AWS 제공 VPA를 검토했다. 약 한 달간 PoC를 진행했지만 오퍼레이터 자체가 정상 동작하지 않았다. AWS 서포트 케이스를 여러 차례 열었고 매니페스트 번들까지 받아서 커스터마이징했지만 결국 포기했다.