동블

그래프 뷰

91. Web Operations 실전 가이드북

75 min read

Web Operations 실전 가이드북

이 가이드북을 통해 아래 질문들에 답할 수 있게 됩니다.

  • 운영 장애, 배포 실패, 관측, 복구 상황에서 어떤 기존 문서를 다시 열어야 하는가?
  • Web Operations의 모든 기존 문서가 어떤 실전 Case와 연결되는가?
  • 학습 내용을 실제 운영 판단으로 바꾸려면 어떤 증거를 먼저 확인해야 하는가?

이 가이드북을 쓰는 방법

이 문서는 Web Operations 문서들을 다시 요약하는 문서가 아니다.

운영 상황을 하나씩 던지고, 그 상황에서 어떤 문서를 다시 열어야 하는지 안내하는 실전 가이드북이다.

읽는 순서는 단순하다.

  1. 지금 겪는 상황과 가장 가까운 Case를 고른다.
  2. 관찰할 증거 또는 확인할 단서를 보고 지금 가진 정보가 충분한지 확인한다.
  3. 먼저 생각해보기 질문에 답해 본다.
  4. 찾아볼 문서 링크를 따라가 기존 문서를 다시 읽는다.
  5. 가져갈 한 문장을 자기 말로 바꿔 적는다.

중요한 것은 한 번에 모든 문서를 외우는 것이 아니다.

실제 상황에서 “지금은 어느 문서를 다시 봐야 하는가”를 빠르게 판단하는 것이다.

커버리지 지도

기존 문서연결된 Case다시 읽어야 하는 이유
00. Web Operations 전체 지도 압축 정리24전체 운영 흐름과 학습 순서를 다시 잡기 위해
01. 개발에서 운영까지 전체 흐름 상세1, 24코드가 실제 트래픽을 받기까지의 경로를 확인하기 위해
02. Build Deploy Observe Recover 지도 상세1, 24장애를 build/deploy/observe/recover 단계로 나누기 위해
03. 백엔드와 인프라 역할 경계 상세13, 14, 24장애 중 백엔드와 인프라가 나눠 볼 자료를 정리하기 위해
04. 개인 프로젝트와 기업 운영 수준 비교 상세19, 24개인 프로젝트와 팀 운영의 기준 차이를 판단하기 위해
05. Web Operations 학습 로드맵 상세19, 24전체 학습 순서를 실습 계획으로 바꾸기 위해
00. Linux Server 운영 기본 압축 정리2서버에서 먼저 나눠 볼 계층을 잡기 위해
01. User Permission Process 기본 상세2실행 사용자, 권한, 프로세스 문제를 분리하기 위해
02. Service systemd 관리 상세2Spring 서비스를 process manager 관점에서 확인하기 위해
03. Port Firewall SSH 기본 상세2, 5, 22port, firewall, SSH, upstream 경로를 구분하기 위해
04. Log Disk Resource 점검 상세2, 8서버 로그, 디스크, CPU, memory 신호를 읽기 위해
05. 운영 서버에서 조심할 명령 상세2장애 중 증거를 지우는 변경 명령을 피하기 위해
00. Build Artifact Config Profile 압축 정리3, 6release와 설정 출처의 큰 그림을 잡기 위해
01. Build Artifact와 Release 단위 상세1, 6jar/image/tag/digest와 release 단위를 구분하기 위해
02. Spring Profile과 Environment 상세3, 18active profile과 property source 문제를 확인하기 위해
03. Config Secret 분리 상세3, 16config와 secret의 경계를 안전하게 유지하기 위해
04. Config Drift와 재현 가능한 배포 상세3, 23문서 값과 실제 운영 값의 drift를 찾기 위해
05. 배포 전 설정 체크리스트 상세1, 23배포 전 중단 조건과 설정 점검을 만들기 위해
00. Docker Image Container Volume Network 압축 정리4, 5Docker 장애를 image/container/volume/network로 나누기 위해
01. Dockerfile Layer와 Image 상세4, 6image 재현성과 tag/digest 문제를 확인하기 위해
02. Container Lifecycle 상세2, 4container 상태와 재시작 전 증거 보존을 판단하기 위해
03. Volume과 데이터 보존 상세4, 12container 교체와 데이터 보존을 분리하기 위해
04. Docker Network와 Port Mapping 상세5host port, container port, upstream을 맞추기 위해
05. Docker 장애 디버깅 상세4, 5Docker 장애를 안전한 순서로 좁히기 위해
00. Docker Compose와 로컬 운영 환경 압축 정리3, 19로컬 운영 환경의 재현성 기준을 잡기 위해
01. Compose Service Network Volume 상세3, 4service/network/volume을 로컬 운영 단위로 이해하기 위해
02. Spring MySQL Redis 로컬 환경 상세3, 19Spring과 의존 서비스를 함께 띄우는 기준을 확인하기 위해
03. 환경 변수와 Secret 주입 상세3, 16Compose 환경 변수와 secret 주입 실수를 줄이기 위해
04. Healthcheck와 의존성 순서 상세3, 9depends_on과 readiness 착각을 줄이기 위해
05. 로컬 운영 환경 재현성 상세19, 24개인 실습 환경을 다시 만들 수 있게 하기 위해
00. Nginx Reverse Proxy Static TLS 압축 정리5, 12프록시, 정적 파일, TLS 경계를 한 번에 보기 위해
01. Reverse Proxy와 Upstream 상세5502/504와 upstream 경로를 구분하기 위해
02. Static Serving과 Cache Header 상세12정적 파일 cache와 배포 순서 문제를 확인하기 위해
03. TLS Termination과 인증서 상세5TLS와 인증서 문제가 애플리케이션 장애처럼 보일 때 확인하기 위해
04. Timeout Buffer Body Size 설정 상세5timeout, upload size, buffering으로 생기는 장애를 보기 위해
05. Nginx 로그와 장애 디버깅 상세5, 8access/error log로 요청 도달 여부를 판단하기 위해
00. CI CD Pipeline 압축 정리6, 23pipeline을 build/test/deploy 단계로 보기 위해
01. CI와 CD 단계 분리 상세6검증 실패와 배포 실패를 분리하기 위해
02. Build Test Package Pipeline 상세6build, test, package 산출물을 확인하기 위해
03. Artifact Version Tagging 상세6배포된 버전을 추적 가능하게 만들기 위해
04. Secret과 배포 권한 관리 상세6, 16CI/CD 권한과 secret 노출을 통제하기 위해
05. 실패한 Pipeline 대응 상세6, 23실패한 pipeline을 새 실패로 덮지 않기 위해
00. 배포 전략 Rolling Blue-Green Canary 압축 정리7, 21배포 전략별 실패 반경을 비교하기 위해
01. Rolling Deployment 상세7점진 교체 중 capacity와 readiness를 보기 위해
02. Blue-Green Deployment 상세7두 환경 전환과 rollback 조건을 판단하기 위해
03. Canary와 점진적 트래픽 전환 상세7작은 트래픽에서 지표를 보고 중단하기 위해
04. Rollback과 Database 변경 호환성 상세1, 21코드 rollback과 DB 호환성을 함께 보기 위해
05. 배포 전후 검증 체크리스트 상세7, 23배포 전후 관찰 지표와 중단 조건을 잡기 위해
00. Logging Metrics Tracing 압축 정리8, 20관측 신호의 역할을 큰 그림으로 보기 위해
01. Structured Logging과 Correlation ID 상세8, 20요청 단위 증거와 correlation id를 남기기 위해
02. Metrics Counter Gauge Histogram 상세8, 17오류율, 처리량, latency, 자원 추세를 보기 위해
03. Distributed Tracing과 Span 상세8요청 경로와 병목 span을 확인하기 위해
04. Spring Boot Actuator Micrometer 상세8, 9Spring 상태와 metric 노출 기준을 확인하기 위해
05. 로그 메트릭 트레이스 연결 분석 상세8, 20서로 다른 신호를 같은 시간대로 묶기 위해
00. APM Health Check Alert 압축 정리9, 10APM, health, alert를 함께 보기 위해
01. APM이 보는 지표 상세9, 17latency/error/throughput/saturation을 해석하기 위해
02. Liveness Readiness Health Check 상세9, 15살아 있음과 준비됨을 분리하기 위해
03. Alert Rule과 Noise 관리 상세10행동 가능한 alert와 noise를 구분하기 위해
04. SLI SLO Error Budget 기본 상세10, 20사용자 영향 기준으로 장애를 판단하기 위해
05. 장애 징후를 알림으로 바꾸는 법 상세10장애 징후를 page/ticket/runbook으로 연결하기 위해
00. Backup Restore Migration 운영 압축 정리11, 21백업, 복구, migration을 함께 보기 위해
01. Backup 종류와 복구 목표 상세11, 21RPO/RTO와 백업 방식을 연결하기 위해
02. Restore Drill과 검증 상세11, 21백업 성공과 복구 가능성을 구분하기 위해
03. Schema Migration 운영 상세1, 11, 21migration 실패와 forward fix를 판단하기 위해
04. 파일 Object Storage 백업 상세12DB row와 object key 복구를 함께 보기 위해
05. 데이터 손실 사고 대응 상세11, 21데이터 손실 범위와 복구 방식을 정하기 위해
00. Incident Response 장애 보고서 압축 정리13, 20사고 대응 흐름과 보고 기준을 보기 위해
01. 장애 탐지와 Severity 분류 상세10, 13사용자 영향으로 severity를 정하기 위해
02. 초기 대응과 커뮤니케이션 상세13장애 채널과 업데이트 주기를 정하기 위해
03. 원인 격리와 임시 완화 상세13, 22원인 후보를 줄이고 임시 완화를 고르기 위해
04. Postmortem과 재발 방지 상세20사후 분석과 action item을 검증 가능하게 만들기 위해
05. 장애 보고서 템플릿 상세13, 20사고 중 보고와 사후 보고를 구분하기 위해
00. Cloud Infra VM VPC LB Object Storage 압축 정리14, 22클라우드 리소스의 운영 책임을 큰 그림으로 보기 위해
01. VM Instance와 운영 책임 상세14VM 위에서 Spring이 실행되는 조건을 확인하기 위해
02. VPC Subnet Security Group 상세14, 22source, target, port 경로를 설명하기 위해
03. Load Balancer와 Health Check 상세9, 14target health와 Spring readiness를 연결하기 위해
04. Object Storage와 정적 파일 상세12, 14파일 저장, 권한, cache, CDN 문제를 확인하기 위해
05. Managed Service 선택 기준 상세18managed service의 limit과 남는 책임을 확인하기 위해
00. Kubernetes 입문과 도입 판단 압축 정리14, 15, 19Kubernetes 도입의 큰 그림과 비용을 보기 위해
01. Pod Deployment Service Ingress 상세15Kubernetes 요청 경로와 리소스 관계를 확인하기 위해
02. ConfigMap Secret Volume 상세16설정, secret, 파일 주입 방식과 반영 시점을 보기 위해
03. Probe Resource Limit 상세15, 17probe와 JVM resource 문제를 함께 보기 위해
04. Kubernetes가 해결하는 문제와 비용 상세14, 19도입 가치와 운영 비용을 비교하기 위해
05. 개인 프로젝트와 팀 서비스 도입 판단 상세19, 24개인/팀 서비스의 도입 기준을 구분하기 위해
00. Web Operations Runbook 압축 정리24Runbook의 전체 역할을 확인하기 위해
01. 배포 실패 대응 Runbook 상세1, 6, 23배포 실패 첫 대응과 종료 조건을 확인하기 위해
02. API 장애 대응 Runbook 상세2, 9, 22API 장애 영향 범위와 완화 순서를 확인하기 위해
03. 로그 메트릭 기반 원인 격리 Runbook 상세8, 20로그/메트릭/트레이스를 같은 시간대로 묶기 위해
04. Rollback Restore 의사결정 Runbook 상세1, 11, 21rollback, restore, forward fix를 구분하기 위해
05. 운영 점검 체크리스트 상세19, 20, 23평소 점검과 장애 후 업데이트를 연결하기 위해

실전 Case 목록

Case상황핵심 판단
1배포했는데 운영 서비스가 되지 않는다배포 실패인지 데이터 호환성 문제인지 나눈다
2서버는 살아 있는데 API가 안 받는다프로세스, 포트, 프록시, 자원을 계층별로 본다
3로컬에서는 되는데 운영 profile에서만 터진다config, secret, profile, drift를 확인한다
4컨테이너를 교체했더니 파일이 사라졌다container와 volume, object storage를 분리한다
5502와 500을 구분하지 못해 시간이 흐른다Nginx와 Spring 경계를 로그로 나눈다
6CI는 초록인데 배포 후 실패한다pipeline 성공과 release 성공을 구분한다
7트래픽을 조금만 보냈는데 지표가 흔들린다배포 전략별 중단 조건을 본다
8로그는 많은데 원인 설명이 안 된다로그, 메트릭, 트레이스를 같은 요청으로 묶는다
9Health는 UP인데 주문이 실패한다health, readiness, APM 지표를 분리한다
10알림이 시끄러워 실제 장애를 놓친다행동 가능한 alert와 SLO 기준을 만든다
11삭제 배치 후 데이터가 이상하다손실 범위와 복구 방식을 먼저 고른다
12파일은 있는데 사용자에게 안 보인다DB metadata, object, cache, 권한을 함께 본다
13장애 채널에 말은 많은데 결정이 없다역할, 업데이트, 임시 완화를 고정한다
14VM에서 클라우드와 Kubernetes로 넘어가려 한다실행 책임과 도입 비용을 비교한다
15Pod는 Running인데 API가 안 된다Service, Ingress, readiness, port를 따라간다
16Secret을 바꿨는데 일부 인스턴스만 실패한다secret 반영 시점과 rollout을 확인한다
17resource limit을 넣은 뒤 p95가 올라간다JVM memory, CPU throttling, probe를 함께 본다
18Managed DB인데 connection이 꽉 찬다managed service limit과 pool 합계를 계산한다
19개인 프로젝트를 운영 가능한 포트폴리오로 만들고 싶다최소 운영 기준과 도입 보류 기준을 정한다
20장애 후 보고서가 흐릿하다증거, timeline, action item을 검증 가능하게 쓴다
21Rollback할지 Restore할지 회의가 길어진다코드 되돌림과 데이터 복구를 분리한다
22보안 그룹 변경 후 결제 API만 timeout 된다네트워크 방향과 source/target/port를 확인한다
23체크리스트가 길지만 장애를 막지 못한다중단 조건, owner, 검증일을 넣는다
24전체 로드맵을 실습 계획으로 바꾸고 싶다큰 흐름을 반복 가능한 실습으로 쪼갠다

Case 1. 배포했는데 운영 서비스가 되지 않는다

상황

금요일 오후, 주문 API 새 버전을 배포했다.

pipeline은 성공했고 배포 도구도 완료를 표시한다.

그런데 모바일 주문 생성 실패율이 천천히 올라가고, 이전 버전으로 되돌리자는 말과 migration 때문에 위험하다는 말이 동시에 나온다.

관찰할 증거 또는 확인할 단서

  • 배포 시작 시각, artifact tag, commit, active profile
  • 새 버전과 이전 버전의 traffic 비율
  • smoke test 결과와 실제 사용자 오류율
  • migration 실행 여부와 이전 버전 호환성
  • rollback 후에도 실패할 수 있는 DB schema 변경 여부

먼저 생각해보기

  • 지금 실패는 새 artifact 문제인가, 설정 문제인가, DB 호환성 문제인가?
  • Rollback이 안전하다는 증거가 있는가?
  • 사용자 영향을 줄이기 위해 먼저 트래픽을 멈출 수 있는가?

찾아볼 문서

정리

배포 실패는 “새 버전이 문제다”로 바로 좁히지 않는다.

artifact, 설정, migration, readiness, smoke test를 같은 시간대에 놓고 본 뒤 rollback 또는 forward fix를 결정한다.

가져갈 한 문장

배포 실패에서 가장 위험한 말은 “일단 되돌리자”가 아니라 “되돌려도 되는지 확인했다”가 빠진 말이다.

Case 2. 서버는 살아 있는데 API가 안 받는다

상황

운영 서버에 SSH 접속은 된다.

CPU도 아주 높지 않고, 서버 상태 화면도 running이다.

하지만 사용자는 API timeout을 보고 있고, health check도 가끔 실패한다.

관찰할 증거 또는 확인할 단서

  • Spring process가 어떤 사용자로 실행 중인지
  • systemd service 상태와 최근 journal log
  • listen port, firewall, upstream 연결 상태
  • disk full, memory pressure, OOM 여부
  • API 장애 Runbook의 영향 endpoint와 status code

먼저 생각해보기

  • 서버가 살아 있다는 말이 Spring process도 정상이라는 뜻인가?
  • timeout과 connection refused는 같은 원인인가?
  • 재시작 전에 어떤 로그와 상태를 남겨야 하는가?

찾아볼 문서

정리

서버 장애 대응은 “서버가 켜져 있다”에서 끝나지 않는다.

실행 사용자, service 상태, port, firewall, log, disk, resource를 안전한 읽기 명령으로 나눠 봐야 한다.

가져갈 한 문장

SSH 접속 성공은 관리 경로가 열린 것이지 사용자 요청 경로가 정상이라는 증거가 아니다.

Case 3. 로컬에서는 되는데 운영 profile에서만 터진다

상황

로컬 Compose 환경에서는 회원가입과 로그인 API가 잘 된다.

운영 배포 후에는 DB 연결은 되는 듯하지만 외부 인증 API만 실패한다.

누군가는 secret 문제라고 하고, 누군가는 profile 문제라고 한다.

관찰할 증거 또는 확인할 단서

  • active profile과 실제 property source
  • 운영 환경 변수, Secret 주입 경로, CI/CD secret 이름
  • 로컬 Compose env 파일과 운영 Config/Secret 차이
  • 변경된 설정의 owner와 마지막 변경 시각
  • drift가 발생한 서버 또는 인스턴스 범위

먼저 생각해보기

  • 로컬과 운영의 차이는 코드인가 설정인가?
  • 같은 artifact가 환경마다 다르게 동작하는 이유는 무엇인가?
  • secret 값 자체가 아니라 secret이 들어오는 경로를 설명할 수 있는가?

찾아볼 문서

정리

운영 profile 장애는 “값이 틀렸다”만으로 부족하다.

값의 출처, 우선순위, 주입 방식, 반영 시점, drift 범위를 같이 확인해야 한다.

가져갈 한 문장

설정 장애는 값 하나보다 “그 값이 어디서 왔는가”를 먼저 물어야 빨리 좁혀진다.

Case 4. 컨테이너를 교체했더니 파일이 사라졌다

상황

이미지 보안 패치를 위해 Spring 컨테이너를 새로 띄웠다.

API는 정상인데 예전 업로드 파일 일부가 보이지 않는다.

새 컨테이너에는 파일이 없고, 이전 컨테이너는 이미 삭제됐다.

관찰할 증거 또는 확인할 단서

  • 파일이 container writable layer에 있었는지 volume에 있었는지
  • named volume, bind mount, object storage 중 어디가 원본인지
  • DB에는 object key 또는 파일 path가 남아 있는지
  • container 재생성 전 로그와 mount 정보가 남아 있는지
  • 백업과 복원 가능한 기준 시각

먼저 생각해보기

  • container 교체와 데이터 보존은 분리되어 있었는가?
  • 파일 원본은 VM disk, Docker volume, Object Storage 중 어디인가?
  • 복구 전에 현재 상태를 보존했는가?

찾아볼 문서

정리

컨테이너는 교체 가능한 실행 단위이고, 데이터는 별도 저장소에 있어야 한다.

파일 장애에서는 container, volume, DB metadata, object storage를 따로 보되 같은 시간대로 맞춰야 한다.

가져갈 한 문장

컨테이너를 삭제해도 괜찮으려면, 삭제 전에 데이터가 어디에 남는지 이미 설명할 수 있어야 한다.

Case 5. 502와 500을 구분하지 못해 시간이 흐른다

상황

사용자는 “서버 오류”라고 말한다.

Nginx access log에는 502와 504가 보이고, Spring log에는 생각보다 요청이 적다.

개발자는 controller 코드를 보고 있고, 인프라 담당자는 upstream을 보고 있다.

관찰할 증거 또는 확인할 단서

  • Nginx access log와 error log
  • Spring access log에 같은 요청이 도달했는지
  • upstream 주소와 port, Docker port mapping
  • TLS, timeout, body size, buffer 설정
  • container 내부 health와 host port publish 상태

먼저 생각해보기

  • 이 오류는 Spring이 만든 500인가, 프록시가 만든 502/504인가?
  • 요청이 Spring까지 도착했는가?
  • Nginx가 host port를 보는지 container network service name을 보는지 설명할 수 있는가?

찾아볼 문서

정리

502/504는 애플리케이션 코드보다 요청 경로가 끊어진 신호일 때가 많다.

Nginx log와 Spring log를 같은 request, 같은 시간대로 비교해야 한다.

가져갈 한 문장

Spring log에 요청이 없다면 controller보다 upstream 경로를 먼저 본다.

Case 6. CI는 초록인데 배포 후 실패한다

상황

CI는 성공했고 test도 통과했다.

하지만 배포된 서버에서는 새 jar가 뜨지 않거나, image tag가 기대한 commit과 다르다.

pipeline 화면만 보면 모두 정상으로 보인다.

관찰할 증거 또는 확인할 단서

  • CI와 CD가 어디서 나뉘는지
  • build, test, package 산출물
  • artifact tag, image digest, Git SHA
  • 배포 권한과 secret 사용 범위
  • 실패한 pipeline을 재실행했는지, 새 실패로 덮었는지

먼저 생각해보기

  • CI 성공은 운영 배포 성공을 증명하는가?
  • 지금 운영 중인 artifact가 어느 commit에서 왔는가?
  • 실패한 pipeline에서 보존해야 할 로그와 산출물은 무엇인가?

찾아볼 문서

정리

CI는 변경이 검증됐다는 신호이고, CD는 운영에 안전하게 반영됐다는 별도 신호다.

artifact 추적성이 없으면 초록 pipeline도 장애 중 증거가 되기 어렵다.

가져갈 한 문장

배포된 버전을 설명하지 못하면 pipeline 성공도 운영 증거로는 약하다.

Case 7. 트래픽을 조금만 보냈는데 지표가 흔들린다

상황

Canary로 5% 트래픽만 새 버전에 보냈다.

오류율은 크게 오르지 않았지만 p95가 천천히 올라가고, DB connection도 평소보다 높다.

팀은 계속 늘려도 될지 멈춰야 할지 망설인다.

관찰할 증거 또는 확인할 단서

  • 배포 전략: Rolling, Blue-Green, Canary 중 무엇인지
  • traffic 비율과 관측 창
  • 새 버전과 이전 버전의 error rate, latency, request 수
  • rollback 조건과 DB 변경 호환성
  • 배포 전후 검증 체크리스트

먼저 생각해보기

  • 지금 지표는 중단 조건에 해당하는가?
  • Canary는 트래픽 비율보다 무엇이 더 중요한가?
  • rollback하면 데이터 호환성 문제가 생기지 않는가?

찾아볼 문서

정리

점진 배포의 핵심은 느리게 올리는 것이 아니라 멈출 조건을 미리 정하는 것이다.

latency와 saturation은 오류율보다 먼저 흔들릴 수 있다.

가져갈 한 문장

Canary는 용기가 아니라 관찰 창과 중단 조건으로 운영한다.

Case 8. 로그는 많은데 원인 설명이 안 된다

상황

장애 중 로그는 계속 쌓인다.

대시보드에는 p95 상승이 보이고, trace에는 외부 API span이 느리게 보인다.

그런데 세 신호가 같은 요청을 말하는지 확신이 없다.

관찰할 증거 또는 확인할 단서

  • correlation id 또는 request id
  • endpoint별 error rate와 p95/p99
  • trace span에서 오래 걸린 구간
  • Actuator/Micrometer metric 이름
  • Nginx log와 Spring log의 시간대 차이

먼저 생각해보기

  • 로그는 사건, 메트릭은 규모, 트레이스는 경로를 설명하고 있는가?
  • 같은 시간대와 같은 요청으로 묶였는가?
  • 장애 보고서에 남길 수 있는 재현 가능한 쿼리나 필터가 있는가?

찾아볼 문서

정리

관측 신호는 많을수록 좋은 것이 아니라 연결될수록 좋다.

같은 요청과 같은 시간대로 묶지 못하면 그래프와 로그가 각자 다른 이야기를 한다.

가져갈 한 문장

장애 중 관측의 목표는 많은 화면을 여는 것이 아니라 같은 사건을 여러 신호로 설명하는 것이다.

Case 9. Health는 UP인데 주문이 실패한다

상황

상태 endpoint는 계속 UP이다.

Load Balancer target도 healthy다.

그런데 주문 생성 API는 DB timeout과 외부 API 지연 때문에 실패한다.

관찰할 증거 또는 확인할 단서

  • liveness와 readiness가 분리되어 있는지
  • Health Check가 무엇을 포함하고 무엇을 제외하는지
  • APM의 latency, error, throughput, saturation
  • Load Balancer target health와 실제 API 성공률
  • API 장애 Runbook의 영향 endpoint

먼저 생각해보기

  • UP은 살아 있다는 뜻인가, 요청을 처리할 수 있다는 뜻인가?
  • Health Check가 너무 얕거나 너무 깊지는 않은가?
  • 사용자가 보는 실패를 어떤 SLI로 표현할 수 있는가?

찾아볼 문서

정리

Health는 운영 판단의 출발점이지 최종 결론이 아니다.

핵심 API 성공률, 의존성 상태, readiness 조건을 함께 봐야 한다.

가져갈 한 문장

Health가 UP이어도 사용자가 실패하면 운영 판단은 사용자 영향 쪽으로 다시 돌아가야 한다.

Case 10. 알림이 시끄러워 실제 장애를 놓친다

상황

하루에 alert가 너무 많이 울린다.

대부분은 금방 회복되고, 정작 주문 실패율이 높아진 날에는 담당자가 알림을 늦게 본다.

회의에서는 “알림을 줄이자”와 “더 촘촘히 잡자”가 동시에 나온다.

관찰할 증거 또는 확인할 단서

  • alert rule의 조건, 지속 시간, severity
  • 사용자 영향과 연결된 SLI
  • SLO와 error budget burn rate
  • page와 ticket을 나누는 기준
  • 실제 장애에서 놓친 징후

먼저 생각해보기

  • 이 알림을 받은 사람이 바로 행동할 수 있는가?
  • 증상 알림인가, 원인 추측 알림인가?
  • 사용자가 느끼는 장애와 연결된 지표인가?

찾아볼 문서

정리

알림은 많이 울리면 안전한 것이 아니라 행동 가능한 신호여야 안전하다.

사용자 영향과 연결되지 않은 알림은 noise가 되기 쉽다.

가져갈 한 문장

좋은 alert는 사람을 깨우는 것이 아니라 다음 행동을 정하게 만든다.

Case 11. 삭제 배치 후 데이터가 이상하다

상황

새벽 배치 이후 일부 주문 상태가 예상과 다르다.

사용자 문의가 들어왔고, 운영자는 최신 백업을 복원하면 된다고 말한다.

하지만 사고 이후 정상 주문도 계속 생성되고 있다.

관찰할 증거 또는 확인할 단서

  • 손실 의심 시각과 발견 시각
  • 잘못된 row 범위와 정상 쓰기 범위
  • 백업 기준 시각, RPO, RTO
  • migration 또는 batch 실행 이력
  • restore, forward fix, replay 중 가능한 방식

먼저 생각해보기

  • 전체 restore를 하면 사고 이후 정상 데이터를 잃지 않는가?
  • 잘못된 데이터 범위를 SQL로 설명할 수 있는가?
  • 자동 배치나 consumer를 먼저 멈춰야 하는가?

찾아볼 문서

정리

데이터 사고에서 빠른 복구보다 먼저 해야 할 일은 손실 범위를 고정하는 것이다.

전체 restore, forward fix, replay는 각각 보존하는 데이터와 잃는 데이터가 다르다.

가져갈 한 문장

데이터 복구는 과거로 돌아가는 일이 아니라 어떤 현재를 보존할지 정하는 일이다.

Case 12. 파일은 있는데 사용자에게 안 보인다

상황

사용자 첨부 파일 문의가 늘었다.

DB에는 file row가 있고 object key도 보인다.

하지만 다운로드 URL은 404 또는 403을 반환하고, 일부 정적 파일은 오래된 cache에서 내려온다.

관찰할 증거 또는 확인할 단서

  • DB metadata와 object key 일치 여부
  • Object Storage bucket, prefix, versioning, lifecycle
  • signed URL 만료 시간과 권한
  • CDN cache와 static file cache header
  • Nginx static serving 또는 proxy 경로

먼저 생각해보기

  • 파일이 없어진 것인가, 접근 권한이 막힌 것인가, cache가 오래된 것인가?
  • DB row와 object가 같은 기준 시각을 바라보는가?
  • 원본 파일과 파생 파일의 복구 우선순위는 다른가?

찾아볼 문서

정리

파일 장애는 storage 문제이면서 권한 문제이고, 때로는 cache 문제다.

DB metadata, object 상태, URL 권한, CDN/Nginx cache를 같은 흐름으로 확인해야 한다.

가져갈 한 문장

파일이 “있다”는 말은 사용자가 “볼 수 있다”는 말과 다르다.

Case 13. 장애 채널에 말은 많은데 결정이 없다

상황

장애 채널에 사람이 많이 모였다.

하지만 누가 최종 결정을 하는지 모호하고, 같은 로그를 여러 사람이 보고 있다.

고객 공지는 늦어지고, 원인 후보만 늘어난다.

관찰할 증거 또는 확인할 단서

  • Incident Commander, Technical Lead, 기록 담당자 지정 여부
  • 임시 Severity와 사용자 영향 문장
  • 다음 업데이트 시각
  • 실행한 완화 조치와 결과
  • 장애 보고서 초안과 타임라인

먼저 생각해보기

  • 지금 필요한 것은 원인 확정인가, 영향 제한인가?
  • 다음 업데이트 시각을 누가 책임지고 있는가?
  • 이미 확인한 사실과 가설이 분리되어 있는가?

찾아볼 문서

정리

장애 중 커뮤니케이션은 친절한 설명보다 역할과 다음 행동을 정하는 일에 가깝다.

역할, 영향, 조치, 업데이트 시간이 정리되면 기술 조사도 빨라진다.

가져갈 한 문장

장애 채널의 첫 목표는 모두가 같은 사실 위에서 움직이게 만드는 것이다.

Case 14. VM에서 클라우드와 Kubernetes로 넘어가려 한다

상황

서비스가 커지면서 VM 한두 대로 운영하던 방식을 바꾸자는 이야기가 나온다.

누군가는 Kubernetes를 제안하고, 누군가는 managed platform이면 충분하다고 한다.

아직 로그와 배포 Runbook도 완전히 정리되어 있지는 않다.

관찰할 증거 또는 확인할 단서

  • 현재 VM 운영 책임: process, patch, log, disk, access key
  • VPC, subnet, security group, Load Balancer 구성 필요성
  • managed service로 줄어드는 책임과 남는 책임
  • Kubernetes 도입으로 해결하려는 실제 문제
  • 운영자가 event, rollout, probe를 읽을 준비가 되었는지

먼저 생각해보기

  • 지금 문제는 배포 표준화인가, scale-out인가, 학습 욕구인가?
  • Kubernetes가 해결하는 문제와 새로 만드는 비용을 모두 말할 수 있는가?
  • managed service limit과 비용 모델을 이해했는가?

찾아볼 문서

정리

인프라 전환은 기술 이름을 고르는 일이 아니라 운영 책임을 어디로 옮기고 무엇을 남길지 정하는 일이다.

Kubernetes는 강력하지만 준비되지 않은 관측과 권한 체계를 대신 만들어 주지 않는다.

가져갈 한 문장

플랫폼 선택은 “무엇을 쓰고 싶은가”보다 “무엇을 운영할 준비가 되었는가”로 결정한다.

Case 15. Pod는 Running인데 API가 안 된다

상황

Kubernetes로 옮긴 Spring API의 Pod는 Running이다.

하지만 외부 요청은 404 또는 503을 보고, Service endpoint가 비거나 Ingress rule이 기대와 다르다.

애플리케이션 로그만 보면 큰 오류는 없다.

관찰할 증거 또는 확인할 단서

  • Deployment desired/current/available 수
  • Pod label과 Service selector
  • Service endpoint 목록
  • Ingress host/path/backend
  • readiness probe 상태와 container port

먼저 생각해보기

  • Running Pod가 Service endpoint에 포함되어 있는가?
  • 외부 요청이 Ingress에서 어떤 Service로 가는가?
  • Spring server port와 targetPort가 일치하는가?

찾아볼 문서

정리

Kubernetes 장애는 Pod 상태만 보면 부족하다.

Deployment, Pod, Service, endpoint, Ingress, readiness를 요청 경로 순서로 따라가야 한다.

가져갈 한 문장

Pod가 Running이어도 Service가 그 Pod를 선택하지 않으면 사용자는 아무것도 받지 못한다.

Case 16. Secret을 바꿨는데 일부 인스턴스만 실패한다

상황

DB password를 회전했다.

새로 뜬 Pod는 정상인데 오래된 Pod 일부는 인증 실패를 내거나, 반대로 새 Pod만 실패한다.

CI/CD secret과 Kubernetes Secret, Compose env 파일까지 이름이 비슷하다.

관찰할 증거 또는 확인할 단서

  • Secret 변경 시각과 rollout 시각
  • env, envFrom, volumeMount 중 어떤 방식인지
  • Pod 재시작 여부와 connection 재수립 여부
  • CI/CD secret과 runtime secret의 경계
  • Secret 값이 로그나 describe 출력에 노출되었는지

먼저 생각해보기

  • Secret 값이 바뀌었다는 말과 애플리케이션이 새 값을 쓴다는 말은 같은가?
  • 회전 절차에 이전 Secret 폐기와 검증이 포함되어 있는가?
  • 어떤 Pod가 어떤 Secret revision을 쓰는지 확인했는가?

찾아볼 문서

정리

Secret 장애는 값 자체보다 반영 경로와 반영 시점이 중요하다.

회전은 새 값 생성, rollout, 연결 확인, 이전 값 폐기의 흐름으로 봐야 한다.

가져갈 한 문장

Secret을 바꿨다면 “누가 새 값을 보느냐”까지 확인해야 변경이 끝난다.

Case 17. resource limit을 넣은 뒤 p95가 올라간다

상황

Kubernetes 비용을 줄이려고 CPU와 memory limit을 낮췄다.

그 뒤 오류율은 낮지만 p95가 올라가고, 일부 Pod가 가끔 재시작된다.

APM에는 latency 상승과 GC pause가 같이 보인다.

관찰할 증거 또는 확인할 단서

  • Pod resource request/limit
  • JVM heap, native memory, thread stack 사용량
  • CPU throttling과 p95/p99 관계
  • OOMKilled event와 readiness 실패
  • APM의 saturation과 metric histogram

먼저 생각해보기

  • memory limit과 JVM heap을 함께 계산했는가?
  • CPU limit이 응답 시간을 늘리고 있지는 않은가?
  • readiness 실패가 실제 장애를 숨기고 있지는 않은가?

찾아볼 문서

정리

resource limit은 비용 설정이면서 장애 격리 설정이다.

Spring JVM에서는 heap만 보지 말고 container memory 전체와 throttling을 같이 봐야 한다.

가져갈 한 문장

limit을 낮추는 일은 절약이 아니라 새로운 운영 조건을 배포하는 일이다.

Case 18. Managed DB인데 connection이 꽉 찬다

상황

운영 DB는 managed service라서 인프라 부담이 낮다고 생각했다.

그런데 replica 수를 늘린 뒤 DB connection limit에 닿고, 일부 API가 timeout 된다.

DB CPU는 아주 높지 않다.

관찰할 증거 또는 확인할 단서

  • 애플리케이션 instance 수와 Hikari pool size
  • managed DB connection limit과 plan quota
  • timeout, retry, circuit breaker 설정
  • scale-out 시 connection 합계
  • 최근 배포나 유지보수 창

먼저 생각해보기

  • managed service가 connection 설계 책임까지 가져가는가?
  • instance 수와 pool size를 곱하면 limit 안에 들어오는가?
  • retry가 connection 부족을 더 키우고 있지는 않은가?

찾아볼 문서

정리

Managed DB는 patch와 일부 장애 조치를 줄여 주지만 애플리케이션의 연결 사용 패턴을 대신 설계하지 않는다.

replica 수, pool size, retry, limit을 같은 표에서 봐야 한다.

가져갈 한 문장

Managed Service를 쓴다는 말은 운영 책임이 사라진다는 말이 아니라 책임의 위치가 바뀐다는 말이다.

Case 19. 개인 프로젝트를 운영 가능한 포트폴리오로 만들고 싶다

상황

개인 프로젝트를 배포해 두었지만, 다시 배포하거나 장애가 났을 때 무엇을 봐야 할지 자신이 없다.

README에는 실행 방법만 있고, 로그, health, 백업, rollback 메모는 없다.

Kubernetes를 붙이면 더 좋아 보일지도 고민 중이다.

관찰할 증거 또는 확인할 단서

  • 배포 script 또는 Runbook 존재 여부
  • version tag와 release note
  • health endpoint와 log 확인 방법
  • Compose 또는 VM 기반 재현성
  • 백업과 restore 메모
  • Kubernetes 도입 목적이 학습인지 운영인지

먼저 생각해보기

  • 다른 사람이 같은 artifact와 설정으로 다시 띄울 수 있는가?
  • 장애 중 확인할 로그와 health가 정해져 있는가?
  • Kubernetes 없이도 현재 운영 문제를 해결할 수 있는가?

찾아볼 문서

정리

개인 프로젝트의 운영 품질은 복잡한 플랫폼보다 재현성과 장애 확인 경로에서 먼저 드러난다.

작게라도 version, config, health, log, backup, rollback이 있으면 학습 흔적이 실전으로 이어진다.

가져갈 한 문장

운영 가능한 개인 프로젝트는 화려한 인프라보다 다시 띄울 수 있는 증거를 가진다.

Case 20. 장애 후 보고서가 흐릿하다

상황

장애는 끝났다.

하지만 보고서에는 “원인 파악 후 조치 완료”와 “모니터링 강화”만 남았다.

다음에 같은 장애가 나면 더 빨리 대응할 수 있을지 확신이 없다.

관찰할 증거 또는 확인할 단서

  • timeline에 사건, 근거, 의사결정이 있는지
  • 사용자 영향과 기술 원인이 분리되었는지
  • 로그/메트릭/트레이스 링크가 재현 가능한지
  • action item에 owner, due date, 검증 방법이 있는지
  • Runbook과 체크리스트가 업데이트되었는지

먼저 생각해보기

  • 보고서가 기억에 의존하는가, 증거에 의존하는가?
  • action item이 완료되면 탐지나 완화 시간이 줄어드는가?
  • 다음 장애 대응자가 이 문서를 보고 행동할 수 있는가?

찾아볼 문서

정리

장애 보고서는 문서 생산물이 아니라 다음 대응 시간을 줄이는 운영 자산이다.

증거, timeline, decision, action item이 없으면 다음 장애 때 같은 질문을 반복한다.

가져갈 한 문장

좋은 Postmortem은 “무슨 일이 있었나”보다 “다음에는 무엇이 더 빨라지는가”를 증명한다.

Case 21. Rollback할지 Restore할지 회의가 길어진다

상황

배포 직후 데이터가 일부 잘못 저장됐다.

애플리케이션 이전 버전으로 되돌리자는 의견과 DB를 특정 시점으로 복원하자는 의견이 나뉜다.

그 사이에도 정상 사용자는 계속 데이터를 만들고 있다.

관찰할 증거 또는 확인할 단서

  • 코드 문제인지 데이터 문제인지
  • schema migration 실행 여부
  • 사고 이후 정상 쓰기 범위
  • backup 기준 시각과 PITR 가능 여부
  • forward fix로 보정 가능한 row 범위

먼저 생각해보기

  • Rollback은 무엇을 되돌리고 Restore는 무엇을 되돌리는가?
  • restore가 정상 데이터를 잃게 만들지는 않는가?
  • 먼저 기능 차단이나 read-only 전환으로 시간을 벌어야 하는가?

찾아볼 문서

정리

Rollback은 코드와 설정의 시간표이고, Restore는 데이터의 시간표다.

두 시간표가 다르면 어떤 현재 데이터를 보존할지 먼저 결정해야 한다.

가져갈 한 문장

복구 의사결정은 되돌리는 속도가 아니라 잃지 말아야 할 현재를 정하는 일에서 시작한다.

Case 22. 보안 그룹 변경 후 결제 API만 timeout 된다

상황

보안 그룹을 정리한 뒤 대부분 API는 정상이다.

그런데 결제 승인 요청만 timeout 된다.

외부 결제사 status는 정상이고, 애플리케이션 로그에는 connection timeout만 남는다.

관찰할 증거 또는 확인할 단서

  • app에서 external payment API로 나가는 egress 경로
  • source, target, port, protocol
  • Security Group, route, NAT, DNS 변경 시각
  • connection refused인지 timeout인지
  • 기능 제한이나 fallback 가능성

먼저 생각해보기

  • inbound 장애인가 outbound 장애인가?
  • 같은 VPC 내부 통신과 외부 API 통신을 구분했는가?
  • 노트북에서 되는 통신이 서버에서도 된다고 말할 수 있는가?

찾아볼 문서

정리

네트워크 장애는 방향을 먼저 나눠야 한다.

source, target, port, 실행 위치가 정리되면 보안 그룹 변경의 영향 범위가 선명해진다.

가져갈 한 문장

“네트워크가 안 된다”는 말은 “어디에서 어디의 몇 번 port로 못 간다”로 바뀌어야 조치가 시작된다.

Case 23. 체크리스트가 길지만 장애를 막지 못한다

상황

배포 전 체크리스트는 있다.

하지만 매번 모두 PASS로 처리되고, 실제 장애에서는 checklist가 어떤 결정을 도왔는지 알 수 없다.

마지막 검증일도 없다.

관찰할 증거 또는 확인할 단서

  • 항목이 예/아니오로 답할 수 있는지
  • 실패 시 중단 조건이 있는지
  • owner와 마지막 검증일
  • 배포 전후 관찰 지표
  • pipeline 실패 후 업데이트 여부

먼저 생각해보기

  • 이 체크리스트는 배포를 멈출 수 있는가?
  • 실패 항목이 있으면 누가 무엇을 해야 하는가?
  • 최근 장애에서 빠진 항목이 반영되었는가?

찾아볼 문서

정리

체크리스트는 많을수록 좋은 것이 아니라 실패를 멈추게 만들수록 좋다.

각 항목에는 확인 위치, 기대 결과, 실패 시 다음 행동이 있어야 한다.

가져갈 한 문장

PASS만 쌓이는 체크리스트보다 배포를 한 번 멈춘 체크리스트가 더 믿을 만하다.

Case 24. 전체 로드맵을 실습 계획으로 바꾸고 싶다

상황

Web Operations 문서를 다 읽었지만 무엇부터 직접 해 봐야 할지 막막하다.

서버, Docker, Nginx, CI/CD, 관측, 복구, 클라우드, Kubernetes가 모두 연결되어 있어 한 번에 너무 커 보인다.

관찰할 증거 또는 확인할 단서

  • 지금 만들 수 있는 최소 운영 산출물
  • 각 챕터 00 압축 정리에서 반복되는 핵심 판단
  • 개인 프로젝트에서 먼저 실습할 수 있는 범위
  • Runbook과 체크리스트로 남길 수 있는 결과물
  • 도구 이름보다 운영 판단이 남는지

먼저 생각해보기

  • 지금 단계에서 필요한 것은 새 도구인가, 실패했을 때 볼 증거인가?
  • 한 주 안에 검증 가능한 운영 산출물은 무엇인가?
  • 다음 단계로 넘어가기 전 어떤 장애 상황을 직접 재현해 볼 수 있는가?

찾아볼 문서

정리

로드맵은 읽는 순서가 아니라 실습 산출물의 순서로 바뀌어야 몸에 남는다.

작은 서비스라도 version, config, health, log, deploy, rollback, backup, report가 연결되면 운영 학습이 된다.

가져갈 한 문장

Web Operations를 배웠다는 증거는 도구 목록이 아니라 장애 상황에서 다시 열 문서를 고를 수 있다는 것이다.

보충 Case

기존 24개 Case는 전체 문서를 빠짐없이 다시 찾아가게 만드는 기본 골격이다.

보충 Case는 그중 한 번만 호출된 문서나, 실제 운영에서 더 잘게 나눠 연습해야 하는 지점을 섹션별로 보강한다.

보충 커버리지 지도

보충 섹션보강 대상 문서연결된 보충 Case추가한 이유
Linux 실행 권한과 안전한 변경00. Linux Server 운영 기본 압축 정리
01. User Permission Process 기본 상세
02. Service systemd 관리 상세
04. Log Disk Resource 점검 상세
05. 운영 서버에서 조심할 명령 상세		25권한, process manager, 로그, 변경 명령을 한 상황에서 다시 연결하기 위해
CI/CD 추적성과 배포 증거01. CI와 CD 단계 분리 상세
02. Build Test Package Pipeline 상세
03. Artifact Version Tagging 상세
04. Secret과 배포 권한 관리 상세
05. 실패한 Pipeline 대응 상세		26초록 pipeline과 실제 운영 버전의 차이를 더 깊게 보기 위해
배포 전략별 실패 반경01. Rolling Deployment 상세
02. Blue-Green Deployment 상세
03. Canary와 점진적 트래픽 전환 상세
05. 배포 전후 검증 체크리스트 상세		27전략 이름보다 전환 조건과 중단 조건을 훈련하기 위해
정적 파일과 Object Storage02. Static Serving과 Cache Header 상세
04. Object Storage와 정적 파일 상세
04. 파일 Object Storage 백업 상세		28파일이 보이지 않는 장애를 cache, 권한, 복구 관점으로 나누기 위해
Kubernetes Service와 Ingress01. Pod Deployment Service Ingress 상세
03. Probe Resource Limit 상세
03. Load Balancer와 Health Check 상세		29Pod Running과 외부 요청 성공을 분리해서 보기 위해
Managed Service와 네트워크 의존성05. Managed Service 선택 기준 상세
02. VPC Subnet Security Group 상세
03. 원인 격리와 임시 완화 상세		30관리형 서비스가 책임을 없애는 것이 아니라 관측 경계를 바꾸는 점을 다루기 위해

보충 섹션 1. Linux 실행 권한과 안전한 변경

Case 25. chmod 한 번으로 서비스는 살아났지만 다음 배포가 실패한다

상황

배포 직후 Spring 서비스가 로그 파일을 쓰지 못해 시작에 실패했다.

누군가 급하게 chmod를 넓게 열어 서비스를 살렸고, 그날은 지나갔다.

다음 배포에서 jar 소유자와 log directory 권한이 다시 꼬였고, 이번에는 systemd 재시작까지 반복된다.

관찰할 증거 또는 확인할 단서

  • 서비스 실행 사용자와 jar, env, log directory 소유자
  • systemd unit의 User, WorkingDirectory, EnvironmentFile
  • journal과 application log에 남은 Permission denied
  • 최근 실행한 권한 변경 명령
  • disk full, log rotate, 중복 process 여부

먼저 생각해보기

  • 권한을 넓게 연 것이 문제를 해결한 것인가, 증거를 흐린 것인가?
  • 서비스가 어느 사용자로 실행되어야 하는지 문서화되어 있는가?
  • 변경 명령을 실행하기 전에 읽기 명령으로 확인할 수 있는 정보는 무엇인가?

찾아볼 문서

정리

운영 서버에서 권한 문제는 빠르게 넓히는 방식보다 실행 사용자, 파일 소유자, 필요한 권한을 좁히는 방식으로 풀어야 한다.

systemd로 실행하는 서비스라면 process, log, env file, restart 정책을 같은 단위로 봐야 다음 배포에서 같은 문제가 반복되지 않는다.

가져갈 한 문장

권한 장애를 고친다는 것은 더 많이 여는 것이 아니라 누가 무엇에 접근해야 하는지 좁혀 적는 것이다.

보충 섹션 2. CI/CD 추적성과 배포 증거

Case 26. pipeline은 초록인데 운영 중인 버전을 설명하지 못한다

상황

CI는 성공했고 CD도 배포 성공으로 표시됐다.

그런데 장애 채널에서 “지금 운영에 올라간 코드가 어느 commit인가”를 물었을 때 아무도 바로 답하지 못한다.

이미지 tag는 latest이고, pipeline 로그는 재실행으로 덮였으며, smoke test가 어떤 artifact를 검증했는지도 불분명하다.

관찰할 증거 또는 확인할 단서

  • Git SHA, build number, image tag, image digest
  • CI에서 만든 artifact와 CD에서 배포한 artifact가 같은지
  • 재실행 전 실패 로그가 보존되어 있는지
  • 배포 권한과 secret이 어떤 environment에 묶여 있는지
  • 운영 Actuator나 release note에서 버전을 확인할 수 있는지

먼저 생각해보기

  • pipeline 성공은 어떤 artifact가 검증됐다는 뜻인가?
  • 배포 성공 화면만으로 운영 버전을 설명할 수 있는가?
  • 실패한 pipeline을 재실행하기 전에 어떤 증거를 남겨야 하는가?

찾아볼 문서

정리

CI/CD의 목표는 버튼을 줄이는 것만이 아니다.

장애 중에 어떤 코드가 어떤 설정과 권한으로 운영에 반영됐는지 설명할 수 있어야 pipeline이 운영 증거가 된다.

가져갈 한 문장

초록 pipeline보다 중요한 것은 운영 중인 artifact를 한 문장으로 설명할 수 있는 추적성이다.

보충 섹션 3. 배포 전략별 실패 반경

Case 27. Blue-Green 전환은 됐는데 Green만 이상하다

상황

Green 환경으로 전환한 직후 일부 사용자만 오류를 겪는다.

Blue로 되돌리면 정상으로 보이지만, Green의 smoke test는 통과했고 health도 healthy였다.

두 환경의 설정, cache, DB migration 상태가 완전히 같은지 확인되지 않았다.

관찰할 증거 또는 확인할 단서

  • Blue와 Green의 artifact version, config, secret revision
  • Green 환경에서만 다른 endpoint, cache, 외부 의존성
  • traffic 전환 시각과 error rate, p95 변화
  • rollback 기준과 중단 조건
  • rolling, blue-green, canary 중 어떤 전략이 현재 위험을 가장 작게 만드는지

먼저 생각해보기

  • Blue-Green은 환경을 둘로 나누는 전략이지 drift를 자동으로 없애는 전략인가?
  • Green smoke test가 실제 사용자 경로를 충분히 대표했는가?
  • 되돌리기 전에 데이터 호환성과 cache 상태를 확인했는가?

찾아볼 문서

정리

배포 전략은 이름보다 실패 반경과 관측 조건이 중요하다.

Blue-Green은 되돌릴 수 있는 길을 열어 주지만, 두 환경의 drift와 데이터 호환성을 확인하지 않으면 빠른 전환이 빠른 혼란이 된다.

가져갈 한 문장

배포 전략을 고르는 일은 멋진 전환 방식을 고르는 일이 아니라 실패했을 때 어디까지 멈출지 정하는 일이다.

보충 섹션 4. 정적 파일과 Object Storage

Case 28. 파일은 업로드됐는데 사용자는 예전 파일을 본다

상황

사용자는 새 이미지를 업로드했다고 말한다.

관리 화면의 DB record도 바뀌었고 Object Storage에도 새 object가 있다.

그런데 브라우저와 CDN에서는 예전 파일이 계속 보이거나, 일부 사용자에게만 403이 발생한다.

관찰할 증거 또는 확인할 단서

  • 정적 파일인지 사용자 업로드 파일인지
  • object key, version, cache header, CDN TTL
  • storage 권한과 signed URL 만료 시간
  • DB record와 실제 object 존재 여부
  • 백업과 복구 대상에 파일 데이터가 포함되어 있는지

먼저 생각해보기

  • 파일 문제는 애플리케이션 배포 문제인가, cache 문제인가, 권한 문제인가?
  • DB를 복구하면 파일도 같은 시점으로 복구되는가?
  • 새 파일을 덮어쓰는 방식과 versioned key 방식 중 어느 쪽인가?

찾아볼 문서

정리

파일 장애는 “있다/없다”만으로 끝나지 않는다.

사용자에게 보이는 경로에는 DB record, object key, 권한, cache, CDN, 백업 정책이 함께 들어간다.

가져갈 한 문장

파일이 저장됐다는 말과 사용자가 최신 파일을 본다는 말은 같은 말이 아니다.

보충 섹션 5. Kubernetes Service와 Ingress

Case 29. Pod는 Running인데 Ingress로는 404가 난다

상황

새 Deployment의 Pod는 Running이고 readiness도 통과한다.

하지만 외부 URL로 접근하면 404가 나거나, 이전 버전 Pod로만 트래픽이 간다.

Pod 로그에는 요청이 거의 없고, Load Balancer target은 일부만 healthy로 보인다.

관찰할 증거 또는 확인할 단서

  • Deployment label과 Service selector가 맞는지
  • Service port, targetPort, containerPort 관계
  • Ingress host/path rule과 backend service
  • readiness probe가 실제 요청 가능 상태를 대표하는지
  • 외부 Load Balancer health check와 Kubernetes readiness의 차이

먼저 생각해보기

  • Pod가 Running이라는 말은 외부 요청 경로가 연결됐다는 뜻인가?
  • 404는 애플리케이션 404인가, Ingress rule mismatch인가?
  • 요청이 Pod 로그에 도달하지 않는다면 어느 계층까지는 통과한 것인가?

찾아볼 문서

정리

Kubernetes에서 Pod 상태와 서비스 노출 상태는 다른 문제다.

외부 요청은 Ingress, Service, selector, Pod, application route를 차례로 지나므로, 어느 지점에서 요청이 사라지는지 봐야 한다.

가져갈 한 문장

Pod가 살아 있다는 증거와 요청이 도착한다는 증거는 따로 확인해야 한다.

보충 섹션 6. Managed Service와 네트워크 의존성

Case 30. 관리형 DB인데 장애 책임이 사라지지 않는다

상황

RDS 같은 Managed DB를 쓰고 있어서 DB 운영은 안전하다고 생각했다.

그런데 특정 시간대에 connection timeout이 늘고, 애플리케이션 thread가 대기하며 API p95가 급격히 오른다.

콘솔의 DB 상태는 available이고, 애플리케이션 로그에는 외부 의존성 timeout만 반복된다.

관찰할 증거 또는 확인할 단서

  • DB 자체 장애인지, connection pool 포화인지
  • subnet, security group, route, DNS 경로
  • 애플리케이션 thread, pool, timeout 설정
  • DB metric과 API metric의 시간대 일치 여부
  • 임시 완화가 traffic 제한인지, pool 조정인지, read-only 전환인지

먼저 생각해보기

  • Managed Service는 어떤 책임을 줄이고 어떤 책임을 남기는가?
  • 콘솔 상태가 available이면 애플리케이션 의존성도 정상이라고 말할 수 있는가?
  • 네트워크, pool, query 중 어느 축을 먼저 격리해야 하는가?

찾아볼 문서

정리

Managed Service는 운영 책임을 없애는 선택이 아니라 책임의 위치를 바꾸는 선택이다.

백엔드 관점에서는 연결 수, timeout, query, network path, cloud metric을 함께 봐야 “DB가 문제”라는 말을 검증할 수 있다.

가져갈 한 문장

관리형 서비스를 쓴다는 것은 직접 관리하지 않는다는 뜻이지 관측하지 않아도 된다는 뜻은 아니다.

마무리 복습 질문

  1. 배포 실패가 났을 때 Rollback 전에 확인해야 할 데이터 관련 질문은 무엇인가?
  2. Nginx 502와 Spring 500을 구분하려면 어떤 두 로그를 같은 시간대로 비교해야 하는가?
  3. Health가 UP인데 핵심 API가 실패할 때 readiness, APM, SLI 중 무엇을 어떤 순서로 볼 것인가?
  4. Secret 회전 후 일부 Pod만 실패할 때 값 자체보다 먼저 확인해야 할 것은 무엇인가?
  5. 데이터 손실 사고에서 전체 Restore보다 Forward Fix가 안전할 수 있는 조건은 무엇인가?
  6. 개인 프로젝트에서 Kubernetes를 도입하기 전에 먼저 갖춰야 할 운영 산출물은 무엇인가?
  7. 좋은 Runbook의 각 단계에 반드시 있어야 할 정보는 무엇인가?
  8. 장애 보고서의 action item이 좋은지 판단하는 기준은 무엇인가?
  9. 체크리스트가 형식 문서가 되지 않으려면 어떤 항목이 필요할까?
  10. 지금 겪는 운영 상황을 Case 중 하나로 고른다면, 어떤 기존 문서 세 개를 먼저 열 것인가?

관련 문서

백링크