데이터베이스 이중화 서비스에 대한 고민 및 적용 사례

1) 서론

현재 프로젝트를 진행 중이며, 주요 기능들은 어느 정도 완성되었고 실제 운영을 고려해볼 단계에 접어들었다. 이 과정에서 "운영 중 데이터베이스에 문제가 생긴다면 어떻게 대처할 것인가?" 와 "사용자들이 불편함을 느끼지 않도록 서비스를 지속적으로 제공하려면 어떻게 해야 하는가?" 라는 고민이 생겼다. 이 질문들에 대한 답으로 데이터베이스 이중화라는 솔루션에 도달했다.

 

소프트웨어 아키텍처의 선택은 상황에 따라 다양하게 적용될 수 있으므로, 개념적으로 정리를 잘해두는 것이 중요하다고 생각한다. 이를 기반으로 내가 원하는 아키텍처 조합을 의도한 대로 설계하고 동작하게 만들 수 있기 때문이다.

 

 

 

---

 

 

 

2) 데이터베이스 이중화를 도입한 이유

현재 서비스는 아직 실제 사용자가 없는 초기 단계이다. 하지만 이중화를 적용하려는 이유는 다음 세 가지로 요약할 수 있다.

1. 서비스 가용성 확보

• 데이터베이스 장애 발생 시, 대체 시스템을 통해 서비스 중단을 방지한다.

2.데이터 보호

• 데이터가 복제본에도 저장되므로, 천재지변, 삭제 실수 등 예기치 못한 상황에서도 데이터 복구가 가능하다.

3. 서비스 연속성 보장

• 중요 데이터를 안정적으로 보호하여 사용자 불편을 최소화하고 서비스의 신뢰성을 유지한다.

 

 

 

---

 

 

 

3) 현재 상황에서의 데이터베이스 이중화 전략

현재의 이중화 전략은 AWS DB, 라즈베리 컴퓨터 그리고 데스크톱을 조합하여 비용 효율성과 데이터 안정성을 모두 확보하는 방향으로 설계했다. 구체적인 구성은 다음과 같다.

 

1.AWS DB (Active 역할)

• 주 데이터베이스로 모든 실시간 트랙픽을 처리한다.
• 서비스의 주요 데이터가 저장되며, 장애가 발생하지 않는 한 기본적으로 모든 요청을 처리한다.

2. 라즈베리 컴퓨터 (준-Active 역할)

• 주기적인 동기화를 통해 AWS 데이터베이스의 복제본을 유지한다.
• CRON 작업을 활용하여 정해진 주기로 데이터를 가져오거나 백업한다.
• AWS 데이터베이스가 장애를 겪을 경우, 라즈베리 컴퓨터를 임시 Active로 전환하여 서비스를 유지할 수 있다.

3. 데스크톱 (Passive 역할)

• 수동 관리로 AWS 데이터베이스의 복제본을 유지한다.
• 데이터 동기화는 비정기적으로 이루어지며, AWS와 라즈베리 컴퓨터의 데이터 손실 또는 손상이 발생했을 때 최종 복구 지점으로 활용할 예정이다.

 

 

 

 

---

 

 

 

4) 현재 구조의 특징

1. 비용 절감

• 완전 자동화된 이중화 구성을 구축하는 데 드는 높은 비용을 줄이기 위해 수동 및 반자동 방식을 혼합하였다.

2. 유연성

• AWS 장애 시 라즈베리 컴퓨터를 대체 Active로 전환 가능하다.
• 최악의 경우 데스크톱 백업을 활용해 데이터의 복구가 가능하다.

3. 단계적 확장 가능성

• 클러스터링(Clustering)과 샤딩(Sharding)은 현재 필요하지 않으므로 추후 서비스 확장시 도입 예정이다.

 

 

 

---

 

 

 

5) 데이터베이스 이중화란?

데이터베이스 이중화는 동일한 데이터를 여러 데이터베이스에 저장하거나 복제하여 한 데이터베이스가 실패했을 때 다른 데이터베이스가 이를 대체하도록 만드는 구조이다.

주로 복제(Replication)와 클러스터링(Clustering)을 통해 구현된다.

 

 

 

 

---

 

 

 

6) 데이터베이스 이중화의 필요성

1. 서비스 가용성 (Availability) 확보

• 장애 시 대체할 수 있는 복제본이 있어 서비스 중단을 방지할 수 있다.

2. 데이터 유실 방지

• 데이터가 복제본에도 저장되므로, 주 데이터베이스에 문제가 생겨도 복구 가능하다.

3. 부하 분산 (Load Blancing)

• 읽기 요청을 복제본에 분산시켜 성능을 최적화 시킨다.

4. 비즈니스 연속성

• 중요 데이터를 안정적으로 보호하며, 재해 복구(Disaster Recovery) 시에도 신속한 복구가 가능하다.

 

 

 

---

 

 

 

7) 데이터 이중화 도입 방법

1. 복제(Replication)

복제는 데이터를 주 데이터베이스에서 보조 데이터베이스로 동기화하는 기술이다.

• 유형
  • 동기식 복제(Synchrnous Replication)
    • 모든 트랜잭션이 복제본에 적용된 후에만 커밋된다.
    • 데이터 일관성이 높으나, 지연 시간이 늘어날 수 있다.
  • 비동기식 복제(Asynchronous Replication)
    • 주 데이터베이스에만 트랜잭션을 커밋하고, 이후 복제본에 데이터를 전단한다.
    • 성능이 뛰어나지만 장애 시 데이터 유실 가능성이 존재한다.

 

2. 장애 조치 (Failover)

주 데이터베이스 장애 발생 시, 복제본을 즉시 활성화하여 사용자의 서비스 경험에 영향을 주지 않는 기술이다.

• Active-Passive Failover
  • 주 데이터 베이스(Active)는 활성화 상태, 보조 데이터베이스(Passive)는 대기 상태
  • 장애 발생 시 Passive 복제본이 Active로 전환된다
• Active-Active Failover
  • 두 데이터베이스 모두 활성화 상태로 트래픽을 처리하며, 데이터가 양방향으로 동기화 된다.

 

3. 데이터베이스 클러스터링 (Clustering)

여러 데이터베이스 인스턴스를 클러스터로 묶어 단일 베이터베이스처럼 작동하도록 구성한다.

• 특징
  • 읽기/쓰기 작업을 노드 간 분산한다.
  • 노드 하나가 다운되더라도 클러스터 전체가 가용성을 유지한다.

 

4. 데이터베이스 샤딩 (Sharding)

데이터를 여러 노드에 분산 저장하여 한 노드가 담당하는 데이터를 줄이는 기술이다.

• 특징
  • 대규모 데이터와 트래픽을 처리하는 데 유용하다.
  • 이중화와는 다르지만, 샤드별로 이중화를 구성하면 강력한 확장성과 안정성을 동시에 확보 가능하다.

 

 

 

---

 

 

 

8) 데이터베이스 이중화 설정 시 고려 사항

1. 데이터 일관성 (Consistency)

• 동기식 복제를 사용하면 일관성이 보장되지만 성능 저하가 발생할 수 있다.
• 비동기식 복제는 성능은 높지만 데이터 유실 가능성이 있다.

2. 성능 및 지연 시간 (Latency)

• 복제본과의 거리, 네트워크 상태에 따라 지연이 발생할 수 있다.

3. 비용

• 이중화된 데이터베이스를 유지하려면 인프라 비용이 증가한다.

4. 복구 시간 목표 (RTO)와 복구 시점 목표 (RPO)

•  장애 시 얼마나 빠르게 복구할지(RTO)와 얼마만큼의 데이터를 복구할지 (RPO)를 설정해야 한다.

5. 보안

• 복제본과의 데이터 전송 과정에서 암호화가 필요하다.

 

 

 

---

 

 

 

9) 데이터베이스 이중화 장점

1. 서비스 가용성 극대화

• 장애 발생 시에도 사용자 경험에 영향을 주지 않게 된다.

2. 데이터 보호

•  데이터 손실 가능성을 최소화 시킨다.

3. 확장성

• 읽기 트래픽을 복제본으로 분산하여 성능을 최적화 시킬 수 있다.

 

 

 

---

 

 

 

10) 데이터베이스 이중화 단점

1. 비용 증가

• 복제본을 유지하고 관리해야 하므로 비용이 추가적으로 발생한다.

2. 설정 및 유지보수 복잡성

• 클러스터 관리 및 장애 조치 설정이 까다로울 수 있다.

3. 동기화 문제 및 성능 문제

• 비동기 복제 시 데이터 지연 또는 손실 가능성이 있다. 
• 동기 복제 시에는 성능 이슈가 생길 수 있다.