장애 전환 지연 공식

데이터베이스 앞에 프록시를 두고 자동 장애 전환을 붙이는 작업이었다. 얼마나 빨리 넘어가느냐는 질문에 답해야 했다.

Table of contents

곱하고 더해지는 네 설정

관련 설정을 전부 찾으니 감시 주기와 연결 타임아웃과 실패 횟수와 실패 뒤 대기 시간 넷이었다. 이 값들이 서로 곱해지고 더해지면서 최종 지연을 만든다.

동작 흐름을 따라가면 감시가 돌 때마다 연결을 시도하고 타임아웃까지 기다렸다가 실패로 세며 그것을 정해진 횟수만큼 반복한 뒤 마지막 대기 시간을 더 기다리고 전환한다. 그래서 감시 주기와 연결 타임아웃의 합에 실패 횟수를 곱하고 마지막 대기 시간을 더하면 최악 지연이 된다.

값을 넣어 얻은 답

정한 설정값을 공식에 넣으니 최악 25초가 나왔다. 얼마나 빨리 넘어가느냐는 질문에 숫자로 답할 수 있게 됐다.

값을 바꾸면 얼마가 되는지도 바로 계산된다. 실패 횟수를 줄이거나 감시 주기를 줄이면 각각 몇 초씩 짧아지는데 빨리 넘어갈수록 오탐이 늘어나므로 공식이 그 교환까지 보여 준다.

대칭이어야 하는 설정

전환 자체 말고 하나가 더 걸렸다. 전환 후에 새 마스터가 복제 소스 역할을 하려면 관련 설정 셋이 양쪽 서버에 다 있어야 한다.

한쪽에만 있으면 전환은 되는데 그다음 복제가 안 붙는다. 전환 직후에 단일 서버가 되고 원래 마스터를 복구해도 다시 못 붙으므로 대칭이 아니면 전환이 반쪽이 된다.

계정 자체를 지우기

보안 항목도 하나 있었는데 기본 관리 계정이 문서에 적힌 알려진 값으로 들어 있다는 것이었다. 첫 배포 직후에 처리해야 하는 항목이다.

새 관리 계정을 만들고 기본 계정을 삭제하는 두 단계로 했다. 비밀번호만 바꾸는 것이 아니라 계정 자체를 지우는데 계정 이름이 알려져 있는 것도 공격 표면이기 때문이다.

근거의 출처를 밝히기

설정을 컨테이너 환경변수로 주려 했는데 지원하지 않았고 대신 설정 파일에 변수 치환 기능이 있었다. 그 옵션을 켜야 치환이 동작하고 안 켜면 변수 표기가 문자열 그대로 들어간다.

이 정리를 하면서 공식 문서에 접근이 안 돼서 이전 연구 결과와 실측을 근거로 작성했고 그 사실을 문서에 적었다. 이 작업에서 가장 유용했던 것이 공식인데 실측은 마스터를 실제로 죽여야 해서 운영에서는 못 하므로 계산으로 예측하고 한 번만 실측으로 검증하면 된다.

정리

• 장애 전환 지연은 설정값들의 공식으로 계산된다
• 감시 주기와 연결 타임아웃의 합에 실패 횟수를 곱하고 대기를 더한다
• 공식이 있으면 설정을 바꿀 때 다시 계산된다
• 매번 실측하지 않아도 된다
• 전환 후 복제가 붙으려면 양쪽 설정이 대칭이어야 한다
• 기본 관리 계정은 비밀번호만 바꾸지 말고 삭제한다
• 환경변수 미지원이면 설정 파일의 치환 옵션을 켠다
• 근거의 출처를 밝힌다