7장 무정지를 위한 인프라 구조

7.1 안정성 및 이중화

7.1.1 안정성이란?

상용 웹 시스템에서는 미들웨어 기능이나 구조로 이중화, 감시, 백업의 세 가지 수단을 구현해서 목표를 실현하고 있다.

7.1.2 이중화란?

하나의 기능을 병렬로 여러 개 나열해서 하나의 장애가 발생해도 다른 것을 이용해서 서비스를 계속할 수 있는 것을 가리킨다.

H/W 컴포넌트 계층 : 일반적인 서버에서는 CPU와 메모리를 여러 개 가지고 있지만, 어디까지나 처리 성능을 향상시키는 것이 목적이다. 즉 특정 CPU가 실행하고 있던 처리를 해당 CPU가 고장 났다고 다른 CPU로 인계할 수 없다.
시스템 계층 : 여러 서버에서 동일한 처리를 실행하는 서버 이중화
물리적 위치 계층 : 시스템을 서로 다른 위치에서 운영하는 이중화다. 비용이 많이든다.

CPU 이중화가 수요가 없는 이유가 CPU에 돈을 들이는 것보다 시스템 이중화가 더 싸고 효과적이기 때문이다.

7.2 서버 내 이중화

7.2.1 전원, 장치 등의 이중화

Rack 뒤쪽 양쪽 끝에는 전원 탭이 붙어 있다. 안정성을 고려할 때 양쪽 전원 탭의 전력 합계를 최대로 사용하는 것이 아니라 한쪽 전원 탭 전력만으로 서버가 가동될 수 있도록 소비 전력 합계를 낮추는 것이다.

7.2.2 네트워크 인터페이스 이중화

PCI 슬롯에 꽂은 카드도 이중화가 가능하다. 여러개의 카드에 복수의 포트가 탑재되는 구성으로 카드 장애 및 포트 장애에 대응할 수 있다.

장애가 발생하면 어떻게 하나?

네트워크 인터페이스 이중화는 일반적으로 액티브-스탠바이 구성이다. 스탠바이 측은 보통 서비스를 제공하지 않고 액티브 측에 어떤 문제가 발생하면 스탠바이 장비로 교체돼서 스탠바이가 액티브로 변경된다. 이렇게 교체하는 것을 Failover라고 한다.

실제 예로 리눅스 OS의 본딩이라는 구조가 있다. 본딩이 이중화된 인터페이스를 감시하는 방식에는 두 가지가 있다. MII 감시(현재 주류)와 ARP 감시다. MII 감시는 링크업이 동작하고 있다면 정상이라고 판단한다. ARP는 특정 IP 주소로 ARP 요청을 보내서 돌아오는 응답 유무에 따라 정상적인지를 확인하는 방법이다.

MII 감시가 선호되는 주된 이유는

불필요한 폴링 패킷이 전송되지 않는다.
폴링 위치로 지정한 IP 주소를 가진 장비에 대해서는 유지관리나 장애를 의식하지 않아도 된다.

하지만 ARP 감시로만 인지할 수 있는 장애도 있다. ARP 감시는 요청을 정기적으로 실행해서 응답이 있으면 정상이라 판단한다. ARP 요청은 MAC 주소를 확인하는 브로드캐스트(동일 네트워크 내의 모든 주소에 패킷을 전송하는 것)다. 단점으로 폴링되는 ARP 요청이 동일 네트워크 내의 브로드캐스트이기 때문에 불필요한 트래픽이 증가한다는 것이다. 따라서 불필요한 트래픽을 고려해서 감시 빈도를 높게 설정하지 않는 것이 중요하다.

ARP 감시에서는 임의의 IP 주소에 대해 ARP 요청을 보낼 수 있고, MII 감시는 인터페이스의 링크 상태를 확인하기 때문에 접속돼 있는 스위치만 감시할 수 있다. 즉 ARP 감시가 더 넓은 범위를 감시한다는 것을 알 수 있다.

7.3 저장소 이중화

7.3.1 HDD 이중화

예전에는 서버 저장소를 FC로 연결하고 SAN이라는 네트워크를 구축하는 방법이 유행했다. 하지만 높은 비용과 변경에 시간이 걸려 잘 사용하지 않았다. 요즘은 TCP/IP 프로토콜 상에 저장소 네트워크를 구축하는 방식이 늘고 있으나 구조가 많이 복잡하다. SAN은 구조가 간단하기 때문에 이를 전제로 한 기술이 다시 개발되고 있다.

저장소 내부 구조와 RAID

HDD 자체 이중화는 RAID로 한다. RAID는 여러 HDD를 묶어서 그룹으로 만들고 이것을 논리적인 HDD로 인식하는 기술이다. 논리적 HDD를 LU라고 한다. 서버가 인식하는 HDD는 LU이다.

RAID의 장점

안정성 확보 : 데이터 기록을 이중화한다.
성능 향상 : 복수의 HDD에 대해 병렬로 I/O처리를 하기 때문에 I/O 처리 성능이 높아진다.
용량 확장

RAID 구성 패턴

RAID5 : 이중화 확보를 위해 패리티라는 오류 수정 부호를 기록한다. 패리티를 하나의 HDD에 집중시키지 않고 분산하는 것이 특징이다.
RAID1 : 일반적으로 OS 디스크 이중화에 사용된다.
RAID10 : RAID0(이중화 없이 HDD에 기록하는 방식) + RAID1(복수의 HDD에 병렬로 이중 기록을 하는 방식)

장애가 발생하면 어떻게 되나?

HDD가 고장나면 RAID 구성에 포함된 데이터는 망가지지 않지만 이중화 구조가 망가진다. 이중화 회복을 위해 핫 스페어라는 디스크를 사용한다. 핫 스페어가 고갈되고 HDD까지 파손된 RAID에서는 데이터 손실이 발생하기 때문에 주의가 필요하다.

7.3.2 버스 이중화

244~245p

7.4 웹 서버 이중화

7.4.1 웹 서버의 서버 내 이중화

대표적인 오픈 소스 웹 서버인 Apache는 요청 접수시 프로세스 또는 스레드를 선택할 수 있다.

7.4.2 서버 이중화

웹 서버를 이중화하는 방법 중 하나가 DNS를 이용해서 하나의 호스트명에 대해 복수의 IP 주소를 반환하는 것이다. 이러한 기법을 DNS 라운드 로빈이라고 한다.

주의사항으로 DNS가 서버 상태를 감시해서 파악하지 않기 때문에 서버가 정지된 경우에도 그 서버의 주소를 반환한다. 또 세션 상태를 파악하지 않기 때문에 다음 접속 시에 동일 서버에 접속해야 하는 경우에도 부적합하다.

부하분산 장치를 이용한 웹 서버 이중화

DNS 라운드 로빈을 고도화한 이중화 방식이 부하분산 장치 로드 밸런서다. 부하분산 장치가 이전에 어느 웹서버에 요청을 할당했는지 쿠키에 저장하고 있어 이 쿠키를 읽어 같은 서버에 요청을 할당한다. 이를 통해 세션 상태를 저장할 수 있다. 세션 상태 저장을 실현하는 기능을 부하분산 장치에서는 Persistence 라고 부른다.

[부하분산 장치의 할당 알고리즘]

알고리즘	내용
라운드로빈	서버에 IP 주소에 순서대로 요청을 할당
최소 연결	현재 활성 세션 수보다 세션 수가 가장 적은 서버의 IP주소에 요청을 할당
응답시간	서버의 CPU 사용률이나 응답시간 등을 고려해서 가장 부하가 적은 서버의 IP 주소에 요청을 할당

장애 발생시

부하분산 장치는 웹 서버의 가동 상태를 감시할 수 있다. 장애를 감지한 경우는 클라이언트 요청을 동적으로 다른 서버에 할당(페일오버)할 수 있다. 정적 콘텐츠의 경우라면 괜찮지만 동적 콘텐츠라면 페일 오버와 세션 정보가 사라지기 때문에 세션 상태가 초기화 된다. 할당 알고리즘 선택시에는 복잡한 알고리즘은 피하자 복잡할수록 데이터가 알고리즘을 통과할 때 높은 부하가 발생한다.

7.5 AP 서버 이중화

7.5.1 서버 이중화

AP 서버 이중화는 두 가지 기능을 이용해서 구현한다.

웹 서버와 같이 부하분산 장치를 이용하거나 AP 서버가 가진 웹 서버 요청 이중화 기능을 이용해서 AP 서버 요청을 분산시키는 것이다.
세션 정보 이중화, 세션 정보란 애플리케이션의 상태를 가리킨다. 애플리케이션 상태를 일시적으로 기억하는 구조라 보면 된다.

장애 발생시 쿠키 정보를 가지고 보조 세션 정보에 접속해 세션이 계속 유지되는 것을 알 수 있다.

7.5.2 DB 연결 이중화

AP 서버에는 DB 서버에 접속 시에 사용할 연결을 사전에 여러 개 생성해 두는 기능이 있다. 이것을 연결 풀링이라고 하며 웹로직의 데이터 소스를 설정해서 이용한다.

원래 데이터 소스는 여러 연결을 만들어서 데이터베이스 처리를 병렬로 실행할 수 있게 하는 구조다. 장점은 애플리케이션이 DB 서버의 IP나 포트 등을 몰라도 된다는 점이다. 애플리케이션은 데이터 소스 명만 알면 된다.

장애 발생시

최솟값과 최대값을 동일하게 설정한다 : 연결을 생성하거나 제거시 발생하는 오버헤드를 가능한 한 경감시키기 위해서다.
방화벽 유무를 확인해 둔다 : 방화벽이 있다면 오랫동안 사용하지 않은 세션을 자동으로 제거하는 경우가 있기 때문에 방화벽 유무를 확인해 두어야 한다.

7.6 DB 서버 이중화

7.6.1 서버 이중화(액티브-스탠바이)

DB 서버 이중화 방법으로는 액티브-스탠바이 클러스터 구성이 있다. 클러스터 구성은 하드웨어로도 구현이 가능하고 일반적으로는 클러스터 소프트웨어를 이용한다.

클러스터 구성은 HA(고가용성) 구성이라고 부르고 클러스터의 노드나 서비스 관계는 마스터-워커 개념을 기반으로 하고 있다. 서버가 정상 동작하는지 확인하기 위한 구조로 하트비트, 투표 장치 같은 기능이 존재한다.

장애 발생시 ? 클러스터 소프트웨어는 등록된 서비스가 정상 동작하고 있는지 정기적으로 확인한다. 이상이 발생하면 서비스를 정지하고 대기하고 있던 스탠바이 측 서비스를 시작해서 서비스를 유지시킨다.

클러스터 소프트웨어를 이용할 때 주의할 점은 클러스터 소프트웨어도 OS에서 실행되는 소프트웨어이기 때문에 오동작할 가능성이 있다는 것이다. 반드시 중요한 데이터는 백업해 두고, 이중 안전 장치가 필요한 경우는 원격 복제 기능 등을 이용하도록 한다.

7.6.2 서버 이중화(액티브-액티브)

DB 서버의 데이터 참조, 갱신 부분은 시스템의 병목 지점이 되기 쉬워서 항상 높은 확장성이 요구된다.

Shared Nothing형은 대량의 데이터를 검색하는 경우 유리하고, 확장이나 갱신의 경우에는 좋지 않다. 가용성 면에서는 Shared Everything형이 어떤 노드에서건 같은 데이터에 액세스할 수 있기 때문에 유리하다. 클라우드상에 구현할 때는 쉐어드 낫씽형이 압도적으로 많다.

캐시 전송

Shared Everything형의 중요 구조인 캐시 전송를 살펴보자 Oracle Real Appilcation Clusters(RAC) 예를 보면 RAC는 캐시의 데이터를 네트워크 경유로 받아서 디스크 액세스를 줄이고 데이터 취득을 고속화하고 있다. 이것을 RAC에서는 캐시 퓨전이라고 부른다. 캐시 퓨전은 디스크 액세스보다 빠르지만 같은 블록이 몇 번이고 네트워크를 통해 교환되는 경우에 응답 속도가 저하된다는 점을 주의해야 한다. 이것을 블록 경합이라고 한다.

Shared Nothing형의 데이터 보호 기능을 보면 데이터 분산 배치로 인해 장애 발생시 데이터 손실 가능서이 있어 이를 방지하기 위한 기능으로 오라클의 MySQL 클러스터가 있다. 데이터 보호는 데이터 노드 간 복제 기능에 의해 구현된다.

7.7 네트워크 장비 이중화

7.7.1 L2 스위치 이중화

서버를 서로 연결하는 장치를 스위치라 한다. L2 스위치 이중화를 살펴보면, 스위치를 크로스 케이블 등으로 연결하면 서로 다른 스위치 간 통신이 가능하다. 이것을 ‘Casecade’라고 한다.

위 그림처럼 트렁크 포트를 사용하면 포트를 복수의 VLAN에 소속시킬 수 있다.

트렁크 포트 이용 시에 필요한 대책 268p

7.7.2 L3 스위치 이중화

L3 스위치 이중화는 기본적으로 액티브-스탠바이다. 웹 시스템에서는 게이트웨이가 다운되면 시스템 서비스가 거의 모두 정지된다. 따라서 L3 스위치 이중화가 매우 중요하다.

7.7.3 네트워크 토폴로지

네트워크에서 중요한 것은 특정 시점에 출발지부터 목적지까지 경로가 하나가 되는 것이다. 경로가 다수 존재하면 안정성 측면에서 좋지 않다. 이것을 해결하기 위한 수단으로 Spanning Tree Protocol (STP)를 이용할 수 있다. STP를 이용하면 논리적으로 포트를 절단할 수 있다. 장애가 밣생하면 STP에 의해 재계산이 이루어지고 논리적으로 절단돼 있는 포트를 개통해서 통신이 가능해진다.

네트워크 구성의 대표적인 패턴

7.8 사이트 이중화

7.8.1 사이트 내 이중화 전체 구성도

7.8.2 사이트 간 이중화

DNS가 반환하는 IP주소를 동적으로 변경하여 사이트 장애에 대비할 수 있다. 원격지에 데이터 전송시 중요한 것은 동기/비동기 여부다. 데이터를 완전히 지키고 싶을 때는 데이터가 원격지에도 기록될 필요가 있기 때문에 동기화 시킨다. 하지만 동기화시 오버헤드가 많이 걸려 응답속도가 느려진다. 비동기는 응답은 좋지만 데이터를 완전히 지킬 수 없다.

7.9 감시

7.9.1 감시란?

감시는 시스템 컴포넌트가 정상 동작하는지 확인하는 기능이다. 감시에서 중요한 것은 어떤 목적으로 감시 기능이 필요한지, 특정 컴포넌트에 감시가 너무 중복돼 있지 않은지 등을 고려하는 것이다.

7.9.2 생존 감시

ping 명령을 정기적으로 실행해서 서버 인터페이스에 대한 통신을 확인하는 감시로 구현이 매우 쉽다. ping 감시는 가능한 모든 장비에 설정할 것을 권장한다.

프로세스 감시는 OS의 ps 명령을 이용해서 확인한다. 실행 중인 프로세스 모두 감시하는 것이 아니라 중요한 것만 추려서 감시하는 것이 좋다.

7.9.3 로그 감시

로그 파일에는 시스템 유지를 위한 중요 정보가 포함돼 있다. 미들웨어 오류나 영역 고갈 등 생존 감시로는 알 수 없는 정보가 로그 파일로 출력된다. 또 장애 원인 분석에도 도움이 된다.

7.9.4 성능 감시

성능 감시는 위 두 감시보다 감시 내용이 복잡하다. 디스크 사용률이나 메모리 사용 현황, 디스크 고갈 등의 리소스 상태 파악과 네트워크 액세스 지연, 디스크 액세스 시간 등의 응답 상태를 파악하는 것이다. df 명령 등의 OS 명령을 정기적으로 실행하거나 vmstat 명령이나 sar 명령 등의 통계 정보를 취득해서 상황을 통계적으로 판단하는 등 다양한 방식이 가능하다.

7.9.5 SNMP

SNMP를 이용해서 감시할 수 있는 주요 내용은 다음과 같다.

네트워크 장비나 서버 가동 상태
서비스 가동 상태
시스템 리소스
네트워크 트래픽

SNMP는 네트워크 장비와 서버를 일괄 감시해서 관리할 수 있는 것이 특징이다.

감시 경로에는 매니저가 정기적으로 질의하는 폴링, 이상 발생시 에이전트가 통지하는 트랩 등 두 가지가 있다. 주요 특징으로는 MIB(관리 정보 기반)이라는 것이 있다. 에이전트는 MIB에 규정된 정보를 수집해서 매니저에게 통지한다. MIB는 데이터베이스 형태와 비슷하다. MIB는 트리 구조로 만들어져 있다.

SNMP는 감시에 특화된 프로토콜이다. 주의점은 SNMP 트랩은 원칙적으로 재전송하지 않으며, 장애로 트랩을 수신하지 못한 경우에는 그 트랩을 잃어버린다. 따라서 모든 통지를 수신해야 한다면 메일을 사용할 수 있다.

7.9.6 콘텐츠 감시

콘텐츠 감시는 부하분산 장치가 담당한다. 감시대상 URL을 등록하고 HTTP의 GET 요청을 해서 정상적으로 응답이 있으면 해당 웹 서버 또는 웹 서버 + AP 서버가 정상 가동되고 있다고 판단한다.

7.10 백업

7.10.1 백업이란?

백업이 이중화와 다른 점은 데이터를 복제해서 별도 장소에 보관한다는 것이다. 그래서 복원, 복구를 이용해 데이터를 원래 장소로 되돌리는 과정이 필요하다.

복구지표

RTO : 복구 목표 시간 - 복구에 어느 정도 시간이 걸리나?
RPO : 복구 기준 시점 - 어느 시점으로 복구할 것인가?

RTO가 짧을수록 설계 난이도가 높고 백업 시스템 가격도 비싸진다.

시스템에서 백업해야하는 대상은 두 가지다 ‘시스템 백업’, ‘데이터 백업’

7.10.2 시스템 백업

시스템 백업은 OS나 미들웨어 등 일반 서버 로컬 디스트 영역을 백업하는 것이다. OS나 미들웨어는 한번 설치해서 설정이 끝난 후에는 많은 변경이 발생하지 않는다. 주로 시스템 백업은 다음과 같은 시점에 실시한다.

초기 구축 후
일괄 처리 적용시
대규모 구성 변경시

시스템 백업 취득시 유의점은 서버의 서비스를 정지할 필요가 있다는 것이다. 가동중인 서비스는 백업할 수 없다.

7.10.3 데이터 백업

시스템 백업과 달리 데이터 백업은 매일 변경되는 데이터가 손실되지 않도록 하는 것으로 취득 빈도가 높다. 따라서 서비스가 가동중인 상태라도 백업이 가능한 구조가 필요하다. 이런 시스템일수록 확실하게 데이터 일치성을 보장해야한다.