무정지를 위한 인프라 구조
안정성 및 이중화
상용 시스템을 장애로부터 보호하기 위해서 빠트릴 수 없는 구조가 있다. 그것은 바로 안정성과 이중화다
안정성 이란? 안정성, 고가용성이란, 서비스가 가능한 한 멈추지 않도록 하는 것을 의미한다. 이중화, 감시, 백업 세 가지 수단을 구현해서 이를 실현할 수 있다.
목표 실현수단
이중화란?
이중화는 기능을 병렬로 처리하여 하나에 장애가 발생해도 서비스가 지속되게 하는 것이다. (예: 카운터가 여럿인 편의점)
이중화를 구성하기 위해 필요한 구조는 아래와 같다.
부하분산 : 요청을 여러 컴포넌트로 분산하는 기능
내부적 생존 감시 : 컴포넌트들의 생존 여부를 감시하는 기능
페일오버 : 장애 발생 시 예비 컴포넌트로 자동 전환하는 기능
서버 내 이중화
물리적인 장치에 대한 이중화이다.
전원, 장치 등의 이중화
데이터 센터 랙의 전원, 팬 등의 이중화이다 대규모 데이터 센터에서는 각 전원 탭이 별도 분전반이나 UPS 에 접속돼 있어서 전원 장애를 대비하고 있다
참고로, 은행들과 같은 주요 시스템은 데이터 센터 이중화를 구축한다 (재해복구 (Disaster Recovery, DR) 시스템)
네트워크 인터페이스 이중화
PCI 슬롯에 꽃은 카드를 이중화한다 카드 장애 및 포트 장애에 대응할 수 있다
저장소 이중화
HDD 이중화
버스 이중화
서버와 저장소 사이의 버스에 대한 이중화이다 예) Red Hat Enterprise Linux 의 DM-Multipath
웹/AP 서버 이중화
웹 서버의 서버 내 이중화
소프트웨어 관점의 웹 서버 이중화이다. Apache 와 같은 웹서버에서 멀티 프로세스/스레드로 병렬로 처리하며, 시스템 리소스에 맞게 병렬값을 세팅한다
요청이 너무 많아 서버에서 처리를 따라갈 수 없는 경우에는 503 Service Unavailable 에러가 반환되며, 요청이 큐에 쌓이지 않고 바로 에러를 반환한다는 특징이 있다
서버 이중화
서버 단위의 이중화이다 DNS 또는 로드밸랜서를 이용하여 여러 서버로 부하를 분산시킨다
DNS 방식의 경우 서버가 정지된 경우에도 전달되기 때문에 안정성을 중시하는 경우 부적합하다 로드밸런서의 경우 서버에서 장애가 발생하면 감지하여 자동으로 제외 시킨다
DATABASE
DB 연결 이중화
AP 서버에는 DB 서버에 접속 시 사용할 연결들을 생성해 두는 Connection Pooling 기능이 있다 DB 연결을 유지하여 연결/해제 시 걸리는 시간이나 리소스를 아껴 고속으로 처리할 수 있는 장점이 있다
연결이나 세션 설계에 대한 일반적인 개념을 숙지 해야한다
AP 서버의 병렬값과 최소/최대값을 동일하게 설정한다 (연결 오버헤드 경감) 방화벽 유무를 확인한다 (사용하지 않은 세션이 자동으로 제거될 수 있어 정기적으로 폴링하는 등의 대책이 필요)
DB 서버 이중화
서버 이중화(액티브-스탠바이)
DB 이중화의 주류는 액티브-스탠바이형의 클러스터 구성이다 이 구성은 서비스를 병렬로 실행할 수 없고 데이터 일관성을 중시하는 서비스/시스템에 적합하다 (DB, 파일서버, JOB관리 시스템)
서버가 정상 동작하는지 확인하기 위한 구조로 하트비트, 투표 장치 같은 기능이 존재한다
클러스터 소프트웨어에서 등록된 서비스에 이상이 발생하면 서비스를 정지하고 대기하고 있던 스탠바이 측 서비스를 시작해서 서비스를 유지시킨다. 일반적으로 십여 분 정도의 정지 시간으로 서비스를 재개할 수 있다
서버 이중화(액티브-액티브)
DB 서버에 대한 확장 가능한 이중화 아키텍처로 두 가지를 소개한다
Shared Nothing
노드별로 디스크를 가지고 있어서 데이터가 분산되는 방식이다 노드를 추가로 배치하기 쉽다
대량의 데이터를 검색하는 경우는 데이터가 분산돼 있기 때문에 유리하지만, 갱신 시에는 데이터 분산 위치를 검토하기 때문에 느려진다 안정성을 고려할 경우에는 데이터 복제 기능을 이용해야 한다
(커버링 = 다운된 서버의 내용을 이어받아 처리하는 구성)
Shared Everything
디스크, 데이터를 모든 노드가 공유하는 방식이다 (공유 디스크가 필수라 클라우드에서는 사용하기 어렵다) 장애가 발생해도 다른 노드로 쉽게 처리를 계속할 수 있다 모든 노드가 같은 데이터에 액세스할 수 있지만, 배타적 제어나 데이터 경합 때문에 처리 속도가 저하된다
6. 네트워크 장비 이중화
L2 스위치 이중화
L2 스위치를 본딩 등의 기술로 이중화 하고 있다
서버의 두 개의 포트를 서로 다른 스위치에 꽂아서 스위치 장애에 대비한다 L3 스위치 이중화
L3 스위치 이중화는 기본적으로 액티브-스탠바이다
L3 스위치는 게이트웨이로 주로 사용되기 때문에 이중화가 매우 중요하다 (웹 시스템에서 게이트웨이가 다운되면 거의 모든 서비스가 정지됨) 네트워크 토폴로지
네트워크에서 출발지부터 목적지까지의 경로를 복수로 만드는 이중화가 필요하다
단, 경로가 다수 존재하면 안정성 측면에서 좋지 않기 때문에 STP(Spanning Tree Protocol)을 이용하여 해결할 수 있다
STP를 이용하면 논리적으로 포트를 절단(블로킹 포트)할 수 있으며, 장애 시 통신 가능한 경로를 재계산한다
대표적인 네트워크 구성으로 사다리형 패턴이 있다
감시
감시란?
시스템 서비스를 안전하게 지속하기 위해서 감시는 필수적이다
감시에는 생존 감시, 로그(에러) 감시, 성능 감시가 있다
실제로 경고가 발생하면 어떤 식으로 대처해야 하는지 정해야 한다. 행동으로 연결되지 않는다면 의미가 없다
처음에는 많은 항목을 감지하도록 하고, 불필요한 경고를 걸러내서 항목을 줄여 나가는 것이 좋다 생존 감시
ping 명령을 정기적으로 실행해서 서버 인터페이스에 대한 통신을 확인하는 ping 감시가 있다
OS 의 ps 명령을 이용하여 중요한 프로세스 생존을 감시하는 것도 주요하다 로그 감시
OS나 미들웨어가 출력하는 로그 파일에는 시스템 유지를 위한 중요 정보가 포함돼 있다
로그 감시 프로세스는 중요하다고 인지하고 있는 로그 출력문을 미리 저정해 두고 있다가 동일한 로그가 발생하면 감시 서버에게 보고하는 방식이다
대부분의 로그는 [alert], [error], [notice] 등의 로그 레벨 문자열이 붙어있기 때문에 주로 키워드로 등록한다 성능 감시
성능 감시는 디스크 사용률이나 메모리 사용 현황, 디스크 고갈 등의 리소스 상태 파악과 네트워크 액세스 지연, 디스크 액세스 시간 등의 응답 상태를 파악하는 것이다
OS 의 df, vmstat, sar 와 같은 명령으로 정보를 취득해서 상황을 통계적으로 판단하는 등의 방식이 가능하다
단, 시스템 통계를 수집하는 동작은 부하를 높일 수 있으니 감시 동작으로 인한 과부하를 주의해야 한다
감시 대상 감시 내용
CPU CPU 사용률, CPU 대기 행렬
메모리 빈 메모리 양
DISK 남은 용량, 디스크 액세스 시간
네트워크 I/F 인바운드/아웃바운드 대역 사용률, 패킷 손실
HTTP(웹 서버 고유) HTTP 요청의 응답 시간, 초당 HTTP 요청 처리 수, 초당 HTTP 세션 수
JAVA(AP 서버 고유) 메모리 힙(Heap) 크기, 가비지 컬렉션 횟수
DATABASE(DB 서버 고유) 영역의 남은 용량, 캐시 사용률, SQL 응답
콘텐츠 감시
콘텐츠 감시는 웹 화면이 정상적으로 보여지는지 확인하기 위한 웹 시스템 특유의 감시다
일반적으로 콘텐츠 감시는 로드밸런서가 담당한다
로드밸런서에 감시 대상 URL(Health Check URL)을 등록해두면 주기적으로 요청을 해서 정상 응답하지 않으면 장애가 있다고 판단해서 해당 웹 서버에는 요청을 할당하지 않는다
백업
백업이란?
장애 대책을 위해 이중화 등을 도입해서 서비스를 지속하는 것도 중요하지만, 만일의 경우를 대비해서 백업을 만들어 두는 것도 매우 중요하다
이중화와 크게 다른 점은 데이터를 복제해서 별도 장소에 보관한다는 것이다
복구 지표는 시스템의 특징에 따라 정해서 구축해야 한다 (비용 이슈)
RTO(Recovery Time Objective) : 복구 목표 시간 - 복구에 얼마나 걸리나?
RPO(Recovery Point Objective) : 복구 기준 시점- 어느 시점으로 복구하나? 그림 - https://www.evolveip.net/resources-library/rpo-and-rto-what-is-the-difference
시스템 백업
시스템 백업은 OS나 미들웨어 등 일반 서버의 로컬 디스크 영역을 백업하는 것이다
OS나 미들웨어는 설치해서 설정이 끝난 후 많은 변경이 발생하지 않는다. 이 때문에 백업 빈도는 데이터에 비해 적은 편이다
초기 구축 후, 일괄 처리 적용 시, 대규모 구성 변경 시 백업을 실시하며 OS 명령 또는 백업 소프트웨어를 사용한다
가독중인 서비스는 백업할 수 없다. 임시 파일이나 프로세스 가동 정보도 백업에 포함되어 복구시 정상 가동되지 않는 경우가 있기 때문이다
시스템 백업은 안전을 고려해서 계획된 시스템 정지 일정에 맞추어 실시해야 한다 데이터 백업
매일 변경되는 데이터가 손실되지 않도록 하는 백업으로 취득 빈도가 높기 때문에 서비스가 가동 중인 상태라도 백업이 가능한 구조가 필요하다
데이터베이스 시스템은 일치성 보장 기능이 필수라서 데이터 자체와 데이터 갱신 내역이 기록돼 있는 저널(트랜잭션 정보)를 모두 취득하는 방식을 사용한다
데이터베이스가 망가진 경우 일관성 있는 데이터를 복구 후 저널 로그를 바탕으로 다시 트랜잭션을 실행해서 복구한다
Last updated