YG Tech Blog

1️⃣ 개요 StatefulSet은 각 Pod가 고유한 ID와 Persistent Volume을 유지하는 특성 때문에 Deployment보다 스케일링이 더 까다롭습니다.특히, StatefulSet의 크기를 조정(스케일링)할 때 발생할 수 있는 데이터 불균형 문제를 해결해야 합니다. 이번 글에서는 StatefulSet의 수직/수평 스케일링 방법과, 데이터 리밸런싱 전략을 포함한 안정적인 운영 방법을 설명하겠습니다. 🚀 2️⃣ StatefulSet 스케일링 방식 StatefulSet을 스케일링하는 방식은 일반적인 Deployment와 다릅니다. • ✅ Pod는 순서대로 추가 및 삭제됨 (pod-0 → pod-1 → pod-2) • ✅ 각 Pod는 고유한 Persistent Volume을 유지함 • ✅ 스케..

1️⃣ 개요 StatefulSet의 특성상 데이터를 저장하는 애플리케이션(예: MySQL, PostgreSQL, Kafka 등)을 운영할 때 롤링 업데이트가 일반적인 Deployment보다 더 까다롭습니다.잘못된 업데이트 전략을 적용하면 데이터 손실, 데이터 불일치, 클러스터 다운타임 등의 문제가 발생할 수 있습니다. 이번 글에서는 StatefulSet의 롤링 업데이트 방법과, 데이터 정합성을 유지하면서 안전하게 업데이트하는 전략을 설명하겠습니다. 🚀 2️⃣ StatefulSet의 롤링 업데이트 원리 ✅ 1. StatefulSet 롤링 업데이트의 특징 • Deployment와 달리 Pod의 종료 및 재배포 순서를 보장함 • Pod가 하나씩 순차적으로 종료되고 업데이트됨 (pod-0 → pod-1 → p..

1️⃣ 개요 StatefulSet을 사용하는 가장 큰 이유 중 하나는 Pod가 재시작되거나 이동하더라도 데이터가 유지되어야 하기 때문입니다.쿠버네티스에서 Persistent Volume(PV)과 Persistent Volume Claim(PVC) 을 활용하면 StatefulSet의 Pod가 데이터를 안전하게 저장하고 유지할 수 있습니다. 이번 글에서는 StatefulSet과 Persistent Volume의 관계, PVC 자동 생성 원리, 데이터 유지 및 삭제 시 고려해야 할 사항을 설명하겠습니다. 🚀 2️⃣ StatefulSet과 Persistent Volume의 관계 ✅ 1. StatefulSet과 Persistent Volume의 동작 원리 StatefulSet을 사용할 때 각 Pod는 고유한 P..

1️⃣ 개요 StatefulSet은 각 Pod가 고유한 네트워크 ID를 유지해야 하는 애플리케이션을 위한 쿠버네티스 리소스입니다.특히 데이터베이스, 메시지 브로커, 캐시 시스템과 같이 노드 간 통신이 필요한 경우 고유한 DNS 주소와 네트워크 정책이 필수적입니다. 이번 글에서는 StatefulSet의 네트워크 관리 방식과, Headless Service를 활용한 Pod 간 통신 방법을 설명하겠습니다. 🚀 2️⃣ StatefulSet의 네트워크 관리 원리 ✅ 1. StatefulSet Pod의 고유 네트워크 ID 일반적인 Deployment의 Pod는 삭제 후 재시작되면 임의의 이름이 부여됩니다.반면, StatefulSet은 각 Pod가 고유한 네트워크 이름을 유지합니다. 📌 StatefulSet Po..

1️⃣ 개요 쿠버네티스에서 데이터를 저장하는 애플리케이션(예: 데이터베이스, 메시지 브로커, 캐시 시스템 등) 은 Pod가 삭제되거나 재시작되더라도 동일한 데이터와 네트워크 ID를 유지해야 합니다.이러한 경우 StatefulSet을 사용해야 합니다. 이번 글에서는 StatefulSet의 개념과 Deployment와의 차이점, 그리고 StatefulSet이 필요한 상황을 정리하겠습니다. 🚀 2️⃣ StatefulSet이란? ✅ 1. StatefulSet의 개념 • StatefulSet은 상태를 유지해야 하는 애플리케이션을 관리하는 컨트롤러 • Pod가 재시작되더라도 고유한 네트워크 ID와 볼륨을 유지 • Persistent Volume (PV)과 연계하여 데이터가 보존되도록 설정 가능 📌 Statefu..

1️⃣ 개요 쿠버네티스에서 애플리케이션을 배포할 때 트래픽을 세밀하게 제어하고, 안전하게 업데이트하는 방법이 필요합니다.특히, Canary Deployment, Blue-Green Deployment, Shadow Deployment 같은 배포 전략을 효과적으로 적용하려면 트래픽을 제어할 수 있는 기술이 필수적입니다. 이를 위해 서비스 메시(Service Mesh) 를 활용하면,✅ 배포 중 트래픽을 Canary 버전과 Stable 버전으로 분배✅ 배포 실패 시 자동 롤백 가능✅ A/B 테스트 및 Shadow Deployment 지원✅ Zero-Trust 네트워크 보안 강화 이번 글에서는 서비스 메시의 개념과, Istio 및 Linkerd를 활용한 배포 제어 방법을 설명하겠습니다. 🚀 2️⃣ 서비스 메시..

1️⃣ 개요 애플리케이션을 운영할 때, 새로운 기능을 배포하더라도 모든 사용자에게 즉시 공개하는 것은 위험할 수 있습니다.이때 Feature Flag(기능 플래그) 를 활용하면, 코드 배포와 기능 활성화를 분리하여 특정 사용자 그룹에게만 새로운 기능을 점진적으로 제공할 수 있습니다. Feature Flag를 활용하면: • ✅ 새로운 기능을 배포하되, 일부 사용자만 활성화 • ✅ 문제가 발생하면 즉시 기능을 비활성화(롤백 없이 기능 차단 가능) • ✅ A/B 테스트, Canary 배포와 결합하여 점진적인 배포 가능 이번 글에서는 Feature Flag의 개념과, Kubernetes 환경에서 Feature Flag를 활용한 동적 배포 방법을 설명하겠습니다. 🚀 2️⃣ Feature Flag란? ✅ 1. F..

1️⃣ 개요 대규모 서비스에서는 단일 Kubernetes 클러스터만으로 모든 애플리케이션을 운영하는 것이 어렵습니다. • 여러 리전(Region) 및 데이터센터에 배포하여 고가용성을 확보해야 할 경우 • 각각의 팀이 독립적으로 운영하는 Kubernetes 클러스터에서 동일한 애플리케이션을 배포해야 할 경우 • 재해 복구(Disaster Recovery, DR) 환경을 구축해야 할 경우 이때 필요한 것이 Multi-Cluster Deployment(다중 클러스터 배포) 전략입니다.이 전략을 활용하면 여러 Kubernetes 클러스터에서 애플리케이션을 효율적으로 배포하고 운영할 수 있습니다. 이번 글에서는 Multi-Cluster Deployment의 개념과, GitOps 및 Kubernetes Federa..

1️⃣ 개요 기존의 Canary Deployment, Blue-Green Deployment는 일정한 트래픽 비율을 기반으로 배포를 진행하지만,Progressive Delivery(점진적 배포) 는 실제 사용자 경험과 트래픽 데이터에 따라 배포 속도를 동적으로 조정하는 전략입니다. 이 방식은 A/B 테스트, 자동 롤백, 지속적인 트래픽 분석과 결합하여, 배포의 안정성을 더욱 높일 수 있는 현대적인 배포 방식입니다. 이번 글에서는 Progressive Delivery의 개념과, 쿠버네티스 환경에서 Argo Rollouts, Flagger 같은 도구를 활용하여 적용하는 방법을 설명하겠습니다. 🚀 2️⃣ Progressive Delivery란? ✅ 1. Progressive Delivery의 개념 • 기존 ..

1️⃣ 개요 실제 운영 환경에서 새로운 애플리케이션 버전이 예상과 다르게 동작할 가능성이 있습니다.특히, 새로운 버전이 기존 시스템과 잘 동작하는지 검증하는 것이 중요하지만, Canary나 Blue-Green 방식으로 배포하더라도 실제 사용자 요청을 받으면서 테스트하기에는 위험이 따릅니다. 이때 활용할 수 있는 배포 전략이 Shadow Deployment(섀도우 배포) 입니다.Shadow Deployment는 실제 트래픽을 복제하여 새로운 버전에 전달하면서도, 사용자의 응답에는 영향을 주지 않는 방식입니다.이를 통해 실제 트래픽을 기반으로 새로운 버전을 검증할 수 있으며, 문제 발생 시 서비스에 영향을 주지 않고 분석할 수 있습니다. 이번 글에서는 Shadow Deployment의 개념과, 쿠버네티스 환..