데이터 무결성

✏️ 데이터 무결성에 대해 설명해주세요

✅ 데이터 무결성이란?

데이터 무결성은 데이터의 정확성, 일관성, 유효성이 유지되는 것을 의미한다.

정확성
중복이나 누락이 없는 상태

일관성
원인과 결과의 의미가 연속적으로 보장되어 변하지 않는 상태

유효성
사용자로부터 값을 입력받을 때 정확한 값만 입력되도록 하는 것

데이터 무결성 설계가 없다면? ❌

테이블에 중복된 데이터 존재, 부모와 자식 데이터 간의 논리적 관계 깨짐, 잦은 에러와 재개발 비용 발생 등과 같은 문제가 발생할 것이다.

그렇기 때문에 DBMS에서 데이터 무결성이 유지되는 것은 아주 중요하며, 주로 데이터에 적용되는 연산에 제한을 두어 데이터의 무결성을 유지한다.

데이터 무결성 종류

1. Entity Integrity (개체 무결성)

기본 키 제약이라고도 하며, 테이블은 기본키를 지정하고 그에 따른 무결성 원칙을 지켜야 하는 조건

• 기본키(Primary Key)는 Null 값을 가질 수 없다.
• 기본 키는 테이블 내에 오직 하나만 존재해야 한다.
  즉, 하나의 테이블에 동일한 기본키를 가진 레코드는 존재할 수 없다.

2. Referential Integrity (참조 무결성)

외래 키 제약이라고도 하며, 테이블 간의 참조 관계를 선언하는 제약조건

• 외래키(Foreign Key)는 Null 값을 가지거나 참조 릴레이션(부모 테이블)의 기본키와 동일해야 한다.
• 외래 키 속성은 참조할 수 없는 값을 지닐 수 없다. -> 참조할 수 있는 값이어야 한다.
  즉, 외래 키 속성 값이 상위 테이블의 인스턴스에 반드시 존재하거나 NULL 이어야 한다.

예시

🗂 테이블 구조
Department (부서 테이블 - 부모 테이블)

dept_id (PK)	dept_name
1	HR
2	Engineering
3	Marketing

Employee (직원 테이블 - 자식 테이블)

emp_id (PK)	name	dept_id (FK)
101	Alice	1
102	Bob	NULL
103	Carol	2
104	David	99 ❌

• NULL 로 지정되어, 참조를 안 하는 것은 괜찮다. (값이 아직 없다는 의미)
• 하지만, David 처럼 부모 테이블에 존재하지 않는 99 부서를 참조할 수는 없다.

3. Domain Integrity (도메인 무결성)

열(column)에 저장되는 값이 정의된 도메인(값의 범위, 형식)을 반드시 만족해야 한다는 제약 조건

• 테이블에 존재하는 필드의 무결성을 보장하기 위한 것
• 필드의 타입, Null 값 허용 등에 대한 사항을 정의하고 올바른 데이터가 입력되었는지 확인한다.
• SQL에서는 NOT NULL, CHECK, DEFAULT, ENUM 등이 도메인 무결성을 구현하는 도구

4. Null Integrity (Null 무결성)

테이블의 특정 속성 값이 NULL이 될 수 없게 하는 조건

5. Key Integrity (키 무결성)

한 테이블에는 적어도 하나의 키(튜플을 고유하게 식별할 수 있는 속성 집합)가 반드시 존재해야 하는 조건

6. Unique Integrity (고유 무결성)

테이블의 특정 속성에 대해 각 레코드들이 갖는 값들이 서로 달라야 하는 조건

7. Relationship Integrity (관계 무결성)

테이블의 어느 한 레코드의 삽입 가능 여부 또는 한 테이블과 다른 테이블의 레코드들 사이의 관계에 대한 적절성 여부를 지정한 조건

• 하나의 테이블에 새로운 레코드를 삽입할 때, 그 레코드가 다른 테이블과의 관계에서 적합한지 확인하는 조건이다.
• 외래 키로 연결된 두 테이블 사이에서, 자식 테이블의 외래 키 값이 부모 테이블의 기본 키 값과 적절한 관계를 유지하는지 확인하는 조건이다.

💡 무결성 제약조건의 장단점

장점

• 스키마를 정의할 때, 일관성 조건을 오직 한 번만 명시하면, DB가 갱신될 때 DBMS가 자동적으로 일관성 조건을 검사해주어 응용 프로그램이 일관성 조건을 매번 검사할 필요가 없다.
• 예를 들어, 제약 조건으로 데이터의 값이 0보다 크거나 같아야 한다라는 제약조건을 걸어놓으면 DBMS가 자동으로 이 조건을 검사해주기 때문에 응용 프로그램에서 이 조건에 대한 검사를 작성하지 않아도 된다.
• 무결성 제약조건을 사용하면 데이터를 실생활의 의미에 맞게 사용할 수 있다.

단점

• 프로그래밍 작업이 훨씬 복잡해지며, 무결성 제약조건을 반복해서 구현해야 한다.
• 무결성 제약조건들끼리 서로 충돌이 발생할 수 있다.

---

RDBMS vs NoSQL

✏️ RDBMS와 NoSQL에 대해 설명해주세요

DBMS, SQL

DBMS

• 데이터베이스 관리 시스템
• 사용자와 데이터 사이에서 사용자의 요청에 의해 데이터의 생성 조회 등 데이터베이스를 관리해주는 시스템

SQL

• 관계형 데이터베이스 관리 시스템(RDBMS)의 관리를 위해 제작된 언어

1️⃣ RDBMS (Relational Database Management System)

💡 개념

• 관계형 데이터베이스 관리 시스템으로, 모든 데이터를 테이블 형태로 표현
• 외래 키(foreign key)를 사용하여 테이블 간 Join 가능
• ACID (Atomicity, Consistency, Isolation, Durability) 원칙을 기본으로 구성
  • ACID란?

✅ 장점

RDBMS는 제약조건, 트랜잭션, 참조 무결성 등을 통해 정확하고 일관된 데이터만 유지되도록 보장하기 때문에 데이터 정합성 측면에서 매우 강력한 장점이 있다.

데이터 정합성이란?

데이터가 정확하고, 일관되며, 신뢰할 수 있는 상태

1. 스키마 기반 구조

• 정의해놓은 스키마에 따라 데이터가 저장되므로 명확한 데이터 구조가 보장된다.

2. 무결성 제약조건 제공

• 기본 키(PK), 외래 키(FK), UNIQUE, NOT NULL, CHECK 같은 제약조건을 통해 잘못된 데이터(중복, 없는 참조, 허용 범위 밖의 값 등)가 저장되지 않게 방지한다.

3. 트랜잭션 지원 (ACID 원칙)

• 하나의 작업 단위를 원자성(Atomicity) 있게 처리하여 중간에 오류 나도 데이터가 깨지지 않는다.
• 동시에 여러 사용자가 접근해도 일관성(Consistency)과 격리성(Isolation) 유지된다.
• 오류 발생 시 롤백(Rollback)으로 정합성 복구 가능

❌ 단점

1. 복잡한 조인 성능 저하

• 테이블 간 관계를 맺고 있어 시스템이 커질 경우, JOIN문이 많은 복잡한 쿼리가 발생할 수 있다.

2. 확장성 제한

• 성능 향상을 위해 Scale-up (수직 확장)만 지원한다.
• Scale-out (수평 확장)이 불가능하기 때문에 처리 비용이 기하급수적으로 커지고, 대규모 트래픽 처리에 한계가 있을 수 있다.

3. 스키마 유연성 부족

• 스키마(테이블 구조)를 미리 정의해야 한다.
• 구조가 변경될 경우, 번거롭고, 유연한 데이터 저장이 어렵다.

❓ Scale-Up, Scale-Out 란?

서버 확장을 위한 방법에는 크게 두가지가 있는데 바로 Scale out과 Scale up이다.
한 대의 서버에서 감당할 수 있는 부하를 감당할 수 있도록 하는 것이 두 방법의 공통된 목표이다.

Scale-Up

• 일을 더 잘하는 사람으로 교체하는 것(Scale Up)
• CPU, 메모리 등의 자원을 단일 서버에 추가하여 성능을 향상시키는 방식
• 단일 서버의 성능을 강화하기 때문에 수직 스케일링 (vertical scaling) 이라고도 한다.
  

Scale-Out

• 일을 하는 사람을 여럿으로 늘리는 것(Scale Out)
• 여러 서버를 연결하여 (서버의 수를 증가시켜) 시스템의 성능을 향상시키는 방식
• 서버를 추가로 확장하기 때문에 수평 스케일링 (horizontal scaling)이라고도 한다.
• 비슷한 사양의 서버를 추가로 연결해 처리할 수 있는 데이터의 용량이 증가하며, 기존 서버의 부하를 분담하여 성능도 향상시킬 수 있다.

2️⃣ NoSQL (Not Only SQL)

이름 때문에 SQL을 사용하지 않는다고 생각할 수 있지만, 그게 아니라 RDBMS가 갖고 있는 특성 + 다른 특성들도 지원한다는 의미이다.

💡 개념

• RDBMS의 성능과 한계를 극복하기 위해 등장
• ACID 특성을 제공하진 않지만 뛰어난 확장성이나 성능의 특징을 가진다.
• 테이블 간의 관계 정의를 하지 않기 때문에 테이블 간 JOIN이 필요없다.

📊 NoSQL 모델 종류

1. Key-Value DB

구조 : key → value
특징: 단순하고 빠르며, 캐시나 세션 저장에 적합하다.

• Key 값은 모든 데이터 타입을 가질 수 있고, 중복되지 않는 유니크 값을 가진다.
• 메모리 기반으로 빠르게 데이터를 읽어올 수 있다.
• 예 : Redis, AWS DynamoDB, Riak 등

// Redis 예시
"user:123" → "Alice"
"session:456" → "eyJhbGciOiJIUzI1NiIs..."

• 키를 통해 값을 바로 찾는다. (O(1) 접근)

2. Document DB

구조: JSON / BSON 문서
특징: 계층적, 중첩 가능. 유연한 스키마

• 비정형 대량 데이터를 저장하기 위한 방식
• key → value 에서 확장되어 key → document 형태로 저장한다.
• Document는 계층적인 데이터 타입 (JSON, XML)으로 저장된다.
• JSON 타입을 사용하므로 HTTP 기반의 웹 서버의 경우 데이터를 편리하게 주고받을 수 있다.
• 예 : MongoDB, Couch DB 등

// MongoDB 예시
{
  "_id": "user123",
  "name": "Alice",
  "email": "alice@example.com",
  "address": {
    "city": "Seoul",
    "zip": "12345"
  }
}

• 하나의 문서에 관련 정보가 다 들어가며, JOIN이 필요하지 않다.

3. Wide Column DB

구조: 행(Row) - 열(Column) 기반, 컬럼을 그룹으로 묶음
특징: 대량 데이터 분석, 빠른 쓰기에 유리

• Row가 아닌 Column 위주로 데이터를 저장하는 방식
• key, value와 유사한 형태의 Column-family Model
• 데이터가 내부에서 Key를 기준으로 오름차순으로 저장된다.
• 이전의 모델들이 key-value 값을 이용해 필드를 결정했다면, 이 모델은 키에서 필드를 결정한다.
• 예 : Apache Cassandra, HBase, Hypertable

// Cassandra 예시
Row Key: user123
-----------------------------------------
| name     | email            | age     |
|----------|------------------|---------|
| "Alice"  | "alice@ex.com"   | 30      |

• 같은 Row에서도 컬럼 구조가 유동적이며, 다른 Row에는 없는 컬럼이 있을 수 있다.

4. Graph DB

구조: 노드(Node) + 간선(Edge)
특징: 복잡한 관계 표현에 최적화 (SNS, 추천 시스템 등)

• 객체와의 관계를 그래프 형식의 데이터로 저장하기 위한 방식
• 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 저장한다.
• SNS, Network Diagrams 등과 SNS에서 함께 아는 친구 찾기, 추천 등 연관된 데이터를 추천해주는 엔진이나 패턴 기능에 사용된다.
• 예 : Neo4j, ArangoDB

// Neo4j 예시 (Cypher 쿼리)
(Alice)-[:FRIEND]->(Bob)
(Alice)-[:LIKES]->(Post123)

• 관계(Edge)에 의미를 담아 쿼리가 매우 직관적이다.

✅ 장점

1. 유연성

• 스키마가 없어 유연하고 자유로운 데이터 구조
• 언제든지 컬럼을 자유롭게 추가/제거할 수 있다.

2. 수평 확장성 우수

• 성능 향상을 위해 Scale-up / Scale-out 모두 가능
• 데이터 분산이 용이하고, RDBMS에 비해 대용량의 데이터 저장 가능

3. 다양한 데이터 처리

• JSON, XML, 로그 등 비정형 데이터도 다룰 수 있다.

4. 특정 목적에 최적화

• 분석, 캐시, 추천 등 상황에 따라 특화된 구조 사용 가능

❌ 단점

1. 데이터 정합성 약함

• 제약조건과 트랜잭션 기능이 제한적이거나 없기 때문에, 데이터 정합성을 보장하려면 애플리케이션 단에서 직접 처리해줘야 한다.

2. 복잡한 관계 표현 어려움

• JOIN이 없거나 제한적이기 때문에 관계형 데이터 처리에는 불리하다.

❓ 언제 RDBMS ? 언제 NoSQL?

⚙️ RDBMS (관계형 데이터베이스) 사용해야 할 때

1. 데이터 정합성 & 트랜잭션 관리가 중요할 때

• ACID 특성을 보장해야 하는 경우
• 상호 연관된 데이터가 많은 경우 (예: 관계형 데이터를 다루는 서비스)
• 예 : 은행 시스템 (입금, 출금 트랜잭션의 정확한 처리), 재고 관리 시스템 (상품 수량의 정확한 추적)

2. 복잡한 쿼리와 JOIN이 필요한 경우

• 여러 테이블 간의 복잡한 관계를 표현하고, JOIN 쿼리를 자주 사용하는 경우
• 예 : 고객 주문 시스템 (고객과 주문, 제품 간의 관계), 교육 시스템 (학생, 수업, 교수 등 복잡한 관계)

3. 고정된 스키마가 필요한 경우

• 테이블 구조가 고정되어 있고 변경이 적은 데이터를 다룰 때
• 예 : 재무 회계 시스템 (항목들이 고정되어 있음)

🔄 NoSQL (비관계형 데이터베이스) 사용해야 할 때

1. 수평 확장이 중요한 경우

• 데이터가 매우 커지고 트래픽이 폭증하는 상황에서 서버를 쉽게 추가하고 수평 확장을 하고자 할 때
• 예 : 소셜 미디어 서비스 (수억 명의 사용자를 처리), IoT 시스템 (기기에서 발생하는 방대한 양의 데이터)

2. 유연한 스키마가 필요할 때

• 데이터 구조가 자주 변경되거나 비정형 데이터가 많을 때
• 예 : 블로그 서비스 (각 블로그 포스트는 다른 형식의 데이터), 로그 분석 시스템 (서버 로그는 고정된 형식이 아님)

3. 비정형 데이터나 반정형 데이터를 다룰 때

• JSON, XML, 이미지, 비디오와 같은 비정형 혹은 반정형 데이터를 많이 다루는 시스템
• 예 : 멀티미디어 콘텐츠 (이미지, 동영상 등), 로그 데이터 분석 (서버 로그, 웹 로그 등)

4. 데이터 모델이 간단하거나 빠른 쓰기/읽기가 중요한 경우

• 간단한 키-값 또는 문서 모델로 데이터를 빠르게 처리해야 할 때
• 예 : 세션 저장소 (Redis 등), 캐싱 시스템 (빈번한 데이터 요청에 대한 캐싱)

---

Redis

✏️ Redis에 대해 설명해주세요

📌 Redis란?

Redis (REmote DIctionary Server) 는 비정형 데이터를 저장하고 관리하기위한 오픈소스 기반의 인메모리 기반의 Key-Value NoSQL 데이터 저장소이다.
데이터를 메모리에 저장하기 때문에 읽기/쓰기 속도가 매우 빠르며, 다양한 데이터 구조를 지원한다.

• DB, Cache, Message Queue, Shared Memory 용도로 사용된다.

❓ DB가 있는데도 Redis라는 인메모리 데이터 저장소를 사용하는 이유는 뭘까?

데이터베이스는 데이터를 물리 디스크에 직접 쓰기 때문에 서버에 문자가 발생하여 다운되더라도 데이터가 손실되지 않는다. 하지만, 매번 디스크에 접근해야 하므로 사용자가 많아질수록 부하가 많아져 느려질 수 있다.
그렇기 때문에 캐시 서버를 도입하여 사용하는데, 이 때 사용할 수 있는 것이 Redis이다.

캐시는 한 번 읽어온 데이터를 임의의 공간에 저장하여 다음에 읽을 때는 빠르게 결과값을 받을 수 있도록 도와준다. 같은 요청이 여러 번 들어오면, 매번 데이터베이스를 거치는 것이 아니라 캐시 서버에서 첫 번째 요청 이후 저장된 결과값을 바로 가져와주기 때문에 DB의 부하를 줄이고 서비스의 속도가 느려지지 않는다는 장점이 있다.

📌 Redis에서 자주 쓰이는 캐시 패턴

1️⃣ Look-Aside (Lazy Loading)

• 가장 일반적이고 널리 사용되는 패턴

🔁 흐름

1. 클라이언트가 캐시에 먼저 조회
2. 없으면 DB에서 읽고 → Redis에 저장
3. 이후부터는 Redis에서 빠르게 제공

2️⃣ Write-Through

• 데이터를 DB와 Redis에 동시에 쓰는 방식

🔁 흐름

• 클라이언트가 데이터를 쓰면, 먼저 Redis에 저장하고, 동시에 DB에도 저장한다.

3️⃣ Write-Behind (Write-Back)

• 먼저 Redis에 쓰고, 일정 시간 후에 DB에 저장하는 방식

🔁 흐름

1. 모든 데이터를 Redis에만 저장
2. 특정 시간동안 저장 후, 비동기적으로 DB에 저장
3. DB에 저장된 데이터는 Redis에서 삭제

🚀 Redis의 주요 특징

⚙️ Key-Value 구조

• 기본적으로 Key와 Value 쌍으로 데이터를 저장한다.
• 때문에 쿼리를 사용할 필요가 없다.

💾 인메모리 저장소

• 모든 데이터를 RAM에 저장하므로 매우 빠른 응답 속도를 제공한다.

🧱 다양한 데이터 타입

• String, List, Set, Hash, Sorted-Set, BitMap 등의 자료 구조를 지원한다.
• 개발의 편의성, 생산성이 좋아진다.
  예를 들어, 정렬된 데이터를 가져와야 한다고 했을 때,
  • DB의 경우 : DB에 데이터를 저장하고, 저장된 데이터를 정렬하고 다시 읽어오는 과정은 디스크에 직접 접근해야하기 때문에 시간이 걸린다.
  • Redis의 경우 : Redis에서 제공하는 Sorted-Set 자료구조를 사용하면 좀 더 빠르고 간단하게 데이터를 정렬할 수 있다.

🕒 TTL 지원

• Key에 만료 시간(Time-To-Live)을 설정할 수 있다.

🔁 Pub/Sub 기능

• 메시지 브로커처럼 채널 기반 실시간 메시징이 가능하다.

🔄 퍼시스턴스 옵션

• 인메모리 데이터 저장소가 가지는 휘발성의 특성으로 데이터가 유실될 경우를 방지하여 백업 기능을 제공한다.
  • AOF (Append On File) 방식 : Redis의 모든 Write/Update 연산 자체를 모두 log 파일에 기록하는 형태
  • RDB (Snapshot) 방식 : 순간적으로 메모리에 있는 내용 전체를 디스크에 담아 영구 저장하는 방식

⚡ 싱글 스레드 기반

• 하나의 스레드로 동작하지만 I/O 처리가 매우 빠르다.
• 한 번에 하나의 명령만 처리할 수 있으므로, Race Condition이 거의 발생하지 않는다.
• 다만, 중간에 처리 시간이 긴 명령어가 들어올 경우, 그 뒤에 명령어들은 모두 앞에 있는 명령어가 처리될 때까지 대기해야 한다.

📚 오픈소스

• 무료이며 다양한 언어와 플랫폼에서 사용할 수 있다.

⚠️ Redis 사용 주의점

1. 싱글 스레드의 특성상, 한 번에 하나의 명령만 수행할 수 있기 때문에 처리하는데 시간이 오래 걸리는 요청의 경우 장애가 발생할 수 있다.

2. 서버에 장애가 발생했을 경우, 이에 대한 운영 계획이 필요하다.

• 인메모리 데이터 저장소의 특성상, 서버에 장애가 발생했을 경우 데이터 유실이 발생할 수 있다.

3. 크고 작은 데이터를 할당하고 해제하는 과정에서 메모리의 파편화가 발생하여 응답 속도가 느려질 수 있기 때문에 메모리 관리가 중요하다.

---

파티셔닝, 리플리케이션, 샤딩, 클러스터링

✏️ 파티셔닝, 리플리케이션, 샤딩, 클러스터링에 대해 설명해주세요

🧩 1. 파티셔닝 (Partitioning)

데이터를 논리적으로 나누어 저장하는 것
(큰 테이블 → 여러 개의 테이블로 나누어서 저장)

종류

• 수직 파티셔닝: 컬럼 기준 나눔 (ex. 자주 쓰는 컬럼만 따로 저장)
• 수평 파티셔닝: 행 기준 나눔 (ex. 고객ID 11000, 10012000 따로 저장)

✅ 장점

• 쿼리 성능이 향상된다.
• 관리가 용이하다.

🌐 2. 샤딩 (Sharding)

수평 파티셔닝의 특수한 형태이다. 즉, 테이블을 Row로 나눠서 Shard로 분배한 것이다.

• 샤딩은 여러 서버에 스키마가 복제된다.
• 데이터는 Shard Key를 기준으로 여러 노드들에 나누어 저장된다.
• Shard Key 알고리즘에 따라 여러 Sharding이 있을 수 있다.

샤딩 알고리즘

1. Hash Sharding

• Shard Key는 DB의 id를 Hashing 하여 결정한다.
• 구현이 간단하다. (key-value)
• DB 서버가 추가될 경우 해시 함수가 변경되어야 하므로 기존에 저장되던 데이터들의 정합성이 깨지게 된다. -> 확장성이 떨어진다.
• 공간에 대한 효율성을 고려하지 않는다.

2. Dynamic Sharding

• Locator Service를 사용한다.
  • Locator Service : 테이블 형식의 데이터를 바탕으로 샤드를 결정하여 적절히 저장하는 방식
• 확장에 용이하다.
  • Node 개수를 늘릴 경우, Locator Service에 Shard Key를 추가하면 된다.
• 해시 샤딩과 달리 단순 키만 추가해주면 되기 때문에 확장성이 좋다.
• Locator Service에 의존적이기 때문에, Locator Service에 문제가 생기면 나머지 샤드에도 문제가 발생한다. (Single Point Of Failure)

3. Entity Sharding

• 1,2번은 Key-Value 형태를 지원하기 위해 나온 방법이라면, Entity Sharding의 경우, RDBMS에 적합하다.
• 관계가 있는 Entity끼리 같은 Shard 내에 공유하도록 만든 방식이다.
• 단일 Shard 내에서 쿼리는 빠르고 효율적이다.
• 다른 Shard의 Entity와 연관되는 경우 비효율적이다.
  • 조인 또는 트랜잭션 대상 데이터가 서로 다른 샤드에 있을 때 발생하는 비효율
  • SELECT * FROM Post JOIN User ON ... (조인)
• cross-partition 쿼리는 single parition 쿼리보다 일관성과 성능이 좋지 않다.
  • 하나의 쿼리가 여러 파티션(샤드)에 동시에 걸릴 때 발생하는 일관성/성능 저하
  • SELECT * FROM Order WHERE amount > 1000 (조건이 모든 샤드에 퍼짐)

👯‍♂️ 3. 리플리케이션 (Replication)

데이터를 복제하여 여러 서버에 동일하게 저장하는 방식이다.
여러 개의 DB를 수직적인 구조 Primary-Secondary (Master-Slave / Source-Replica)로 구축하는 방식이다.

• DB 서버뿐만 아니라 DB Storage도 여러 개 만드는 방식이다.
• Primary는 쓰기 작업만을 처리하고, Secondary는 읽기 용도로만 사용한다.
• Secondary 서버 여러 개를 통해 분산하여 처리할 수도 있어 성능 향상에 도움이 된다.
• 비동기 방식으로 데이터를 동기화하기 때문에 일관성있는 데이터를 얻지 못할 수도 있다.
• Primary 서버가 다운되면 복구 및 대처가 까다롭다.

🧱 4. 클러스터링 (Clustering)

여러 개의 DB를 수평적인 구조로 구축하는 방식이다.

• 분산 환경을 구성하여 Single Point of Failure와 같은 문제를 해결할 수 있는 Fail Over 시스템을 구축하기 위해 사용한다.
• 동기 방식으로 노드들 간의 데이터를 동기화한다.

❓ Single Point of Failure, Fail Over?

• Single Point Of Failure (단일 장애점, SPOF) : 하나가 고장 나면 전체 시스템이 멈추는 구성 요소
• Fail Over : 시스템에서 장애가 발생했을 때, 자동으로 대기 중인 다른 시스템(백업 시스템)으로 업무를 넘겨서 서비스가 중단되지 않도록 하는 기술

1. Active & Active

• 서버 한 대가 죽더라도 하나의 서버가 동작하고 있어서 서비스에 큰 문제가 생기지 않는다.
• 다른 서버가 동작하는 동안 복구를 할 수 있어 서버의 중단 없이 서비스를 제공할 수 있다.
• 하나의 데이터베이스에 가해지는 부하가 두 개로 나눠지므로 CPU, Memory 부하가 줄어든다.
• 여러 개의 서버가 하나의 스토리지를 공유하기 때문에 병목현상이 발생할 수 있다.

2. Active & Stand-By

• Active 상태의 서버에 문제가 생겼을 때 Fail Over를 하여 Stand-By 서버를 Active로 전환한다.
• Fail Over가 발생하는 시간동안에는 서비스가 중단될 수 있다.
• 결론적으로는 서버 한 대가 운영되는 것이며, 효율은 Active & Active의 절반이다.
• 비용이 저렴하다.