RDBMS는 주로 수직 스케일링 (vertical scaling) 방식 - scale up을 사용하여 성능을 향상시킨다.
이는 서버의 성능을 높이거나 하드웨어를 업그레이드하여 처리 능력을 증가시킨다.
그러나 이러한 방식은 한계에 도달하면 확장성이 제한된다.
NoSQL 데이터베이스는 수평 스케일링 (horizontal scaling) - scale out을 지원한다.
데이터베이스를 여러 노드로 분산시키고 부하를 분산시킬 수 있다.
따라서 대규모 데이터 및 트래픽 처리에 적합하다.
이외에도 RDBMS는 가질 수 없는 NoSQL의 스키마 유연성, NoSQL의 대량의 데이터 처리 능력, NoSQL의 높은 가용성 덕분에 NoSQL이 분산 처리에 더 적합하다.
BASE 속성
RDBMS는 트랜잭션에 대한 ACID 속성을 지키고, 분산환경에서의 NoSQL은 BASE 속성을 지켜야한다고 한다.
BASE 속성은 Basically Available / Soft-state / Eventually Consistency 속성을 말한다.
Basically Available 가용성
데이터에 항상 접근 가능한 특성
부분적으로 지원되지 않더라도, 나머지라도 사용이 가능해야한다. ➡️ 주 서버가 죽더라도 백업 서버가 동작한다.
따라서 다수의 스토리지에 복사본을 저장해야한다.
Soft-state 독립성
노드의 상태는 외부에서 전송된 정보를 통해 결정되는 특성
분산된 노드 간의 데이터 업데이트는, 데이터가 노드에 도달한 시점에 반영한다.
사용자가 관리(refresh, modify)하지 않으면 Data가 expire 될 수도 있다.
( 데이터베이스의 상태가 계속 바뀔 수 있어, 최신데이터로 업데이트될 수 있다. )
Eventually Consistency 일관성
일정 시간이 경과해도 데이터는 일관성있게 유지되어야하는 특성
지금 당장은 분산된 노드 간 데이터가 일관성이 없어도, ( 동기화 등을 통해 ) 최종적으로는 일관성을 보장해야한다.
ACID 특성과의 차이점
우선 ACID 속성은 원자성/일관성/독립성/지속성을 말한다.
다 성공하거나 실패해야하고 / 데이터는 일관적으로 유지해야 하고 / 다른 트랜잭션에 영향을 받으면 안되고 / 성공한 트랜잭션이 커밋되면 완전히 반영됨과 동시에 로그를 남기고, 이 로그로 되돌릴 수 있어야한다.
ACID 특성은 기본적으로 하나의 트랜잭션에 대한 특성을 말하지만, BASE 특성은 시스템 전체에 대한 속성이다.
BASE 특성은 일관성은 조금 저하되더라도 성능과 가용성을 우선으로 한다.
반면에, ACID는 데이터를 일관성있게 유지함과 동시에 무결성을 보장하고자 한다.
CAP 이론 - Consistency / Availability / Partition Tolerance
CAP 이론은 분산 시스템은 아래 3가지 특성중 최대 2가지 특성만 만족할 수 있다는 이론이다.
Consistency 일관성
분산된 서버에서 데이터가 얼마나 Consistent 일관성 있게 존재할 수 있는지
한개 노드에 쓰기가 될 때, 그 쓰기가 완료되기 전에 다른 노드에 데이터가 복제된다.
Availability 가용성
우리 서비스가 항상 Available하는지, 가용성이 보장되는지
모든 요청이 성공 또는 실패 결과를 반환해야한다.
Partition Tolerance 분할 내성
분산 환경에서 서버가 파티션된 구조일 때 이슈가 생겨도 - ex. 어떠한 네트워크 장애로 인해 서버들끼리 서로 커뮤니케이션 할 수 없는 상황이 발생한 경우 - 시스템이 계속 동작할 수 있는지
네트워크로 연결된 모든 분산 시스템에서는 이슈가 발생하기 쉽다. 네트워크 단절이나 메시지 유실이 발생할 수 있기 때문이다.
따라서 Partition Tolerance를 필수로 보장할 수 있게 설계해야한다.
CAP 이론의 세가지 분산 시스템(조합)
두개의 노드 A,B로 분산된 환경이라고 가정하자.
CAP 이론에서는 분산 환경은 최대 두가지의 특성을 지킬 수 있으므로 아래 3가지의 시스템으로 분류할 수 있다.
CP - Consistenct and Partition Tolerance
만약, 분산 환경에서 두 노드 간의 네트워크가 중단되었을 때, 가용성 보장이 떨어지더라도 데이터는 일관성있게 그리고 시스템은 계속 동작할 수 있게 해야하는 시스템이다.
시스템 가용성이 저하되더라도, 요청을 취소하여 데이터 일관성을 보호한다.
어떤 노드 A에서는 쓰기를 할 수 없게 막는다면, 데이터의 일관성을 보장할 수 있다.
A 노드에서 쓰기가 불가능하므로 가용성은 떨어지게 되지만 일관성을 보장하고, 시스템이 계속 동작하므로 Partition Tolerance도 보장할 수 있다.
이런 상황이라면, 네트워크가 복구된 이후 데이터 동기화를 수행해야한다.
A 노드에도 B 노드 데이터가 반영되게 함으로써, 다른 노드에도 데이터가 일관성있게 복구하는 작업이 필요하다.
AP - Available and Partition Tolerance
만약, 분산 환경에서 두 노드 간의 네트워크가 중단되었을 때, 데이터가 일관되도록 완벽히 보장할 수는 없을지라도 모든 요청은 결과를 반환해 가용성을 보장하고 시스템은 계속 동작할 수 있게 해야하는 시스템이다.
일관되지 않은 데이터가 반환되는 경우에도 가용성을 제공한다.
모든 노드가 요청에 응답하기 때문에 시스템은 가용성을 보장하게 된다.
동시에 시스템은 계속 동작하므로 Partition Tolerance도 함께 보장할 수 있다.
하지만 데이터는 일관되지 않기 때문에 동일한 내용의 요청일지라도 다른 데이터를 가지고 있기에, 응답은 다를 수 있다. 데이터의 일관성을 보장할 수 없는 것이다.
이런 상황이라면, (CP 시스템 처럼) 네트워크가 복구된 이후 데이터 동기화를 수행해서 일관성을 보장해야한다.
CA - Consistent and Available
만약, 분산 환경에서 두 노드 간의 네트워크가 중단되었을 때, 시스템을 이용할 수 없다면 가용성도 일관성도 의미가 없다.
따라서 이 시스템은 파티션되지 않은 환경에서 일관성과 가용성을 보장하는 시스템이다.
시스템에 따른 올바른 DB 선택하기
위의 AP/CP/CA 시스템에 따라서 올바른 데이터베이스를 선택해야한다.
- CA 시스템이라면 파티션되지 않는 환경에 적합한 RDBMS가 적합할 것이다.
- CP 시스템이라면 파티션되어도 일관성을 보장하는 MongoDB 등이 적합하다.
- MongoDB는 쓰기 작업이 완료되면, 이후의 모든 읽기 작업에서 가장 최근 값을 반환하도록 설계되어 있어, 일관성을 보장한다.
- 물론 MongoDB가 더 높은 가용성을 보장하고자 Replica set을 이용한 클러스터를 구성해 Secondary 멤버를 이용한다면 달라진다.
- Replica 없이 Primary 멤버만 이용한다면 Primary 멤버가 모든 읽기와 쓰기를 처리한다. 하지만 Secondary 멤버를 구성해 일부 읽기 작업이나 모든 읽기 작업을 라우팅하고 쓰기 작업은 Primary 멤버가 수행하게 구성할 수 도 있다.
- 이런 구조는 책임을 분산시켜 가용성을 높일 수 있지만, 지연 시간으로 인해 일관성이 떨어질 수 있다.
- Primary 멤버를 통한 변경 사항이 Secondary 멤버에도 반영되어야하는데, 여기서 지연시간이 발생하게 되므로 내내 데이터에 대한 일관성을 보장하는 것이 아닌 최종적인 일관성을 보장하는 구조가 된다.
- AP 시스템이라면 파티션되어도 가용성을 보장하는 Cassandra 등이 적합하다.
- Cassandra는 최종적인 일관성을 가지고 있어서, 쓰기 작업이 완료된 후에 변경 사항이 없으면 최종적으로 최신 데이터를 반영하도록 설계되어 있다.
CAP 이론의 한계
- 완벽한 CP, AP 시스템은 사용할 수 없다.
- 대부분 분산 시스템은 CP와 AP의 중간 어디쯤이다.
- 모든 분산 시스템이 파티션을 사용하진 않는다.
PACELC 이론
CAP 이론의 한계에 따라 실제 운영을 반영한 이론이다.
파티션의 여부에 따른 특성을 고려한다.
분산된 환경에서 장애가 발생한(Partition) 경우, 가용성(Availability)과 일관성(Consistency)을 고려해야하고, 정상 상황의 경우(Else), 지연시간(Latency)과 일관성(Consistency)를 고려해야한다.
장애 상황이라면(P), 일부 접근 불가능한 노드가 있을텐데 이때 데이터 반영을 일관되게 적용할 수 없다면 아예 반영 자체를 실패하게 만들어 일관성을 보장하거나(C), 접근 가능한 노드라도 반영하게 해 가용성을 보장해야한다(A).
정상 상황이라면(E), 모든 노드에 일관성있게 데이터를 반영하고 지연 시간이 늘어나는 것을 감당해 일관성을 보장하던지(C), 빠르게 응답하기 위해 지연 시간을 줄이고 일관성은 저하해 지연 시간을 보장해야한다(L).
PACELC 이론의 4가지 시스템
| 장애 상황 | 정상 상황 | 설명 |
| P + A ( 장애 상황 + 가용성 ) | E + L ( 정상 상황 + 지연 시간 ) | 장애 상황에서는 가용 노드만 기능을 제공하고, 정상 상황에서는 지연 시간을 최적화 하는 것을 우선적으로 고려하는 시스템 |
| P + A ( 장애 상황 + 가용성 ) | E + C ( 정상 상황 + 일관성 ) | 장애 상황에서는 가용 노드만 기능을 제공하고, 정상 상황에서는 지연 시간이 증가하더라도 일관적인 데이터를 보장하는 시스템 |
| P + C ( 장애 상황 + 일관성 ) | E + L ( 정상 상황 + 지연 시간 ) | 장애 상황에서는 데이터에 일관성을 보장하고, 정상 상황에서는 지연 시간을 최적화 하는 것을 우선적으로 고려하는 시스템 |
| P + C ( 장애 상황 + 일관성 ) | E + C ( 정상 상황 + 일관성 ) | 장애 상황에서도, 정상 상황에서도 데이터가 일관성을 보장하는 시스템 |
MongoDB는 PA/EC 시스템이다.
분산 환경에서 장애가 발생하면 쓰기를 중단하고 읽기만 가능하게 만들기 때문이다.
또 정상 상황에서는 Secondary 멤버와 Primary 멤버 간의 데이터 일관성을 보장하기 때문이다.
여기서, 장애가 발생하면 쓰기가 중단되는 것을 조금 더 설명하자면 mongoDB의 automatic failover기능 때문이다.
'electionTimeoutMillis' 이라는 설정값만큼 timeout을 적용해, 이 timeout 시간 내에 Primary 노드가 다른 구성원과 소통하지 않으면 클러스터는 가지고 있는 Secondary 노드 중 하나를 Primary 노드로 만든다.
Secondary 노드 중 하나를 Primary 노드로 만드는 election 과정 중에는 쓰기 작업이 중단된다.
Cassandra나 DynamoDB는 PA/EL 시스템이다.
( 카산드라를 써보지 않았지만, ) 장애 상황에서는(P) 정상인 노드에만 데이터를 읽고 쓰고(A), 장애 노드가 복구된다면 그때 데이터를 반영한다.
정상 상황에서는(E) 빠른 응답을 위해서 모든 노드에 데이터를 읽고 쓰지 않는다(L).
레퍼런스
https://joosjuliet.github.io/nosql2/
https://itpenote.tistory.com/727
https://www.instaclustr.com/blog/cassandra-vs-mongodb/
https://www.mongodb.com/docs/manual/replication/#automatic-failover
'CS' 카테고리의 다른 글
| HashMap과 Red-Black Tree (0) | 2023.09.10 |
|---|---|
| 가상 메모리 (0) | 2023.08.22 |