코지셀

왜 어려웠나

사람이 공급처에서 직접 주문하면 자동 구매 실행 기록이 남지 않아서, DB만 보는 중복 방지로는 잡을 수 없었어요. 공급처 주문 내역을 조회하는 가드는 있었지만 재시도일 때만 켜지게 만들어 두었어요. 첫 시도는 안전하다고 본 거예요. 게다가 상품 관리 도구 쪽 상태가 바뀌어도 동기화가 그 행을 다시 읽지 않아서, 이미 처리된 주문이 계속 구매 대상으로 남아 있었어요.

추적 과정

1. 1. 매칭 기준이 틀렸을까?

   가드 첫 부분을 보니, 첫 시도면 공급처 주문 내역을 아예 조회하지 않고 '중복 없음'을 돌려주고 있었어요.

2. 2. 이미 처리된 주문이 왜 아직 후보일까?

   상품 관리 도구의 상태가 바뀌면 동기화가 그 행을 다시 읽지 않아서, 로컬 행이 예전 상태로 굳어 있었어요.

3. 3. 조건문만 지우면 될까?

   아니었어요. 첫 시도에서는 조회 시작 시각이 실행 기록의 생성 시각으로 잡혀서, 그 전에 사람이 직접 한 주문이 조회 범위 밖으로 빠졌어요.

4. 4. 어느 계정으로 조회해야 할까?

   첫 시도에는 계정 선택 기록이 없을 수 있어서, 주문 라우팅에 지정된 공급처 계정을 대신 쓰게 했어요.

원인

중복 가드(evaluate_run_for_duplicate)가 재시도가 아니면 공급처를 조회하지 않고 바로 '중복 없음'을 돌려줬어요.

해결

첫 시도에도 공급처 주문 내역을 조회해요. 조회 시작 시각은 고객이 주문한 시각으로 잡고, 계정 선택 기록이 없으면 라우팅에 지정된 계정을 써요. 상품번호, 옵션, 수량과 금액이 확실히 일치할 때만 결제를 막고 후보에서 빼요. 공급처 조회 자체가 실패했을 때만은 모든 주문이 멈추지 않도록 통과시키는 예외를 그대로 뒀어요. 결제 결과가 불확실할 때 차단하는 것과는 다른 단계의 판단이에요.

if not _is_redispatch(run):
    return DuplicateMatch("none", reason="first_attempt")
since = _first_attempt_at(run)

is_redispatch = _is_redispatch(run)
account_ids = _supplier_account_ids_for_order(run)
if not account_ids:
    fb = _dispatch_supplier_account_id(run)  # 라우팅에 지정된 계정
    if fb:
        account_ids = [fb]
since = _first_attempt_at(run) if is_redispatch else _candidate_order_datetime(run)

왜 어려웠나

버그가 두 겹이었어요. 백엔드 컨테이너에는 docker를 다룰 도구와 소켓이 없었고, 그걸 붙여도 업데이트가 백엔드까지 다시 만들면서 업데이트하던 프로세스가 같이 종료됐어요. 업데이터가 자기가 돌고 있는 컨테이너를 교체하는 구조였던 거예요. 결제 세션을 들고 있는 워커를 그냥 다시 만들면 진행 중인 결제도 끊겼고요.

추적 과정

1. 1. 502는 어디서 날까?

   업데이트 API가 요청 안에서 업데이트를 동기로 실행하고 있었고, 첫 이미지 pull에서 바로 실패했어요.

2. 2. docker 소켓만 붙이면 될까?

   아니었어요. 컨테이너를 다시 만드는 순간 업데이터가 같이 죽어서 헬스체크와 롤백까지 가지 못했어요. 업데이트 로직은 멀쩡하고 실행 위치만 틀렸다고 결론 냈어요.

3. 3. 그럼 어디서 실행해야 할까?

   호스트의 systemd 감시자가 요청 파일을 보고, compose 프로젝트 밖의 일회성 컨테이너를 띄우게 했어요. bash로 다시 짜는 안은 검증과 롤백 로직이 중복돼서 버렸어요.

4. 4. 실제 서버에서도 돌아갈까?

   아무것도 바꾸지 않는 스모크를 돌리자, systemd 환경에 $HOME이 없어 스크립트가 바로 끝나고 작업 디렉터리 옵션이 이미지 설정을 덮어쓰는 문제가 나왔어요.

5. 5. 첫 실제 업데이트는?

   헬스체크 요청이 허용되지 않은 호스트 이름으로 400을 받고, 파일 권한 때문에 설정을 읽거나 쓰지 못했어요. 매번 자동 롤백이 서버를 지켰고, 하나씩 고쳐 1.0.9에서 1.0.10으로 업데이트에 성공했어요.

원인

업데이트 API(FleetApplyUpdateView)가 요청을 처리하면서, 교체 대상인 백엔드 컨테이너 안에서 업데이트를 동기로 실행했어요.

해결

API는 업데이트를 직접 하지 않고 요청 파일만 남긴 뒤 202를 돌려줘요. 이미 요청이 있으면 409예요. 호스트의 systemd 감시자가 이 파일을 보고 스크립트를 실행해요. 스크립트는 잠금을 잡고, 자동 구매를 멈추고, 진행 중인 결제가 0건이 될 때까지 기다린 뒤, 현재 버전 이미지로 일회성 업데이트 컨테이너를 띄워요. 이 컨테이너는 compose 프로젝트 밖에 있어서 다른 컨테이너가 다시 만들어져도 살아남아요.

try:
    result = run_fleet_update(str(offer["target_version"]), ...)
except FleetUpdateError:
    return Response({"detail": "...이전 버전으로 복구됨"}, status=502)

# API: 요청만 남기고 바로 응답
if self_update_request_pending():
    return Response({...}, status=409)
if not request_self_update(offer):   # .fleet-control/request.json
    return Response({...}, status=501)
return Response({"queued": True}, status=202)

# 호스트 스크립트 (systemd path 감시자가 실행, 줄인 것)
flock -n 9 || exit 0; trap cleanup EXIT INT TERM
pause; drain until inflight == 0        # 15분 넘으면 업데이트 중단
docker run --rm -v /var/run/docker.sock:... <현재 버전 이미지> \
  python manage.py fleet_update --request request.json

왜 어려웠나

Chromium의 프로필 잠금은 '호스트이름-PID' 형식인데, 컨테이너에서는 호스트이름이 컨테이너 ID예요. 컨테이너가 새로 만들어지면 남은 잠금이 '다른 컴퓨터가 쓰는 프로필'로 보여요. 앱의 정리 로직은 호스트이름이 다르면 손대지 않게 되어 있었고, 다른 PID 네임스페이스라 그 프로세스가 살아 있는지 확인할 방법도 없었어요. 강제 종료 순간 브라우저가 열려 있을 때만 생기는 간헐적인 문제였고요.

추적 과정

1. 1. 잠금 주인이 아직 살아 있을까?

   잠금이 가리키는 호스트이름은 어떤 컨테이너에도 없었고, 그 프로필을 쓰는 Chromium 프로세스도 0개였어요.

2. 2. 정리 코드가 안 불렸을까?

   정상으로 불렸어요. 다른 호스트의 잠금은 설계상 회수하지 않는 거였어요.

3. 3. 오프라인 복구 도구로 충분할까?

   첫 수정은 같은 볼륨을 쓰는 워커 5개를 멈춰야 해서, 운영 중에는 실행할 수 없었어요.

4. 4. 잠금은 언제 생겼을까?

   잠금 파일 시각을 같은 날 배포 로그와 맞춰 보니, 14분 뒤에 '2분 안에 종료되지 않아 강제 종료'한 기록이 있었어요.

5. 5. 실패가 모두 같은 원인일까?

   정확히 30초에 끝난 실패는 페이지 로딩 대기 시간 초과로 원인이 달랐어요. 따로 분류했어요.

원인

배포 때 컨테이너가 2분 종료 유예를 넘겨 강제 종료됐고, Chromium이 잠금을 풀지 못했어요. 사라진 컨테이너를 가리키는 잠금이 남았는데 회수할 경로가 없었어요. 같은 서버에서 60일 동안 배포 중 강제 종료가 40번 있었어요.

해결

잠금의 호스트이름이 컨테이너 ID 형식이면, 그 ID를 가진 컨테이너가 상태와 상관없이 하나라도 남아 있는지 확인해요. 이어서 호스트의 모든 프로세스를 훑어, 장치와 inode가 같은 프로필 디렉터리를 쓰는 Chromium이 있는지 봐요. 확인이 하나라도 불완전하면 지우지 않아요. 워커를 멈추지 않는 온라인 복구 모드와, 배포가 끝날 때마다 자동으로 회수하는 단계도 넣었어요.

host, pid_text = os.readlink(lock_path).rsplit("-", 1)
if host != socket.gethostname() or not pid_text.isdigit():
    return False   # 컨테이너가 바뀌면 영원히 False

m = re.fullmatch(r"([a-f0-9]{12}|[a-f0-9]{64})-([1-9][0-9]*)", target)
for c in containers:                     # 모든 상태의 컨테이너
    if c["Id"].startswith(m[1]) or c["Config"].get("Hostname") == m[1]:
        raise ProfileInUseError("former_owner_container_present")
ident = (info.st_dev, info.st_ino)
for ref in process_refs:                 # /proc/<pid>/root 기준 --user-data-dir
    if ref.error:
        raise ProfileInUseError("host_process_scan_incomplete")
    if ref.identity == ident:
        raise ProfileInUseError("host_profile_process_still_active")