SPOF와 해결 방법

SPOF ( Single Point Of Failure )
시스템 내에서 하나의 구성 요소가 실패할 경우 전체 시스템이 중단되는 지점

예를 들어, 모든 웹 트래픽을 단일 서버가 처리하거나, 데이터를 단일 데이터베이스 서버에서 관리하는 구조에서 둘 중 하나만 장애가 발생하더라도 전체 시스템이 정상적으로 동작하지 못하게 됨

더 나아가, 이는 코드 레벨에서도 발생할 수 있음 ( 특정 라이브러리나 서비스에 과도하게 의존하는 경우 )

데이터베이스 서버 의존성 해결 방안

---

서버가 단일 데이터베이스에 의존할 때 데이터베이스 서버 장애가 발생하면 전체 시스템에 영향을 줄 수 있음

따라서, 이를 어떻게 해결할 것인가 ???

[ 고려해야 할 것 ]

고가용성( High Availability )

⇒ 하나의 서버가 다운되더라도 다른 서버가 그 역할을 대신하여 서비스 중단을 방지

확장성( Scalability )

⇒ 필요에 따라 클러스터에 새로운 서버를 추가함으로써 시스템의 용량과 성능을 확장

부하 분산( Load Balancing )

⇒ 여러 서버에 작업을 분산하여 성능을 향상시키고, 응답 시간을 줄임

[ 해결 방안 ]

1. 데이터베이스 Replication 활용

Replication : 하나의 DBMS를 기반으로 Master/Slave 구조를 구성하여 DB 서버의 부하를 분산하는 것

Replication에서는 Master 노드에 쓰기 작업을 수행하고, Slave 노드에 조회 작업을 진행하도록 함

결제와 같이 실시간성이 중요한 작업에서는, 데이터 변경 사항이 Slave 서버에 즉시 반영되지 않을 수 있기
때문에 Master 서버에서 직접 조회를 수행하는 반면, 포인트 적립 후 내역을 조회하는 경우처럼 약간의 
지연이 허용되는 상황에서는 사용자가 새로고침 등을 통해 최신 데이터를 확인할 수 있으므로, 실시간성이 
반드시 요구되지는 않기 때문에 Slave 서버를 통해 조회를 진행하기도 함 

그럼 왜 이렇게 역할을 나누냐 ??

일반적으로 시스템에서는 쓰기 작업보다 조회 작업이 많기 때문에, 만약 모든 요청을 단일 DB 서버에서 처리하게 되면 해당 DB 서버에 부하가 크기 때문임

또한, Master 서버에 장애가 발생할 경우 Slave를 승격하여 시스템을 복구할 수 있도록 할 수 있음

💡

Mysql에서 Replication을 구성하는 과정 : 바이너리 로그를 활용

바이너리 로그 : Mysql에서 DB의 변경 이벤트 ( DDL, DML )를 기록하는 이진 로그 파일

( show, select 등의 단순 조회는 기록되지 않음 )

주요 용도

1 ) Replication

Master 노드에서 생성된 바이너리 로그를 Slave 노드가 읽어 동일한 변경을 수행하여 동기화

2 ) 시점 복구 ( Point-in-Time Recovery )

장애나 실수로 인한 데이터 손실 시, 백업 + 바이너리 로그를 통해 특정 시점까지 데이터 복원

바이너리 로그의 특징

트랜잭션은 commit 직전에 로그에 기록하며, 성공적으로 commit이 되면 로그가 유지되고 아니라면 무효, commit 후에는 Slave에 이 로그를 전달하여 Master의 변경사항을 반영 및 적용

바이너리 로그 방식의 문제점

바이너리 로그 복제는 로그 파일명과 위치로만 추적되고 Slave 서버는 이 파일명과 위치를 기준으로 Master의 바이너리 로그를 읽고 따라가는데 만약 장애가 발생하면 정확한 복제 지점을 파악하기 어렵고, 복구가 번거로워짐

GTID 방식으로 해결 ( Global Transaction ID )

로그 파일명과 위치로 추적하는 것이 아닌 트랜잭션의 고유 번호로 추적하기 때문에 몇 번째 트랜잭션까지 처리 했는가만 기억하면 되므로 장애 발생 시 안정성과 효율이 증가함

[ Replication 동작 과정 ]

1. Master에서 데이터 변경 발생 → Binary Log에 기록
2. Master의 바이너리 덤프 스레드가 Binary Log를 읽고 Slave로 전송
3. Slave의 I/O Thread가 받아서 Relay Log에 기록
4. SQL Thread가 기록된 Relay Log를 읽어 복제를 실행

Mysql의 Replication은 기본적으로 Master 서버의 변경 사항이 비동기 복제 방식으로 Slave에 전달됨

[ 장점 ]

여러 개의 Slave를 가질 수 있기에 조회 작업에 대한 부하가 분산됨

데이터를 백업할 수 있고, Master 노드가 다운된 경우 Slave를 승격함으로써 어느정도 이를 해결할 수 있음

[ 단점 ]

데이터의 정합성을 보장할 수 없음

Binary Log File 관리

Failover ( 장애 조치 ) 불가 : Master 노드가 다운 되었을 때 Slave를 승격시키지 못하는 것 ( 수동으로 진행 )

2. 데이터베이스 클러스터링 ( Cluster : 집합 )

여러 데이터베이스 서버를 하나의 시스템처럼 동작 하도록 구성하는 기술

( 다른 서버가 다운되더라도 다른 서버가 역할을 대신 하기에 서비스 중단을 방지할 수 있음 )

클러스터링의 유형

1. 공유 디스크 클러스터링 ( Shared-Disk Clustering )

   → 여러 서버가 동일한 디스크 스토리지를 공유하며 작업을 수행

   → 디스크의 일관성을 유지해야 하므로, 복잡한 매커니즘이 필요함

2. 공유 없음 클러스터링 ( Shared-Nothing Clustering )

   → 각 서버가 독립적인 디스크를 가지고 있으며, 노드 간 데이터를 분산 저장함

   → 노드 간의 통신이 중요하며, 데이터 파티셔닝과 리밸런싱이 필요

3. 병렬 클러스터링 ( Parallel Clustering )

   대규모 병렬 처리 작업을 수행하는 데 적합하며, 주로 데이터 웨어하우스에서 사용됨

   데이터와 쿼리를 여러 노드에 병렬로 분산하여 처리
   
   

Active-Active 방식

1. 공유 스토리지 방식

   모든 노드가 하나의 공통된 스토리지를 사용하여 데이터를 직접 읽고 씀

   공유 스토리지에 병목 현상이 발생할 수 있음

2. 로컬 스토리지 + 동기 복제 방식

   각 노드가 자체 스토리지를 가지고 있으며, 쓰기 작업은 다른 노드에 동기식으로 복제됨

   스토리지 고립성이 높고 유연한 확장이 가능하지만 복제 지연과 네트워크 부하 문제가 있음

클러스터에 포함된 모든 노드가 동시에 활성 상태로 작동하며, 트래픽과 작업을 분산 처리함

각 노드는 직접 쓰기 작업을 수행할 수 있으며, 하나의 노드에서 처리된 데이터는 다른 노드로 동기식으로 복제되고, 또한 로드 밸런싱을 통해 클라이언트 요청이 자동으로 여러 노드에 고르게 분산됨

이러한 구조 덕분에 여러 노드가 동시에 요청을 처리하므로 부하 분산이 가능하고, 특정 노드에 장애가 발생하더라도 서비스 중단을 방지할 수 있음

하지만, 데이터베이스 스토리지는 결국 하나이므로 병목 현상이 발생할 수 있음

Active-standBy 방식

1. Hot Standby 방식

   stand-by 서버를 항상 가동 상태로 두는 방식 ( 즉각 failover )

2. Cold Standby 방식

   stand-by 서버를 평시에는 가동하지 않은 상태로 두고, active 서버에 장애가 발생한 시점에 가동하는 방식

Active 상태의 서버와 stand-by 상태의 서버를 나누어 운영하는 것

stand-by 상태의 서버는 준비 상태로 대기하며 하트비트 모니터링을 통해 Active 서버가 동작하지 않음을 확인하면 active 상태로 변경되어 failover( 장애 극복 )를 진행

하나의 서버가 스토리지에 접근하므로 병목현상이 발생하지 않음

다만, 장애 발생 시 Stand-by 상태에서 Active 상태로 전환하는 시간 동안 서비스를 사용할 수 없게 되며, 여러 대의 서버 사용을 통한 트래픽의 감소 효과 역시 그 효율이 줄어든다는 단점이 있음

3. 데이터베이스 샤딩

데이터를 샤드라고 하는 더 작은 청크로 분할하고 여러 데이터베이스 서버에 저장하는 방식

샤딩과 레플리케이션 비교

데이터베이스 샤딩은 동일한 정보의 복사본을 생성하지 않으며, 대신 하나의 데이터베이스를 여러 부분으로 분할하여 서로 다른 서버에 저장함

따라서, 레플리케이션과 달리 고가용성을 제공하지 않으므로 샤딩과 레플리케이션을 함께 사용하는 것을 권장

[ 장점 ]

• 응답 시간 개선 대규모의 단일 데이터베이스에서 데이터를 검색하려면 여러 행을 검색하여 찾아야 하므로 시간이 오래 걸리지만, 데이터 샤드는 전체 데이터베이스보다 행 수가 적기 때문에 특정 정보를 검색하거나 쿼리를 실행할 때 시간이 단축되고, 여러 대의 서버를 사용하고 병렬로 처리함으로써 확장성과 성능을 향상
  

• 전체 서비스 중단 방지 만약 단일 DB 서버를 사용할 경우 장애가 발생하면 전체 서비스가 중단되지만 샤딩을 통해 여러 서버에 데이터를 나누어 관리한다면 일부 서버에 장애가 발생하더라도, 전체 서비스가 중단되지는 않음 하지만, 일반적으로 샤딩은 레플리케이션과 함께 사용하므로 어떤 샤드가 장애 나도 복제된 샤드를 승격해서 계속 운영 할 수 있음
  
• 효율적인 크기 조정 데이터를 여러 서버 ( 샤드 )에 나눠서 저장하고 처리하므로 필요할 때 서버를 더 추가하여 새로운 샤드를 생성할 수 있음 이러한 과정은 런타임 시점에도 가능하므로, 서비스를 중단하지 않고 확장할 수 있음
  

[ 단점 ]

• 핫스팟 데이터 분포가 고르지 않아 일부 샤드가 불균형하게 되는 것 ( 최적의 샤드 키를 사용하여 데이터를 고르게 분산할 수 있음 )
  
• 운영 복잡성 여러 샤드를 사용하는 환경에서는 개발자가 단일 데이터베이스가 아닌 여러 노드를 관리해야 하며, 데이터를 조회할 때는 여러 샤드를 쿼리하고 결과를 통합해야 하므로 분석이 더 복잡해질 수 있음
  

• 인프라 비용 서버를 추가할 경우 비용이 더 많이 발생
  
• 복잡성 대부분의 DBMS에는 샤딩 기능이 내장되어 있지 않으므로 개발자가 직접 수동으로 분할하고 분산하여 관리해야 함
  
  
  

[ 작동 원리 ]

데이터베이스 샤딩은 데이터 세트를 파티션이나 샤드로 분할하고, 전체 데이터를 행 단위로 나눠서, 샤드를 여러 서버에 나눠서 저장하고, 각 샤드는 자신만의 데이터를 가지고 있으며 한 노드에 저장됨

파티션 : 한 데이터베이스 서버 내에서 테이블을 분할하는 것

샤드 : 여러 서버에 데이터를 분산하여 저장하는 것 ( 분할된 데이터 청크 )

샤드 키는 데이터를 어떻게 분할할지를 결정하는 기준이 되는 열이며, 이 키의 값에 따라 각 데이터 행이 어느 샤드에 저장될지가 결정되게 됨

또한, 샤드 키는 기존 열에서 선택하거나 새 샤드 키를 만듦

데이터베이스 샤딩은 비공유 아키텍처를 기반으로 작동함

각 샤드는 독립된 DB 서버에서 작동하며, 서로를 알지 못하고, 요청된 데이터가 있는 샤드만 해당 작업을 처리하며, 필요한 경우 여러 샤드가 병렬로 작동합니다.

[ 샤딩 아키텍처 ]

데이터베이스의 샤딩은 샤드 키에 여러 규칙을 적용하여 특정 데이터 행을 처리할 노드 ( 서버 )를 결정

1 ). 범위 기반 샤딩 ( 동적 샤딩 )

값의 범위에 따라 데이터베이스 행을 분할하고 각 범위에 샤드 키를 할당하는 방식

이름	샤드 키
A ~ I로 시작	A
J ~ S로 시작	B
T ~ Z로 시작	C

위 경우에는 애플리케이션이 고객의 이름과 같은 값을 확인해 적절한 샤드 키를 정하고, 그런 다음 이 키를 기준으로 어떤 서버( 노드 )에 저장할지 결정하며, 해당 서버에 데이터를 저장하게 됨

데이터를 조회할 때는 애플리케이션이 샤드 키를 사용해 어떤 서버에 데이터가 있는지 찾아 접근함

[ 장점 ]

구현이 쉽다

[ 단점 ]

범위 기반이므로 단일 DB 서버에서 데이터가 오버로드( 과부하 ) 될 수 있음

2 ). 해시 샤딩

데이터를 샤드 키( 고객 ID, 이메일 .. )에 대해 해시 함수를 적용하여 결과 값에 따라 샤드를 선택하는 방식

[ 장점 ]

데이터 고르게 분산, 어느 샤드에 편중되어 저장되는 것을 방지

[ 단점 ]

정보와 의미에 따라 데이터베이스를 분할하지 않음

hash(샤드 키) % 샤드 수로 샤드를 결정하기 때문에 샤드의 수가 바뀌면, 즉 서버의 수를 늘리면 계산 결과가 바뀌기 때문에 해시 값을 재할당 하는데 어려움을 겪을 수 있음

3 ). 디렉터리 샤딩

미리 정의된 테이블( 조회 테이블 )을 참고해서 각 데이터 항목이 어떤 샤드에 저장될지 직접 매핑하는 방식

색상	샤드
Red	샤드 A
Blue	샤드 B
Green	샤드 C
Black	샤드 B
Yellow	샤드 A

[ 장점 ]

개발자가 직접 기준을 설정할 수 있으므로 유연성이 존재

[ 단점 ]

조회 테이블에 잘못된 정보가 존재하는 경우 샤딩이 실패하게 됨

4 ). 지리적 샤딩

지리적 위치에 따라 데이터를 분할하고 저장하는 방식

이름	샤드 키
John	캘리포니아
Jane	워싱턴
Paulo	애리조나

[ 장점 ]

로직이 복잡하지 않기에 검색이 빠름

[ 단점 ]

데이터가 고르게 분산되지 않을 수 있음

고른 데이터 분산을 위해 데이터베이스 샤딩을 최적화하는 방법

특정 샤드에만 데이터 오버로드가 발생하면 해당 샤드는 데이터베이스의 핫스팟이 되고, 핫스팟이 발생하면

데이터베이스의 조회 속도가 저하되므로 샤딩의 의미가 사라지게 됨

따라서, 샤드 키를 선택할 때 아래의 것들을 고려해야 함

1 ). 카디널리티

샤드 키가 가질 수 있는 고유한 값의 수

Ex) “남/여”로 나누게 되면 샤드를 고르게 분할하기 어렵지만, 종류가 많을수록 데이터가 더 고르게 분산됨

2 ). 빈도

특정 샤드에 특정 정보가 저장될 확률

만약 특정 사이트에서 샤드 키로 나이를 선택했을 때, 애초에 특정 연령대가 몰려있는 사이트라면 핫스팟이 발생할 수 있음

3 ). 단순 변화

샤드 키의 변화율로써, 샤드 키가 단순히 증가하거나 감소하면 균형이 맞지 않게 됨

설정 방법
샤드 A에는 구매 건수가 0~10건인 고객의 피드백이 저장
샤드 B에는 구매 건수가 11~20건인 고객의 피드백이 저장
샤드 C에는 21건 이상 구매한 고객의 피드백이 저장

⇒ 비즈니스가 성장함에 따라 21건 이상 구매하는 사용자가 많아진다면 핫스팟이 발생할 수 있음

샤딩의 대안

1 ). 수직 조정

단일 시스템의 컴퓨팅 파워를 높이는 것으로, DB서버에 CPU, RAM, HDD를 추가하는 방법

수직 조정은 비용이 적게 들고, 리소스에 제한이 있지만, 샤딩이 구현도 쉬워서 굳이 ?

2 ). 레플리케이션

…

3 ). 샤딩과 레플리케이션 비교

데이터베이스 샤딩은 동일한 정보의 복사본을 생성하지 않으며, 대신 하나의 데이터베이스를 여러 부분으로 분할하여 서로 다른 서버에 저장함

따라서 레플리케이션과 달리 고가용성을 제공하지 않으므로, 샤딩과 레플리케이션을 함께 사용하는 것을 권장