postgres 버전 마이그레이션 후기

postgres 엔진 버전 마이그레이션 후기

갑작스러운 요금 폭탄

새 회사에 입사한지 한달이 지났을 무렵 갑작스럽게 경영부서에서 긴급 요청이왔다.
지난달 aws 요금이 이전보다 3배 가까이 폭증해서 원인을 파악해달라는 요청이었다.
아직 입사 한달차에 클라우드 구성도 제대로 파악하지 못한 상태였지만 부랴부랴 aws 사용량을 확인해봤다 하지만 지난달에 비해 트래픽 증가나 새로운 리소스가 생성된 내역은 찾을수 없었다.

그와중 동료 개발자도 같이 원인 파악에 나섰는데 빌링 대시보드에서는 유독 rds 요금이 3배 폭증했다는게 눈에 띄였고 동료가 조사한바에 따르면 aws에서 실행중인 인스턴스가 지원이 종료되면 추가 요금이 발생할수있다고 알려줬다.

원인은 postgres 13 버전 지원 종료

위에서 동료가 말해준 내용이 정말로 사실인지 추가 조사를 해봤다. 근데 진짜 사실이었다.
먼저 회사에 기존 rds 인스턴스는 전부 13버전으로 돌아가고 있었고 aws 알림을 확인해봤더니 13버전이 종료된다고 10번이 넘게(..) 알림이 와있었다.
결정적으로 이 문서에서 postgres 13버전이 2026년 2월 28일 부터 종료 되며 그 이후부터 실행되는 인스턴스에는 추가 요금이 발생한다고 명시적으로 안내를 하고있고 요금이 폭증한게 정확히 지원 종료 다음달인 3월이었다.

하지만 정말로 이거때문에 요금이 폭등했는지 확인이 필요해서 먼저 개발용으로 쓰고있던 인스턴스의 엔진 버전을 18버전으로 올리고 다음날 확인했을때 정말로 요금이 줄어드는지 검증을 해보기로했다.
확인 결과는 명확했다. 진짜 인스턴스 하나만 바꿨는데 요금이 눈에 띄게 감소하는게 보였다.

rds 마이그레이션을 해야하는데....

결국 기존 postgres 13버전을 쓰고있는 rds 인스턴스를 18버전으로 전부 마이그레이션을 하기로했다 사실 14버전등 지원중인 버전으로 바꿔도 되지만 나중을 위해서 그냥 18버전으로 올리기로 결정했다.

문제는 외주 서비스, 사내 툴등 이미 프로덕션으로 돌아가고있는 인스턴스들을 건드리는 작업이라 매우 조심스럽게 진행해야했다.
그래서 일단은 개발용으로 쓰고있는 인스턴스부터 회사 내부 툴용, 프로덕션용 순서로 점진적으로 적용시키기로했다.

마이그레이션 과정

회사 인프라는 테라폼으로 관리를 하고있었지만 콘솔에서 직접 생성한것도 섞여있는 상태였다.
아직 회사 인프라를 전부 파악하지 못한상태에서 단순히 테라폼으로 버전만 수정했다간 무슨일이 발생할지 몰라서 최대한 안정적으로 진행하기 위해서 일단은 aws 콘솔에서 직접 블루 그린 마이그레이션을 완료하고 테라폼 코드를 싱크하는 방법으로 진행하기로 했다.

제일먼저 rds에 접속해서 데이터가 무엇이 들어있는지, 어떤 서비스가 해당 인스턴스를 연결해서 쓰고있는지 하나하나 찾아서 전부 확인한 다음 교체 작업을 진행했다.(이거 진짜 찾는거 개빡쎗음)

그린 인스턴스 생성

다행이 aws에서 rds 블루그린을 자동화 해주는 기능을 제공했다.
콘솔에서 실행중인 인스턴스의 업데이트된 그린 버전을 생성해주고 스위치 부터 블루 삭제까지 손쉽게 처리할수 있다.
물론 postgres 버전이 올라가면서 바뀐내용이 많아 파라미터 그룹 설정등 신경써야할 부분이 많아서 꽤나 애를먹었다.

인스턴스 스위칭

그린 인스턴스가 문제없이 실행됐을때 직접 접속해서 데이터나 쿼리가 문제없는지 확인했다.
그 다음 그린 인스턴스로 트래픽을 전환했는데 (이때가 제일 무서운 타이밍) 다행이 개발용으로 쓰던 인스턴스는 백엔드에서 접속하는것도 문제가 없었다.

블루 인스턴스 삭제

이전에 사용하던 블루 인스턴스는 삭제하기전 마지막으로 스냅샷을 저장해두고 완전히 삭제했다. 그리고 블루그린 배포 생성도 삭제하여 업그레이된 인스턴스가 완전히 대체하도록 적용했다.

테라폼 싱크

마지막으로 콘솔에서 직접 수정한걸 테라폼 코드에도 반영해야해서 업그레이드된 버전, 적용된 설정등을 파악하고 기존 인프라 코드를 수정하고 plan을 봤을때 수정이나 삭제없이 변동사항이 없다고뜬걸 확인한 다음 마지막으로 apply 한번 해주고 실제 인프라와 코드상 동기화까지 끝냈다.

개발용으로 쓰던 인스턴스는 문제없이 업데이트 했고 다음으로 회사 내부에서만 쓰는 서비스 db를 하나하나 바꿔나가고있었다.
나름 순조롭게 진행되고 있나 싶었지만 아니나 다를까 사소하고 앙증맞은 찐빠가 발생했다.

실행중이던 내부 서비스가 다운됨

갑자기 슬랙에 쿠버네티스 다운 알림이 터져나왔다.
사내 서비스가 다운된거였는데 로그를 보니 인스턴스 접속하려니까 ssl 설정때문에 튕기면서 서비스가 다운되고 있었다.
나중에 알고보니 postgres가 15버전 부터 ssl 설정 여부를 엄격하게 쓰도록 바뀌었다고 한다. 이전 코드가 그런 설정없이 그대로 쓰고있던거라 에러가 난거였다. 급하게 해당서비스 코드의 ssl 설정을 수정하고 배포했더니 다행이 멀쩡하게 돌아갔다.

주말 10시간을 넘게 작업하다 겨우 겨우 업데이트를 완료했고 다음날 rds 요금을 보니 이전과 비슷한 수준으로 줄어든걸 확인할수있었다.

바꾸지 못한 인스턴스들

그렇다고 모든 인스턴스를 다 18버전으로 업그레이드 한건 아니다.
몇몇 인스턴스는 건드릴 엄두조차 못나서 못바꾸거나 어떤건 아예 바꾸는거 자체가 불가능해진 것도 있었다.

여러 서비스에서 하나의 rds를 db만 구분해서 돌려쓰고있는(...)게 있었는데 워낙 많은곳에서 쓰고있어서 도저히 어떤곳에서 연결하고있는지 파악할수가없었다.

이걸 바꿨다가 위 사례처럼 백엔드 서버가 다운될 위험이 있어서 이건 수정하지 못하고 그대로 13버전으로 남겨둘수 밖에 없었다.

또 다른건 마지막으로 수정된게 5년전 인 프로젝트가 있는데 이건 실제로 18버전으로 업그레이드 하던중 문제가 터져서 수정하려고 했더니 빌드하는 과정에서 참고하고있는 패키지가 회사 내부 비공개 저장소를 참조하는데 키가 없어서 접근도 불가능했고 더더욱 문제인건 다른 의존성 패키지는 아예 삭제되서 찾을수조차 없는 상황(...) 이라 아예 코드를 수정하는것 자체가 불가능해진것도 있었다.

이건 진짜 어쩔수없이 다시 13버전으로 바꿔야 했었다.

전체 후기

사실 이거말고도 입사 2주만에 쿠버네티스 노드 자체가 다운 되는등 신나는 이벤트가 여럿 있었다.
전부 처음 겪어본 상황이었고 대응도 완벽하다곤 할수 없지만 그래도 중요한 경험이었다.