시스템 변경, 호환성을 고려해야 하는 이유
시스템 변경(System Change)은 불가피하며, 호환성을 고려하지 않으면 롤백(Rollback)조차 무의미해짐
혼합 버전(Mixed Versions), 지연된 소비자(Delayed Consumers), 부분적 롤아웃(Partial Rollouts)을 수용하는 설계가 중요함
데이터 구조 변경(Data Structure Change)은 롤백을 어렵게 만들며, 상태 관리(State Management)의 중요성을 강조함
생산 환경(Production Environment)에서 호환성을 확보하기 위한 설계 및 테스트(Design and Testing)의 중요성을 역설함
롤백(Rollback)의 허구성
게시물에서는 롤백이 안전망이 될 수 없음을 강조하며, 데이터 구조 변경(Data Structure Change)이 발생하면 이전 버전으로의 복귀가 어려워진다고 지적한다. 특히, 스키마 변경, 새로운 데이터 구조 저장, 이벤트 형식 변경 등은 롤백을 복잡하게 만든다. 따라서, 시스템 설계 시 호환성(Compatibility)을 고려하여 이전 버전과 새로운 버전이 동일한 상태에서 작동할 수 있도록 해야 한다. 이는 상태 관리(State Management)의 중요성을 시사한다. 롤백은 코드 수준에서 가능할지라도, 데이터 상태가 호환되지 않으면 무용지물이 된다.
프로듀서(Producer)와 컨슈머(Consumer)의 속도 차이
게시물은 프로듀서와 컨슈머 간의 속도 차이로 인한 호환성 문제를 지적하며, 이는 메시지 기반 시스템(Message-Driven Systems)에서 흔히 발생한다. 새로운 페이로드를 전송하는 프로듀서와 이전 백로그를 처리하는 지연된 컨슈머가 공존하는 상황에서, 컨슈머가 새로운 페이로드를 이해하지 못하면 오류가 발생한다. 이러한 문제를 해결하기 위해, 호환성(Compatibility)을 고려한 설계를 통해 지연된 컨슈머(Delayed Consumers), 부분적 채택(Partial Adoption), 병합 규칙(Merge Rules)을 처리해야 한다. 이는 시스템의 안정성을 높이는 데 기여한다.
경계 지점(Boundary)에서의 문제 발생
게시물은 시스템의 경계 지점에서 호환성 문제가 발생하기 쉽다고 강조한다. 특히, 새로운 필드가 추가되거나, 페이로드의 순서가 변경되는 경우, 기존 컨슈머가 문제를 겪을 수 있다. 이러한 문제를 해결하기 위해, 관찰 가능한 동작(Observable Behavior)을 중요하게 고려해야 한다. 즉, 문서화되지 않은 동작이라도 많은 사람이 의존하는 경우, 실제 인터페이스의 일부로 간주해야 한다. 호환성(Compatibility)을 위한 설계는 추가적인 스키마 변경, 이중 쓰기, 섀도 리드, 기능 플래그, 텔레메트리 개선 등을 필요로 할 수 있다.
호환성을 위한 설계의 중요성
게시물은 호환성을 위한 설계가 시스템의 신뢰성을 높이는 데 기여한다고 주장한다. 혼합 버전(Mixed Versions), 지연된 소비자(Delayed Consumers), 부분적 롤아웃(Partial Rollouts)을 고려한 설계는 시스템의 변화에 유연하게 대응할 수 있게 한다. 또한, 롤백 결정을 실제 상태에 적용할 수 있도록 지원한다. 게시물은 구조적 변경 전에 이전 버전이 새로운 상태에서 안전하게 실행될 수 있는지, 지연된 컨슈머가 새로운 페이로드를 처리할 수 있는지, 파괴적인 변경과 추가적인 변경이 분리되었는지 등을 질문하며, 텔레메트리(Telemetry)를 통해 이전 경로를 사용하는 사용자를 파악하는 것이 중요하다고 강조한다.
