https://waylog.pages.dev/category/devops Waylog Blog의 DevOps 카테고리에 속한 글 모음 ko-KR Thu, 21 May 2026 13:50:29 GMT Mon, 09 Mar 2026 00:00:00 GMT Next.js https://waylog.pages.dev/posts/ebpf-network-observability-cilium-intro https://waylog.pages.dev/posts/ebpf-network-observability-cilium-intro Mon, 09 Mar 2026 00:00:00 GMT DevOps 커널 수준에서 패킷을 들여다보는 것이 왜 중요한가 쿠버네티스 클러스터를 운영하다 보면 "이 파드 간 통신이 왜 실패하는가"라는 질문 앞에서 막막함을 느낄 때가 있습니다. kubectl logs에는 아무런 에러가 없고, kubectl describe pod를 봐도 이상이 없습니다. 그런데 A 서비스가 B 서비스를 호출하면 간헐적으로 연결이 끊깁니다. 우리 팀은 수백 개의 파드가 뜨고 지는 대용량 클러스터에서 정확히 이 상황을 마주했습니다. 결국 원인은 iptables NAT 테이블의 conntrac https://waylog.pages.dev/posts/terraform-state-remote-backend-locking https://waylog.pages.dev/posts/terraform-state-remote-backend-locking Thu, 19 Feb 2026 00:00:00 GMT DevOps 인프라가 "코드"라면, 그 코드의 상태를 누가 책임지는가 Terraform을 처음 도입한 팀이 가장 빨리 맞닥뜨리는 위기는 terraform apply를 두 사람이 동시에 실행하는 순간입니다. 우리 팀의 플랫폼 팀에서 정확히 이 상황이 벌어졌습니다. SRE 한 명이 EKS 노드 그룹 스케일아웃을 적용하는 동안, 다른 팀원이 보안 그룹 규칙을 추가했습니다. 두 작업 모두 성공한 것처럼 보였지만, 이후 terraform plan을 실행하자 누가 만든 것인지 모를 리소스 diff가 수십 줄씩 쏟아졌습니 https://waylog.pages.dev/posts/argocd-app-of-apps-gitops-repo-structure https://waylog.pages.dev/posts/argocd-app-of-apps-gitops-repo-structure Fri, 23 Jan 2026 00:00:00 GMT DevOps 클러스터가 10개로 늘어나는 순간, 수동 배포는 채무가 된다 우리 팀이 단일 Kubernetes 클러스터에 하나의 ArgoCD로 운영하던 시절, 배포는 어렵지 않았습니다. dev, staging, prod 네임스페이스를 나누고 ArgoCD Application을 손으로 만들면 됐습니다. 하지만 서비스가 성장하면서 리전이 늘었고, 보안 정책상 퍼블릭 클라우드 클러스터와 온프레미스 클러스터를 분리해야 했으며, SRE 팀과 개발팀의 배포 권한을 격리해야 하는 요구가 생겼습니다. 클러스터가 7개를 넘어섰 https://waylog.pages.dev/posts/helm-chart-values-templating-best-practices https://waylog.pages.dev/posts/helm-chart-values-templating-best-practices Wed, 14 Jan 2026 00:00:00 GMT DevOps Kubernetes에 배포할 때 YAML 파일을 그대로 복사해 환경마다 고치고 있다면, 이미 문제가 시작됐다 우리 팀이 처음 Helm을 도입한 프로젝트는 결제 플랫폼 마이크로서비스 12개를 Kubernetes 위에서 운영하는 환경이었습니다. 초기에는 각 서비스마다 deployment.yaml, service.yaml, configmap.yaml을 직접 작성했고, 환경이 dev·staging·production으로 나뉘면서 관리해야 할 YAML 파일이 36개를 넘어섰습니다. image tag 하나 https://waylog.pages.dev/posts/container-image-hardening-sbom-distroless https://waylog.pages.dev/posts/container-image-hardening-sbom-distroless Fri, 07 Nov 2025 00:00:00 GMT DevOps 컨테이너는 작을수록 안전하다 Dockerfile이 동작한다고 해서 운영에 안전한 이미지는 아닙니다. 빌드 도구, 패키지 매니저, shell, curl, 테스트 파일, 캐시, 심지어 빌드 시 사용한 token이 runtime image에 남는 경우가 많습니다. 이미지는 한 번 registry에 올라가면 여러 환경으로 복제되고, 취약점 스캐너와 감사 대상이 됩니다. 작은 실수 하나가 공급망 보안 이슈가 됩니다. 컨테이너 이미지 하드닝의 목표는 공격 표면을 줄이고, 이미지 출처를 검증 가능하게 만들고, https://waylog.pages.dev/posts/production-secret-management-rotation-vault https://waylog.pages.dev/posts/production-secret-management-rotation-vault Wed, 17 Sep 2025 00:00:00 GMT DevOps 시크릿은 환경변수에 넣는 순간 끝난 것이 아니다 데이터베이스 비밀번호, API token, OAuth client secret, webhook signing key, cloud access key는 모두 서비스의 혈관입니다. 그런데 많은 팀에서 시크릿 관리는 배포 설정의 부속품처럼 다뤄집니다. .env 파일을 만들고, CI 변수에 넣고, Kubernetes Secret으로 배포하면 끝이라고 생각합니다. 문제는 시크릿의 진짜 운영이 그 다음부터 시작된다는 점입니다. 시크릿은 언젠가 유출됩니다. 로그 https://waylog.pages.dev/posts/kubernetes-autoscaling-hpa-vpa-keda-production https://waylog.pages.dev/posts/kubernetes-autoscaling-hpa-vpa-keda-production Tue, 02 Sep 2025 00:00:00 GMT DevOps 오토스케일링은 자동이지만 자동으로 안전해지지는 않는다 Kubernetes를 쓰면 트래픽이 늘어날 때 Pod가 자동으로 늘어나고, 노드가 부족하면 클러스터도 알아서 커질 것처럼 느껴집니다. 실제로 HPA(Horizontal Pod Autoscaler), VPA(Vertical Pod Autoscaler), Cluster Autoscaler, KEDA 같은 도구는 훌륭합니다. 하지만 운영에서 오토스케일링은 "켜면 끝"이 아니라, 여러 제어 루프가 서로 충돌하지 않도록 설계하는 일에 가깝습니다. 우리 https://waylog.pages.dev/posts/opentelemetry-production-observability-slo-tracing https://waylog.pages.dev/posts/opentelemetry-production-observability-slo-tracing Sun, 03 Aug 2025 00:00:00 GMT DevOps 장애는 로그 한 줄로 설명되지 않는다 운영 장애를 처음 겪는 팀은 대부분 로그부터 찾습니다. 에러 로그가 있으면 원인이 보일 것이라고 기대합니다. 하지만 실제 장애는 그렇게 친절하지 않습니다. 결제 API의 p95 지연 시간이 300ms에서 3초로 튀었는데 애플리케이션 로그에는 에러가 없습니다. 사용자 일부만 로그인에 실패하는데 인증 서비스는 200 응답을 반환합니다. 특정 지역에서만 이미지 업로드가 느린데 서버 CPU는 정상입니다. 이런 상황에서 로그만 뒤지는 방식은 금방 한계에 부딪힙니다. 관 https://waylog.pages.dev/posts/haproxy-stick-table-session-affinity-deep-dive https://waylog.pages.dev/posts/haproxy-stick-table-session-affinity-deep-dive Mon, 21 Jul 2025 00:00:00 GMT DevOps Redis는 너무 무거웠다 — stick-table을 다시 본 계기 2024년 말, 우리 팀은 B2B SaaS 플랫폼의 API 레이어 앞단을 대대적으로 정비했습니다. 당시 Rate Limiting 구현체는 Redis를 중앙 카운터 저장소로 쓰는 전형적인 구조였습니다. 애플리케이션이 요청을 받을 때마다 Redis에 INCR을 치고, TTL을 확인하고, 한도 초과 여부를 판단했습니다. 이론적으로는 깔끔해 보였지만, 실제 운영에서는 두 가지 문제가 누적됐습니다. 첫째, Redis 클러스터 레이턴시가 카 https://waylog.pages.dev/posts/reverse-proxy-internals https://waylog.pages.dev/posts/reverse-proxy-internals Fri, 13 Jun 2025 00:00:00 GMT DevOps 브라우저가 naver.com에 요청을 보낼 때, 실제로 TCP 연결을 받고 응답을 돌려주는 서버가 naver.com 오리진 서버가 아닐 수 있습니다. 수십 개의 오리진 서버 앞에 조용히 앉아 있는 리버스 프록시가 요청을 받고, SSL을 해제하고, 헤더를 덧붙이고, 가장 한가한 백엔드로 넘겨줍니다. 클라이언트는 이 중간 행위자의 존재를 전혀 알지 못합니다. 저희가 DevOps 실무에서 Nginx와 HAProxy를 다루다 보면, 리버스 프록시가 단순한 포워딩 장치가 아니라 트래픽 처리의 핵심 결정 지 https://waylog.pages.dev/posts/reverse-proxy-nginx-haproxy-setup https://waylog.pages.dev/posts/reverse-proxy-nginx-haproxy-setup Fri, 06 Jun 2025 00:00:00 GMT DevOps 1부에서 리버스 프록시가 어떤 원리로 클라이언트와 오리진 사이에 끼어드는지, TCP 커넥션 재사용과 헤더 재작성이 왜 중요한지를 살펴봤다면(리버스 프록시 원리 가이드(1부)), 2부인 이 글에서는 실제 트래픽을 받는 서버를 손으로 세웁니다. 이론을 알고 있어도 설정 파일 한 줄 차이로 서비스가 무너지는 경험은 누구나 합니다. 우리 팀도 그랬습니다. WebSocket 프록시에서 proxyhttpversion 1.1을 빠뜨려 모든 실시간 연결이 101 Switching Protocols 단계에서 끊겼 https://waylog.pages.dev/posts/github-actions-cicd-guide https://waylog.pages.dev/posts/github-actions-cicd-guide Sat, 03 May 2025 00:00:00 GMT DevOps GitHub Actions 혁명: 개발 패러다임을 바꾼 완벽한 자동화 환경 소프트웨어 개발 프로세스에서 "빌드하고 배포하는 일"은 개발의 본질이면서도, 동시에 가장 개발자를 지치게 만드는 노동이었습니다. 로컬 컴퓨터에서는 잘 돌아가던 코드가 운영 서버에만 올라가면 에러를 뿜어내고, 누군가 테스트 코드를 실행하지 않고 병합(Merge)해버려 전체 메인 브랜치가 마비되는 상황을 우리는 수없이 겪어왔습니다. 이러한 고통을 해결하기 위해 CI/CD(지속적 통합/지속적 배포)의 개념이 등장했고, Jenki https://waylog.pages.dev/posts/57 https://waylog.pages.dev/posts/57 Tue, 17 Dec 2024 00:00:00 GMT DevOps Git은 현대 소프트웨어 개발의 필수 도구입니다. 기본적인 add, commit, push 명령어는 누구나 알지만, 실무에서 마주하는 복잡한 상황들을 해결하려면 더 깊은 이해가 필요합니다. 이 글에서는 Git의 고급 기능과 실제 팀 개발에서 유용한 워크플로우를 상세히 다룹니다. 1. 브랜치 전략의 이해 1.1 Git Flow vs GitHub Flow Git Flow는 Vincent Driessen이 제안한 전통적인 브랜치 전략입니다. main(또는 master), develop, feature, https://waylog.pages.dev/posts/incident-postmortem-runbook-alert-fatigue https://waylog.pages.dev/posts/incident-postmortem-runbook-alert-fatigue Thu, 29 Aug 2024 00:00:00 GMT DevOps 장애는 끝난 뒤부터 팀의 실력이 드러난다 서비스 장애가 발생하면 팀은 복구에 집중합니다. 알림이 울리고, 대시보드를 열고, 로그를 뒤지고, 임시 조치를 적용합니다. 하지만 진짜 중요한 일은 장애가 끝난 뒤 시작됩니다. 왜 같은 종류의 장애가 다시 발생하는지, 왜 알림은 많았는데 원인 파악은 늦었는지, 왜 대응자가 매번 같은 명령을 검색해야 했는지 돌아봐야 합니다. 장애 회고는 누군가를 비난하는 문서가 아닙니다. 시스템이 어떤 조건에서 실패했고, 팀의 관측성과 절차가 어디서 부족했는지 확인하는 과정 https://waylog.pages.dev/posts/logging-structured-context-correlation-id https://waylog.pages.dev/posts/logging-structured-context-correlation-id Wed, 21 Aug 2024 00:00:00 GMT DevOps 로그는 문자열이 아니라 사건 기록이다 장애가 나면 가장 먼저 로그를 봅니다. 하지만 많은 서비스의 로그는 정작 장애 순간에 도움이 되지 않습니다. "error occurred" 같은 메시지만 남아 있고, 어떤 사용자 요청인지, 어떤 주문인지, 어떤 외부 API 호출과 연결되는지 알 수 없습니다. 반대로 너무 많은 로그가 쌓여 중요한 신호가 묻히기도 합니다. 좋은 로그는 사람이 읽을 수 있으면서도 시스템이 검색하고 집계할 수 있어야 합니다. 그래서 구조적 로깅이 필요합니다. JSON 형태로 time