무정지를 위한 인프라 구조

그림으로 공부하는 IT 인프라 구조 7장 내용 정리

 

---

 

1. 안정성 및 이중화

---

상용 시스템을 장애로부터 보호하기 위해서 빠트릴 수 없는 구조가 있다. 그것은 바로 안정성과 이중화다.

 

안정성 이란?

안정성, 고가용성이란, 서비스가 가능한 한 멈추지 않도록 하는 것을 의미한다.

이중화, 감시, 백업 세 가지 수단을 구현해서 이를 실현할 수 있다.

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

 

이중화란?

이중화는 기능을 병렬로 처리하여 하나에 장애가 발생해도 서비스가 지속되게 하는 것이다.

(예: 카운터가 여럿인 편의점)

 

이중화를 구성하기 위해 필요한 구조는 아래와 같다.

 

- 부하분산 : 요청을 여러 컴포넌트로 분산하는 기능

- 내부적 생존 감시 : 컴포넌트들의 생존 여부를 감시하는 기능

- 페일오버 : 장애 발생 시 예비 컴포넌트로 자동 전환하는 기능

 

 

2. 서버 내 이중화

---

물리적인 장치에 대한 이중화이다.

 

전원, 장치 등의 이중화

- 데이터 센터 랙의 전원, 팬 등의 이중화이다

- 대규모 데이터 센터에서는 각 전원 탭이 별도 분전반이나 UPS 에 접속돼 있어서 전원 장애를 대비하고 있다

- 참고로, 은행들과 같은 주요 시스템은 데이터 센터 이중화를 구축한다 (재해복구 (Disaster Recovery, DR) 시스템)

 

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

- PCI 슬롯에 꽃은 카드를 이중화한다

- 카드 장애 및 포트 장애에 대응할 수 있다

 

 

3. 저장소 이중화

---

HDD 이중화

- HDD는 가동 빈도가 높아서 고장 나기 쉽기 때문에 주요 이중화 대상이다

- SAN 또는 RAID 구성을 통해 디스크를 이중화한다

- 안정성 확보, 성능 향상, 용량 확장의 장점이 있다

- SAN(Storage Area Network)은 높은 비용과 변경(증설 등)에 시간이 걸리기 때문에 흔히 접하기 어렵다

 

 

버스 이중화

- 서버와 저장소 사이의 버스에 대한 이중화이다

- 예) Red Hat Enterprise Linux 의 DM-Multipath

 

 

4. 웹/AP 서버 이중화

---

웹 서버의 서버 내 이중화

- 소프트웨어 관점의 웹 서버 이중화이다.

- Apache 와 같은 웹서버에서 멀티 프로세스/스레드로 병렬로 처리하며, 시스템 리소스에 맞게 병렬값을 세팅한다

- 요청이 너무 많아 서버에서 처리를 따라갈 수 없는 경우에는 503 Service Unavailable 에러가 반환되며, 요청이 큐에 쌓이지 않고 바로 에러를 반환한다는 특징이 있다

 

서버 이중화

- 서버 단위의 이중화이다

- DNS 또는 로드밸랜서를 이용하여 여러 서버로 부하를 분산시킨다

- DNS 방식의 경우 서버가 정지된 경우에도 전달되기 때문에 안정성을 중시하는 경우 부적합하다

- 로드밸런서의 경우 서버에서 장애가 발생하면 감지하여 자동으로 제외 시킨다

 

DB 연결 이중화

- AP 서버에는 DB 서버에 접속 시 사용할 연결들을 생성해 두는 Connection Pooling 기능이 있다

- DB 연결을 유지하여 연결/해제 시 걸리는 시간이나 리소스를 아껴 고속으로 처리할 수 있는 장점이 있다

- 연결이나 세션 설계에 대한 일반적인 개념을 숙지 해야한다

• AP 서버의 병렬값과 최소/최대값을 동일하게 설정한다 (연결 오버헤드 경감)
• 방화벽 유무를 확인한다 (사용하지 않은 세션이 자동으로 제거될 수 있어 정기적으로 폴링하는 등의 대책이 필요)

 

 

5. DB 서버 이중화

---

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

- DB 이중화의 주류는 액티브-스탠바이형의 클러스터 구성이다

- 이 구성은 서비스를 병렬로 실행할 수 없고 데이터 일관성을 중시하는 서비스/시스템에 적합하다 (DB, 파일서버, JOB관리 시스템)

- 서버가 정상 동작하는지 확인하기 위한 구조로 하트비트, 투표 장치 같은 기능이 존재한다

- 클러스터 소프트웨어에서 등록된 서비스에 이상이 발생하면 서비스를 정지하고 대기하고 있던 스탠바이 측 서비스를 시작해서 서비스를 유지시킨다. 일반적으로 십여 분 정도의 정지 시간으로 서비스를 재개할 수 있다

 

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

DB 서버에 대한 확장 가능한 이중화 아키텍처로 두 가지를 소개한다

그림 - https://prev.github.io/posts

Shared Nothing (샤딩)

• 노드별로 디스크를 가지고 있어서 데이터가 분산되는 방식이다
• 노드를 추가로 배치하기 쉽다
• 대량의 데이터를 검색하는 경우는 데이터가 분산돼 있기 때문에 유리하지만, 갱신 시에는 데이터 분산 위치를 검토하기 때문에 느려진다
• 안정성을 고려할 경우에는 데이터 복제 기능을 이용해야 한다 (커버링 = 다운된 서버의 내용을 이어받아 처리하는 구성)

 

Shared Everything

• 디스크, 데이터를 모든 노드가 공유하는 방식이다 (공유 디스크가 필수라 클라우드에서는 사용하기 어렵다)
• 장애가 발생해도 다른 노드로 쉽게 처리를 계속할 수 있다
• 모든 노드가 같은 데이터에 액세스할 수 있지만, 배타적 제어나 데이터 경합 때문에 처리 속도가 저하된다

 

 

6. 네트워크 장비 이중화

---

L2 스위치 이중화

- L2 스위치를 본딩 등의 기술로 이중화 하고 있다

- 서버의 두 개의 포트를 서로 다른 스위치에 꽂아서 스위치 장애에 대비한다

 

L3 스위치 이중화

- L3 스위치 이중화는 기본적으로 액티브-스탠바이다

- L3 스위치는 게이트웨이로 주로 사용되기 때문에 이중화가 매우 중요하다 (웹 시스템에서 게이트웨이가 다운되면 거의 모든 서비스가 정지됨)

 

네트워크 토폴로지

- 네트워크에서 출발지부터 목적지까지의 경로를 복수로 만드는 이중화가 필요하다

- 단, 경로가 다수 존재하면 안정성 측면에서 좋지 않기 때문에 STP(Spanning Tree Protocol)을 이용하여 해결할 수 있다

- STP를 이용하면 논리적으로 포트를 절단(블로킹 포트)할 수 있으며, 장애 시 통신 가능한 경로를 재계산한다

- 대표적인 네트워크 구성으로 사다리형 패턴이 있다

 

 

7. 감시

---

감시란?

- 시스템 서비스를 안전하게 지속하기 위해서 감시는 필수적이다

- 감시에는 생존 감시, 로그(에러) 감시, 성능 감시가 있다

- 실제로 경고가 발생하면 어떤 식으로 대처해야 하는지 정해야 한다. 행동으로 연결되지 않는다면 의미가 없다

- 처음에는 많은 항목을 감지하도록 하고, 불필요한 경고를 걸러내서 항목을 줄여 나가는 것이 좋다

 

생존 감시

- 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)을 등록해두면 주기적으로 요청을 해서 정상 응답하지 않으면 장애가 있다고 판단해서 해당 웹 서버에는 요청을 할당하지 않는다

 

 

8. 백업

---

백업이란?

- 장애 대책을 위해 이중화 등을 도입해서 서비스를 지속하는 것도 중요하지만, 만일의 경우를 대비해서 백업을 만들어 두는 것도 매우 중요하다

- 이중화와 크게 다른 점은 데이터를 복제해서 별도 장소에 보관한다는 것이다

- 복구 지표는 시스템의 특징에 따라 정해서 구축해야 한다 (비용 이슈)

- RTO(Recovery Time Objective) : 복구 목표 시간 - 복구에 얼마나 걸리나?

- RPO(Recovery Point Objective) : 복구 기준 시점- 어느 시점으로 복구하나?

 

그림 - https://www.evolveip.net/resources-library/rpo-and-rto-what-is-the-difference

 

시스템 백업

- 시스템 백업은 OS나 미들웨어 등 일반 서버의 로컬 디스크 영역을 백업하는 것이다

- OS나 미들웨어는 설치해서 설정이 끝난 후 많은 변경이 발생하지 않는다. 이 때문에 백업 빈도는 데이터에 비해 적은 편이다

- 초기 구축 후, 일괄 처리 적용 시, 대규모 구성 변경 시 백업을 실시하며 OS 명령 또는 백업 소프트웨어를 사용한다

- 가독중인 서비스는 백업할 수 없다. 임시 파일이나 프로세스 가동 정보도 백업에 포함되어 복구시 정상 가동되지 않는 경우가 있기 때문이다

- 시스템 백업은 안전을 고려해서 계획된 시스템 정지 일정에 맞추어 실시해야 한다

 

데이터 백업

- 매일 변경되는 데이터가 손실되지 않도록 하는 백업으로 취득 빈도가 높기 때문에 서비스가 가동 중인 상태라도 백업이 가능한 구조가 필요하다

- 데이터베이스 시스템은 일치성 보장 기능이 필수라서 데이터 자체와 데이터 갱신 내역이 기록돼 있는 저널(트랜잭션 정보)를 모두 취득하는 방식을 사용한다

- 데이터베이스가 망가진 경우 일관성 있는 데이터를 복구 후 저널 로그를 바탕으로 다시 트랜잭션을 실행해서 복구한다