LabHub
배우기 러닝패스 코스

ICA — 이스티오 인증 어소시에이트 · 재시도와 업무 트랜잭션의 경계 · 실습

응답은 실패했는데 업무는 끝났다

LabHub 에서 이어서 보기

목표

실제 Istio 재시도와 업무 기록을 비교하고, 응답 시간 초과·프로세스 종료가 생겨도 동일 업무의 중복을 막는 트랜잭션 경계를 구현합니다.

왜 중요한가

200은 업무 한 번의 증명이 아니고 504는 롤백의 증명이 아닙니다. 같은 주문의 전송 시도마다 새 업무 키를 만들면 중복 방지 장치도 무력해집니다. 반대로 내용이 같은 다른 주문을 합쳐도 오류입니다. 이 실습은 실제 메시의 합성 HTTP 업무와 별도 트랜잭션 코드 수정을 함께 다룹니다. 학생 코드 수정은 임시 SQLite 시험에 적용되며 HTTP 서버 코드를 자동 교체하는 기능은 아닙니다.

단계

1. python3 /opt/fixtures/ica-retry/runtime.py inventory의 출력 전체를 /root/ica-retry/inventory.json에 저장합니다. namespace는 ica-retry이며 client와 upstream의 실제 프록시가 준비되어야 합니다.
2. /root/ica-retry/routes.yaml에 networking.istio.io/v1 VirtualService retry-lab을 만듭니다. namespace는 ica-retry, hosts와 모든 목적지는 upstream.ica-retry.svc.cluster.local, 포트는 8080입니다. 첫 라우트 flaky는 /flaky·/naive exact 두 match, timeout 1s, attempts 2, perTryTimeout 1s, retryOn '503', retryIgnorePreviousHosts false입니다. 두 번째 lost는 /lost exact, timeout 500ms, attempts 0입니다. 마지막 control은 match 없이 같은 목적지, attempts 0입니다. 적용 후 collect retry를 실행해 retry.json의 실제 수신·업무 횟수를 비교합니다.
3. 같은 도구의 collect timeout을 실행합니다. timeout.json에는 /lost의 클라이언트 504, 서버의 커밋된 응답, 같은 키로 /charge를 호출한 회수 결과가 함께 있어야 합니다. 숫자를 직접 만들어 쓰지 않습니다.
4. collect conflict로 conflict.json을 저장합니다. 같은 업무 키에 금액을 100에서 200으로 바꾼 요청이 409를 받고 기존 업무 금액은 100으로 남는지 확인합니다.
5. collect durability로 durability.json을 저장합니다. 도구는 이 VM 안의 upstream 파드만 실제 삭제·재생성합니다. client UID는 같고 upstream UID·서버 instance는 달라야 합니다. 같은 업무 키와 응답 ID는 보존돼야 합니다.
6. /opt/fixtures/ica-retry/broken.py를 /root/ica-retry/transaction.py로 복사하고 charge의 기본 실행에 있는 분리 커밋 결함을 고칩니다. initialize·charge·Conflict, after-business·after-key·after-commit 강제 종료 지점을 유지합니다. 커밋 전에는 업무·키 모두 0개, 커밋 후에는 둘 다 1개가 남고 재시도 후 업무는 항상 1개여야 합니다.
7. transaction_probe.py /root/ica-retry/transaction.py identity로 같은 키의 동시 요청 8개를 확인합니다. 새 처리는 하나여야 하며 같은 키의 고객·금액 변경은 Conflict, JSON 순서 변경은 같은 응답, 다른 키의 같은 내용은 별개 업무여야 합니다. 잘못된 금액과 알 수 없는 필드는 ValueError로 거절합니다.
8. /root/ica-retry/incident.json에 추가 시도 2·최대 시도 3·naive 업무 3·중복 방지 업무 1을 기록합니다. timeout_means_rollback과 external_payment_exactly_once는 false입니다. changed_payload_status는 실제 충돌 코드, durable_scope는 same-vm-disk, atomic_scope는 single-sqlite-file로 적습니다. 앞선 실제 관측도 그대로 남겨 최종 채점합니다.

참고

단계 8개

  1. 실제 프록시와 파드 신원 기록
  2. 세 번 수신과 세 번 업무를 구별하기
  3. 504 뒤 이미 커밋된 업무 회수
  4. 같은 키의 다른 금액 거절
  5. 파드를 바꿔도 같은 업무 응답
  6. 분리 커밋 결함을 코드로 고치기
  7. 동시 요청과 별개 업무의 경계
  8. 응답과 업무를 나눈 사고 보고서