들어가기 앞서애플리케이션 트레이싱 도입을 검토하던 중, ADOT을 활용한 AWS X-Ray 트레이싱을 사용하기로 결정했다. Istio 환경에서는 Jaeger를 사용하는 것도 하나의 선택지일 수 있다. 그러나 Jaeger는 Feign 라이브러리 추가 등 애플리케이션 코드 변경이 필요한 비교적 침투적인 방식이다. 현재 상황에서 애플리케이션 코드를 수정할 수 없는 상황이라고 판단했기 때문에, 코드 변경 없이 트레이싱을 구성할 수 있는 ADOT을 선택했다. 본 글에서는 ADOT을 이용해 X-Ray 트레이싱을 구성하는 방법을 설명한다.AWS Distro for OpenTelemetry (ADOT) 이란?AWS Distro for OpenTelemetry(ADOT)는 클라우드 CNCF의 OpenTelemetry 프..

1. 들어가기 앞서개발 / 품질 환경의 경우 Instance Scheduler 를 사용하여 EKS 의 노드를 종료시킬 수 있다. 자세한 내용은 아래의 포스팅을 참고 부탁하며 그 중 핵심은 ASG(Auto Scaling Group) 의 desired, min, max 를 각각 0 으로 조정하여 내리는 방법이다. https://hyukops.tistory.com/39 AWS: Instance Scheduling들어가기 앞서현재 운영중인 프로젝트의 비용최적화 방안으로 개발 및 품질과 같은 운영을 제외한 환경에 있는, EC2를 포함한 RDS와 같은 인스턴스 등을 업무시간 이외에 자원을 중지시키고 업무hyukops.tistory.com문제는 EKS Automode 의 경우 ASG 를 사용하지 않는다는 것이다. E..

Secret Manager 란?AWS Secrets Manager는 데이터베이스 자격증명, 애플리케이션 자격증명, OAuth 토큰, API 키 등 민감정보(시크릿)의 생성, 저장, 검색, 버전관리 및 자동 로테이션을 전체 수명주기(lifecycle) 관점에서 관리하는 서비스이다. 하드코딩된 비밀값을 대체하여 보안 태세를 개선하도록 설계되었다.목적소스코드나 환경변수에 민감정보를 남기지 않도록 하여, 코드 노출 시 비밀노출 위험을 줄인다.중앙화된 저장과 접근 제어로 감사·모니터링이 가능하도록 한다.누가 쓰는가 / 사용 시나리오애플리케이션(서버, Lambda, 컨테이너 등)이 런타임에 비밀번호/토큰을 조회해야 하는 경우.주기적 로테이션이 필요해 사람이 직접 교체하기 번거로운 자격증명.여러 서비스가 동일 자격증..

들어가기 앞서현재 운영 중인 서비스는 개발, 품질, 운영 환경을 각각 분리하여 구성되어 있다. 비용 최적화를 위해 각 환경의 EC2 및 EKS 워커 노드 인스턴스 타입을 변경하였으며, 이 과정에서 일부 문제가 발생하였다.개발 및 품질 환경의 경우, 비용 절감을 위해 리소스를 인스턴스 스케줄러를 통해 관리하고 있다. 이에 따라 리소스는 아래와 같이 정기적으로 중지 및 재시작된다:EC2 및 RDS: 매일 22시에 인스턴스를 중지하고, 다음 날 08시에 재시작EKS 워커 노드: 22시에 노드 인스턴스를 종료(Scale In)하고, 08시에 다시 생성(Scale Out)문제가 발생한 시점은 08시 EKS 워커 노드가 새로 생성되는 시점이었다. 이때 워커 노드 내의 일부 파드가 Pending 상태로 머물렀으며, ..

들어가기 앞서 현재 운영중인 서비스는 Right Sizing 이후 비용 최적화 및 운영 효율성 측면에서 Gravition 과 Karpenter 도입을 앞두고 있다. 본 포스팅은 아래의 AWS Innovate 영상을 정리한 글이다. Karpenter 의 경우 자세한 내용을 따로 추후 포스팅 하도록 하겠다!https://www.youtube.com/watch?v=yMOaOlPvrgY&t=570s쿠버네티스 클러스터 운영 상 비용 과제MSA 도입의 증가 및 AI/ML 의 데이터 플랫폼의 활용 등 쿠버네티스 활용 용도가 넓어짐에 따라 쿠버네티스의 사용량과 비용 또한 증가하고 있다. 비용 효율성과 성능 및 애플리케이션 가용성 사이에 다음과 같은 세 가지 주요 비용 과제가 있다.팀과 부서간 클러스터 리스소의 비용 할..

들어가기 앞서현재 운영 중인 서비스는 AWS Control Tower 구성으로 되어 있다. Security 계정에 3rd Party 보안 솔루션이 있다. 사용자의 트래픽은 각 계정의 보안 솔루션을 통과하고 최종적으로 Web 서버가 배포되어 있는 계정의 EKS에 먼저 도달한다. EKS 앞에는 NLB와 ALB(istio) 가 있다. 즉, NLB - ALB - EKS 구성으로 트래픽이 전달된다. 문제는 8443 포트의 리스너에서 헬스체크 실패가 발생했다. 최상단의 NLB 에서 시작되는 헬스체크는 EKS 에 도달하여 결과를 반환한다. 즉, NLB의 헬스체크와 ALB의 헬스체크는 모두 EKS 에서 설정한 헬스체크 경로에서 반환한다는 것이다. Readiness Probe 경로 문제인가제일 먼저 짚고 넘어가야 할 점..

들어가기 앞서앞서 NodeSelector, NodeAffinity 및 Taint/Tolerance 와 같은 파드 스케줄링 방식에 대해 확인했습니다. 현재 운영중인 서비스의 개발 및 품질 환경의 EKS 는 매우 낮은 스펙의 인스턴스를 사용하고 있습니다. 또한, 저희는 비용최적화를 위해 Instance Scheduler 를 적용해 매일 22시에 모든 노드 인스턴스가 종료되고 08시에 노드 인스턴스가 새로 생성됩니다. 이러한 과정에서 파드가 재배포되는 과정에서 Replica 가 2개 이상인 Deployment 파드들이 한개의 노드에 몰려서 배치되는 현상이 발생하였고 특정 노드의 리소스 Request 가 할당가능한 양을 초과하여 DaemonSet 파드가 배치되지 않는 결과가 되었습니다. 이를 해결하기 위해 C..

podAntiAffinitypodAntiAffinity는 특정 조건을 만족하는 파드들이 같은 노드 또는 같은 topology 도메인(예: 같은 가용 영역)에 스케줄링되지 않도록 제한하는 기능입니다. 이를 활용하면 동일한 애플리케이션의 파드가 여러 노드에 분산 배치되어 가용성을 높일 수 있습니다.구성 옵션requiredDuringSchedulingIgnoredDuringExecution : 조건에 맞게 스케쥴링을 할 수 없을 때 pending 파드 발생 (hard)동일한 topology(노드, 존 등)에 하나의 파드를 배포하는 것이기 때문에, 존에 대해 podAntiAffinity를 설정하면 zone 당 하나의 파드 생성만 허용되어, 존의 수보다 많은 수의 파드를 배포할 수 없음존에 대해 설정하지 않는 것..

들어가기 앞서앞서 포스팅한 EKS 업그레이드 장애에서 두번째 문제점이 발생했다. 해당 부분에 대한 포스팅을 진행하겠다. https://hyukops.tistory.com/51 EKS 업그레이드 장애 (1) - WARM_IP_TARGET들어가기 앞서현재 운영 중인 개발(DEV), 품질(QA), 운영(PROD) 환경의 EKS 클러스터는 모두 Kubernetes 1.29.0 버전을 사용하고 있다.AWS에서 3월 말부터 1.29.0 버전이 만료되면 추가 요금이 발생하므로 1.31.hyukops.tistory.com 두번째 문제점 발생추가로 CoreDNS 혹은 CSI Driver 등과 같은 EKS 관리형 애드온들의 설치가 진행되지 않았다. coredns에서 지속적으로 AWS VPC network와 udp 통신에 ..

들어가기 앞서현재 운영 중인 개발, 품질 및 운영 환경의 EKS 클러스터는 모두 Kubernetes 1.29.0 버전을 사용하고 있다. AWS에서 3월 말부터 1.29.0 버전이 만료되면 추가 요금이 발생하므로 1.31.0 버전으로 업그레이드를 진행하였다. 업그레이드는 먼저 DEV 환경의 클러스터를 대상으로 수행했으며, 외부망 및 내부망을 포함하여 총 6개의 EKS 클러스터를 업그레이드하였다. 또한, 금융권 특성상 굉장히 철저히 폐쇄망 환경을 유지하여.. 기본적인 인터넷조차 불가능하고 모든 설치파일 등을 파일 형태로 내부 반입하여 보안 점검을 하고 진행하였다.업그레이드 조건커스텀 노드 그룹 사용관리형 노드 그룹이 아닌 커스텀 노드 그룹을 사용한다.보안 소프트웨어가 설치된 Golden Image를 사용해야..