https://nanta-data.dev/tags/eks/Recent content in Eks 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/emr-on-eks-lakeformation-poc/Tue, 03 Mar 2026 00:00:00 +0000https://nanta-data.dev/posts/emr-on-eks-lakeformation-poc/EMR-on-EKS에 Spark 잡 레벨의 권한제어를 도입해야 했다. Ranger는 EMR-on-EKS의 구조적 한계(마스터 노드 부재, 플러그인 설치 불가)로 기각되었고, LakeFormation을 선택했다. PoC 과정에서 서비스 라벨 셀렉터 불일치, FGAC의 RDD/UDF/synthetic type 차단, cross-account Glue 접근 제한 등 10개의 이슈를 만났다. 각각의 원인 파악과 우회 방법, 그리고 FGAC가 기존 Spark 코드에 미치는 영향을 정리한다.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/eks-topology-aware-hints/Fri, 27 Feb 2026 00:00:00 +0000https://nanta-data.dev/posts/eks-topology-aware-hints/EKS cross-AZ 통신 비용 절감을 위해 Topology Aware Hint 적용을 검토했다. EndpointSlice에 힌트는 정상적으로 붙었지만, 실제 효과는 없었다. AWS Load Balancer Controller의 IP 타깃 모드가 kube-proxy를 우회하고, 주요 내부 워크로드(Spark, Trino, Airflow)가 모두 싱글 존 또는 stateful 통신이라 힌트가 참조되는 경로 자체가 존재하지 않았다.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 서포트 케이스를 여러 차례 열었고 매니페스트 번들까지 받아서 커스터마이징했지만 결국 포기했다.