DevOps

커널 수준에서 패킷을 들여다보는 것이 왜 중요한가 쿠버네티스 클러스터를 운영하다 보면 "이 파드 간 통신이 왜 실패하는가"라는 질문 앞에서 막막함을 느낄 때가 있습니다. kubectl logs 에는 아무런 에러가 없고, kubectl describe pod 를 봐도 이상이 없습니다. 그런데 A 서비스가

인프라가 "코드"라면, 그 코드의 상태를 누가 책임지는가 Terraform을 처음 도입한 팀이 가장 빨리 맞닥뜨리는 위기는 terraform apply 를 두 사람이 동시에 실행하는 순간입니다. 우리 팀의 플랫폼 팀에서 정확히 이 상황이 벌어졌습니다. SRE 한 명이 EKS 노드 그룹 스케일아웃을 적용하

클러스터가 10개로 늘어나는 순간, 수동 배포는 채무가 된다 우리 팀이 단일 Kubernetes 클러스터에 하나의 ArgoCD로 운영하던 시절, 배포는 어렵지 않았습니다. dev , staging , prod 네임스페이스를 나누고 ArgoCD Application을 손으로 만들면 됐습니다. 하지만 서비스

Kubernetes에 배포할 때 YAML 파일을 그대로 복사해 환경마다 고치고 있다면, 이미 문제가 시작됐다 우리 팀이 처음 Helm을 도입한 프로젝트는 결제 플랫폼 마이크로서비스 12개를 Kubernetes 위에서 운영하는 환경이었습니다. 초기에는 각 서비스마다 deployment.yaml , serv

컨테이너는 작을수록 안전하다 Dockerfile이 동작한다고 해서 운영에 안전한 이미지는 아닙니다. 빌드 도구, 패키지 매니저, shell, curl, 테스트 파일, 캐시, 심지어 빌드 시 사용한 token이 runtime image에 남는 경우가 많습니다. 이미지는 한 번 registry에 올라가면 여

시크릿은 환경변수에 넣는 순간 끝난 것이 아니다 데이터베이스 비밀번호, API token, OAuth client secret, webhook signing key, cloud access key는 모두 서비스의 혈관입니다. 그런데 많은 팀에서 시크릿 관리는 배포 설정의 부속품처럼 다뤄집니다. .env

오토스케일링은 자동이지만 자동으로 안전해지지는 않는다 Kubernetes를 쓰면 트래픽이 늘어날 때 Pod가 자동으로 늘어나고, 노드가 부족하면 클러스터도 알아서 커질 것처럼 느껴집니다. 실제로 HPA(Horizontal Pod Autoscaler), VPA(Vertical Pod Autoscaler),

장애는 로그 한 줄로 설명되지 않는다 운영 장애를 처음 겪는 팀은 대부분 로그부터 찾습니다. 에러 로그가 있으면 원인이 보일 것이라고 기대합니다. 하지만 실제 장애는 그렇게 친절하지 않습니다. 결제 API의 p95 지연 시간이 300ms에서 3초로 튀었는데 애플리케이션 로그에는 에러가 없습니다. 사용자

Redis는 너무 무거웠다 — stick table을 다시 본 계기 2024년 말, 우리 팀은 B2B SaaS 플랫폼의 API 레이어 앞단을 대대적으로 정비했습니다. 당시 Rate Limiting 구현체는 Redis를 중앙 카운터 저장소로 쓰는 전형적인 구조였습니다. 애플리케이션이 요청을 받을 때마다 R

브라우저가 naver.com에 요청을 보낼 때, 실제로 TCP 연결을 받고 응답을 돌려주는 서버가 naver.com 오리진 서버가 아닐 수 있습니다. 수십 개의 오리진 서버 앞에 조용히 앉아 있는 리버스 프록시가 요청을 받고, SSL을 해제하고, 헤더를 덧붙이고, 가장 한가한 백엔드로 넘겨줍니다. 클라이

1부에서 리버스 프록시가 어떤 원리로 클라이언트와 오리진 사이에 끼어드는지, TCP 커넥션 재사용과 헤더 재작성이 왜 중요한지를 살펴봤다면(리버스 프록시 원리 가이드(1부)), 2부인 이 글에서는 실제 트래픽을 받는 서버를 손으로 세웁니다. 이론을 알고 있어도 설정 파일 한 줄 차이로 서비스가 무너지는

GitHub Actions 혁명: 개발 패러다임을 바꾼 완벽한 자동화 환경 소프트웨어 개발 프로세스에서 "빌드하고 배포하는 일" 은 개발의 본질이면서도, 동시에 가장 개발자를 지치게 만드는 노동이었습니다. 로컬 컴퓨터에서는 잘 돌아가던 코드가 운영 서버에만 올라가면 에러를 뿜어내고, 누군가 테스트 코드를

Git은 현대 소프트웨어 개발의 필수 도구입니다. 기본적인 add, commit, push 명령어는 누구나 알지만, 실무에서 마주하는 복잡한 상황들을 해결하려면 더 깊은 이해가 필요합니다. 이 글에서는 Git의 고급 기능과 실제 팀 개발에서 유용한 워크플로우를 상세히 다룹니다. 1. 브랜치 전략의 이해

장애는 끝난 뒤부터 팀의 실력이 드러난다 서비스 장애가 발생하면 팀은 복구에 집중합니다. 알림이 울리고, 대시보드를 열고, 로그를 뒤지고, 임시 조치를 적용합니다. 하지만 진짜 중요한 일은 장애가 끝난 뒤 시작됩니다. 왜 같은 종류의 장애가 다시 발생하는지, 왜 알림은 많았는데 원인 파악은 늦었는지, 왜

로그는 문자열이 아니라 사건 기록이다 장애가 나면 가장 먼저 로그를 봅니다. 하지만 많은 서비스의 로그는 정작 장애 순간에 도움이 되지 않습니다. "error occurred" 같은 메시지만 남아 있고, 어떤 사용자 요청인지, 어떤 주문인지, 어떤 외부 API 호출과 연결되는지 알 수 없습니다. 반대로