👼🏻 귤씨, 뭐하고 지냈어요?
🍊 제가 자격증이 없었어서요, 정처기랑 SQLD를 준비해봤어요
👼🏻 어때요! 잘 됐어요?
🍊 저도 알고싶은데, 2주 뒤에 알 수 있어요.
🗨️ 용어정리
👼🏻: 이중화에 관해서 공부하겠다구요! 관련 용어들부터 봐봐요
| Name | Description |
| AP 서버 (Application Server) |
1. 서버 그 자체 2. 네트워크가 연결되어있다면 그 네트워크를 통해 Endpoint 간 통신을 할 수 있는 Server 3. HTTP, TCP, UDP 등 다양한 프로토콜을 전달받아 클라이언트에 서비스 제공 |
| Hot Standby | 1. 항상 Active 시스템과 동일한 데이터를 유지하여 대기하는 구성 2. 장애 발생 시, 즉시 전환 가능 3. 다운타임 최소화 |
| Cold Standby | 1. 장애 발생 시에 데이터를 동기화하고 전환하는 구성 2. 전환 시간이 더 걸리나 비용적으로 저렴 |
| Outbound | 1. 시스템이나 네트워크에서 외부로 나가는 트래픽 2. 주로 데이터 전송 방향을 나타내는 용어 (외부로 향한다) ex1) 서버의 클라이언트 데이터 응답 ex2) 내부 네트워크에서 외부 네트워크로 데이터 전송 |
| FailOver | 장애대비기능, 장애 발생 시 대체 시스템으로 자동 전환하며 서비스가 지속되도록 함 |
| HA | 1. High Availability, 고가용성 2. 시스템의 장애 없이 지속적 운영이 가능한 능력 |
| Primary-Backup Server | 1. 대기 상태로 있다가 Primary 시스템 장애 발생 시 이를 대신하여 Backup 서버가 처리 2. Backup 시스템은 Primary 시스템의 데이터를 주기적으로 복제하여 최신 상태 유지 |
| inbound Traffic | 외부에서 서버로 들어오는 트래픽 (예: 사용자 요청) |
| Outbound Traffic | 서버에서 외부로 나가는 트래픽 (예: 응답 데이터 전송) |
1️⃣ 이중화를 위한 방법들
👼🏻 : 우선, 이중화를 하는 이유는 뭘까요?
🍊 : 서비스 연속성 유지과 트래픽 분산을 통한 과부하 방지요.
👼🏻 : 옹!
이중화를 하는 목적
- 죽은 서버의 업무를 지연 없이 동일한 기능을 수행할 수 있는 다른 서버로 대체하여 서비스 연속성을 유지
- 너무 많은 요청 트래픽을 분산시킴으로써 과부화를 막는 것
목적 달성을 위한 여러 방법
- L4스위치를 사용하는 하드웨어적 방법
- Proxy || VIP 설정 변경
- MMM/MHS 및 Maxscale 등 소프트웨어를 사용하는 방법
- 다양한 클러스터링 기법
👼🏻 그렇다면 규씨는 어떤 방법을 쓸 거예요?
🍊 우선 저 트래픽 분산 목적이기 때문에 로드 밸런싱을 통한 트래픽 제어 방법을 쓸 거구요, 특히 L4를 통한 로드 밸런싱 방식을 써볼 거예요.
2️⃣ L4 스위치의 역할
L4 스위치란
- OSI의 4계층(Transport Layer)에서 동작하는 네트워크 장비
- 데이터 패킷을 전송 계층의 정보(TCP/UDP Port Number)를 기반으로 처리하고 라우팅
- 주로 로드밸런싱과 네트워크 트래픽 관리에 사용
위와 같이 로드밸런싱은 트래픽과 관련하여 특정 포트 번호에 대해 필터링 후 보안/관리를 수행한다거나, Client와 Server 간의 세션 정보를 유지해서 연결 지속성을 보장하고 장애 발생 시 트래픽을 대체 서버로 자동 전환하는 역할을 수행하기도 한다.
이를 통해서 대용량 트래픽의 처리와 포트별 서비스 전환을 기대할 수 있다.
3️⃣ 로드밸런싱의 주요 방법
1. Round Robin
- 각 서버에 들어오는 요청을 순서대로 분배
- 구현과 설정이 간단하며, 모든 서버에 트래픽을 균등하게 분배
- 각 서버의 부하는 고려하지 않음
2. Least Connection (최소 연결 수)
- 현재 가장 적은 수의 활성 연결을 가진 서버에 새로운 요청을 분배
- 라운드 로빈과 달리 서버 간 부하를 효율적으로 분배
- 설정과 모니터링이 비교적 복잡함
3. IP HASH
- 클라이언트의 IP주소를 Hash를 통해 특정 서버에 매핑
- 동일 클라이언트의 요청은 항상 동일한 서버로 전달
- 세션 지속성이 보장, 동일 클라이언트의 트래픽을 일관되게 처리
- 특정 서버에 트래픽 집중 가능성 존재
이 외에도 Weight Round Robin, Weighted Least Connection 등이 존재한다.
4️⃣ 이중화 아키텍처
👼🏻 귤씨는 어떤 이중화 구조를 생각하시나요?
🍊 우선 Active-Active 아키텍처 내에서 DB와 AP 서버의 분리 여부를 중심으로 세 가지의 후보가 있었어요.
AP, DB가 함께 존재하는 서버 2개의 로드밸런싱
- AP와 DB가 동일한 물리적 서버에 공존한다
- 각 AP 서버는 로컬 DB만 접근한다
- 두 DB는 비동기 복제를 통해 데이터 일관성을 유지한다
👼🏻 이렇게 되면 우려점이 있지 않나요?
🍊 우선, 비동기이니까 실시간성은 떨어질 거에요. 그러나 일정 시간차(ms)를 허용할 수 있다는 가정이 있어 괜찮다고 보고 있어요.
AP 서버 2개와 별도의 DB 서버 1개의 로드밸런싱
- AP와 DB가 물리적으로 분리되어 있어 독립적 확장이 가능하다
- 두 AP 서버가 공통의 DB 서버에 접근한다
- 모든 데이터 처리가 DB서버에 이루어져 데이터 일관성을 유지할 수 있다
👼🏻 여기에서 우려점은요?
🍊 단일 DB 서버의 부하가 집중될 수도 있겠죠, DB 성능이 전체 시스템에 대한 영향력이 커져 있는 구조예요. 단일 장애점의 위험을 고려해야 합니다.
AP 서버 2개와 별도의 DB 서버 2개의 로드밸런싱
- AP와 DB가 물리적으로 분리되어 있다
- 두 AP 서버는 상황에 따라 두 외부 DB 서버 중 하나에 접근한다
- 동일성을 위하여 DB는 Replication 혹은 클러스터링을 이용토록 한다
👼🏻 얘는 또 어떤 고려 사항이 있을까요?
🍊 DB 간의 데이터 동기화, 부하 분산을 동일하게 고려해 봐야죠.
👼🏻 좋아요, 현재 서비스는 데이터 일관성, 장애 복구 능력, 부하 분산, 확장성 중 어떤 것에 우선을 두는지를 보고 좋은 아키텍처 결정을 내려봐요!
🍊 그래요.