데이터베이스 분할
한 곳에 모여있다면 리소스가 집중되고 사용자가 많아질수록 처리속도에 한계가 올 것이고, 필연적으로 많이 요청되는 패킷의 데이터부터 분리해야 한다고 생각됩니다.
예로들면 사용자를 등록하는 데이터베이스와 로그인하기 위한 사용자를 읽어들이는 데이터베이스를 분리하였을 때, 사용자 모두가 같은 데이터를 받을 수, 받지 못할 수 있는데 일관성 문제와 가용성 문제 사이에 고려해야하는 문제가 있기 때문입니다.
먼저, 일관성에 대한 여러 모델을 알아 봅시다.
즉각적 일관성
즉각적 일관성은 강력한 일관성이라고도 한다.
사용자 전원에게 동시에 동일한 데이터가 보인다.
대부분의 관계형 데이터베이스가 이 모델을 따른다.
백업하기가 상대적으로 쉽다.
지원되는 아무 방식을 통해서 아무 지점에서나 백업할 수 있다.
데이터베이스 뷰가 항상 일관적이다.
최종적 일관성
최종적 일관성이라는 표현은 문제의 개체를 변경하지 않으면 해당 개체의 읽기 작업은 모두 최종적으로 동일한 값을 반환한다는 개념에서 유래한다.
최종적 일관성의 대표적인 예는 DNS이다.
DNS 변경사항이 전세계 모든 DNS 서버로 전파되려면 몇 분에서 몇 시간이 소요되지만 최종적으로 전달되고 모든 DNS 서버가 동일한 값을 반환하게 된다.
이러한 이유로 최종적으로 일관적인 데이터베이스는 즉각적으로 일관적인 데이터베이스에 비해 백업하기 복잡하다.
하이브리드 일관성
NoSQL 데이터베이스에서 자주 사용된다.
하이브리드 일관성은 최종적으로 일관적인 쓰기 작업을 지원하지만 읽기 작업에 필요한 일관성 수준을 API 호출 별로 지정하게 해준다.
백업 시에 전체적으로 일관적인 데이터를 원하는지 이 기능을 활용해 지정할 수 있다.
데이터베이스 백업
일관성 모델에 따라 데이터 보호 방법이 좌우된다.
일관적인 데이터를 백업 중이라는 확신이 있거나 일관적인 데이터를 복원할 능력이 있다는 확신이 있어야 하기 때문이다.
예를 들어, MongoDB나 Cassandra 같은 멀티노드 데이터베이스에서 쓸모 없어진 데이터베이스 노드를 백업하면 백업본도 쓸모 없게 된다.
또한, 두 노드에 각각 포함된 데이터의 시점이 서로 다르면, 둘 다 동시에 백업해도 모든 데이터의 일관성 있는 백업본을 얻을 수 없다. 두 노드를 서로 다른 두 시점으로 복원하면 두 노드 사이에 소위 ‘참조 무결성 문제’(referential integrity issue)가 생긴다.
데이터베이스별로 지원하는 일관성 모델을 정리하면 다음과 같다.
| Database | Consistency Model |
|---|---|
| Oracle | 즉각적 일관성 |
| MySQL | 즉각적 일관성 |
| PostgreSQL | 즉각적 일관성 |
| Cassandra | 최종적 일관성 |
| MongoDB | 하이브리드 일관성 |
| DynamoDB | 하이브리드 일관성 |
필수 실행 3단계
데이터베이스 백업에 성공하기 위해서는 해당 데이터의 위치를 확인해야한다.
하드웨어, 가상환경, 클라우드 서버, 서버리스 등 어디인지 알아야 백업 방식을 정할 수 있다.
다음으로 백업 방식을 정해야 하는데, 인기있는 방식의 데이터베이스 서버라면 해당 제품의 에이전트를 사용할 수 있다.
즉, 백업용 스토리지 또는 클라우드 시스템으로 데이터를 직접 전송할 수도 있다.
그게 아니거나 에이전트를 거치지 않고 직접 옮긴다면, '덤프-앤-스윕'방식을 사용하여 해당 제품의 백업 툴로 디스크 상에 백업본을 만든 후 백업 시스템으로 정리하는 방식이다.
백업 에이전트 방식에 비해 복잡하지만 유연성을 훨씬 크다.
마지막으로, 최종적 일관성 모델을 사용하는 멀티노드 데이터베이스인 경우에 가장 어렵다. 데이터베이스에 백업이 필요 없다는 사람의 말은 무시하는 것이 좋다.
백업본이 없는 데이터베이스는 노드 오류 등은 견딜지 모르지만 사람이 저지르는 오류와 사이버 공격에는 여전히 취약하다.
문제의 제품을 조사해서 전체 데이터베이스를 백업하거나 해당 데이터베이스의 각 테이블을 백업하는 방법을 알아내야 한다. 그와 같은 노드 수준의 탄력성이 있다면 테이블 수준에서의 복원이 가능하다.
