장애 시나리오
소프트웨어 장애 : MySQL 등의 데이터베이스 프로그램의 폭주와 충돌처럼 소프트웨어 주변의 결함으로 인해 서비스를 제공할 수 없는 유형의 장애
- 소프트웨어 장애는 소프트웨어의 품질이 장애 빈도와 심각성에 결정적인 영향을 미침
- 제품을 평가하는 데 있어서 [기능]과 [성능]에만 눈이 가기 쉽지만 장기간 운용하기 위해서는 [품질]도 중요함
OS 장애 : Windows의 블루 스크린, Linux 커널 패닉(OS에서 심각한 오류가 발생하여 프로세스를 중지하는 것)과 같은 OS 주변의 장애로 인해 서비스 제공할 수 없게 되는 패턴
- 현실적으로 발생 빈도가 높은 문제로는 장치 드라이버의 버그 ⇒ 최신 드라이버로 업데이트 해라
- 예를 들어 고부하 처리가 일정 시간 이상 지속 후 갑자기 디스크 액세스를 전혀 할 수 없게 되는 문제가 발생하기도 함
- 어느 정도 사용되는(검증된) 기술을 사용하는 것이 중요
- 하드웨어 장애: HDD와 같이 물리적으로 작동하는 것은 한 개당 수명이 2~3년 정도로 그다지 길지 않음
- 조작 실수
디스크 이중화로 데이터 손실 방지하기
- 문제를 발생시키지 않는 것이 최선이지만 현실적으로 발생 확률을 제로로 하는 것은 불가능. ⇒ [장애가 발생해도 서비스를 제공할 수 있도록 설계하는 것 이 중요함
RAID
- 현재 데이터베이스의 데이터는 HDD에 저장되는 것이 보통인데, HDD는 하드웨어 중에서 가장 고장률이 높은 부품임 ⇒ 하나의 서버에 여러 개의 HDD를 탑재하고 동일한 데이터를 두 개 이상의 HDD에 분산시키는 기술이 사용되고 있음 (RAID)
서버 이중화에 의한 다운 타임 줄이기
- 장애의 원인이 디스크만이 아니라 CPU 고장, 커널 패닉도 있으며, 데이터 프로세스 장애도 있기에 RAID 구성을 짜고 있다 해도 서버가 하나밖에 없으면 시스템은 다운됨 ⇒ (DB)서버가 두대 이상 필요
복제(Replica)
- 하나의 서버가 다운 되더라도 동일한 데이터가 나머지 서버에 있기 때문에 서비스를 계속 할 수 있음
- Mysql에 도입되어 있는 것 중심으로 다룸
단방향 복제
단방향/비동기
- 마스터에서 갱신한 결과가 슬레이브에 비동기로 전파하는 유형의 복제
- MySQL에서 표준으로 사용되는 복제 기능
- MySQL에서는 마스터에서 실행한 갱신계의 SQL 문(또는 갱신 전후의 행 이미지)이 바이너리 로그라는 전용 로그 파일로 기록됨. 이 로그 파일의 내용이 슬레이브로 전송되어 저장
- 슬레이브는 저장된 로그 파일을 순차적으로 실행함으로써 결과적으로 마스터와 슬레이브의 상태가 일치
- 슬레이브에는 바이너리 로그 수신 과 바이너리 로그 실행 이라는 2단계로 구성. 각각 별도의 스레드가 담당하고 있으며, 전자는
I/O 스레드, 후자는SQL 스레드가 실행하고 있음 (모두가 비동기) - 디스크에 비해 네트워크 병목현상이 되는 일은 적기에 수신은 거의 동기에 가까운 속도로 진행된다(SSD고려 안한 내용일 수 있음)
- 반영되지 않은 상황
- 마스터에서 생성한 바이너리 로그가 슬레이브에서는 마지막까지 수신되지 않은 상황 ⇒ MySQL 이 크래쉬되었을 뿐 OS 살아있을 경우 SSH 접속하여 바이너리 로그를 가져올 수 있음(이것을 자동화해주는 도구도 있음)
- 슬레이브에서의 바이너리 로그의 실행이 마지막까지 종료되지 않은 상황 ⇒ 슬레이브에 저장된 바이너리 로그로 해소 가능
단방향/준동기화
- 슬레이브가 바이너리 로그를 수신하는 단계를 동기화 방식으로 실행하는 것 = 준동기식 복제(semi-synchronous replication)
- 해당 단계가 동기 방식이 됨으로, 마스터를 업데이트한 클라이언트는 그 결과를 마스터의 DB에 반영하는 것 뿐 아니라 대상 슬레이브로 전송하여 확인 응답 반환될 때 까지 기다리게 됨
- 이거 다 기다려야 하기 때문에 응답시간이 나빠질 수 있음
단방향/동기
- 마스터가 장애를 일으킨 경우 동기 복제는 슬레이브에서 업데이트 결과가 모두 반영되어 있기 때문에 즉시 슬레이브에서 서비스를 재개할 수 있음
양방향 복제
- 단방향 복제는 마스터 → 슬레이브 라는 단방향 제약이 있기에 업데이트는 마스터에서만 할 수 있음
또한 대부분의 경우 슬레이브는 단일 스레드로 복제를 담당하게 되어 있으므로 갱신의 동시성이 없음
- 최근 하드웨어는 SSD와 멀티 코어 CPU와 같이 여러 스레드에서의 병렬성을 높일 수 있도록 되어 있기 때문에 그 혜택을 받을 수 없다는 것은 문제가 될 수 있음
- 그래서 마스터를 두 개 이상 갖게 하고 각각의 마스터를 업데이트할 수 있도록 한
멀티 마스터(양방향 복제)라는 구성도 생각할 수 있음
- 양방향 복제 시, 두 대의 DB 서버에 동일한 id에 대해 다른 update를 반영하면 서로 다른 값을 양쪽에 복제해 버릴 수 있음 ⇒ 이에 대해 DB 제품에 따라서 여러 서버에 각각 업데이트 할 수 있으며 그들이 자동으로 동기화되는 구조를 가진 것이 있음
Mysql Cluster - MySQL Cluster는 데이터 노드라고 하는 특수 서버에서 데이터를 가지고 있음 ⇒ 동일한 기본 키 값을 업데이트하는 경우는 동일 서버에 대해서 액세스 되도록 하고 있음
- 중복성을 위해 두 개 이상의 데이터 노드에서 동일한 데이터를 서로 보관함
- 한 데이터 노드에 적용된 업데이트는 다른 쪽 데이터 노드에 동기적으로 반영됨
장애로부터의 복구 방법
- 슬레이브 하드웨어 오류로 인해 해당 서버의 데이터를 소실했을 경우, 다른 살아있는 슬레이브 또는 마스터에서 데이터를 복원하거나 정기적으로 백업을 받았다면 그것으로 되돌릴 수 밖에 없음
- 한편, OS 장애 등에 의해 일시적으로 사용할 수 없게 되었으나 데이터 자체는 디스크에 남아있는 유형의 장애도 있음
- MySQL을 예로 들면 MySQL에서는 복제가 어디까지 진행되고 있었는가? 라는 상태 정보를 전용 파일로 관리하고 있음. 복제가 진행되면 동시에 그 파일이 갱신. 그러나 이 파일은 디스크에 대해 동기적으로 쓰기를 한다는 보장이 없다
- 따라서 OS 장애 등에 의해 크래시가 발생하면
실제로 업데이트된 위치와파일에 기록되는 위치가 어긋나게 됨
- MySQL Cluster 등 고도의 데이터베이스의 경우는 단순히 장애를 일으킨 서버를 재기동하는 것만으로 자동적으로 미반영의 데이터를 특정하여 차분만을 복구하여 줌
고의로 지연시킨 복제
- 비동기 복제를 응용하여 인위적 실수에 대비하는 솔루션도 있음.
Time Delayed Replication이라 불리는 기술
- 마스터에서 수행한 업데이트를 즉시 슬레이브에 반영하지 않고, 1시간 등 어느 정도의 시간이 지난 후에 반영하는 방식
- 대상 슬레이브가 항상 지연된 상태이기에 애플리케이션에서의 참조 쿼리는 돌릴 수 없음