728x90
안정성을 수치로 어떻게 표현하는지, 안정성(가용성)을 높이기 위한 방법에는 무엇이 있는지 알아보고자 한다.
가용성 (Availablity)
- 시스템이 언제든지 사용 가능한 상태를 유지하는 능력
- 컴퓨터 시스템이 특정 기능을 실제로 수행할 수 있는 시간의 비율
= 전체 사용 시간 중 정상적인 사용 시간
- `업타임(uptime)` : 정상적인 사용시간
- `다운타임(downtime)`: 정상적인 사용이 불가한 시간
가용성 = 업타임 / (업타임 + 다운타임)
📌 고가용성 (HA, High Availablity) = 가용성이 높음, 지향점
안정적인 시스템은 어느정도의 가용성을 가져야 하는가?
일반적으로 안정적인 시스템인 `99.999%` 이상을 목표로 함 (= 파이브 나인스)
| 가용성 (%) | 1년간 다운타임 | 한 달간 다운타임 | 한 주간 다운타임 |
| 90% (원 나인) | 36.53일 | 73.05시간 | 16.8시간 |
| 99% (투 나인스) | 3.65일 | 7.31시간 | 1.68시간 |
| 99.5% | 1.83일 | 3.65시간 | 50.4분 |
| 99.9% (쓰리 나인스) | 8.77시간 | 43.83분 | 10.08분 |
| 99.95% | 4.38시간 | 21.92분 | 5.04분 |
| 99.99% (포 나인스) | 52.56분 | 4.38분 | 1.01분 |
| 99.999% (파이브 나인스) | 5.26분 | 26.3초 | 6.05초 |
| 99.9999% (식스 나인스) | 31.56초 | 2.62초 | 0.604초 |
| 99.99999% (세븐 나인스) | 3.16초 | 0.262초 | 0.0604초 |
파이브 나인스의 다운타임도 굉장히 낮지만, 절대로 다운이 돼서는 안 되는 시스템의 경우엔 치명적
서비스는 왜 다운되는가?
- 과도한 트래픽
- 예상치 못한 소프트웨어 상의 오류
- 하드웨어 장애
- 보안 공격, 자연 재해
- etc..
안정성은 어떻게 높일 수 있을까?
= 다운타임을 낮추면 됨
- 다운타임의 발생원인을 원천적으로 차단하는 것은 불가능 함
(자연 재해 어케 막을 건데) - 핵심은 문제가 발생해도 계속 기능하도록 설계하는 것
📌 결함 감내 (Fault Tolerance)
문제가 발생하더라도 기능할 수 있는 능력
결함을 감내할 수 있도록 서비스나 인프라를 설계하는 것이 중요
가용성을 높이는 방법
이중화 (Redundancy)
"하나가 고장 나면 다른 하나가 대신한다."
결함을 감내하여 가용성을 높이기 위한 가장 기본적이고 대표적인 방법
= 예비(백업)을 마련하는 방법
이중화 대상: 문제가 발생할 경우 `시스템 전체가 중단`될 수 있는 대상 = `SPoF`(Single Point of Failure)
- 서버 컴퓨터, 네트워크 인터페이스, 스위치 같은 물리적 장비
- DB, 웹 서버 프로그램
- etc..
EX) 인간의 심장 = SPoF, 인공 심장 = 이중화
이중화 구성 방법
- 액티브 / 스탠바이 (active - standby)
- 한 시스템은 가동하고, 다른 시스템은 백업 용도로 대기 상태 (스탠바이)
- 한 시스템이 다운되면, 대기 상태 시스템이 활성화 됨 (성능면에서 큰 차이X)
- 액티브 / 액티브 (active - active)
- 두 시스템 모두를 가동 상태
- 한 시스템이 다운되면, 다른 시스템에 순간적으로 로드 급증 가능
이중화의 확장, 다중화
무언가를 여러 개 두는 기술
이중화, 다중화 사례 - 티밍(teaming)과 본딩(bonding)
여러 네트워크 인터페이스(NIC)를 이중화/다중화 하여,
더 뛰어나고 안정적인 성능의 하나의 인터페이스처럼 보이게 하는 기술
티밍: 윈도우, 본딩: 리눅스
고가용성을 요구하는 호스트는 클라이언트보다 일반적으로 서버임
서버를 다중화 했더라도, 무조건적으로 안정적으로 운영된다고 보장할 순 없음
과도한 트래픽은 거의 반드시 서버의 가용성을 저하시킴
∴ 고가용성을 위해서는 이중화, 다중화뿐 아니라 트래픽을 고루 분배해야 함
로드 밸런싱
로드 밸런서 (Load balancer)에 의해 수행
- 전용 네트워크 장비 (L4 스위치, L7 스위치)로 수행
- `L4 스위치`: IP 주소, 포트 번호와 같은 전송 계층까지의 정보를 바탕으로 로드 밸런싱
- `L7 스위치`: URI, HTTP 메시지 일부, 쿠키 등 응용 계층의 정보까지 활용하여 로드 밸런싱
- 로드 밸런싱 소프트웨어를 설치하면 일반 호스트도 로드 밸런서로 사용 가능
- HAProxy, Envoy 등
- Ngnix에도 로드 밸런싱 기능 내포
L4 스위치 (Layer 4 Load Balancer)
전송 계층(TCP/UDP)까지의 정보(IP, 포트)를 기반으로 요청을 분산
세션 레벨의 로드 밸런싱을 수행
❓ 세션 레벨의 로드 밸런싱
TCP/UDP 수준에서 연결(세션) 단위로 분산하는 것
동작 방식
- 클라이언트가 L4 스위치에 접속 (예: TCP 요청)
- L4 스위치는 목적지 (예: 80, 443), 출발지 IP, 프로토콜(TCP/UDP) 등의 정보를 확인
- 로드 밸런싱 알고리즘에 따라 백엔드 서버 선택
- 패킷을 그대로 포워딩하거나 NAT 수행
장점
- 빠름 (패킷 헤더만 확인하므로 오버헤드 少)
- OSI 4계층까지만 보므로 구현 단순
단점
- HTTP 요청에 따른 분기 처리 불가능
- 세션 고정은 IP 기반으로만 가능
❓ 세션 고정은 IP 기반으로만 가능하다
L4 로드밸런서는 HTTP 내용을 볼 수 없음
즉, 세션을 고정하려면 유일하게 식별할 수 있는 건 클라이언트의 IP 주소 뿐
∴ L4 로드 밸런서는 사용자 구분을 'IP 주소'로밖에 못하기 때문에, 다양한 시나리오에서는 정확한 세션 고정 어려움
L7 스위치 (Layer 7 Load Balancer)
응용 계층까지의 정보(URI, 쿠키, 헤더 등)를 기반으로 요청을 분산
콘텐츠 레벨(Content-aware) 로드 밸런싱을 수행
동작 방식
- 클라이언트 요청을 받은 후 HTTP/HTTPS 패킷 분석
- URI, Host 헤더, 쿠키, User-Agent 등의 정보를 기반으로 분기
- `/api` 요청은 A 서버, `/static`은 B서버
- 특정 사용자 쿠키 값에 따라 서버 고정
- 요청에 따라 리다이렉트, 인증, 캐싱 등 고급 처리 가능
장점
- URL, 쿠키 기반 트래픽 분산 가능
- A/B 테스트, 특정 사용자 트래픽 고정 등 유연한 정책 가능
- 보안/캐싱/SSL 종료(termination) 등의 고급 기능 포함 가능
단점
- L4보다 처리량 낮음 (HTTP 메시지 파싱 필요 → CPU 부담 큼)
- 복잡한 설정과 구성 필요
| 항목 | L4 스위치 | L7 스위치 |
| 작동 계층 | OSI 4계층 (TCP/UDP) | OSI 7계층 (HTTP/HTTPS 등) |
| 분산 기준 | IP, 포트, 프로토콜 | URI, 헤더, 쿠키, 메시지 내용 등 |
| 속도 | 빠름 | 상대적으로 느림 (많은 연산 필요) |
| 유연성 | 낮음 (단순 분산) | 높음 (세세한 정책 가능) |
| 사용 예시 | 게임 서버, 단순 웹 서버 | 마이크로서비스, API 게이트웨이 등 |
| 요청 내용 인식 | X | O |
| 요청 단위 분산 | X | O |
로드 밸런서의 위치
일반적으로 이중화/다중화된 서버와 클라이언트 사이에 위치
클라이언트들은 로드밸런서에 요청을 보내고, 로드 밸런서는 해당 요청을 각 서버에 균등하게 분배
그렇다면, 분배 시에 서버의 상태를 확인해야 함.
헬스 체크 (Health Check)
전송 주기와 재전송 횟수 등을 설정한 이후 반복적으로 서버에 요청을 보내는 것
👉 서버에 부하가 되지 않을 만큼 요청 횟수가 적절해야 함
- 서버들의 건강 상태를 주기적으로 모니터링하고 체크
- 주로 로드 밸런서에 의해 이루어짐
- HTTP, ICMP 등 다양한 프로토콜 활용
📌 서버간 하트비트(heartbeat)라는 메시지를 주기적으로 주고 받는 방법도 있음
TCP, HTTP 등 다양한 방법으로 요청을 보내며, 정상적으로 이루어졌다면 정상 서버로 판별
ex) TCP 요청을 보냈는데 3way handshake가 정상적으로 발생하지 않으면 비정상 서버
로드 밸런싱 알고리즘
트래픽이 고르게 분산되도록, 분산 대상을 선택하는 방법
| 알고리즘 | 설명 | 사용 예시 / 특징 |
| Round Robin (라운드 로빈) | 요청을 서버에 순차적으로 분배 | 가장 기본적, 설정 쉬움 |
| Weighted Round Robin | 서버에 가중치 부여하여 분배 | 성능이 다른 서버에 비례 배분 |
| Least Connections (최소 연결) | 현재 연결 수가 가장 적은 서버에 분배 | 상태 기반 로드 밸런싱 |
| IP Hash | 클라이언트 IP 해시값 기준으로 서버 결정 | 세션 유지 필요할 때 사용 |
| Random (무작위) | 서버를 무작위로 선택 | 간단하지만 예측 불가 |
| Least Response Time | 응답 시간이 가장 빠른 서버 선택 | 동적 성능 기반 (Datadog, NGINX Plus 등에서 사용 가능) |
| Consistent Hashing | 특정 키(IP, 세션 등) 기준으로 해시 분배 | 쿠키, 세션 고정, 분산 DB용 |
| L7 (Application Layer) 기반 | URI, Header 등 내용 보고 분기 | API Gateway, NGINX Ingress 등에서 사용 |
어떤 상황에 어떤 알고리즘을 채택해야 하는가?
- 단순 웹 서버: Round Robin 또는 Weighted Round Robin
- 트래픽 쏠림 방지: Least Connections
- 세션 고정 필요: IP Hash 또는 Sticky Session 설정
- 성능 최우선: Least Response Time + 헬스 체크 연동
- 분산 캐시/DB: Consistent Hashing (예: Redis Cluster)
📌 현재는 단일 알고리즘보다, 헬스 체크 + 다중 알고리즘 조합이 일반적.
클라우드 서비스(AWS, GCP 등)에서는 내부적으로 상태 기반 + 라운드로빈을 조합해 사용함
DNS 로드 밸런싱
예시
http://www.example.com → 192.0.2.1, 192.0.2.2, 192.0.2.3
DNS 서버가 `www.example.com` 요청에 대해 여러 개의 IP 주소를 라운드로빈 방식 등으로 순환 응답,
👉 클라이언트가 각기 다른 서버로 접속하도록 유도하는 방법
📌 "접속 전에 IP를 분산하는 간단한 로드 밸런싱 방식"
그러나 세션 유지, 장애 대응, 정밀한 분산에는 부족하며, L4/L7 로드 밸런서와 함께 사용하는 경우 多
동작 방식
- 클라이언트가 도메인 이름으로 접속 (예: www.service.com)
- DNS 서버가 여러 개의 A 레코드(IP 주소)를 반환
- 클라이언트(혹은 OS)는 이 중 하나를 선택해서 접속
장점
- DNS 설정만으로 구현 가능 (비용, 장비 X)
- 전 세계 분산: 지역별 DNS 응답을 다르게 설정할 수 있음
- 클라우드 CDN과 연동: AWS, Route53 등에서 활용
단점
| 단점 | 설명 |
| TTL 캐싱 | DNS 응답은 브라우저/OS/중간 DNS 서버에 캐시됨 → 변경사항이 바로 반영되지 않음 |
| 실시간 상태 감지 불가 | 서버가 죽어도 DNS는 응답할 수 있음 (건강 상태 체크 안됨) |
| 로드 밸런스 정확도 낮음 | 사용자가 어느 서버에 접속할지 DNS 클라이언트가 임의로 결정 |
| 세션 유지 어려움 | 세션 기반 서비스에선 같은 사용자 요청을 같은 서버로 보내기 어려움 |
DNS 설정 예 (BIND, Route 53 등)
www.example.com. IN A 192.0.2.1
www.example.com. IN A 192.0.2.2
www.example.com. IN A 192.0.2.3→ 라운드로빈 응답
- 첫 번째 요청 → 192.0.2.1
- 두 번째 요청 → 192.0.2.2
- ...
| 활용 사례 | 이유 |
| 글로벌 서비스 지역 분산 | DNS 기반 Geo Load Balancing (예: 사용자 위치에 따라 아시아 서버, 유럽 서버 응답) |
| 단순한 웹 서비스 | 정적 콘텐츠 서비스 등에서는 충분 |
| 클라우드 서비스와 연동 | AWS, GCP, Cloudflare 등은 헬스 체크 및 지능형 라우팅도 제공 가능 |
728x90