작은 서비스도 어느 순간부터 손대기 어려워진다. 코드는 저장소에 있지만 실제 동작에 필요한 것은 그보다 많다. 데이터베이스, 도메인, 서버 설정, 어딘가에만 남아 있는 기억이 함께 서비스를 지탱한다. 운영비는 적어도 다시 만드는 비용은 클 수 있다. 배포 도구를 하나 더 고르기 전에, 이 서비스가 돌아오려면 무엇이 남아 있어야 하는지 적어보고 싶다.
kqr의 NixOS is making me less afraid는 선언적 설정이 개인 서비스를 관리하는 마음에 어떤 변화를 주었는지 설명하는 글이다. 저자의 경험이지 다른 서버의 복구를 보장하는 자료는 아니다. 여기서 생각해볼 부분은 읽을 수 있는 설정과 변경에 대한 자신감의 관계다. 그 자신감이 어디까지 유효한지 알려면, 설정에 들어 있지 않은 것도 살펴야 한다.
설정 파일 밖의 의존성
한 사람이 쓰는 가상의 RSS 서비스를 떠올려보자. 애플리케이션 패키지와 웹서버 설정은 다시 만들 수 있다. 구독 목록과 읽음 상태는 데이터베이스에 있다. 도메인은 서버를 가리키고, 비밀값은 데이터베이스 접근을 허용한다. 도메인과 복구 이메일을 관리하는 외부 계정도 필요할 수 있다. 패키지를 다시 설치한다고 읽은 기록이 생기지는 않는다. 데이터베이스를 복원해도 도메인 계정에 접근하지 못하면 공개 주소를 되찾기 어렵다.
복구할 때 필요한 순서로 이 요소들을 적어본다. 먼저 실행할 공간과 그곳을 관리할 접근 수단이 있다. 다음은 애플리케이션과 요구사항을 가리키는 설정 리비전이다. 사용할 수 있는 백업과 승인된 비밀값 제공 경로가 뒤따른다. 마지막으로 공개 주소와 올바른 서비스가 돌아왔음을 확인할 기준이 필요하다. 기록에는 각 요소를 어디서 구하는지 적되, 암호나 복구 코드를 복사해 넣지 않는다. 설명 문서가 또 하나의 비밀 보관소가 되면 관리할 경계가 늘어난다.
이를 서비스의 ‘복구 범위’라고 불러볼 수 있겠다. 다시 쓸 만한 상태를 만드는 데 필요한 자료와 접근 권한의 최소 묶음이다. 서버 바깥에 있는 것까지 포함한다. 값싼 기기에 문서화되지 않은 의존성이 많다면, 더 비싼 관리형 서비스보다 복구 범위가 넓을 수도 있다. 그렇다고 어느 쪽이 반드시 저렴하다는 결론은 아니다. 월 이용료만 비교할 때 빠뜨린 시간과 접근 문제를 함께 보자는 뜻이다. 무엇을 잃어도 되는지에 따라 선택은 달라질 수 있다.
원본을 건드리지 않는 복구 연습
가상의 RSS 서비스라면 날짜가 붙은 백업을 격리된 임시 환경에 복원하는 연습을 제안할 수 있다. 주소를 다르게 쓰고 외부 이메일 발신은 막는다. 기존 서비스는 그대로 둔다. 알려진 구독 항목이 나타나는지, 특정 글의 읽음 상태가 백업 시점과 맞는지 확인한다. 첫 페이지가 열린다는 사실만으로 복구가 끝난 것은 아니다. 서비스를 쓰던 이유인 데이터가 돌아왔는지도 봐야 한다. 이는 실제로 수행했다는 보고가 아니라, 무엇을 검증할지 정하는 설계다.
허용할 수 있는 손실도 드러내야 한다. 매일 밤 한 번 백업하는 가정이라면 다음 백업 직전의 장애에서 거의 하루의 변경이 빠질 수 있다. 특정 백업 제품의 성능에 대한 말이 아니라 그 일정에서 생기는 간격이다. 읽음 기록 하루가 없어져도 괜찮다면 충분할 수 있다. 대체할 수 없는 제출물을 저장한다면 같은 일정은 맞지 않을 수 있다. 견딜 수 있는 공백을 먼저 적으면 백업 주기를 선택한 이유도 분명해진다. ‘백업이 있다’와 ‘필요한 것을 되찾을 수 있다’는 다른 확인이다.
연습에서 막힌 부분은 유용한 결과다. 빠진 확장 기능, 문서에 없는 경로, 열리지 않는 백업이 발견될 수 있다. 해당 의존성을 작게 고친 뒤 영향을 받은 검사를 다시 하면 된다. 그 과정에서 모든 인프라를 갈아엎을 이유는 없다. 복구 연습이 조용히 마이그레이션으로 바뀌면 질문도 바뀐다. 알고 싶었던 것은 현재 서비스가 돌아올 수 있는지였지, 새 구조를 설계할 수 있는지가 아니었다. 실패한 자료도 남겨야 다음 연습이 같은 빈틈에서 시작하지 않는다.
한 장의 기록이 알려주는 한계
짧은 복구 기록에는 설정 리비전, 백업 날짜, 기대하는 데이터 기준점, 마지막 연습 날짜, 미해결 의존성을 남길 수 있다. 비밀값은 기존 승인 저장소에서 받아야 한다고 적으면 된다. 멈출 기준도 필요하다. 계정을 확인할 수 없거나 유일한 정상 데이터를 덮어쓸 위험이 있다면, 즉흥적으로 진행하기보다 남은 것을 보존하고 빠진 조건부터 해결한다. 연습의 목적이 불안을 줄이는 것이라면, 불확실성을 성공으로 덮는 기록은 도움이 되지 않는다.
개인 프로젝트마다 거창한 가용성 목표를 둘 필요는 없다고 생각한다. 다만 그 안의 가치와 유지 노력은 맞아야 한다. 작은 서버에 서비스를 하나 더 얹기 전에, 복구 범위를 한 장으로 설명하고 안전하게 확인할 수 있는지 물어보면 좋겠다. 아직 어렵다면 그 한 장을 쓰는 일이 먼저일 수 있다. 무엇을 믿어도 되고 무엇이 남아야 하는지 아는 것은, 서버가 오늘 잘 켜져 있다는 사실과는 다른 종류의 안심을 준다.
