[펌글] HA(High Availability)란 무엇인가?

서비스 다운타임을 초래하는 요소들
서비스의 연속성을 저해하는 요인은 크게 두 가지로 나눌 수 있다. 계획된 다운타임(Planned Downtime)과 계획되지 않은 다운타임(Unplanned Downtime)이 바로 그것. 
계획된 다운타임에는 △시스템 변경 △신규 시스템 도입 △데이터 백업 △소프트웨어 추가 △애플리케이션 마이그레이션 같은 것들이 있다.
시스템을 운영하는 데 이와 같은 작업은 필수이다. 비록 작업 전에 계획된 다운타임을 공고한다 할지라도 고객들은 서비스를 받지 못하는 불편함을 감수해야만 한다. 
한편 계획되지 않은 다운타임에는 △정전 및 UPS 장애 △하드웨어 장애 △소프트웨어 장애 △네트워크 장애 같은 것들이 있다.
서비스 시스템은 항상 장애가 발생할 수 있는 소지를 갖고 있다.
계획되지 않은 다운타임은 서비스 시스템에 갑자기 발생하는 장애로 인한 것이다. 장애의 종류와 정도에 따라 다운타임 시간은 며칠이 될 수도 있다. 예고 없이 발생하는 장애로 인해 야기된 서비스 다운은 기업이나 조직에게 치명적인 위협을 가할 수도 있다.

서비스 장애 시 발생할 수 있는 일들
요즘 시스템을 이용해 처리되는 많은 업무들은 우리가 매일 이용하는 서비스들이다. 따라서, 서비스 장애 시 우리는 서비스의 중단에서 오는 불편함을 직접 느낄 수밖에 없다. 몇 가지 예를 살펴보자.
백화점에 가서 멋진 겨울 외투를 카드로 구매하려고 하는데, 신용카드 회사의 결제 서버에 장애가 발생한다면 어떻게 될까? 설상가상으로 백화점의 메인 서버에 장애가 발생하면 어떻게 될까? 우리는 물건을 사고 싶어도 살 수 없을 것이다. 
홈쇼핑의 메인 서버에 장애가 발생하면 고객들은 큰 불편을 겪게 될 것이고, 홈쇼핑 업체에서는 엄청난 매출 손실을 보게 될 것이다. 또, 인터넷 상거래 서버가 다운되면 거래를 할 수 없게 된 수많은 회사들이 아우성을 칠 것이다. 자동화가 된 제조 업체에서 공장 제조 라인을 제어하는 서버에 장애가 발생하면, 공장 라인은 멈출 수밖에 없다.
필자는 동사무소에서 증명서를 발급받을 때, 한 시간 이상을 기다린 경험이 있다. 당시 증명서를 발행하는 서버에 문제가 있었기 때문이다. 
물론, 예로 든 이러한 몇 가지 상황들은 극히 일부에 불과하다. 그러나 예고 없는 서비스의 중단은 우리의 일상 생활에 큰 불편을 초래한다는 점은 분명하다. 서비스가 중단됐을 때 우리가 할 수 있는 일이라곤 서비스가 복구되기를 기다리는 일뿐이다.

서비스 다운타임=손실
그림 2에서 보는 바와 같이 서비스의 다운타임은 곧 직접 손실로 이어진다. 서비스의 종류와 중요도에 따라 손실액은 더 증가할 수 있다. 서비스의 다운타임이 너무 오래 지속되면 그 기업은 회생하기 어려울 수도 있다.
피해액을 계산하기조차 어려운 간접 손실은 더 큰 문제다. 다운타임이 늘어날수록 직접 손실뿐만 아니라 추가적인 간접 손실도 늘어나고, 이는 비즈니스에 치명타가 된다. 브랜드 가치, 시장 점유율, 주가, 평판, 고객 만족 등이 추락하며, 고객들은 등을 돌리고 다른 기업을 찾아 떠난다. 한번 신뢰를 잃고 떠나간 고객은 되돌아오지 않는다.
‘소 잃고 외양간 고친다’는 속담이 있다. 서비스가 다운되는 장애를 겪은 후에야 시스템에 대한 투자를 서두르는 기업들이 바로 이에 해당하는 경우일 것이다. 미리 조금만 투자했더라면 훨씬 손실을 줄일 수 있었을 것이다. 서비스 다운 시 발생하는 간접 손실까지 고려하면, 가용성에 대한 투자는 필수라고 할 수 있다. 특히 요즘처럼 경쟁이 치열한 환경에서는, 서비스의 가용성을 높여야만 유사시에도 회사가 살아남을 수 있다는 절박한 인식이 필요하다.

(그림 3) HA 구성과 단일 시스템 비교

HA의 필요성
HA(High Availability)는 고가용성을 의미한다. HA와 클러스터(Cluster)라는 용어는 엄밀히 말하면 다르지만, 고가용성이라는 의미로 혼용해 사용하고 있다. 아마도 몇몇 HA 제품들의 명칭에 클러스터라는 단어가 사용되고 있기 때문일 것이다. 
HA의 목적은 서비스의 다운타임을 최소화함으로써 가용성을 극대화하자는 것이다. 운영 서버에 장애가 발생하더라도, 대기 서버가 즉시 서비스를 대신 처리해 준다면 서비스의 다운타임은 최소화될 수 있다. 운영 서버에 언제 장애가 발생할 지는 아무도 예측할 수 없다. 관리자가 아무도 없는 새벽 시간에 장애가 발생할 수도 있다. HA는 관리자가 없을지라도, 운영 서버의 장애를 모니터링해 대기 서버가 처리할 수 있도록 함으로써 중단 없이 서비스를 제공하는 역할을 한다.
HA는 이와 같이 계획되지 않은 다운타임을 위해 구성하는 것이지만, 더불어 계획된 다운타임에 대해서도 이용할 수 있다. 운영 서버 작업 시, HA를 이용해 대기 서버로 쉽고 빠르게 서비스를 이관할 수 있다. 이렇듯 HA는 서비스 이관의 편리함을 제공한다.
과거에는 HA에 투자하는 것을 과잉 투자라고 생각했다. 그러나 HA는 이제 선택 사항이 아니다. e비즈니스 환경에서 기업이 살아남기 위한 필수 사항이 된 것이다.

가용성의 수준
가용성 100%는 이상적인 수치이다. 아무리 견고한 시스템이라도 장애가 발생할 수 있는 소지가 분명히 있다. 그림 2에 보면 99.99%인 경우, 1년 중 발생하는 다운타임은 총 52분임을 알 수 있다. 
그러나 HA 솔루션에도 많은 진보가 있었다. HA 솔루션의 기술 진보 과정을 살펴보면 다음과 같이 나눌 수 있다.

1세대: 시스템 장애만을 감지하는 수준
시스템의 하드웨어 장애가 발생할 경우에만 장애를 감지해 대기 서버로 서비스를 이관한다. 그러나 애플리케이션의 장애는 감지하지 못하는 단점이 있었으며 99.5% 정도의 가용성을 제공한다.

2세대: 시스템 장애뿐만 아니라 서비스 레벨까지 감지
하드웨어 장애뿐 아니라 애플리케이션의 장애까지 감지해 서비스를 이관한다. 현재 상용 제품들이 대부분 2세대에 속한다. 대표 제품으로는 레가토, 베리타스 클러스터를 들 수 있으며 99.99% 정도의 가용성을 보장한다.

3세대: 커넥션 손실이 없는 차세대 HA
2세대 HA는 운영 서버 장애 시 커넥션 손실이 발생한다. 그리고 대기 서버가 서비스를 시작하면 새로운 커넥션을 형성해야 한다. 차세대 HA는 커넥션 손실이 없는 100% 가용성에 가장 근접한 HA가 될 것이다.

현재 대부분의 HA 제품은 2세대로서, 가용성 수준은 99.99%에 달한다. 2세대 제품에 대해서는 다음 회에서 고가용성의 다양한 구현 방법을 논하면서 설명할 계획이며, 100%를 지향하는 차세대 HA는 마지막 회에서 더욱 자세히 다룰 예정이다.

HA 구현 효과
HA 구현의 가장 큰 효과는 무엇보다 중단 없는 서비스를 가능하게 해준다는 것이다. 이와 더불어 HA는 시스템 관리자들의 부담을 가볍게 해준다. 시스템 관리자들의 어깨를 짓누르고 있는 것은 장애에 대한 부담이다. 장애 발생 시 서비스 중단에 대한 책임을 져야 하고, 시스템을 복구하는 것 또한 관리자들의 몫이다. 
HA를 구현하면 관리자들의 짐이 줄어든다. 장애가 발생하더라도 대기 서버가 즉시 서비스를 수행하게 될 것이며, 본래 운영 서버를 수리할 시간 여유가 생기기 때문이다.

다양한 HA 제품들
현재 상용되고 있는 HA 제품들은 크게 하드웨어 업체에서 제공하는 것과 서드파티 제품으로 구분할 수 있다.
각 하드웨어 업체들은 자체 HA를 가지고 있다. 하드웨어 업체의 HA는 해당 하드웨어와 해당 OS에 종속적이다. 반면에, 서드파티 제품은 하드웨어 업체나 OS 플랫폼에 독립적이며 애플리케이션 레벨에서 동작하기 때문에 제품이 가볍다. 또한 이기종 OS 환경 하에서도 단일 콘솔로 관리할 수 있다는 장점이 있다.

HA가 관리하는 장애 포인트
HA는 어떠한 상황을 장애로 판단하고 대기 서버를 구동해 서비스를 하도록 하는 것일까?
HA가 관리하는 포인트는 크게 세 가지로 나누어 볼 수 있다.
- 하드웨어 장애: 전원 공급, CPU, 메모리, HDD 장애
- 네트워크 장애: 네트워크 카드, LAN 케이블 장애
- 프로세스 장애: DB 및 각종 애플리케이션 장애
HA는 계속해서 상대방 시스템의 상태를 모니터링하고 있다가 이와 같은 장애가 발생할 경우 자동으로 조치하게 된다. 이를 통해 서비스를 지속적으로 제공할 수 있도록 해준다.
HA는 양쪽 서버에 각각 설치하게 된다(그림 7). 
각 시스템을 보면 맨 하단에 OS가 있고, 그 위에 애플리케이션이 있다. HA는 맨 상단에서 시스템과 애플리케이션을 모니터링한다. Heartbeat는 두 서버 간의 HA 통신 라인이다. 서로의 상태를 모니터링하는 중요한 연결 라인이다.
그림 8에 HA 절체(Failover) 원리에 대해 도시했다.
활성(Active)-대기(Standby) 상태의 두 시스템이 있다. 활성 서버에 장애가 발생했을 때, 모든 서비스가 대기 서버에서 구동돼 서비스가 이루어진다. 물론 HA가 활성 서버의 장애를 자동으로 감지해 대기 서버로 넘기는 것이다. 이런 현상을 절체, 페일오버(Failover), 스위치오버(Switchover)라고 말한다.
HA는 첫째, 서비스 IP인 10.10.10.3을 넘겨준다. 클라이언트에서는 10.10.10.3 IP만 찾으므로 대기 시스템으로 연결된다. 
둘째, 스토리지의 파일 시스템인 /data를 마운트한다. 이 안에 모든 데이터가 들어있다.
셋째, DB 및 각종 애플리케이션을 구동한다. 애플리케이션까지 구동돼야만 온전한 서비스를 할 수 있게 된다.

지금까지 HA의 정의와 필요성, 구축 효과 등에 대해 알아보았다. HA의 도입으로 서비스의 가용성을 극대화할 수 있다. 언제 장애가 발생하더라도 HA가 자동으로 대처해 주기 때문에, 기업들은 업무의 지속성을 유지할 수 있으며, 관리자들은 장애에 대한 공포를 덜 수 있게 된다.