새 이미지 업로드 경로를 운영에서 직접 검증하고 싶었다. ALB 에 서버가 여러 대 물려 있으니 한 대만 deregister-targets 로 떼어 거기서 시험하면 되겠다고 생각했다.
Table of contents
Open Table of contents
조사 — 격리되는 것과 안 되는 것
떼면 무엇이 격리되는지를 적어 봤다. AWS 공식 문서대로 대상을 등록 해제하면 진행 중 요청만 드레인하고 새 요청은 안 보내므로 인입 사용자 트래픽은 격리된다.
RDS 와 S3 와 SQS 큐와 이미지 서비스는 나머지 서버들과 그대로 공유된다. 하나만 격리되고 넷은 공유인 상태였다.
원인 — 공유 큐가 만드는 경로
특히 큐가 위험했다. 등록 경로를 보니 등록 직후 조건이 맞으면 SyncProductJob 을 dispatch() 로 큐에 넣고 있었다.
카나리 박스가 만든 작업이 공유 SQS 에 들어가고 나머지 서버의 queue:work 중 하나가 그것을 집어 실제 마켓에 송신한다. 떼어 놓은 박스에서 시험했는데 실제 마켓에 진짜 상품이 올라가는 경로가 열려 있었다.
판단 기준 — 이름을 붙인 상태
이 상황을 한 문장으로 정리했다. 분리된 환경이 아니라 분리된 입구와 공유된 데이터라는 것이다.
분리된 환경이라고 생각하면 무엇을 해도 안전할 것 같지만 실제로는 읽기와 쓰기가 다 공유된다. 그래서 시험할 수 있는 것은 연동 작업이 안 걸리는 조건뿐이고 채널이 연결되지 않은 상품이나 테스트 전용 입점사로만 해야 한다.
주의 — 성공하면 원복이 없는 시험
수정 시험은 더 나빴다. 이미지 업로드가 PUT 교체 방식이라 성공하면 기존 이미지가 우리 쪽 것으로 영구 교체되고 실패했을 때만 catch 의 보상 로직이 원복한다.
보상은 실패 경로에만 있으므로 시험이 성공하는 순간 실제 셀러의 이미지가 바뀐다. 성공하면 안 되는 시험이고 그런 것은 하지 않는다.
원복 목록과 대안
시험 후 ROLLBACK.md 에 FEATURE_NEW_UPLOAD 플래그와 config:cache 와 코드와 register-targets 재등록을 넣었는데 하나가 빠져 있었다. 성공한 시험이 남긴 상품과 미디어 레코드와 저장소 객체를 정리하는 항목이다.
시험이 성공하면 흔적이 남고 코드를 원복해도 데이터는 남으므로 데이터를 안 넣으면 원복 목록이 반쪽이 된다. 두 가지 방법이 있었는데 전용 입점사로 카나리 박스에서 시험하는 것과 RDS 덤프를 붙인 로컬에서 검증하는 것이다. 내 권고는 뒤쪽이었다. 이유는 데이터가 완전히 격리돼 성공해도 남는 것이 없어서다. 대신 실연동 충실도가 떨어져 마켓 응답 형식은 검증 못 하는 것을 감수했다. 충실도와 안전의 교환이므로 무엇을 검증하려는지에 따라 고르도록 둘 다 적고 판단은 넘겼다.
정리
- 트래픽 격리와 데이터 격리는 다른 얘기다
- ALB 에서 떼도 RDS 와 S3 와 SQS 는 공유된다
- 큐가 공유되면 격리된 박스가 만든 작업을 다른 박스가 실행한다
- 분리된 환경이 아니라 분리된 입구와 공유된 데이터다
- 검증은 연동이 안 걸리는 전용 대상으로만 한다
- 교체 방식은 성공하면 원복이 없다
- 원복 목록에 성공한 시험이 남긴 데이터를 넣는다
- 대안은 충실도와 안전의 교환으로 적고 판단은 넘긴다