업그레이드가 계속 실패하고 메모리가 바닥을 향한 일

개발 환경에서부터 올라가지 않았다

관리형 데이터베이스의 버전 지원이 끝난다는 안내 메일이 왔다. 기존 버전을 계속 쓰면 연장 지원 비용이 생긴다는 내용이었다. 메이저 버전을 올려야 했다.

운영에 적용하기 전에 개발 환경에서 먼저 시도했다. 그런데 업그레이드가 계속 실패했다. 처음에는 데이터에 문제가 있는 줄 알았다. 확장 기능을 빼 보고 설정도 바꿨지만, 성공하지 못했다.

실패할 때마다 무엇을 바꿨는지 기록했다. AI 도구와 계획을 세우며 작업해서 시도한 내용도 남아 있었다. 로그와 지표를 살펴보니, 업그레이드를 시도할 때 쓸 수 있는 메모리가 매우 적어지는 모습이 보였다. 시도별로 남은 메모리도 더 낮게 나타났다.

이 관측과 원인 확정은 구분할 필요가 있었다. 몇 번 실패한 뒤에는 우리가 가진 정보만으로 더 진행하기 어렵다고 판단했다. 지금까지 바꾼 설정과 실패한 결과, 원인 후보, 되돌릴 계획을 정리해 클라우드 지원에 보냈다. 지원에서는 업그레이드 중 인스턴스의 메모리가 부족했다고 판정했다.

평소에 돌아가는 것과 업그레이드되는 것은 달랐다

데이터베이스가 평소 요청을 처리하고 있다고 해서 업그레이드도 같은 조건에서 끝나는 것은 아니었다. 메이저 업그레이드는 기존 데이터와 기능을 새 엔진 버전에서 사용할 수 있도록 옮기는 작업이다. 애플리케이션과 확장 기능의 호환성도 확인해야 한다. AWS의 안내도 운영에 적용하기 전 별도 환경에서 업그레이드와 애플리케이션 동작을 시험하도록 설명한다. 메이저 업그레이드 안내

이번에는 그 작업을 수행하는 동안의 메모리가 문제였다. 개발 인스턴스의 사양을 높이자 업그레이드에 성공했고, 끝난 뒤에는 원래 사양으로 낮췄다. 평상시 사용하는 사양과 업그레이드에 필요한 사양을 같은 것으로 보고 있었는지 돌아보게 된다.

새 데이터베이스를 만들고 데이터를 실시간으로 옮기는 방법도 고려했다. 다만 데이터 용량이 커서 그 방법은 보류했다. 어떤 이관 도구를 썼다고 특정할 만큼 정확하게 기억나지는 않는다.

운영은 더 큰 사양에서 Blue/Green 방식으로 업그레이드를 진행했다. 기존 환경을 두고 변경할 환경을 따로 준비한 뒤, 준비가 되면 새 환경으로 전환하는 방식이다. 데이터베이스에서는 기존 환경의 변경을 새 환경에 동기화하면서 업그레이드를 시험할 수 있다. 실제 지원 범위는 엔진과 버전에 따라 확인해야 한다. Blue/Green 방식 소개

사용자가 가장 적은 새벽 시간을 골랐고, 전환 뒤에도 이전 클러스터를 한동안 남겨 두었다. 운영에서는 업그레이드 단계의 같은 오류가 다시 나타나지 않았다. 개발 환경에서 먼저 실패했기 때문에 이 실패가 그대로 운영 사고로 이어지지는 않았다. 다만 업그레이드를 마쳤을 때는 지원 종료 날짜가 이미 지나 있었다.

실패한 시도에서 무엇을 남길 것인가

지금 돌아보면 실패 횟수보다 각 시도를 비교할 수 있었다는 점이 더 중요하게 느껴진다. 설정을 바꿨다는 사실만 남아 있으면, 다음에 같은 오류가 나도 그 변경이 도움이 됐는지 알기 어렵다. 이번에는 시도한 내용과 메모리 관측을 함께 전달했고, 지원의 판단을 받아 다음 조치를 정할 수 있었다.

다시 비슷한 작업을 한다면 기록에는 바꾼 조건과 관측한 결과를 나란히 두고 싶다. 예를 들면 “확장 기능을 제외한 뒤에도 같은 단계에서 실패했다”, “사양을 바꾼 뒤 그 단계를 통과했다”처럼 적는 것이다.

AI 도구와 작업하면 대화와 실행 과정이 남지만, 그 안에 있는 추측이 곧 확인된 원인은 아니다. 메모리가 낮게 보였다는 관측, 메모리 부족이라는 지원의 판정, 사양을 바꾼 뒤 성공했다는 결과를 따로 적어야 나중에도 무엇을 근거로 판단했는지 알 수 있겠다.

같은 코드로 만들어도 확인할 차이는 남는다

당시 개발과 운영은 사양이 달랐고 구성도 같지 않았다. 운영과 더 비슷한 환경을 준비했다면 무엇을 일찍 발견할 수 있었을지 아쉬움이 남는다. 그렇다고 환경을 같게 만들기만 하면 이 문제가 반드시 먼저 드러났을 거라고 단정할 수는 없다.

현재 나라별 서비스를 위한 인프라 코드는 개발과 운영에 같은 구성 정의를 사용하고, 사양 같은 값은 환경별로 넣는 방식이다. 지금의 구성을 놓고 보면, 같은 방식으로 만드는 것과 같은 조건에서 시험하는 것은 어디까지 같을까 하는 질문이 남는다.

인프라를 코드로 정의하면 같은 자원 구성을 재사용할 수 있다. AWS CDK에서는 관련 자원을 스택으로 묶고, 같은 정의를 바탕으로 필요한 구성을 만든다. CDK 스택 소개

하지만 같은 코드를 쓴다는 말이 모든 실행 조건이 같다는 뜻은 아니다. 사양과 설정을 다르게 넣을 수 있고, 저장된 데이터의 크기와 실제 요청도 다르다. 구조를 맞춰도 이번에 확인하려는 작업에 중요한 차이는 따로 살펴야 한다.

다음 업그레이드에서는 평소 잘 돌아가는지를 넘어, 업그레이드 중 어느 단계에 어떤 자원이 필요한지 더 보고 싶다. 실패한 기록도 그 질문에 답할 수 있게 남겨두면 좋겠다. 기록이 있다고 실패를 피할 수는 없지만, 같은 추측을 처음부터 반복하는 일은 줄이고 싶다.