고정은 의도일 때만 남긴다
워크로드를 특정 위치에 고정하면 처음에는 예측 가능해 보인다. 그러나 시간이 지나 장비 상태나 용량이 바뀌면 그 고정이 복구를 막는 제약이 될 수 있다. 반드시 필요한 조건과 단순한 관성으로 남은 조건을 구분해야 한다.
배치 규칙은 성능, 데이터 일관성, 규정 준수처럼 설명 가능한 이유가 있을 때만 유지한다. 이유가 사라진 규칙을 걷어 내면 스케줄러가 사용할 수 있는 선택지가 늘고, 유지보수 중에도 서비스가 머물 자리를 찾기 쉬워진다.
이동성을 확인하는 질문
- 이 조건이 없으면 실제로 어떤 문제가 생기는가
- 대체 위치에서도 같은 방식으로 시작할 수 있는가
- 상태와 설정이 실행 위치에 묶여 있지 않은가
- 복구 절차가 특정 장비를 전제로 하지 않는가
구현보다 계약을 공개한다
공개 문서에는 실제 배치 정보 대신 애플리케이션이 플랫폼에 요구하는 계약을 설명한다. 필요한 자원의 성격, 중단을 견디는 방식, 상태를 복구하는 원칙 정도면 설계의 핵심을 전달할 수 있다. 내부 토폴로지는 운영 문서에만 남긴다.