[Infra]무중단을 위한 인프라 아키텍처

안정성 및 이중화

안정성

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

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

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

이중화

이중화한 간단히 말하면 하나의 기능을 병렬로 여러 개 나열해서 하나에 장애가 발생해도 다른 것을 이용해서 서비스를 계속할 수 있는 것을 말한다. 하나의 기능이 병렬로 가동되기 때문에 이런 고가용성에 대한 의미뿐만 아니라 확장성이나 부하 분산 같은 성능에 대한 의미도 가진다.
이중화를 할 때는 구체적으로 어떤 구조가 필요할까? 이중화 기능은 반드시 부하분산, 내부적 생존 감시, 마스터 결정, 페일 오버를 갖추고 있다.

이중화에 의한 안정성은 다양한 계층에서 실현할 수 있다.

1. H/W 컴포넌트 계층
   전원이나 네트워크, 하드디스크 이중화다. 신뢰도가 비교적 낮은 부분과 데이터 보호를 목적으로 한다. 일반적인 서버에선 CPU와 메모리를 여러 개 가지고 있지만, 어디까지나 처리 성능을 향상시키는 것이 목적이다. '동일 처리를 병렬로 실행한다', '데이터를 복제한다' 등은 하지 않는다. 즉, 특정 CPU가 실행하고 있던 처리를 해당 CPU가 고장 났다고 다른 CPU로 인계할 수 없다.
2. 시스템 계층
   여러 서버에서 동일한 처리를 실행하는 서버 이중화다. 특정 서버의 처리가 중단돼도 다른 서버에서 처리를 지속해서 사용자에게는 영향을 주지 않는 것이 목적이다. 이 방식은 매우 자주 사용된다.
3. 물리적 위치 계층
   시스템을 서로 다른 위치(데이터 센터나 클라우드)에서 운영하는 이중화다. 데이터 센터의 정전이나 대규모 장애가 발생한 경우에도 시스템을 유지하는 것이 목적이다. 비용이 들지만 중요한 시스템을 위해서 많은 기업들이 채택하고 있는 방식이다. 인프라에서 중요하느 것은 사용자에게 영향을 주지 않는 것이다. 물리적 위치 계층에서 완전히 보호되고 있어서 장애 발생 시에 위치를 빠르게 바꿀 수 있다면, H/W나 시스템 계층의 이중화를 갖출 필요가 없다. 그러나 서로 다른 위치에 있는 시스템을 빠르게 교체하려면 많은 비용이 든다.

비용과 신뢰도는 상호 의존 관계가 있다. CPU 이중화의 수요가 없는 이유다. CPU에 돈을 들이는 것보다 시스템 이중화가 더 싸고 효과적이다. 즉, 감시에 있어 중요한 것은 단일 호스트의 장애 인지보다 시스템 서비스의 장애를 인지하는 것이다.

---

서버 내 이중화

전원, 장치 등의 이중화

일반적인 서버 내부 컴포넌트에서는 전원, 팬 등이 이중화되어있다. 이들 중 하나가 망가져도 서버가 정상 가동하도록 설계되어 있다.
랙 뒤쪽의 양 끝에는 전원 탭이 붙어 있다. 양 끝에 있는 이유는 이중화 때문이다. 각각의 전원 탭에 접속한다. 서버 설치 시에 이와 같이 설치해 두면 장애를 예방할 수 있다. 또한, 대규모 데이터 센터에서는 각 전원 탭이 별도 분전반이나 UPS(정전 시에 이용하는 대규모 충전지)에 접속돼 있어서 전원 장애에 대비하고 있다.
안정성을 고려할 때 중요한 것은 양쪽 전원 탭의 전력 합계를 최대로 사용하는 것이 아니라, 한 쪽 전원 탭 전력만으로 서버가 가동될 수 있도록 소비 전력 합계를 낮추는 것이다. 한쪽 전원이 모두 공급되지 않아도 다른 한쪽의 전원만으로 시스템을 가동할 수 있기 때문이다.

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

PCI 슬롯에 꽂은 카드도 이중화가 가능하다. 네트워크 인터페이스나 파이버 채털 포트에는 이중화 기능이나 이중화를 실현하는 소프트웨어가 있다. 이 기능들을 전체로 카드 이중화 및 포트 이중화를 할 수 있다. 여러 개의 카드에 복수의 포트가 탑재되는 것이다. 이런 구성을 통해 카드 장애 및 포트 장애에 대응할 수 있다.
네트워크 인터페이스가 여러 개 있으면 이중화 소프트웨어나 기능을 이용해서 가용성과 성능을 향상할 수 있다.

---

저장소 이중화

HDD 이중화

저장소 이중화의 주요 대상은 HDD다. HDD는 가동 빈도가 높아서 고장 나기 쉽기 때문이다. 최근에는 잘 사용되지 않지만, 예전에는 서버 저장소를 파이버 채널로 연결하고 SAN(Storage Area Network)이라는 네트워크를 구축하는 방법이 유행했다. 하지만 최근에 접할 수 없는 이유는 높은 비용과 변경에 시간이 걸리기 때문이다.
요즘에는 TCP/IP 프로토콜상에 저장소 네트워크를 구축하는 방식이 늘고 있다. 하지만 TCP/IP 프로토콜상에 SCSI 프로토콜을 이용하는 등, 여러 기술을 조합했기에 사용은 쉽지만 구조가 그만큼 복잡하다. 반면 SAN은 구조가 간단해서 이를 전제로 한 기술이 다시 개발되고 있다.

버스 이중화

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

---

웹 서버 이중화

웹 서버의 서버 내 이중화

클라이언트의 HTTP 프로토콜 요청을 받는 것은 웹 서버에서 동작하고 있는 웹 서버 프로그램이다. 여기서는 대표적인 오픈 소스 웹 서버인 Apache HTTP Server를 예를 들어 설명하겠다. 최근 웹 서버는 스레드가 주류이지만, 아파치는 요청 접수 시 프로세스 또는 스레드를 선택할 수 있다.
클라이언트 관점에서는 서버 측이 프로세스로 가동되는지, 스레드로 가동되는지 의식할 필요는 없다. 아파치에서는 어느 쪽이든 미리 여러 개를 가동시켜 두어서 클라이언트 요청에 빠르게 대응할 수 있는 구성을 가지고 있다. 여러 개를 가동시켜 두면 프로세스/스레드 중 하나에 장애가 발생해도 다른 프로세스/스레드가 가동되고 있기 때문에 웹 서버의 서비스 전체가 정지되는 일은 없다.
일반적으로 상용 시스템은 시스템 리소스에 여유가 있으면 가동 프로세스/데몬 수의 최솟값, 최댓값이 같다. 동일 값으로 하면 프로세스나 스레드의 가동/정지 오버헤드를 줄일 수 있다.

서버 이중화

웹 서버를 이중화하는 방법 중 하나가 DNS를 이용해서 하나의 호스트명에 대해 복수의 IP 주소를 반환하는 것이다. DNS는 질의에 대해 순서대로 IP 주소를 등록해 두는 것으로서 서버 이중화 기법 중 하나다. 이 방법은 매우 간단하게 서버를 이중화할 수 있다는 이점이 있지만, 몇 가지 주의 사항이 있다.
첫 번째는 DNS가 서버 상태를 감시해서 파악하지 않기 때문에 서버가 정지된 경우에도 그 서버의 주소를 반환한다. 이 때문에 가용성을 중시하는 경우에는 부적합하다.
두 번째는 DNS가 세션 상태를 파악하지 않기 때문에 다음 접속 시에 동일 서버에 접속해야 하는 경우에도 부적합하다.

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

이런 제약 사항 때문에 조금 더 고도화한 이중화 방식이 로드밸런서다. 세션 유지를 위한 방법에는 여러 가지가 있지만, 로드밸런서가 이전에 어느 웹 서버에 요청을 할당했는지를 쿠키에 저장하고 있다. 클라이언튼 측에서 쿠키 사용을 허가하면 두 번째 이후 접속부터 HTTP 요청 헤더에 쿠키를 저장해서 접속한다. 로드밸런서는 이 쿠키를 읽어서 같은 서버에 요청을 할당하는 것이다. 이를 통해 세션 상태를 저장할 수 있다. 로드밸런서는 임시 대응 관리표로 세션 테이블이라는 것을 만든다. 클라이언트에 요청을 반환할 때는 이 테이블을 참조한다. 세션 상태 저장을 실현한느 기능을 로드밸런서에서는 Persistence기능이라고 한다.
이런 기술들을 적용하기 전에 각각의 주의사항 및 고려사항을 알아둘 필요가 있다.
출발지 IP 주소를 이용한 퍼시스턴스는 프록시를 경유하면 프록시 서버의 IP 주소가 클라이언트 IP 주소가 돼서 요청이 한쪽으로 몰릴 수 있다. 쿠키를 사용하는 경우는 각 애플리케이션 서버 등이 쿠키를 사용할 때 부하분산 장치가 부여한 쿠키를 덮어쓰기 하지 않는지 확인해야 한다.
URL에 정보를 심는 경우, URL은 사용자가 직접 편집 가능한 정보이기 때문에 부정 접속에 대한 대책을 검토해 두어야 한다. 일반적으로는 해시 함수를 이용해서 변경한 값을 심는다.
또한, 로드밸런서의 첫 접속 시 서버 할당 알고리즘에도 몇 가지 방식이 존재한다.

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

---

애플리케이션 서버 이중화

서버 이중화

애플리케이션 서버 이중화는 두 가지 기능을 이용해서 구현한다.
첫 번째는 웹 서버와 같이 로드밸런서를 이용하거나, 애플리케이션 서버가 가진 웹 서버 요청 이중화 기능을 이용해서 애플리케이션 서버 요청을 분산시키는 것이다.
두 번째 구현 방법은 세션 정보 이중호다. 애플리케이션을 실행하는 애플리케이션 서버에서는 세션 정보 이중화 기능을 갖추고 있다
요청의 분산 및 세션 정보 이중화 기능을 사용해서 애플리케이션 서버를 이중화할 수 있다.

서버 연결 이중화

애플리케이션 서버는 3계층형 시스템의 중간에 위치한다. 애플리케이션 서버에는 DB 서버에 접속 시에 사용할 연결을 사전에 여러 개 생성해 두는 기능이 있다. 이것을 연결 풀링이라고 하며, 웹로직 데이터 소스를 설정해서 이용한다.
원래 데이터 소스는 여러 연결을 만들어서 데이터베이스 처리를 병렬로 실행할 수 있게 하는 구조다. 데이터 소스를 이용하는 장점은 애플리케이션이 DB 서버의 IP나 포트 등을 몰라도 된다는 점이다. 애플리케이션은 데이터 소스명만 알면 된다.

---

DB 서버 이중화

서버 이중화(Active-Stand by)

DB 서버 이중화 방법으로 주류가 되고 있는 액티브-스탠바이형의 클러스터 구성이 있다. 클러스터 구성은 하드웨어로도 구현할 수 있지만, 일반적으로 클러스터 소프트웨어를 이용한다. 클러스터 구성은 오픈 시스템에 있어 빠트릴 수 없는 중요한 요소라고 할 수 있다.
클러스터의 노드나 서비스 관계는 마스터-워커 개념을 기반으로 하고 있다. 서버가 정상 동작하는지 확인하기 위한 구조로 'Heartbeat'나 '투표 장치'같은 기능이 존재한다.

서버 이중화(Active-Active)

DB 서버의 데이터 참조, 갱신 부분은 시스템의 병목 지점이 되기 쉬워서 항상 높은 확장성이 요구된다. 이 때문에 확장 가능한 다양한 기술들이 생겨나고 있다.
DB 서버에 대한 확장 가능한 이중화 아키텍처로 Shared Everything형과 Shared Nothing형이 있다.
대량의 데이터를 검색하는 경우는 데이터가 분산돼 있기 때문에 Shared Nothing형이 유리하다. 작은 트랜잭션이 대량으로 발생하는 경우도 노드 추가를 통해 쉽게 확장할 수 있기 때문에 Shared Nothing형이 유리하다. 하지만 확장 시에는 데이터 재배치를 검토 및 설계해야 하기 때문에 확장성이 쉽지 않다. 또한, 갱신 시에 데이터 분산 위치를 검토하기 때문에 전반적인 갱신 처리가 느려지는 경향이 있다.
Shared Everything형에서는 다른 노드에 있는 메모리 데이터의 일치성을 확인할 필요가 잇기 때문에 노드 수를 늘려도 확장이 쉽지 않다. 또한, 모든 노드가 같은 데이터에 액세스 할 수 있지만, 이 경우 서로 배타적 제어나 데이터 경합을 하기 때문에 처리 속도가 저하된다.
가용성 면에서는 Shared Everything형이 어떤 노드에서건 같은 데이터에 액세스할 수 있기 때문에 유리하지만, Shared Nothing형에서도 데이터 복제 기능을 이용해서 안정성을 고려한 데이터베이스를 사용할 수 있다.
어떤 한쪽이 빠르다고 단정 짓기 어렵다. 시스템 특성에 따라 해당 시스템의 병목 현상이나 장애 시 영향 등을 고려하는 것이 중요하다고 할 수 있다.

---

백업

백업이란?

장애 대책을 생각할 때 이중화 등을 도입해서 서비스를 지속하는 것도 중요하지만, 만일의 경우에 대비해서 백업을 만들어 두는 것도 매우 중요하다. 이중화와 크게 다른 점은 데이터를 복제해서 별도에 보관하는 것이다. 이 때문에 복구를 이용해서 데이터를 원래 장소로 되돌리는 과정이 필요하다. 백업은 데이터를 복제해두기만 하는 것이 백업 취득 빈도나 시점을 고려해서 계획을 세워야 한다. 백업은 RTO와 RPO와 같은 복구 지표를 정해서 설계한다.

1. RTO(Recovery Time Objective): 복구 목표 시간
   복구에 어느 정도 시간이 걸리는가?
2. RPO(Recovery Point Objective): 복구 기준 시점
   어느 시점으로 복구할 것인가?

RTO는 수 시간 내에 복구하지 않으면 업무에 큰 영향을 끼치는 시스템이나, 수 일 동안 업무 대체가 가능해서 천천히 복구해도 되는 것 등 시스템에 따라 백업 요건이 달라진다. 당연히 RTO가 짧을수록 설계 난이도가 높고 백업 시스템 가격도 비싸진다.
RPO는 데이터를 최신 상태로 만들지 않으면 곤란할 것 같지만, 일괄 처리가 주류인 시스템에서는 일괄 처리 실행 직후까지 되돌리면 업무에 문제가 없는 경우도 있다.

위 그림은 RTO와 RPO 관계를 보여주고 있다. 또한, 관련 시스템 전체의 일관성이 확보되는 시간을 미리 설정해 두고 그것을 RPO로 측정하며, 시스템 간 데이터 일관성 확인 시간을 줄일 수 있다.
시스템에서 백업해야 하는 대상은 시스템 백업(OS나 미들웨어 등의 백업)과 데이터 백업(데이터베이스나 사용자 파일)이 있다.

시스템 백업

시스템 백업은 OS나 미들웨어 등 일반 서버의 로컬 디스크 영역을 백업하는 것이다.
OS나 미들웨어는 한번 설치해서 설정이 끝난 후에는 많은 변경이 발생하지 않는다. 이 때문에 백업 빈도는 데이터에 비해 적은 편이다. PC 백업을 생각해 보면 이해하기 쉽다. 작성한 문서나 사진 등은 자주 백업하고 싶지만, OS 자체는 백업을 거의 하지 않을 것이다.
시스템 백업은 초기 구축 후, 일괄 처리 적용 시, 대규모 구성 변경 시와 같은 시점에 실시한다.
취득 방법에는 OS 명령(tar, dump 등)과 백업 소프트웨어와 같은 것이 있다.
백업은 압축 기능이 유효한 처리다. 데이터 갱신이 발생하지 않고, 평상시에는 사용하지 않는 데이터로 가능한 작은 크기로 저장해 두고 싶은 데이터이기 때문이다. 압축은 압축 시는 물론 해제 시에도 CPU 사용률이 늘어나고 실행 시간도 길어지는 경향이 있다. 하지만 RTO 시간 내에 처리가 끝난다면 꼭 압축을 사용하도록 한다.
시스템 백업 취득 시의 유의점은 서버의 서비스를 정지할 필요가 있다는 것이다. 가동 중인 서비스는 백업할 수없다. 미들웨어가 가동 중인 상태에서 백업을 취득하면 임시 파일이나 프로세스 가동 정보도 취득하게 돼서 복구 시에 정상 가동되지 않는 경우가 있기 때문이다. 시스템 백업은 안전을 고려해서 계획된 시스템 정지 일정에 맞추어 실시하도록 한다.

데이터 백업

데이터 백업은 시스템 백업과 달리 매일 변경되는 데이터가 손실되지 않도록 하는 것으로, 취득 빈도가 높다. 이 때문에 정지하기 힘든 시스템은 서비스가 가동 중인 상태라도 백업이 가능한 구조가 필요하다. 그러나 그런 시스템일수록 확실하게 데이터 일관성을 보장해야 하며, 특히 데이터베이스 시스템에 있어서 일관성 보장 기능이 필수다.
이와 같은 이유로 데이터베이스 백업은 데이터 자체와 데이터 갱신 내역이 기록돼 있는 저널을 모두 취득하도록 하고 있다.
데이터는 기본적으로 서비스를 정지한 후 변경이 발생하지 않는 상태에서 취득한다. 일부 데이터베이스에서는 서비스가 가동 주인 경우라도 데이터 백업을 할 수 있다. 저널 로그는 트랜잭션 정보가 기록돼 있으며, 갱신이 발생하지 않는다. 따라서 임의의 시점에 서비스를 중지하지 않고도 백업을 할 수 있다.
데이터베이스가 망가진 경우라면 일관성 있는 데이터와 저널 로그 양쪽을 복원한다. 그리고 일관성이 있는 데이터에 대해 저널 로그를 바탕으로 다시 트랜잭션을 실행해서 복구한다. 또한, 백업되지 않은 저널 로그가 장애 발생 직전까지 존재한다면 최신 데이터로 복구할 수 있다.
백업 취득 방법은 다양하다. 데이터베이스 전용 명령어나 OS 명령을 이용할 수도 있고, 저장소 차분 데이터 블록 복사 기능을 이요하는 경우도 잇다. 차분 데이터 블록 복사는 고속으로 데이터를 복사할 수 있어서 서비스 정지 시간도 매우 짧다. 또한, 데이터 백업도 시스템 백업과 마찬가지로 압축하는 것이 좋다.