230's

ArgoCd는 GitOps 도구로 항상 Git 저장소의 상태(Desired State, 원하는 상태)와 실제 클러스터 상태(Live State, 현재상태)를 똑같이 일치시키려고 감시한다.OutOfSync는 내가 깃헙에 올려둔 코드랑 실제 쿠버네티스 클러스터에 배포되어 있는 상태가 서로 다를 때를 말한다.이때 Sync(동기화) 버튼을 누르거나(CLI로 Sync하거나) 자동 동기화(Auto-Sync)가 작동하면 Synced로 바뀐다.이번 케이스는 Synced가 안되는 상황 중 하나를 트러블슈팅한 것이다.배경 및 문제상황발생 일자: 2026-05-14재현 일자: 2026-05-29shoong-delivery의 GitOps 파이프라인을 처음 셋업하던 중이었다. 4개 MSA 서비스(order/kitchen/del..

배경 및 문제상황발생 일자: 2026-05-19배경EKS 클러스터에 관측성(Observability) 스택을 얹는 작업을 하고 있었다.로그 수집은 Loki, 트레이스 수집은 Tempo를 쓰기로 하고, 두 컴포넌트를 ArgoCD 애플리케이션으로 정의해 monitoring 네임스페이스에 배포했다.솔직히 이때는 수집한 로그,트레이스가 어디에 어떻게 저장되는지까지 깊게 따져보지않았다.이 컴포넌트들이 떠있으려면 별도의 영구 볼륨을 먼저 붙여야 한다는 것을 잊고 있었다.변명하자면 이제 막 초기 셋팅 진행 중이라 정신 없어서 신경 쓸 겨를이 없었다.문제상황ArgoCD가 Sync를 끝냈는데도 Loki/Tempo Pod가 Running으로 넘어가지 못하고계속 Pending 상태에 머물렀다. 시간이 지나도 Running이..

들어가며서비스가 어느 정도 안정적으로되면서 자연스럽게 다음 스텝인 운영 고도화에 눈이 가기 시작했다. 서비스가 단순히 뜨는 것을 넘어 얼마나 버틸 수 있을지 궁금해졌다.트래픽이 10 RPS, 20 RPS로 올라갈 때 응답 시간(Latency)은 안정적으로 유지되는가?설정해 둔 HPA가 제때 발동하는가? 발동한다면 새로운 Pod이 뜨기까지 몇 초나 걸리는가?만약 시스템이 무너진다면 그 임계점은 어디인가? 앱 서버가 먼저 뻗을까? DB가 먼저 뻗을까?용어 정리RPS (Requests Per Second): 초당 요청 수. "이 서비스가 1초에 몇 건을 처리하는가"를 재는 결과 지표. 성능테스트가 보려는 값.VU (Virtual User): 가상 사용자 한 명. 부하 도구가 띄우는 동시 사용자 단위로, 한 V..

들어가며보안을 어디까지 챙겨야 할까? 과하면 업무 효율을 떨어뜨리는 과잉 규제가 되고, 미흡하면 기본적인 관리 소홀로 이어지기 때문이다. 실무에서 같은 인프라를 짠다면 어디서 멈출지를 계속 떠올리면서 선을 잡아갔다.먼저 시스템에 고정된 비밀번호나 인증 키를 남기지 않는 것을 목표로 잡았다. AWS Access Key, SSH 키, kubeconfig 같은 중요한 인증 정보를 설정에 고정으로 심어두지 않는 방식이다. 실제 운영 환경에서 이런 고정 키가 유출돼서 일어나는 경우가 많을테니 유출될 만한 키 자체를 애초에 만들지 않는 게 가장 확실한 보안이라고 생각했다.이것을 출발점으로 잡고 Edge → Network → IAM → App 4계층으로 나눠서 보안 설계를 했다. 1. Edge — WAF + Clou..

들어가며EKS 위에 마이크로서비스 5개(order, kitchen, delivery, notification, batch)를 올린 후 주문이 느려진 경우가 있었는데 어느 서비스에서 지연되는지 알 수 없는 문제가 생겼다.처음엔 kubectl logs -f -l app=shoong-order로 로그를 보려고 했다. order는 replicaCount가 2였고 --prefix로 Pod 구분은 할 수 있었지만 같은 시간대에 들어온 다른 주문 로그 사이에서 그 요청 한 건에 해당하는 줄들을 골라서 보기 어려웠다. 어찌저찌 order Pod를 찾아 본다고 해도 order는 kitchen, kitchen은 delivery, delivery는 notification을 부른다. 터미널을 네 개 열어 kubectl log..

들어가며Shoong Delivery를 EKS 위에 올리면서 제일 먼저 생각난 건 어떻게 열고 어디까지 막아야하는가 였다.처음에는 VPC 하나 만들고, EKS 만들고, ALB 붙이면 끝날 줄 알았다. 그런데 막상 Terraform으로 하나씩 만들다 보니 네트워크 설계가 거의 모든 리소스의 기준점이 됐다.ALB는 어디에 둘 것인가EKS Worker Node는 인터넷에 직접 노출되지 않아도 되는가RDS는 어떤 경로로만 접근하게 할 것인가Private Subnet의 노드가 ECR, SSM, EKS API에는 어떻게 접근할 것인가비용 때문에 dev와 prod를 어디까지 다르게 가져갈 것인가이번 글은 Shoong Delivery에서 실제로 구성한 VPC, Subnet, Route Table, NAT Gateway,..

들어가며처음에는 배포 과정을 전부 수동으로 했다.Terraform으로 EKS, RDS, CloudFront 같은 인프라를 만들고 나면 그걸로 끝일 줄 알았다. 그런데 실제로는 terraform apply가 끝난 뒤에도 해야 할 일이 많았다. EKS에 접속해야 했고, Terraform output으로 나온 값을 GitOps 레포에 반영해야 했고, ArgoCD를 설치해야 했고, ESO를 붙여야 했고, DB 접속 확인과 초기 데이터 삽입까지 해야 했다!게다가 이 프로젝트는 AWS 비용을 줄이려고 작업이 끝나면 매일 밤 terraform destroy를 하고 다음 작업 때 다시 terraform apply를 하는 방식으로 운영했다. 인프라를 매번 새로 만들다 보니 VPC ID, CloudFront Distrib..

테라폼으로 인프라 처음부터 짜보기 — shoong-delivery들어가며테라폼은 인터넷 강의랑 공식 문서 보면서 공부했다. 예제 따라치는 거 말고 프로젝트 인프라를 IaC로 깐 건 이번이 처음이었다. 단순히 동작하는 코드를 만들기보다는 실무에서 이 코드를 누가 받아서 운영한다면? 을 계속 떠올리면서 구조를 짰다. 이 글은 그 과정에서 내가 했던 선택과 그 이유를 정리한 글이다.레포: shoong-terraform (배달 서비스 인프라 — VPC, EKS, RDS, ALB, CloudFront 등 다 들어 있다)디렉토리 구조부터shoong-terraform/├── bootstrap/ # state 백엔드 자체를 만드는 별도 프로젝트│ ├── main.tf # S3 + ..

들어가며EKS 위에 마이크로서비스를 올릴 때 가장 먼저 고민된 부분이 있었다."외부 트래픽을 어떻게 받고, 서비스끼리는 어떻게 통신시킬 것인가?"단순히 "Ingress 하나 만들면 되는 거 아냐?" 라고 생각했다가, 선택지가 생각보다 많다는 걸 알게 됐다. 그리고 조합도 너무 많았다......이 글은 각 게이트웨이를 비교하고, 최종적으로 ALB + Istio 를 선택한 이유와, 그로 인해 만들어진 트래픽 흐름을 정리한다.1. 후보 기술 정리: 각 레이어에 뭐가 있는가조합을 따져보기 전에 각 레이어에서 후보로 둘 만한 기술들의 특성을 먼저 정리한다. 트래픽이 인터넷에서 서비스 Pod까지 도달하려면 보통 세 개의 레이어를 거친다.인터넷 → [① 로드밸런서] → [② 클러스터 내부 라우팅] → [③ 서비스 간..

Kubernetes Architecture Design Logv0.1 - 초기 구조구성 요소EKS Control Plane (ETCD, Cloud Controller Manager, Controller Manager, K8s API Server, Scheduler)워커 노드 3개 (az a, az b, az c)Ingress ALBNamespace: argocd, todo-apptodo-app: frontend, auth, projects, tasks, notificationIstio 사이드카 인젝션 적용 (todo-app 네임스페이스)문제점ArgoCD가 감지할 GitOps Repository 연결 안됨ArgoCD -> todo-app 배포 흐름 표현 안됨v0.2 - GitOps 연결구성 요소GitOps..