레코드를 바꾸면 그 변경이 즉시 온 세상에 반영될 것 같지만 실제로는 그렇지 않다. 값을 바꾼 직후에도 한동안은 옛 값으로 응답받는 사용자가 남아 있고, 새 값이 완전히 자리 잡기까지는 시간이 걸린다. 이 시차를 흔히 전파라고 부른다. 전파를 이해하지 못한 채 레코드를 바꾸면, 서비스가 반쯤 옛 서버로 반쯤 새 서버로 흩어지는 어정쩡한 상태에 당황하게 된다.
이번 편은 이 전파와 그 열쇠가 되는 유효 기간을 다룬다. 유효 기간이 무엇을 뜻하는지, 전파라는 말이 실제로는 무엇을 가리키는지, 유효 기간을 언제 낮추고 언제 높여야 하는지, 전파 중의 어정쩡한 상태를 어떻게 관리하는지, 그리고 무중단으로 서비스를 옮기는 순서는 어떻게 짜야 하는지를 차례로 짚는다. 전파의 원리를 손에 쥐면 레코드 변경이 더는 불안한 도박이 아니게 된다.
유효 기간이라는 재사용 허용치
모든 레코드에는 유효 기간이 붙는다. 이 값은 조회한 답을 얼마나 오래 재사용해도 되는지를 초 단위로 나타낸다. 리졸버는 어떤 이름의 답을 받으면 이 기간만큼 저장해 두고, 그동안 같은 질문이 오면 원본에 다시 묻지 않고 저장된 답을 그대로 돌려준다. 유효 기간은 곧 원본에 되묻기 전까지 답을 재사용해도 좋은 시간의 허용치다.
이 허용치는 조회의 부담과 변경의 민첩함 사이의 균형을 정한다. 유효 기간이 길면 답이 오래 저장되어 원본에 묻는 횟수가 줄고 조회가 빨라지지만, 값을 바꾸었을 때 옛 답이 오래 남아 변경이 더디게 퍼진다. 반대로 유효 기간이 짧으면 변경이 빨리 반영되지만, 저장이 자주 만료되어 원본에 묻는 횟수가 늘고 네임서버의 부하가 커진다. 유효 기간을 정하는 일은 이 두 가지를 저울질하는 결정이다.
유효 기간은 레코드마다 따로 설정할 수 있다. 자주 바뀌지 않는 안정적인 레코드는 길게 두어 조회 효율을 높이고, 곧 바꿀 예정인 레코드는 짧게 두어 변경에 대비한다. 그래서 유효 기간은 고정된 값이 아니라, 그 레코드가 앞으로 얼마나 자주 바뀔지를 예상해 조절하는 운영의 손잡이다. 평상시에는 길게, 변경을 앞두고는 짧게 두는 것이 기본 전략이다.
유효 기간의 기준은 원본 네임서버가 응답에 실어 보내는 값이다. 리졸버는 이 값을 받아 그만큼 답을 저장하지만, 일부 리졸버는 자체 정책으로 이 기간을 더 늘리거나 최소값을 강제하기도 한다. 그래서 유효 기간을 짧게 설정했다고 해서 모든 리졸버가 정확히 그 시간에 맞춰 답을 버리는 것은 아니다. 전파 시간을 가늠할 때는 이 편차를 감안해 여유를 두어야 한다.
유효 기간을 초 단위로 다룬다는 점도 익혀 둘 만하다. 한 시간은 3600, 하루는 86400처럼 값이 초로 표기되므로, 익숙하지 않으면 의도한 것보다 훨씬 길거나 짧은 기간을 설정하는 실수를 저지른다. 특히 변경을 앞두고 유효 기간을 줄일 때 이 단위를 착각하면, 며칠로 줄인다는 것이 몇 주로 늘어나 전파 준비가 어긋난다. 유효 기간을 만질 때는 그 값이 실제로 몇 분, 몇 시간에 해당하는지를 매번 환산해 확인하는 습관이 필요하다.
전파의 실체
전파라는 말은 마치 변경이 물결처럼 서버에서 서버로 퍼져 나가는 장면을 떠올리게 하지만, 실제 메커니즘은 그렇지 않다. 원본 네임서버의 값은 바꾸는 즉시 바뀐다. 다만 세상 곳곳의 리졸버가 그 전에 저장해 둔 옛 답을 유효 기간이 끝날 때까지 계속 쓸 뿐이다. 전파는 값이 퍼지는 것이 아니라, 저장된 옛 답이 하나씩 만료되어 사라지는 과정이다.
이 사실을 이해하면 전파 시간이 왜 유효 기간에 의해 결정되는지가 분명해진다. 어떤 리졸버는 값을 바꾸기 직전에 옛 답을 저장했을 수 있고, 그 저장은 유효 기간이 다 지나야 만료된다. 그래서 최악의 경우 변경이 완전히 퍼지기까지는 옛 유효 기간만큼의 시간이 걸린다. 전파가 끝나는 시점을 예측하려면 값을 바꾸기 전에 그 레코드의 유효 기간이 얼마였는지를 보아야 한다.
전파 중에는 사용자마다 받는 답이 다르다. 옛 답을 저장한 리졸버를 쓰는 사용자는 옛 서버로 향하고, 저장이 만료되었거나 처음 묻는 사용자는 새 서버로 향한다. 같은 순간에 어떤 사용자는 옛 서비스를, 어떤 사용자는 새 서비스를 보게 되는 것이다. 이 불균일한 상태는 유효 기간이 다 지날 때까지 이어지며, 전파의 본질적인 특성이다.
전파 상태를 확인하는 흔한 방법은 여러 지역의 리졸버에 같은 질문을 던져 보는 것이다. 지역마다 저장된 답이 다르므로, 여러 곳에서 조회해 보면 새 값이 얼마나 퍼졌는지를 가늠할 수 있다. 다만 이 방법으로도 모든 리졸버의 상태를 알 수는 없으므로, 전파가 끝났다고 단정하기보다 옛 유효 기간만큼의 시간이 지날 때까지 기다리는 편이 안전하다.
유효 기간을 낮추고 높이는 전략
레코드를 바꿀 계획이 있다면, 실제 변경보다 먼저 유효 기간을 낮추는 것이 정석이다. 변경을 앞두고 유효 기간을 짧게 줄여 두면, 이후에 값을 바꾸었을 때 옛 답이 짧은 시간 안에 만료되어 전파가 빠르게 끝난다. 다만 이 유효 기간 단축 자체도 전파되어야 효력이 생기므로, 옛 유효 기간만큼 기다린 뒤에야 실제 변경을 진행할 수 있다.
이 순서를 지키지 않으면 유효 기간 단축의 효과가 사라진다. 유효 기간을 줄이자마자 곧바로 값을 바꾸면, 아직 옛 긴 유효 기간으로 저장된 답들이 그대로 남아 전파가 예상보다 오래 걸린다. 유효 기간 단축은 변경보다 며칠 앞서 미리 해 두어야, 변경 시점에는 모든 리졸버가 이미 짧은 유효 기간을 따르고 있게 된다. 준비의 순서가 전파 속도를 좌우한다.
변경이 끝나고 안정되면 유효 기간을 다시 높이는 것이 좋다. 짧은 유효 기간을 계속 유지하면 네임서버가 잦은 조회에 시달리고, 리졸버의 저장 효율도 떨어진다. 값이 다시 안정적으로 자리 잡았다면 유효 기간을 원래의 긴 값으로 되돌려, 평상시의 조회 효율을 회복하는 것이 바람직하다. 짧은 유효 기간은 변경 기간에만 쓰는 임시 상태로 다루어야 한다.
유효 기간을 정할 때는 그 레코드가 서비스에서 얼마나 중요한지도 고려한다. 장애 시 빠르게 다른 서버로 돌려야 하는 핵심 레코드는 유효 기간을 다소 짧게 유지해 대응의 민첩함을 확보하고, 거의 바뀌지 않는 부속 레코드는 길게 두어 효율을 취한다. 유효 기간은 획일적으로 정할 값이 아니라 레코드의 성격에 맞춰 개별적으로 조율할 값이다.
전파 중의 어정쩡한 상태
전파 중에는 옛 서버와 새 서버가 동시에 사용되는 상태가 불가피하게 발생한다. 이 상태에서 두 서버가 서로 다른 데이터를 다루면 심각한 문제가 생긴다. 어떤 사용자의 요청은 옛 서버에, 어떤 사용자의 요청은 새 서버에 도달하므로, 두 서버가 같은 데이터를 공유하지 않으면 사용자마다 보는 내용이 갈리고 갱신이 한쪽에만 반영된다.
그래서 전파를 동반하는 이전에서는 두 서버가 같은 데이터를 바라보게 만드는 것이 핵심이다. 데이터 저장소를 공유하거나, 옛 서버가 새 서버로 요청을 넘기게 하거나, 데이터를 미리 완전히 옮겨 두는 방식으로 전파 기간 동안의 일관성을 확보한다. 이 준비 없이 서버만 바꾸면 전파 기간 내내 데이터가 두 갈래로 갈라지는 사고가 벌어진다.
어정쩡한 상태를 줄이는 또 다른 방법은 두 서버가 동일하게 응답하도록 만들어 두는 것이다. 옛 서버와 새 서버가 완전히 같은 내용을 서비스하면, 사용자가 어느 쪽에 도달하든 차이를 느끼지 못한다. 이렇게 두 서버를 잠시 나란히 운영하다가 전파가 끝난 뒤 옛 서버를 내리면, 사용자는 전환이 일어난 사실조차 알아채지 못한다. 무중단 전환의 이상적인 모습이다.
전파 중에 문제가 발견되면 값을 되돌려야 할 수도 있다. 그런데 되돌리기 역시 전파가 필요하므로 즉시 원상 복구되지 않는다. 이 때문에 되돌림에 걸리는 시간까지 감안해 변경을 계획해야 하며, 유효 기간이 짧을수록 되돌림도 빠르다는 점이 위험 관리의 근거가 된다. 변경 전에 유효 기간을 낮추는 것은 전파를 빠르게 할 뿐 아니라 되돌림도 빠르게 하는 이중의 안전장치다.
무중단 이전의 순서
서비스를 다른 서버로 옮기는 무중단 이전은 정해진 순서를 따를 때 안전하다. 첫 단계는 새 서버를 완전히 준비해 옛 서버와 동일하게 동작하도록 만드는 것이다. 이 단계에서는 아직 레코드를 바꾸지 않으므로 사용자는 모두 옛 서버로 향하며, 새 서버는 직접 이름으로 접근해 정상 동작을 확인하는 검증 대상으로만 쓰인다.
두 번째 단계는 변경을 앞두고 해당 레코드의 유효 기간을 짧게 낮추는 것이다. 이 단축이 전파되기를 옛 유효 기간만큼 기다린 뒤에야 실제 전환을 진행한다. 세 번째 단계에서 레코드의 값을 새 서버로 바꾸면, 짧아진 유효 기간 덕분에 전파가 빠르게 이루어진다. 이때 옛 서버와 새 서버가 같은 데이터를 바라보고 있어야 전파 기간의 일관성이 지켜진다.
네 번째 단계는 전파가 완전히 끝날 때까지 두 서버를 함께 운영하며 기다리는 것이다. 조회가 옛 서버로 거의 향하지 않는다고 확인될 때까지 옛 서버를 내리지 않는다. 성급하게 옛 서버를 내리면 아직 옛 답을 붙든 사용자가 사라진 서버로 향해 접속에 실패한다. 충분한 관찰 뒤에 옛 서버를 내리는 것이 마지막 단계다.
마지막으로, 전환이 안정되면 유효 기간을 원래의 긴 값으로 되돌려 평상시의 효율을 회복한다. 이 다섯 단계를 지키면 전파라는 불확실한 과정 속에서도 서비스가 끊기지 않는다.
전파를 둘러싼 오해
전파에 대한 가장 흔한 오해는 그것이 특정 지역부터 순차적으로 퍼진다는 생각이다. 어떤 지역에서 먼저 새 값이 보이고 다른 지역이 나중에 보이는 현상을 두고, 변경이 지리적으로 이동한다고 여기는 것이다. 그러나 지역 사이의 차이는 순서가 있는 이동이 아니라, 각 지역의 리졸버가 옛 답을 저장한 시점과 유효 기간이 제각각이라 만료 시점이 흩어지는 것일 뿐이다. 전파에는 방향도 순서도 없다.
또 하나의 오해는 어떤 특별한 도구로 전파를 강제로 완료시킬 수 있다는 기대다. 전 세계 리졸버의 저장을 소유자가 한꺼번에 지울 방법은 없으므로, 유효 기간이 지나기 전에 전파를 끝내는 마법 같은 수단은 존재하지 않는다. 전파를 빠르게 하는 유일한 정공법은 미리 유효 기간을 낮춰 두는 것뿐이다. 이 사실을 받아들이면 변경 계획이 훨씬 현실적으로 세워진다.
변경 직후 자신의 환경에서 새 값이 보인다고 전파가 끝났다고 단정하는 것도 위험하다. 자신이 쓰는 리졸버는 이미 옛 답이 만료되었거나 처음 조회한 것일 뿐, 다른 리졸버는 여전히 옛 답을 붙들고 있을 수 있다. 자신에게 보이는 상태는 전 세계의 상태를 대표하지 않는다. 전파의 완료는 개인의 눈이 아니라 옛 유효 기간이라는 시간의 척도로 판단해야 한다.
마지막 오해는 유효 기간을 무작정 짧게 두는 것이 항상 좋다는 생각이다. 짧은 유효 기간은 변경의 민첩함을 주지만 네임서버에 조회 부담을 지우고, 네임서버가 잠시라도 응답하지 못하면 저장된 답이 곧 만료되어 서비스가 빠르게 영향을 받는다. 적당히 긴 유효 기간은 원본이 잠깐 불안정해도 저장된 답이 그 공백을 메워 주는 완충 역할을 한다. 유효 기간은 짧을수록 좋은 값이 아니라, 상황에 맞게 저울질할 값이다. 이렇게 유효 기간의 의미, 전파의 실체, 조절 전략, 어정쩡한 상태의 관리, 무중단 이전의 순서, 그리고 흔한 오해까지 이해하면 레코드 변경이 통제 가능한 작업이 된다. 다음 편은 이 이름 위에 안전한 연결을 세우는 보안 연결과 인증서를 다룬다.