관리형 DB 서비스는 왜 비싸고 언제 사용하는 것이 좋을까
관리형 DB 서비스는 사용자가 직접 서버에 MySQL이나 MariaDB 같은 데이터베이스를 설치하고 운영하는 대신 서비스 제공 업체가 데이터베이스 설치와 백업과 장애 감지와 복구와 보안 업데이트와 모니터링을 대신 수행해 주는 방식이며 일반 가상 서버보다 가격은 높지만 데이터베이스 운영에 필요한 관리 부담을 크게 줄일 수 있다는 것이 가장 큰 특징이다.
위는 디지털오션의 상품가격인데 국내에는 IDC가 없어 사용이 곤란하다.
Akamai Cloud는 일본에 있어 그나마 가까운곳에 있고 Vultr은 국내 IDC가 있지만 아직도 인지도가 적은 것은 왜 일까?
자동 백업과 시점 복구
관리형 DB는 일정 주기로 자동 백업을 수행하고 일부 서비스는 특정 시점으로 데이터를 되돌릴 수 있는 시점 복구 기능도 제공하므로 실수로 데이터를 삭제하거나 잘못된 프로그램이 대량으로 데이터를 변경한 경우에도 직접 백업 파일을 찾아 복원하는 작업을 줄일 수 있으며 백업 파일 관리와 보관 정책까지 서비스 제공 업체가 관리한다는 장점이 있다.
장애 감지와 서버 복구
일반 서버에 직접 데이터베이스를 설치한 경우 서버가 멈추거나 데이터베이스 프로세스가 비정상 종료되면 사용자가 직접 상태를 확인하고 서비스를 재시작하거나 새로운 서버를 만들어 복구해야 하지만 관리형 DB는 서버와 데이터베이스 상태를 지속적으로 확인하면서 장애를 감지하고 필요한 경우 새로운 서버를 준비한 뒤 데이터를 복원하는 과정을 자동화할 수 있다.
대기 서버와 자동 마스터 승격
고가용성 구성을 사용하는 경우 주 서버가 장애를 일으키면 대기 서버를 새로운 마스터로 승격시키고 애플리케이션의 접속 경로까지 자동으로 변경할 수 있으므로 관리자가 직접 서버 상태를 확인하고 복제를 중단하고 마스터를 변경하고 접속 주소를 수정하는 작업을 하지 않아도 된다는 장점이 있으며 서비스 중단 시간을 크게 줄일 수 있다.
자동 마스터 승격이 어려운 이유
마스터 서버가 응답하지 않는다고 해서 단순히 대기 서버를 새로운 마스터로 바꾸면 되는 것은 아니며 기존 마스터가 완전히 죽은 것이 아니라 네트워크 문제로 잠시 분리된 상태일 수도 있기 때문에 잘못된 판단으로 새로운 마스터를 승격시키면 두 서버가 동시에 쓰기를 받는 상황이 발생할 수 있고 이를 스플릿 브레인이라고 하며 데이터가 서로 다른 방향으로 변경되기 시작하면 단순한 복제 복구만으로 해결하기 어려워진다.
어느 서버가 최신인지 판단하기 어려운 문제
장애 발생 시 가장 단순한 경우는 한 서버가 최신 데이터를 가지고 있고 다른 서버가 조금 뒤처져 있는 상황이지만 실제 운영 환경에서는 기존 마스터에만 존재하는 데이터와 새로 승격된 마스터에만 존재하는 데이터가 동시에 생길 수도 있으며 이렇게 되면 어느 서버가 최신인지 단순하게 판단할 수 없고 두 서버의 변경 내용을 비교하면서 데이터를 병합해야 하므로 복구 난도가 급격하게 높아진다.
기존 마스터를 차단해야 하는 이유
안전한 자동 장애 전환을 위해서는 새로운 마스터를 승격시키는 것보다 기존 마스터가 더 이상 쓰기를 받지 못하도록 확실하게 차단하는 과정이 중요하며 기존 마스터가 살아 있는 상태에서 새로운 마스터까지 동시에 쓰기를 받으면 두 데이터베이스의 내용이 갈라질 수 있기 때문에 관리형 DB는 기존 서버를 네트워크에서 분리하거나 쓰기를 차단하는 방식으로 데이터 충돌 가능성을 줄이는 구조를 사용한다.
복제 지연 문제
대기 서버는 주 서버의 데이터를 실시간에 가깝게 복제하지만 항상 완전히 동일한 시점까지 복제가 완료되었다고 보장할 수 있는 것은 아니며 주 서버가 갑자기 장애를 일으킨 순간 대기 서버가 마지막 변경 내용을 아직 전달받지 못했다면 새로운 마스터로 승격한 뒤 일부 데이터가 사라질 가능성이 있으므로 자동 장애 전환 시스템에서는 복제 상태와 마지막 반영 위치를 확인하는 과정이 매우 중요하다.
보안 관리의 장점
관리형 DB는 운영체제 보안 업데이트와 데이터베이스 보안 패치와 암호화 연결과 접근 제어와 네트워크 격리 같은 기능을 서비스 제공 업체가 일정한 기준으로 관리하므로 사용자가 직접 방화벽과 운영체제와 데이터베이스 보안 설정을 계속 확인해야 하는 부담을 줄일 수 있으며 여러 개발자가 함께 사용하는 환경에서는 설정이 제각각 달라지는 문제도 줄일 수 있다.
모니터링과 알림
CPU 사용률과 메모리 사용량과 디스크 사용량과 접속 수와 느린 쿼리와 복제 지연 같은 정보를 자동으로 수집하고 이상 상태가 발생하면 알림을 받을 수 있으므로 문제가 실제 장애로 커지기 전에 확인할 수 있으며 직접 구축하는 경우 별도의 모니터링 프로그램을 설치하고 설정해야 하는 작업을 줄일 수 있다.
마스터 슬레이브 구조에서 승격 잘못 했다가 데이터 꼬이면 인생에 기억나는 하루로 죽기 전까지 잊지 못할듯.