무정지를 위한 인프라 구조
7.1 안정성 및 이중화
안정성, 고가용성: 시스템 서비스가 가능한 한 멈추지 않도록 하는 것.
이중화: 하나의 기능을 병렬로 여러 개 나열해서 하나에 장애가 발생해도 다른 것을 이용해서 서비스를 계속 할 수 있는 것을 가리킨다.
7.2 서버 내 이중화
7.2.1 전원, 장치 등의 이중화
7.2.2 네트워크 인터페이스 이중화
PCI 카드 이중화 및 포트 이중화로 카드 장애 및 포트 장애에 대응.
네트워크 인터페이스 이중화는 하드웨어 또는 OS로 구현한다.
리눅스 OS의 본딩(bonding) 구조. 본딩의 액티브-스탠바이 구성은 ‘액티브-백업’이라고 한다.
본딩이 이중화된 네트워크 인터페이스를 감시하는 방법에는 두 가지가 있다.
- MII 감시(Media Independent Interface, 대부분 선호)
- ARP 감시
7.3 저장소 이중화
7.3.1 HDD 이중화
컨트롤러에는 CPU나 캐시가 있어서 HDD I/O 제어를 한다.
최근에는 서버와 저장소 사이를 파이버 채널(FC)로 연결한 SAN(Storage Area Network) 네트워크 구성이 사용된다.
SAN에서는 IP대신 WWN(World Wide Name) 주소를 이용해서 데이터를 전송한다.
HDD를 서로 연결하는 내부 버스는 최근 SAS(Serial Attached SCSI) 방식을 사용한다.
HDD 자체 이중화는 RAID를 사용한다.
- RAID의 장점
-
- 안정성 확보
- 성능 향상
- 용량 확장
- RAID 구성 패턴
- RAID0
- 이중화 없이 HDD에 기록
- RAID1
- 일반적으로 OS 디스크 이중화에 사용.
- RAID1+0
- 복수의 HDD에 병렬로 이중 기록. 안정성과 성능을 균형 있게 구성.
- 그러나 미러링을 하기 때문에 HDD 전체 용량의 1/2 용량밖에 사용할 수 없다.
- RAID5
- 이중화 확보를 위해 패리티 오류 수정 부호 기록.
- 패리티를 하나의 HDD에 집중시키지 않고 분산하는 것이 특징.
- 이중화 부분이 적고 (HDD 수 – 1) / HDD 수만큼의 용량을 사용할 수 있다.
- 그러나 패리티 연산이 이루어지기 때문에 I/O 성능이 RAID1+0에 비해 느리다.
- RAID0
7.4 웹 서버 이중화
7.4.1 웹 서버의 서버 이중화(소프트웨어 관점)
클라이언트 관점에서는 서버 측이 프로세스로 가동되고 있는지, 스레드로 가동되고 있는지를 의식할 필요는 없다.
아파치(Apache HTTP Server)에서는 어느 쪽이든 미리 여러 개를 가동시켜 두어서 클라이언트 요청에 빠르게 대응할 수 있는 구성을 가지고 있다.
프로세스/스레드 중 하나에 장애가 발생해도 다른 프로세스/스레드가 가동되고 있기 때문에 웹 서버의 서비스 전체가 정지되는 일은 없다.
7.4.2 서버 이중화(웹 서버 자체)
DNS를 이용해서 하나의 호스트명에 대해 복수의 IP 주소를 반환(DNS round robin).
부하분산 장치를 이용한 웹 서버 이중화.
- 부하분산 장치가 이전에 어느 웹 서버에 요청을 할당했는지를 쿠키에 저장한다. 이 쿠키를 읽어서 같은 서버에 요청을 할당한다.
- 이를 통해 세션 상태를 저장할 수 있는데, 부하분산 장치는 임시 대응 관리표로 세션 테이블을 만든다.
- 세션 상태 저장을 실현하는 기능을 부하분산 장치에서는 ‘퍼시스턴스(persistence, 지속성)’이라고 한다.
- 소스 IP 주소: 클라이언트 IP 주소를 기반으로 요청을 할당할 웹 서버를 결정.
- 쿠키: HTTP 헤더 내에 접속한 웹 서버 정보를 저장.
- URL: URL구조 내에 접속한 웹 서버 정보를 저장.
- 부하분산 장치의 할당 알고리즘
- 라운드 로빈(round robin): 서버의 IP 주소에 순서대로 요청을 할당.
- 최소 연결(least connection): 현재 활성 세션 수보다 세션 수가 가장 적은 서버의 IP 주소에 요청을 할당.
- 응답 시간(response time): 서버의 CPU 사용률이나 응답 시간 등을 고려해서 가장 부하가 적은 서버의 IP 주소에 요청을 할당.
7.5 AP 서버 이중화
7.5.1 서버 이중화
웹 서버와 같이 부하분산 장치를 이용하거나, AP 서버가 가진 웹 서버 요청 이중화 기능을 이용해서 AP 서버 요청을 분산.
서버 내 이중화, 즉 하나의 AP 서버 내에 복수의 AP 서버가 존재하는 형태로, 복수의 JVM이 하나의 AP 서버에서 동작한다.
7.5.2 DB 연결 이중화
AP 서버가 DB 서버에 접속하는 경우의 이중화.
AP 서버에는 DB 서버에 접속 시에 사용할 연결(connection)을 사전에 여러 개 생성해 둔다. (연결 풀링, connection pooling).
7.6 DB 서버 이중화
7.6.1 서버 이중화(액티브-스탠바이)
액티브-스탠바이형의 클러스터(cluster) 구성(HA 구성). 일반적으로 클러스터 소프트웨어로 구현한다.
클러스터의 노드나 서비스 관계는 마스터-슬레이브 개념을 기반으로 한다.
서버가 정상 동작하는지 확인하기 위한 구조로 ‘하트비트(heartbeat)’나 ‘투표 장치(voting)’ 같은 기능이 존재한다.
액티브-스탠바이 구성은 서비스를 병렬로 실행할 수 없고 데이터 일관성을 중시하는 서비스/시스템에 적합하다.
장애 발생시
- 클러스터 소프트웨어는 등록된 서비스가 정상 동작하고 있는지 정기적으로 확인한다.
이상이 발생하면 서비스를 정지하고 대기하고 있던 스탠바이 측 서비스를 시작해서 서비스를 유지시킨다(페일오버). - 클러스터 소프트웨어는 ‘하트비트’를 통해 상호 간의 상태를 확인한다.
하트비트를 통해 상태를 인식할 수 없게 되면, 페일 오버 실시 여부를 판단할 수 없다. (스플릿 브레인, split-brain). - 스플릿 브레인 시, 투표 장치에 대한 투표 결과를 가지고 클러스터 소프트웨어가 살아 남을 노드를 선택한다.
- (배타적 제어로 데이터 이중 기록 등의 문제 방지)
- 투표 장치는 하트비트 기능을 보완한다.
7.6.2 서버 이중화(액티브-액티브)
- 쉐어드 에브리씽형(shared everything)
- Oracle RAC, IBM DB2 puerScale.
- 디스크, 데이터를 모든 노드가 공유한다.
- 장애가 발생해도 다른 노드로 쉽게 처리를 계속할 수 있다.
- 캐시 퓨전(cache fusion): 캐시의 데이터를 네트워크 경유로 받아서 디스크 액세스를 줄이고 데이터 취득을 고속화한다.
- 쉐어드 낫씽형(shared nothing)
- Oracle MySQLCluster 등
- 각 노드별로 디스크를 가지고 잇어서 데이터가 분산된다
- 노드를 배치하기 쉽다.
7.7 네트워크 장비 이중화
7.7.1 L2 스위치 이중화
L2 스위치 A와 L2 스위치 B를 서로 캐스케이드(cascade)해서 패킷이 흐르도록 한다.
최근에는 트렁크 포트를 사용하여 포트를 복수의 VLAN에 소속시켜 사용한다.
7.7.2 L3 스위치 이중화
기본적으로 액티브-스탠바이.
L3 스위치는 스위치 기능과 간이 라우터 기능을 동시에 갖추고 있는 장비이다.
L3 스위치의 액티브-스탠바이를 실현하는 프로토콜인 Virtual Router Redundancy Protocol(VRRP)가 있다.
VRRP
- 어느 쪽 장비가 기본(마스터 라우터)인지를 정한다.
- 정기적인 하트비트(advertisement)를 보내서 생존 감시를 한다.
- 보조(백업 라우터) 장비가 애드버타이즈먼트를 일정 시간 수신하지 못하면 마스터 라우터 역할을 인계한다.
7.7.3 네트워크 토폴로지
L2 스위치와 L2 스위치를 조합하는 구성을 말한다.
복수의 경로가 존재하는 네트워크 구성을 ‘루프(loop)’라고 하는데, 이는 안정성 측면에서 좋지 않다.
이를 해결하기 위한 수단으로 스패닝 트리 프로토콜(Spanning Tree Protocol, STP)를 사용한다.
STP를 이용하여 논리적으로 포트를 절단(블로킹 포트)할 수 있다.
장애 시에는 STP에 의한 재계산이 이루어지며, 논리적으로 절단돼 있는 포트를 개통해서 통신이 가능해진다.
STP의 단점은 계산에 걸리는 시간인데, 현재는 RSTP(Rapid-STP)가 사용돼서 페일오버 시간은 거의 제로에 가깝다.
7.8 사이트 이중화
7.8.2 웹사이트 이중화
글로벌 서버 부하분산(GSLB)
- 화재 등 재해에 대한 대책으로 원격지 데이터 센터와 연계하는 기술.
- DNS가 반환하는 IP 주소를 동적으로 변경한다.
- 원격지에 데이터를 전송할 때 중요한 것은 동기/비동기 여부다.
7.9 감시
7.9.1 감시란?
시스템 컴포넌트가 정상 동작하는지 확인하는 것.
- 생존 감시
- 로그(에러) 감시
- 성능 감시
7.9.2 생존 감시
예) ping 명령을 정기적으로 실행해서 서버 인터페이스에 대한 통신을 확인.
7.9.3 로그 감시
OS나 미들웨어가 출력하는 로그 파일에는 시스템 유지를 위한 중요 정보가 포함돼 있다.
로그 내용을 선별해서 중요한 로그 정보이면 감시 서버에 경고 메시지를 보낸다.
7.9.4 성능 감시
디스크 사용률, 메모리 사용 현황, 디스크 고갈 등의 리소스 상태 파악
네트워크 액세스 지연, 디스크 액세스 시간 등의 응답 상태 파악.
7.9.5 SNMP
SNMP는 네트워크 장비와 서버를 일괄 감시해서 관리할 수 있다.
- 네트워크 장비나 서버 가동 상태
- 서비스 가동 상태
- 시스템 리소스(시스템 성능)
- 네트워크 트래픽
7.9.6 콘텐츠 감시
웹 시스템 특유의 감시. 부하분산 장치가 담당한다.
부하분산 장치에 감시 대상 URL을 등록하고, HTTP의 GET 요청을 해서 정상 여부를 판단한다.
7.10 백업
7.10.1 백업이란?
이중화와 다른 점은 데이터를 복제해서 별도 장소에 보관한다는 점이다.
복구 지표를 정해서 백업을 설계한다.
- RTO(Recovery Time Objective): 복구 목표 시간
- RPO(Recovery Point Objective): 복구 기준 시점
시스템에서 백업해야 하는 대상.
- 시스템 백업(OS나 미들웨어 등의 백업)
- 데이터 백업(데이터베이스나 사용자 파일)
7.10.2 시스템 백업
다음과 같은 시점에 실시.
- 초기 구축 후
- 일괄 처리 적용 시
- 대규모 구성 변경 시
취득 방법
- OS 명령(tar, dump 등)
- 백업 소프트웨어
7.10.3 데이터 백업
시스템 백업과 달리 매일 변경되는 데이터가 손실되지 않도록 하는 것으로, 취득 빈도가 높다.
데이터베이스 백업은 데이터 자체와 데이터 갱신 내역이 기록돼 있는 저널(journal)을 모두 취득하도록 하고 있다.