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

Istio 1.28 업그레이드를 고려하는 사용자를 위해 참고용으로 본 글을 작성한다. (본인이 1.28 업그레이드 과정에 겪은 현상이기 때문) istioctl 1.28 를 설치하면 일부 명령어의 동작 방식이 이전 버전과 다르게 수행되는 것을 확인할 수 있다.> istioctl proxy-statusError: no running Istio pods in "istio-system"> istioctl versionIstio is not present in the cluster: no running Istio pods in namespace "istio-system"client version: 1.28.2 상태 확인을 원하는 istio proxy 버전의 revision 및 namespace 를 명시하여 실행할..

서비스 메시와 사이드카 패턴사이드카 패턴은 애플리케이션 컨테이너와 함께 프록시 컨테이너를 배포하는 방식이다. 그러나 Kubernetes는 오랫동안 사이드카 컨테이너를 공식적으로 지원하지 않아, Job이 종료되어도 사이드카가 계속 실행되며 Pod가 종료되지 않는 문제가 발생했다. 이 문제를 해결하기 위한 논의는 2019년에 시작되었고, Kubernetes 1.28에서 알파 단계의 네이티브 사이드카 지원이 도입되었다. Istio는 이미 해당 기능을 구현했으며, 이를 활용하는 방법을 다루는 내용이다.사이드카의 고충사이드카 컨테이너는 강력하지만, Kubernetes에서는 모든 컨테이너를 동일한 생명주기로 취급하기 때문에 구조적인 문제가 발생한다. Pod 내 컨테이너들은 일부 리소스를 공유할 수는 있으나, 생명주..

들어가기 앞서EKS 환경에서 Istio를 1.26에서 1.27로 업그레이드(1.26 → 1.27)하는 과정에서 발생한 이슈를 시나리오 기반으로 정리한다. EKS 클러스터 버전은 1.33으로 고정된 상태에서 Istio 버전만 업그레이드한 사례를 기준으로 한다. 업그레이드 과정에서 변경된 istioctl 명령어 옵션과 1.27부터 도입된 Native Sidecar 적용 사항을 중심으로 다룬다. 각 버전 전환 시점에서 실제로 문제가 발생했던 지점을 구분하고, 원인 분석과 함께 해결 방법을 단계별로 설명한다.EKS : 1.33 Istio : 1.26 -> 1.27 Istio 1.26 Operator 설치Istio 설치는 Helm이나 istioctl 커맨드 라인을 통한 직접 설치 방식이 아니라, 필요한 옵션을 사..

들어가기 앞서CloudFront는 인터넷을 통해 ALB의 퍼블릭 DNS로 요청을 보내므로 ALB는 인터넷 접근이 가능해야 한다. Private 서브넷의 ALB는 VPC 내부에만 존재하므로 CloudFront가 직접 오리진으로 연결할 수 없다. 따라서 CloudFront 오리진으로 사용하려면 ALB를 퍼블릭 서브넷에 두어 외부 요청을 받을 수 있게 해야 한다. 이때 CloudFront를 오리진으로 설정한 상황에서 클라이언트가 CloudFront를 우회해 ALB에 직접 접근하지 못하도록 완전하게 차단해야 한다.VPC Origin 을 사용하는 방법VPC Origin 기능은 2024년 11월에 출시되었습니다. CloudFront VPC Origin은 ALB를 프라이빗 서브넷에 두고 CloudFront만 접근하도..

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, 컨테이너 등)이 런타임에 비밀번호/토큰을 조회해야 하는 경우.주기적 로테이션이 필요해 사람이 직접 교체하기 번거로운 자격증명.여러 서비스가 동일 자격증..

들어가기 앞서istio proxy 의 access log 를 활성화 하였다. 크게 Telemetry API 를 사용하는 방법과 Mesh Config 를 사용하는 방법이 있는데, 필자의 경우 후자(Mesh Config)를 이용해 활성화 하였다.https://hyukops.tistory.com/140 [istio] istio 의 Access Log 활성화들어가기 앞서파드를 재배포하며 Rolling Update를 수행하는 과정에서, APM 모니터링을 통해 일시적으로 응답 속도가 지연되는 현상을 확인하였다. 이 현상은 Istio proxy(Envoy)가 종료 중인 파드보다 먼hyukops.tistory.comIstioOperator 를 이용해 적용하였으며 이를 적용하는 방법에 대한 YAML 은 아래와 같다kub..

들어가기 앞서Amazon MSK 업그레이드에 대한 메커니즘, 업그레이드 방안 및 모범 사례는 아래 포스팅을 확인해주세요https://hyukops.tistory.com/158 [AWS] MSK 업그레이드 (Console & Terraform)들어가기 앞서MSK 업그레이드 메커니즘, 고려 사항과 Best Practice 에 대해 알아보겠습니다.Amazon MSK 업그레이드 메커니즘Amazon MSK는 소프트웨어에 대한 롤링 업데이트 방식을 통해 클러스터의 고가hyukops.tistory.comMSK 업그레이드 이슈Terraform을 사용하여 Amazon MSK 클러스터를 업그레이드하는 방법은 매우 간단합니다. 단지 kafka_version 값을 새로운 버전으로 변경하면 됩니다. 그러나 단순히 버전만 변경하..

들어가기 앞서MSK 업그레이드 메커니즘, 고려 사항과 Best Practice 에 대해 알아보겠습니다.Amazon MSK 업그레이드 메커니즘Amazon MSK는 소프트웨어에 대한 롤링 업데이트 방식을 통해 클러스터의 고가용성을 유지합니다. 이 과정에서 브로커는 한 번에 하나씩 재부팅되며, Kafka는 자동으로 리더십을 다른 온라인 브로커로 이전합니다. Kafka 클라이언트는 이러한 리더십 변화를 자동으로 감지하여, 업데이트 중에도 MSK 클러스터에 대한 데이터 읽기와 쓰기를 지속할 수 있는 메커니즘을 갖추고 있습니다.구성 변경 시 브로커가 일시적으로 오프라인 상태가 되면, 클라이언트에서 간헐적인 연결 해제 오류가 발생할 수 있습니다. 이는 정상적인 현상입니다. 또한 짧은 시간(최대 2분, 일반적으로 그보..