[IT인프라] 고가용성 IT 인프라 _ 20241128

1. 인프라 구성도 제작 with Draw.io

** draw.io 란?

- 순서도, 구성도, 흐름도, 다이어그램, 조직도 등을 제적하는데 사용하는 설계 소프트웨어

- 회원가입 없이 무료로 사용가능하며, Google Drive, Github 등 다양한 저장소에 저장하여 사용가능

- 웹으로도 쉽게 접근 가능

- 이외에도 Cloudcraft, Cacoo, MS Visio가 있음.

 

(1) draw.io 사용법

- 제작할 설계도 저장할 위치 선택

- 다른 다이어그램 가져오기

- 여러 형식으로 보내기 (PNG, JPEG, SVF, PDF...)

 

(2) draw.io를 통해 직접 만든 학사행정 웹 서비스 IT 인프라 구성도

 

2. 고가용성 개요

- High Availaility, 높은 가용성

- 가용성이란? 서버와 네트워크 등 서비스가 정상적으로 사용 가능한 정도

- 서비스가 다운(장애)되지 않고 정상적으로 유지된 시간

- 주로 백분율화 하여 표기 (99%, 99.9%, 100% 등)

 

(2) 고가용성 구현을 위한 솔루션

① 이중화

- 시스템의 장애를 대비하는 등 안전성 강화를 위해 같은 시스템을 2개 이상으로 구현하는 구조

- 특정 지점에 문제가 발생하더라도 서비스를 계속 제공할 수 있게 지원

Active 시스템	Standby 시스템
- 시스템에 연결이 되어 정상적인 동작을 하고 있는 시스템	- Active 시스템이 장애가 발생시 Standby 시스템이 Active로 전환

Active-Active 이중화 구성	Active-Standby 이중화 구성
동일한 시스템을 구성하여 시스템 모두를 Active로 유지하는 이중화 구성	Standby 시스템을 대기 상태로 유지 Active 시스템에 장애 발생시 Standby 시스템이 Active 시스템으로 승격

 

② Failover

- Standby 상태였던 시스템이 Active 상태로 전환되는 기능

Hot Standby Failover	Warm Standby Failover	Cold Standby Failover
- 기존 시스템 장애 시 즉각 Standby 시스템 사용 가능 - Active 시스템과 Standby 시스템의 구성이 같은 상태로 유지 - 실시간으로 데이터 동기화	- 기존 시스템 장애 시 Standby 시스템의 추가 설정 이후 사용 - Active 시스템과 Standby 시스템의 구성이 다른 상태로 유지 - 주기적 동기화 - Active 시스템 장애 시 Standby 시스템으로 교체 후 기존 Active 시스템의 구성으로 변경	- Standby 시스템을 정지(유휴)상태로 유지하다가 기존 시스템 장애 시 수동으로 작동하여 사용 - Active 시스템 장애 시 Standby 장비를 On하여 Active로 교체
장점 : 장애 발생시 즉시 전환이 가능하여, 중단 시간이 거의 없음 단점 : 대기 서버가 항상 활성화되어 있어 리소스를 지속적으로 소비함	장점 : 핫보다 리소스 소비가 적고, 몇 분 내 대기 서버가 활성화 단점 : 전환에 시간이 걸릴 수 있고, 핫보다는 복구 시간이 길어짐	장점 : 리소스를 가장 적게 소비하고 단순 구성 가능 단점 : 장애 발생시 서비스 중단, 대기 서버 활성화까지 시간이 많이 소

 

③ 로드밸런서

- 로드밸런싱(부하분산) : 처리해야할 업무, 요청, 트래픽 등을 나누어 처리하도록 분산하는 것

	L4 로드밸런서 (택배기사)	L7 로드밸런서 (우편 담당 직원)
기준	IP와 Port - '주소'만 보고 배달	IP와 Port 외 URL, Payload, Http, Cookie 등 내용 - '내용'을 확인하여 담당 부서에 전달
부하분산방식	1) 라운드 로빈 - 순차적으로 서버에 트래픽을 할당하여 분산 2) 가중치 라운드 로빈 - 가중치를 설정하고 가장 높은 가중치가 설정된 서버부터 트래픽 처리 3) 최소 연결 방식 - 가장 처리를 적게 한 서버에게 우선적으로 할당하여 분산 4) IP 해시 방식 - 클라이언트 IP 주소를 기반으로 동일한 IP 트래픽은 항상 동일한 서버로 연결	1) URL 스위칭 방식 - 특정 하위 URL 들은 특정 서버로 처리하는 방식 2) 컨텍스트 스위칭 방식 - 특정 리소스 요청에 대해 특정 서버를 연결

 

- 활용 기준

사용방식	경우	예시
L4	빠르고 단순한 요청 처리	게임서버, 스트리밍 서비스 LOL, Netflix, Twitch 등
L7	요청 내용을 분석해 적합한 서버로 보내야 하는 경우	전자상거래, 웹사이트, 정적/동적 콘텐츠 분리 Amazon, Coupang, YouTube
L4 + L7	대규모 서비스에서 트래픽을 효율적으로 관리하고, 세밀한 제어도 필요한 경우	글로벌 웹 서비스, 복합 앱 AWS, GCP, Google, KaKao

 

④ 로드밸런서의 기능

- Health Check : 서버들의 장애 여부를 주기적으로 모니터링하고, 정상적으로 동작중인 서버로만 트래픽을 전달

- NAT : 공인 IP 주소와 사설 IP 주소간 변환

- DSR(Direct Server Return) : 로드밸런서를 거치지 않고 서버에서 클라이언트로 트래픽을 전달

 

3. 서버, 네트워크, 스토리지, 보안, 사이트 이중화

(1) 서버 이중화

- 서버를 이중화하여 장애, 재해 시 빠른 서비스 재개를 목표

 

(2) 네트워크 이중화

- 네트워크 장비의 장애 발생시 계속해서 통이 가능하도록 예비 네트워크 장비를 배치하는 것

 

(3) 스토리지 이중화

- 스토리지 장비에 장애 발생시 데이터로의 접근

- 데이터 손실을 최소화 하도록 예비 스토리지 배치

- RAID : Redundant Array of Indepent Disk

  - 여러 개 디시크에 데이터를 나눠서 저장

  - 디스크 I/O 병렬화로 성능 향상

  - 디스크 복제로 인한 안정성 향상

  - RAID (0, 1, 5, 6, 10)

	종류	내용
RAID 0		- Striping  - 최소 2개 이상의 디스크가 필요 - 데이터를 분할하여 저장 - 다수의 디스크를 하나로 묶어 고용량, 고성능 효과 - 하나의 디스크라도 문제가 발생하면 RAID 기능 장애
RAID 1		- Mirroring - 최소 2개 이상의 디스크가 필요 - 데이터를 복제하여 저장 - 디스크에 문제 발생 시, 다른 디스크에서 복제하여 복원 가능 - 안정성은 좋으나 비용이 n배 필요
RAID 5		- 가장 많이 사용되는 RAID 구성 - Block 단위로 Striping 하고, 패리티를 순차적으로 다른 디스크에 저장 - 1개 디스크 장애 시, 복구 가능 (2개 이상 장애 시 복구 불가) - RAID 0 에서 성능과 용량을 조금 줄이고, 안정성을 높인 레벨 - 최소 3개 이상의 디스크 필요
RAID6		- RAID 5에서 성능과 용량을 좀 더 줄이고 안정성을 더 높인 레벨 - 패리티를 2개 저장 - 2개 디스크 장애 시 복구 가능 (3개 디스크 장애 시 복구 불가) - 조금 더 안정성을 높여야 하는 서버 구축 시 사용
RAID 10 (1+0)		- RAID 0의 빠른 속도의 장점을 살리고, RAID 1으로 안전성 보강 - 미러링 -> 스트라이핑 방식 - 최소 4개의 디스크 필요

 

(4) 사이트 이중화

- 2개 이상의 데이터 센터에 동일한 인프라를 구현

 

(5) Disaster Recovery

- 재해복구 : 각종 재해 및 위험요소에 의해 구현되어있는 서비스나 시스템이 중단되었을 때 정상 상태로 복구 시키는 것

- 지진 또는 화재, 기술장애, 사용자의 실수, 악의적인 무단 접근

- DR 중요성 : 비즈니스 연속성, 고객유지, 복구비용 절감

** 복구 목표

① RTO : 복구 시간 목표

- 서비스가 중단된 시점부터 서비스가 복원된 시점에 대한 허용된 최대 시간

 

② RPO : 복구 시점 목표

- 마지막으로 백업한 복구시점부터 서비스가 중단된 시점 사이의 최대 시간

이미지 출처 : Rubrik

 

③ DR 전략 소개

- Backup & Restore 전략 : 백업으로 복구, 간단하지만 시간 소요

- Pilot Light 전략 : 핵심만 항상 준비, 필요 시 확장

- Warm Standby 전략 : 대기 중인 시스템으로 빠른 복구

- Multi-site active 전략 : 여러 장소에 활성화된 시스템으로 빠르고 안정적 복구