무정지를 위한 인프라 구조

 

 

1. 안전성 및 이중화

 

안전성, 고가용성

시스템 서비스가 가능한 한 멈추지 않도록 하는 것을 의미합니다.

 

안전성, 고가용성 목표	실현 수단
고장, 장애에 의한 정지가 발생하지 않을 것 (MTBF)	컴포넌트 이중화
고장, 장애가 발생해도 복구할 수 있을것 (MTTR)
고장, 장애가 발생한 것을 검출할 수 있을 것	컴포넌트 감시
고장, 장애가 발생해도 데이터가 보호될 것	데이터 백업

 

 

이중화

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

이중화는 부하분산, 내부적 생존 감시, 마스터 결정, 페일오버 구조를 갖추고 있습니다.

 

 

 

2. 서버 내 이중화

 

전원, 장치 등의 이중화

이중화 때문에, 랙 뒤쪽의 양 끝에는 전원 탭이 있습니다.

서버 설치 시 이와 같이 설치를 하게 된다면 장애를 예방할 수 있습니다.

 

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

PCI 카드도 이중화가 가능합니다. 이중화로 인해 카드 장애 및 포트 장애에 대응할 수 있습니다.

네트워크 인터페이스 이중화는 하드웨어 또는 OS로 구현합니다.

대표적인 구현 방법 중 하나는 리눅스 OS 본딩입니다.

본딩의 액티브-스탠바이 구성은 '액티브-백업' 이라 하며, 본딩이 이중화된 네트워크 인터페이스를 감시하는 방법은 아래와 같습니다.

 

① MII 감시

현재 주류로 자리잡고 있는 감시 방식 입니다.

링크업이 동작하고 있다면 정상이라 판단합니다.

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

 

② ARP 감시

특정 IP 주소로 ARP 요청을 보내 돌아오는 응답 유무에 따라 정상적인지 확인하는 방법입니다.

 

 

 

3. 저장소 이중화

 

HDD 이중화

최근에는 서버와 저장소 사이를 파이버 채널(FC)로 연결한 SAN(Storage Area Network) 네트워크 구성이 사용된다. SAN에서는 IP대신 WWN(World Wide Name) 주소를 이용해서 데이터를 전송한다.

 

HDD를 서로 연결하는 내부 버스는 최근 SAS 방식을 이용합니다.

HDD 자체 이중화는 RAID를 사용합니다.

RAID는 여러 HDD를 묶어 그룹을 만들고 이를 논리적인 HDD로 인식하는 기술입니다.

 

RAID 장점

 

① 안정성 확보

RAID에서는 HDD에 장애가 발생해도 데이터가 손실되지 않도록 데이터 기록을 이중 화한다 HDD는 움직이는 부분이 많아서 고장이 쉽게 납니다. 따라서 기록 처리를 이중화 한다는 것은 매우 중요한 의미를 가집니다.

 

② 성능 향상 

여러 개의 HDD를 병렬로 동시에 동작시키기 때문에 하나의 HDD를 동작시킬 때보다 I/O 처리 성능이 높아집니다.

 

③ 용량 확장

논리 HDD는 이런 물리적 한계를 넘어서 자유롭게 용량을 결정할 수 있습니다.

 

RAID 구성 패턴

RAID0 : 이중화 없이 HDD에 기록

RAID1 : 일반적으로 OS 디스크 이중화에 사용

RAID1+0 : 복수의 HDD에 병렬로 이중 기록, 안정성과 성능을 균형 있게 구성하며 미러링을 하기 때문에 HDD 전체 용량의 1/2 용량만 사용

RAID5 : 이중화 확보를 위해 패리티 오류 수정 부호 기록, 패리티를 하나의 HDD에 집중시키지 않고 분산하는 것이 특징이며 이중화 부분이 적고 (HDD 수 - 1) / HDD 수만큼의 용량을 사용할 수 있습니다. 그러나 패리티 연산이 이루어지기 때문에 I/O 성능이 RAID1+0에 비해 느립니다.

 

버스 이중화

서버와 저장소 사이에 있는 버스 또한 이중화 대상입니다.

버스 이중화는 장애 시의 버스 교체 시간을 고려해야 합니다. 일반적으로 장애라고 판단하기까지의 HBA 타임 아웃 값은 30초 정도로 설정되어 있는데, 불필요한 버스의 페일오버를 발생시키지 않도록 하기 위함으로, 실제 장애 발생 시에는 페일오버 타임 이웃 시간동안 저장소 I/O가 정지되기 때문에 처리에 영향을 끼치는 경우에는 값 단축을 검토해야 합니다. 이것은 HBA 드라이버의 파라미터로 설정을 변경할 수 있습니다.

 

 

 

4. 웹 서버 이중화

 

웹 서버의 서버 이중화

클라이언트 관점에서는 서버 측이 프로세스로 가동되고 있는지, 스레드로 가동되고 있는지를 의식할 필요는 없습니다.

Apache HTTP Server에서는 어느 쪽이든 미리 여러 개를 가동시켜 두어서 클라이언트 요청에 빠르게 대응할 수 있는 구성을 가지고 있습니다.

프로세스/스레드 중 하나에 장애가 발생해도 다른 프로세스/스레드가 가동되고 있기 때문에 웹 서버의 서비스 전체가 정지되는 일은 없습니다.

 

서버 이중화

DNS를 이용해서 하나의 호스트명에 대해 복수의 IP 주소를 반환하여 웹 서버를 이중화합니다.

 

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

부하분산 장치가 이전에 어느 웹 서버에 요청을 할당했는지를 쿠키에 저장합니다. 해당 쿠키를 읽어서 같은 서버에 요청을 할당합니다.

이를 통해 세션 상태를 저장할 수 있는데, 부하분산 장치는 임시 대응 관리표로 세션 테이블을 만듭니다.

세션 상태 저장을 실현하는 기능을 부하분산 장치에서는 ‘퍼시스턴스(지속성)’ 라고 합니다.

 

 

퍼시스턴스 종류	내용
소스 IP 주소	클라이언트 IP 주소를 기반으로 요청을 할당할 웹 서버를 결정합니다.
쿠키	HTTP 헤더 내에 접속한 웹 서버 정보를 저장합니다.
URL	URL구조 내에 접속한 웹 서버 정보를 저장합니다.

 

 

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

 

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

 

 

 

5. AP 서버 이중화

 

서버 이중화

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

① 웹 서버와 같이 부하분산 장치를 이용하거나, AP 서버가 가진 웹 서버 요청 이중화 기능을 이용해서 AP 서버 요청을 분산시킵니다.

② 서버 내 이중화, 즉 하나의 AP 서버 내에 복수의 AP 서버가 존재하는 형태로, 복수의 JVM이 하나의 AP 서버에서 동작합니다.

 

DB 연결 이중화

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

연결 풀링의 일반적인 설계 방침은 아래와 같습니다.

 

· 최솟값과 최댓값을 동일하게 설정해야 합니다.

연결을 생성하거나 제거할 때 발생하는 오버헤드를 가능한 경감시키기 위해서다.

 

· 방화벽 유무를 확인해 둡니다.

중간에 방화벽이 있다면 오랫동안 사용하지 않은 세션을 자동으로 제거하는 경우가 있기 때문에 방화벽 유무를 확인해 두어야 합니다.

 

 

 

6. DB 서버 이중화

 

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

DB 서버 이중화 방법으로 액티브-스탠바이형의 클러스터 구성이 있습니다. 해당 클러스터 구성은 하드웨어로도 구형이 가능하지만, 일반적으로 소프트웨어를 이용합니다.

클러스터의 노드나 서비스 관계는 마스터-슬레이브 개념을 기반으로 합니다.

서버가 정상 동작하는지 확인하기 위한 구조로 ‘하트비트나 ‘투표 장치’ 같은 기능이 존재합니다.

액티브-스탠바이 구성은 서비스를 병렬로 실행할 수 없고 데이터 일관성을 중시하는 서비스/시스템에 적합합니다.

 

만약 장애가 발생되면?

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

클러스터 소프트웨어는 ‘하트비트’ 를 통해 상호 간의 상태를 확인합니다. 하트비트를 통해 상태를 인식할 수 없게 되면, 페일 오버 실시 여부를 판단할 수 없습니다. 이를 스플릿 브레인이라 합니다.

스플릿 브레인 시, 투표 장치에 대한 투표 결과를 가지고 클러스터 소프트웨어가 살아 남을 노드를 선택합니다. 이는 배타적 제어로 데이터 이중 기록 등의 문제를 방지하기 위함입니다. 투표 장치는 하트비트 기능을 보완합니다.

 

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

쉐어드 에브리씽형

Oracle RAC, IBM DB2 puerScale. 디스크, 데이터를 모든 노드가 공유합니다.

장애가 발생해도 다른 노드로 쉽게 처리를 계속할 수 있습니다.

· 캐시 퓨전(cache fusion): 캐시의 데이터를 네트워크 경유로 받아서 디스크 액세스를 줄이고 데이터 취득을 고속화합니다.

 

쉐어드 낫씽형

Oracle MySQLCluster 등 각 노드별로 디스크를 가지고 잇어서 데이터가 분산됩니다.

노드를 배치하기 쉽습니다.

 

 

 

7. 네트워크 장비 이중화

 

L2 스위치 이중화

L2 스위치 A와 L2 스위치 B를 서로 캐스케이드해서 패킷이 흐르도록 합니다.

최근에는 트렁크 포트를 사용하여 포트를 복수의 VLAN에 소속시켜 사용합니다.

 

L3 스위치 이중화

기본적으로 액티브-스탠바이 구조입니다.

L3 스위치는 스위치 기능과 간이 라우터 기능을 동시에 갖추고 있는 장비입니다.

L3 스위치의 액티브-스탠바이를 실현하는 프로토콜인 Virtual Router Redundancy Protocol(VRRP)가 있습니다.

 

※ VRRP

어느 쪽 장비가 기본(마스터 라우터)인지를 정합니다.

정기적인 하트비트(advertisement)를 보내서 생존 감시를 합니다.

보조(백업 라우터) 장비가 애드버타이즈먼트를 일정 시간 수신하지 못하면 마스터 라우터 역할을 인계합니다.

 

네트워크 토폴로지

L2 스위치와 L2 스위치를 조합하는 구성을 말합니다.

복수의 경로가 존재하는 네트워크 구성을 ‘루프’ 라고 하는데, 이는 안정성 측면에서 좋지 않습니다. 이를 해결하기 위한 수단으로 스패닝 트리 프로토콜(Spanning Tree Protocol, STP)를 사용합니다.

STP를 이용하여 논리적으로 포트를 절단할 수 있습니다. 이를 블로킹 포트라 합니다.

장애 시에는 STP에 의한 재계산이 이루어지며, 논리적으로 절단돼 있는 포트를 개통해서 통신이 가능해집니다.

STP의 단점은 계산에 걸리는 시간인데, 현재는 RSTP(Rapid-STP)가 사용돼서 페일오버 시간은 거의 0에 가깝습니다.

 

 

 

8. 사이트 이중화

 

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

 

 

 

 

웹사이트 이중화

글로벌 서버 부하분산(GSLB)

화재 등 재해에 대한 대책으로 원격지 데이터 센터와 연계하는 기술입니다.

 

DNS가 반환하는 IP 주소를 동적으로 변경합니다.

원격지에 데이터를 전송할 때 중요한 것은 동기/비동기 여부입니다.

 

 

 

9. 감시

 

감시는 시스템 컴포넌트가 정상 동작하는지 확인하는 것입니다.

감시는 대표적으로 아래 같은 것이 있습니다.

· 생존 감시

· 로그(에러) 감시

· 성능 감시

 

생존 감시

ping 명령을 정기적으로 실행해서 서버 이터페이스에 대한 통신을 확인합니다.

 

로그 감시

OS나 미들웨어가 출력하는 로그 파일에는 시스템 유지를 위한 중요 정보가 포함되어 있습니다.

로그 내용을 선별해서 중요한 로그 정보이면 감시 서버에 경고 메시지를 보냅니다.

 

성능 감시

디스크 사용률, 메모리 사용 현황, 디스크 고갈 등의 리소스 상태 파악합니다.

또한 네트워크 액세스 지연, 디스크 액세스 시간 등의 응답 상태 파악합니다.

 

SNMP

네트워크 장비와 서버를 일괄 감시해서 관리할 수 있습니다.

SNMP를 이용해서 감시할 수 있는 내용은 아래와 같습니다.

· 네트워크 장비나 서버 가동 상태

· 서비스 가동 상태

· 시스템 리소스(시스템 성능)

· 네트워크 트래픽

 

콘텐츠 감시

웹 시스템 특유의 감시. 부하분산 장치가 담당합니다.

부하분산 장치에 감시 대상 URL을 등록하고, HTTP의 GET 요청을 해서 정상 여부를 판단합니다.

 

 

 

10. 백업

 

이중화와 다른 점은 데이터를 복제해서 별도 장소에 보관하는 것을 백업이라 합니다.

 

구체적으로는 다음과 같이 복구 지표를 정해서 백업을 설계합니다.

RTO(Recovery Time Objective): 복구 목표 시간

RPO(Recovery Point Objective): 복구 기준 시점

 

시스템에서 백업해야 하는 대상으로 시스템 백업(OS나 미들웨어 등의 백업)과 데이터 백업(데이터베이스나 사용자 파일)이 있습니다.

 

시스템 백업

초기 구축 후, 일괄 처리 적용 시점, 대규모 구성 변경 시점에 실시합니다.

 

취득 방법은 다음과 같은 것들이 있습니다.

· OS 명령(tar, dump 등)

· 백업 소프트웨어

 

백업은 압축 기능이 유효한 처리입니다. 데이터 갱신이 발생하지 않고, 펑상 시에는 사용하지 않는 데이터로 가능한 작은 크기로 저장해 두고 싶은 데이터이기 때문입니다. 압축은 압축 때는 물론 해제 시에도 CPU 사용률이 늘어나고 실행 시간도 길어지는 경향이 있습니다. 하지만 RTO 시간 내에 처리가 끝난다면 꼭 압축을 사용하는 것이 좋습니다.

 

시스템 백업 취득 시의 유의점은 서버의 서비스를 정지할 필요가 있다는 것입니다. 가동 중인 서비스는 백업할 수 없습니다. 미들웨어가 가동 중인 상태에서 백업을 취득하면 임시 파일이나 프로세스 가동 정보도 취득하게 되기에, 복구 시에 정상 가동되지 않는 경우가 있기 때문입니다. 시스템 백업은 안전을 고려해서 계획된 시스템 정지 일정에 맞추어 실시해야 합니다. 

 

데이터 백업

시스템 백업과 달리 매일 변경되는 데이터가 손실되지 않도록 하는 것으로, 취득 빈도가 높습니다.

데이터베이스 백업은 데이터 자체와 데이터 갱신 내역이 기록되어 있는 저널을 모두 취득하도록 하고 있습니다.

데이터는 기본적으로 서비스를 정지할 수 변경이 발생하지 않는 상태에서 취득합니다.