배포 후 문제가 생겼을 때 원인 찾기

배포 환경에서만 문제가 나타나는 건 로컬과 운영의 차이 때문이 대부분이다. 하지만 그 차이가 뭔지 찾는 건 생각보다 복잡하다.

재현 조건 명확히 하기

먼저 문제가 정확히 언제, 어디서 나타나는지 파악해야 한다.

# 배포된 앱의 로그 확인
kubectl logs deployment/app-name --tail=100

# 최근 배포 이력
kubectl rollout history deployment/app-name

# 배포 전후 비교
kubectl diff -f app.yaml

"가끔 느려진다"와 "항상 느려진다"는 완전히 다른 원인을 가질 수 있다. 시간대, 사용자 수, 데이터 크기 등을 함께 기록해야 한다.

로그에서 읽을 부분

로그는 정답을 직접 말해주지 않지만, 어느 부분이 느려졌는지 힌트를 준다.

# 에러 로그만 필터링
kubectl logs deployment/app-name | grep -i error

# 특정 시간대 로그만
kubectl logs deployment/app-name --since=1h | tail -50

# 응답 시간 분석
kubectl logs deployment/app-name | grep -oE 'took [0-9]+ms' | sort -rn | head -20

로그에 응답 시간이 찍혀 있다면, 어느 엔드포인트가 느린지 알 수 있다. 데이터베이스 쿼리가 느렸다면, 인덱스 부재를 의심해볼 수 있다.

설정과 코드의 차이 비교하기

배포 환경에서 사용하는 환경 변수나 설정 파일을 로컬과 비교한다.

# 배포된 환경 변수 확인
kubectl exec deployment/app-name -- env | grep -i 'db\|cache\|timeout'

# 로컬 환경 변수
echo $DATABASE_URL
echo $REDIS_URL

데이터베이스 주소, 캐시 서버, 타임아웃 값이 다를 수 있다. 로컬에선 localhost지만 운영에선 원격 서버를 쓸 수도 있고, 타임아웃이 다르면 응답이 느려질 수 있다.

한 가지씩만 바꿔서 배포하기

원인이 보인다면 한 부분씩만 수정해서 배포한다.

# 데이터베이스 연결 풀 크기를 10에서 20으로 증가
# -> 배포
# -> 24시간 모니터링

# 캐시 TTL을 5분에서 10분으로 변경
# -> 배포
# -> 24시간 모니터링

한 번에 여러 개를 바꾸면 어디가 영향을 미쳤는지 알기 어렵다.

정상 상태 기준점 정하기

배포 후 문제가 해결됐는지 판단하려면 "정상"이 뭔지 정의해야 한다.

• 응답 시간: 평균 200ms 이하
• 에러율: 0.1% 이하
• CPU 사용량: 70% 이하

이런 기준을 정해두고 배포 후 1주일을 모니터링하면, 진짜 해결된 건지 판단할 수 있다.

마지막 확인

문제를 해결한 뒤엔 다음을 체크한다:

1. 로그에 에러가 더 이상 없는가
2. 메트릭(응답시간, 에러율)이 정상 범위인가
3. 실제 사용자의 반응이 개선됐는가

모두 맞다면 비로소 배포가 성공한 것이다.