NCP 계정 이전, 왜 무중단 대신 짧은 점검을 선택했나

들어가며

새 계정에 서버를 준비하고 앱을 올렸다고 해서 이전이 끝나는 것은 아닙니다. 사용자가 남긴 메시지와 로그인 상태도 새 환경으로 가져와야 합니다. 이번 NCP 계정 이전에서도 Terraform과 NKS로 운영 환경을 구성한 뒤, PostgreSQL과 Redis의 데이터를 어떻게 옮길지 결정해야 했습니다.

1편에서 다룬 그룹웨어 WITIM은 메시지와 근태·결재 기록을 PostgreSQL에 저장하고 있었습니다. 로그인 세션과 사용량 정보 일부는 Redis에 남아 있었습니다. 서버는 새로 만들 수 있지만, 이 데이터는 기존 상태를 보존하면서 옮겨야 했습니다.

처음에는 서비스를 멈추지 않고 전환할 수 있는지부터 검토했습니다. 하지만 이전 작업을 인수받기 전, 로그인 서비스를 새 계정으로 전환했다가 되돌리는 과정에서 며칠간의 로그인·감사 기록이 운영 DB에서 빠진 사례가 있었습니다. 중요한 계정 정보의 변경은 없었고 원본 백업도 보존돼 있었지만, 트래픽을 되돌리는 것만으로 데이터까지 원래대로 돌아오지는 않았습니다.

이전 담당자가 남긴 계획에는 PostgreSQL 논리 복제도 있었습니다. 복제는 중단을 줄이는 데 유리한 방법이지만, 운영 중인 DB에 연결과 복제 상태를 새로 도입해야 합니다. 당시에는 인프라를 인수받은 지 얼마 되지 않아, 운영 중인 구성부터 확인해야 했습니다.

그래서 중단 시간을 줄이는 방법과 함께, 어느 시점에 쓰기를 멈추고 어떤 조건에서 전환해야 데이터가 갈라지지 않는지를 먼저 정리했습니다. 이 글에서는 세 가지 이전 방식을 비교하고, 짧은 점검 시간에 데이터를 한 번에 옮기기로 한 이유를 설명하겠습니다.

1. 앱만 바꾸는 블루그린 배포와는 다른 문제였습니다

일반적인 블루그린 배포에서는 기존 앱과 새 앱이 같은 DB를 사용할 수 있습니다. 앱으로 들어오는 트래픽을 바꾸더라도 데이터를 저장하는 곳은 그대로입니다. 하지만 이번에는 DB 자체도 다른 NCP 계정으로 옮겨야 했습니다.

기존 앱 → 기존 DB
새 앱   → 새 DB

이 상태에서 두 환경이 동시에 쓰기를 받으면 사용자의 기록이 서로 다른 DB에 쌓입니다. 이후 이전 계정으로 돌아가더라도 새 DB에 생긴 기록을 따로 처리해야 합니다.

한쪽 DB에만 쓰도록 제어하면 앱을 두 곳에 띄우는 것 자체는 가능합니다. 다만 나중에 데이터 저장소를 바꾸는 순간에는 여전히 동기화와 쓰기 제어가 필요합니다.

앞서 로그인 서비스에서 데이터 공백이 생긴 사례를 확인했기 때문에, 두 DB가 각자 쓰기를 받는 구간을 만들지 않는 것을 전환의 원칙으로 삼았습니다. 접속 경로가 정상인지 확인하는 데서 그치지 않고, 새 계정에서 발생한 쓰기를 이전 계정으로 되돌릴 수 있는지도 따져야 했습니다.

2. 세 가지 이전 방식을 비교했습니다

검토한 방식은 덤프·복원, 논리 복제, 앱과 DB를 나누어 옮기는 방법이었습니다. 각 방식으로 줄일 수 있는 중단 시간과 새로 관리해야 할 작업을 함께 비교했습니다.

논리 복제는 중단을 줄이는 데 가장 직접적인 방법이었습니다. 먼저 전체 데이터를 동기화하고, 이후에는 운영 DB에서 바뀐 내용을 계속 따라가게 합니다. 그러면 전환 당일에는 마지막 차이만 확인하면 됩니다. 이전 기록에도 실제 테이블을 동기화한 흔적이 있었습니다.

다만 테이블 내용이 따라간다는 것만으로 이전 준비가 끝나지는 않습니다. 시퀀스와 DDL 변경은 별도로 다뤄야 하고, 복제 연결·슬롯·지연 상태를 계속 관찰해야 합니다. 복제 슬롯을 정리하지 않으면 WAL 보관량이 늘어날 수도 있습니다. 이전이 끝나면 없앨 연결을 위해 이 작업들을 도입할 만큼 점검 시간을 줄일 필요가 있는지 판단해야 했습니다.

앱을 먼저 옮기고 DB를 나중에 이전하는 방법도 검토했습니다. 새 앱이 기존 DB를 공유하면 첫 번째 트래픽 전환은 무중단에 가깝게 진행할 수 있습니다. 대신 두 계정 사이의 네트워크 연결을 추가하고, DB·Redis 접속 허용 범위도 넓혀야 합니다. 데이터 저장소를 옮기는 시점에는 다시 한번 전환해야 합니다.

앱 변경 폭이 크거나 DB 데이터가 매우 커서 작업을 나눠야 한다면 이 방법이 유리할 수 있습니다. 이번에는 같은 앱 이미지를 옮기는 작업이었고, 데이터도 작았습니다. 앱을 먼저 옮겨 첫 전환을 무중단으로 만들더라도, 계정 이전 전체에서 데이터 전환 문제를 해결해 주는 것은 아니었습니다.

3. 실제 데이터 규모와 이용 시간을 기준으로 결정했습니다

이 부담을 감수할지 판단하려면 실제로 얼마나 많은 데이터를 옮겨야 하는지부터 알아야 했습니다. 당시 확인한 수치는 다음과 같습니다.

이 규모라면 데이터 복사 자체보다 앱을 멈추고 다시 띄우는 시간, 새 환경에서 기능을 확인하는 시간이 더 클 가능성이 높았습니다. 서비스에는 이미 점검 모드가 있었고, Cloudflare 프록시의 원본 주소를 변경하면 새 로드밸런서로 트래픽을 보낼 수 있었습니다.

점검할 시간대를 고르기 위해 이전 4주간의 메시지 수도 확인했습니다. 새벽에는 이용자가 없을 것이라고 가정하기보다, 실제 기록에서 상대적으로 조용한 시간대를 찾으려 했습니다.

당시 계획에서는 덤프 방식의 쓰기 정지 시간을 약 15–20분, 논리 복제 방식은 약 3–5분으로 예상했습니다. 두 값은 방식을 선택할 때의 추정치입니다. 논리 복제를 선택하더라도 앱 재기동·Redis 이전·기능 확인에 드는 시간은 남습니다. 줄일 수 있는 시간은 전체 점검 시간 중 일부였습니다.

이 조건들을 비교한 뒤, 새 환경을 미리 구성하고 검증한 다음 점검 시간에는 최종 데이터만 옮기기로 했습니다. PostgreSQL은 계정 이전과 동시에 17로 업그레이드하지 않고 기존과 같은 15.15를 유지했습니다. 이전 범위가 늘어나면 문제가 생겼을 때 확인해야 할 변수도 많아지기 때문입니다.

Redis는 처음에 로그인 토큰만 가져오려고 했습니다. 하지만 운영 키를 분류해 보니, 캐시처럼 다른 원본에서 다시 만들 수 있는 데이터만 있는 것은 아니었습니다. 아직 DB로 옮겨지지 않은 사용량 통계와 모바일 로그인 상태처럼 Redis에만 남은 정보도 있었습니다. 무엇을 버려도 되는지 하나씩 고르는 과정에서 오히려 데이터가 빠질 수 있다고 판단해 전체를 옮기기로 했습니다.

PostgreSQL의 이전 방식을 무엇으로 정하든 Redis 상태는 따로 옮겨야 했습니다. 따라서 PostgreSQL의 쓰기 정지 시간을 논리 복제로 줄여도 전체 서비스가 자동으로 무중단 전환되는 것은 아니었습니다. 약 9천 개 키라면 전체 복사가 충분히 가능한 규모라고 판단했습니다.

4. 중단보다 중요했던 것은 쓰기 재개 시점이었습니다

방식을 정한 다음에는 언제 데이터를 복사하고, 어떤 확인을 거쳐 쓰기를 다시 받을지 순서를 정했습니다.

이때 점검 화면을 켜는 것과 실제 쓰기를 멈추는 것을 구분해야 했습니다. 외부 요청을 막아도 내부 worker나 예약 작업이 DB에 계속 기록할 수 있기 때문입니다. 그러면 최종 덤프를 만든 뒤에도 원본 데이터가 바뀝니다. 이를 막기 위해 앱과 작업을 멈춘 뒤 최종 데이터를 복사하도록 순서를 정했습니다.

새 환경에서 사용자 쓰기가 시작되기 전까지는 기존 환경으로 돌아갈 여지가 있습니다. 하지만 새 DB에 기록이 쌓인 뒤에는 DNS만 되돌리는 것으로 복구할 수 없습니다. 이미 발생한 쓰기를 어떻게 다룰지 별도로 판단해야 합니다. 그래서 주소를 바꾸는 순간보다, 데이터 대조와 새 서비스 확인을 통과한 뒤 쓰기를 재개하는 시점을 전환 기준으로 삼았습니다.

처음 계획에서는 새 환경을 확인하는 작업까지 전환 당일에 포함해 점검 시간을 1–2시간으로 예상했습니다. 이 확인을 전날 리허설로 옮기면, 당일에는 쓰기 중지·최종 데이터 복사·검증·트래픽 전환에 집중할 수 있습니다.

실제 이전은 10월 23일에 약 13분의 사용자 영향으로 마쳤습니다. 선택 당시 예상했던 점검 범위 안에서 전환을 끝낼 수 있었습니다.

마무리하며

이번 이전에서는 데이터 규모와 복원 시간을 먼저 확인한 덕분에, 짧은 점검 시간을 확보하고 덤프·복원으로 옮기는 방식을 선택할 수 있었습니다. 몇 분을 더 줄이기 위해 임시 네트워크와 복제 상태를 관리하는 부담보다, 미리 검증한 절차로 쓰기를 멈추고 옮기는 편이 당시 운영 조건에 맞는다고 판단했습니다.

이 선택을 덤프 방식이 논리 복제보다 항상 낫다는 결론으로 일반화할 수는 없습니다. 서비스 규모와 운영 조건을 측정하고, 그 조건에서 관리할 수 있는 복잡도를 선택한 결과입니다.

방식을 정한 뒤에는 실제 운영 데이터로 복원과 앱 동작을 확인해야 했습니다. 3편에서는 이 결정을 어떻게 구현하고, 운영 환경에 영향을 주지 않으면서 어떤 문제를 발견했는지 설명하겠습니다.

시리즈: 1편 · Terraform·NKS로 운영 환경 이전 · 2편 · 이전 방식의 의사결정 · 3편 · 운영 데이터로 리허설과 검증