RDS 장애 조치와 유지보수 창, 맡긴 대가로 오는 재부팅

관리인이 있는 건물에 살면 배관을 직접 고칠 일이 없어요. 대신 정기 점검일에 물이 잠겨요. 관리인이 있다는 것은 일이 줄어든다는 뜻이면서, 그 일이 언제 일어날지를 제가 정하지 못한다는 뜻이기도 해요.

관리형 데이터베이스가 그래요. 백업과 패치와 이중화를 대신 해 주는 대신, 재부팅이 예고된 창 안에서 알아서 일어나요. 여기서 갈리는 것은 그 사실을 알고 설계했느냐예요.

유지보수는 예고된 재부팅이다

관리형 데이터베이스에는 유지보수 창이라는 시간대가 있어요. 이 안에서 엔진 패치 같은 작업이 적용되고, 그 과정에 재시작이 포함돼요.

유지보수 방식은 작업 종류에 따라 달라요. 일반 RDS Multi-AZ 인스턴스의 OS 패치는 대기 인스턴스를 먼저 고친 뒤 역할을 바꿀 수 있어요. 반면 데이터베이스 엔진 업그레이드는 주·대기 인스턴스를 함께 수정하는 경우가 있어요. 이중화를 켰다고 모든 유지보수가 같은 순서나 같은 중단 시간으로 끝나지는 않아요.

이름이 가리키는 곳이 바뀐다

교대가 일어나면 데이터베이스의 주소가 새 인스턴스를 가리키도록 바뀌어요. 인스턴스가 옮겨 가는 것이 아니라 이름이 가리키는 대상이 바뀌는 방식이에요.

여기서 앞 시리즈의 도메인 편이 다시 나와요. 이름을 주소로 바꾼 결과는 잠시 기억돼요. 그 기억이 남아 있는 동안 애플리케이션은 이미 물러난 인스턴스로 계속 연결하려 들어요.

커넥션 풀은 이미 맺은 연결을 모아 다시 쓰는 장치예요. DNS가 새 주소를 알려 줘도 기존 연결 자체가 새 서버로 이사하지는 않아요. AWS의 장애 전환 설명도 연결과 이름 캐시를 함께 다뤄요. 끊긴 연결을 버리고 새 연결을 만들 때 올바른 주소를 알아내야 앱이 다시 일을 할 수 있어요.

증상은 특징적이에요. 데이터베이스는 정상이고 콘솔에서도 문제가 없는데 애플리케이션만 계속 실패해요. 그리고 애플리케이션을 재시작하면 갑자기 나아요. 재시작이 고친 것은 코드가 아니라 캐시와 연결 풀이에요.

무엇이 일어나나	애플리케이션이 겪는 것	미리 정해 둘 것
유지보수 창의 패치	짧은 전환과 연결 끊김	창 시간을 한가한 시간대로 옮긴다
역할 교대	이름이 다른 대상을 가리킨다	이름 캐시 유효 시간을 짧게 둔다
연결 재사용	죽은 연결을 계속 쓴다	연결의 유효성을 쓰기 전에 확인한다

세 줄 모두 데이터베이스 쪽이 아니라 애플리케이션 쪽에서 대비하는 항목이라는 점이 중요해요. 관리형은 전환을 대신 해 주지만 전환을 견디는 일까지 대신해 주지는 않아요.

대기 DB로 전환한 뒤 앱의 기존 연결을 살펴보세요.

DB 이름의 목적지

DB A

앱의 연결

DB A와 연결 중

Multi-AZ 전환은 DB 이름의 목적지를 바꾸지만 기존 연결을 옮기지는 않아요. 바뀐 목적지로 다시 연결해야 해요.

이름과 현재 연결이 모두 DB A로 이어져 있어요.

DNS의 목적지는 바뀌었지만 기존 연결은 옮겨지지 않아요.

이름을 새로 확인하고 연결을 다시 만들어 DB B에 닿았어요.

RDS Multi-AZ DB instance의 예시예요. DNS 캐시 갱신과 연결 재생성은 함께 필요하며, 실제 전환 시간은 표시하지 않아요.

저는 무엇을 앱에 남겼나

관리형에 맡기면 편하다는 말은 절반만 맞아요. 편해지는 것은 백업을 뜨고 패치를 적용하는 일이고, 그 대신 전환이 정기적으로 일어난다는 새 조건이 생겨요. 직접 운영하면 전환이 드물게 일어나는 대신 그 준비를 전부 제가 해요.

그래서 앱에는 끊긴 연결을 버리고 다시 연결하는 길을 남겼어요. 다만 조회를 다시 하는 것과 결제 같은 쓰기를 다시 하는 것은 달라요. 응답을 못 받았어도 저장은 끝났을 수 있거든요. 같은 요청이 반복되어도 결과가 중복되지 않는 성질을 멱등성이라고 해요. 재연결과 함께, 어느 요청을 안전하게 다시 보낼 수 있는지도 정해야 해요.

돌아보면 관리형 서비스를 고를 때 물어야 할 것은 무엇을 대신해 주는가보다 그 대신 무엇이 정기적으로 일어나는가였어요. 앞의 것은 홍보 문구에 적혀 있고 뒤의 것은 운영 문서에 적혀 있어요.