저장공간 부족은 1시간이었는데 흔적은 이틀 남았다 — 원인을 못 찾은 채 다음을 대비한 이야기

앞선 글에서 "주의 280건"의 정체는 종료된 Evicted Pod를 하루 종일 다시 센 숫자라는 것까지 확인했다. 남은 질문은 하나였다. 그 Pod들은 왜 쫓겨났고, 노드의 임시 저장공간은 왜 모자랐을까.결론부터 적으면 원인은 끝내 밝히지 못했다. 대신 다음에 같은 일이 생기면 원인이 남도록 관측을 하나 추가했다. 이 글은 왜 원인을 못 찾았는지, 그래서 무엇을 하고 무엇을 하지 않기로 했는지에 대한 기록이다.먼저 시간표를 맞춰 봤다노드 관측 이력과 Evicted Pod의 관측 시각을 나란히 놓고 보니 예상과 달랐다. 저장공간이 모자란 시간은 길지 않았다. 시각(KST) ..

일일 요약의 "주의 280건"은 장애가 아니었다 — 같은 종료 Pod를 하루 종일 다시 센 숫자

매일 아침 클러스터 점검 요약이 메신저로 온다. 어느 날 이런 줄이 와 있었다.정상 8 / 주의 280 / 위험 0 / 실패 0노드가 몇 대 안 되는 클러스터에서 주의 280이라니, 어디가 크게 잘못된 줄 알았다. 그런데 숫자만 있고 무엇이 문제인지는 어디에도 적혀 있지 않았다. 결국 이렇게 되물을 수밖에 없었다. "주의 280건이 뭐야?"확인해 보니 이 숫자는 노드 280개가 아니라 점검 회차를 센 것이었고, 그 대부분은 이미 끝난 Pod 몇 개가 하루 종일 반복해서 잡힌 결과였다.먼저 280이 무엇을 세는 숫자인지 확인했다요약은 하루 동안 쌓인 점검 기록을 상태별로 세어서 만든다. 점검이 5분마다 돌면 하루에 최대 288번이다. 그중 280번이 주의라면 거의 모든 회차가 주의였다는 뜻이다.여기서 두 ..

Kubernetes 검증 환경을 운영과 분리한다는 것은 무엇일까?

코드를 수정한 뒤 코드 리뷰만 해서는 실제로 동작하는지 완전히 알기 어렵다.Dockerfile은 정상으로 보여도 실제 빌드할 때 실패할 수 있고, 이미지가 만들어져도 Pod가 실행되자마자 죽을 수 있다. Pod가 정상적으로 떠도 실제 HTTP 요청에는 제대로 응답하지 않을 수도 있다.그래서 승인하기 전에 실제 Kubernetes에 애플리케이션을 한번 띄워보는 임시 검증 환경을 만들려고 했다.그런데 여기서 궁금한 점이 생겼다.검증용 Deployment를 하나 더 띄운다고 해서 정말 운영과 분리되는 걸까?Ingress를 분리한다는 건 뭘 따로 만든다는 뜻일까?Secret도 새로 만들어야 하는 걸까?이 부분을 하나씩 정리해봤다. (취미생활)먼저 전체 구조를 보자현재 운영 서비스가 다음과 같다고 생각해보자.사용..

임시 검증 인스턴스는 운영 배포를 건드리지 않아야 한다

코드 리뷰만으로는 "이 변경이 실제로 동작하는가"를 확인할 수 없다. 문법이 맞고 로직이 그럴듯해 보여도, 실제로 이미지를 빌드해서 띄워봐야만 드러나는 문제가 있다. 그래서 승인 전에 실제로 한 번 띄워보는 검증 인스턴스를 만들기로 했을 때, 가장 먼저 정한 원칙은 하나였다. 검증 인스턴스는 운영 배포와 최대한 닮아야 하지만, 운영 배포의 리소스 이름과 트래픽과 Secret 경계는 절대 건드리지 않아야 한다는 것이다.코드 리뷰의 한계여러 저장소의 변경을 사람 대신 검토하고 PR까지 만들어주는 자동화를 운영하다 보면, 어느 시점부터는 "코드가 그럴듯한가"와 "코드가 실제로 동작하는가"가 다른 질문이라는 게 눈에 밟힌다. Dockerfile 문법은 맞는데 빌드 도중 의존성이 깨질 수도 있고, 이미지는 정상적..

Codex worker를 일반 응답과 이미지 응답으로 나눈 이유

챗봇에서 사용자 요청을 받아 AI 응답을 만드는 컴포넌트를 Codex worker라고 부른다. 처음에는 이 worker 하나가 일반 대화 응답과 이미지가 포함된 요청(이미지를 이해해야 하는 응답)을 함께 처리했다. 요청을 받는 곳도 하나, 처리하는 프로세스도 하나였으니 구조는 단순했다. 문제는 이 단순함이 두 가지 성격이 전혀 다른 요청을 한 그릇에 담고 있었다는 데 있었다.문제 상황: 이미지 요청 하나가 일반 대화까지 늦춘다이미지를 이해해야 하는 응답은 텍스트만 처리하는 응답보다 처리 시간이 길어지는 경우가 많다. 이미지를 분석하는 단계가 먼저 끝나야 그다음 응답을 만들 수 있기 때문이다. 그런데 같은 worker가 두 요청을 순서대로 처리하다 보니, 앞에 이미지 요청이 걸려 있으면 뒤따라온 짧은 인사..

패스키 지문 창이 안 뜨던 문제, 서버를 고치지 않았는데 브라우저와 Play 서비스를 올리니 해결됐다

지난 글에서 모바일 Chrome의 패스키 로그인이 지문 창 없이 멈추는 문제를 다뤘다. 결론은 서버가 아니라 브라우저와 기기 인증 서비스 쪽 호환성 문제로 보는 것이 가장 타당하다는 것이었다. 이후 Chrome과 Google Play 서비스를 업데이트했더니 같은 기기, 같은 패스키, 같은 서버에서 로그인이 정상 동작했다. 그 사이 서버 코드는 바꾸지 않았다.결론이 맞았는지는 "서버를 고치지 않았는데 좋아졌는가"로 확인할 수 있었다.그때 무엇을 근거로 서버를 건드리지 않았나증상은 버튼을 눌러도 지문 창이 뜨지 않는 것이었다. 서버 로그를 보면 로그인 옵션 요청은 200이었고 인증 결과를 보내는 verify 요청은 아예 없었다. 서버가 응답을 못 준 것이 아니라, 브라우저가 인증 결과를 보내기 전에 흐름이 ..