고가용성은 시스템, 애플리케이션, 데이터베이스, 네트워크 등이 지속적으로 운영될 수 있도록 보장하는 것을 말한다. 장애나 오류가 발생해도 서비스가 중단되지 않고 최대한 연속성을 유지하는 시스템을 구축하는 것이 고가용성의 핵심이다. 일반적으로 가용성을 99.9% (3 9s, 99.999% : 5 9s)이상 유지하는 것을 목표로 하며, 이는 1년 중 약 8.77시간 이하의 다운타임을 허용하는 수준이다.

하지만 얻는 것이 있다면 잃는 것도 있는 법. 대체적으로 세상 많은 것이 완벽과 안전을 추구하면 그에 상응하는 비용이 든다(대표적 Trade-off 관계). 이번에 쿠버네티스 클러스터를 구축하며 어디까지 구현할 것인지 고민을 하게 된 순간이 많기에 겸사겸사 포스팅으로 내용을 남긴다.

고가용성 구축 방법

고가용성 시스템을 구축하는 데에는 몇 가지 일반적인 방법이 있다.

중복성 (Redundancy)

서버, 네트워크 장비, 데이터 저장소 등을 다중화하여 하나의 요소에 장애가 발생해도 다른 요소가 대신 처리할 수 있도록 한다.

장애 조치 (Failover)

한 시스템에 장애가 발생하면 자동으로 대체 시스템으로 전환하는 기능이다. 로드밸런서를 통해 다수의 서버로 트래픽을 분산시켜 특정 서버에 장애가 생겨도 트래픽을 다른 서버로 자동으로 전환할 수 있다.

무중단 유지보수 (Rolling Updates)

시스템이 가동 중인 상태에서도 소프트웨어 업데이트, 패치 등을 적용할 수 있게 하여 서비스 중단 없이 유지보수를 가능하게 한다.

데이터 복제 및 백업

중요한 데이터는 여러 곳에 복제하거나 정기적으로 백업하여, 데이터 손실이나 장애에 대비한다. 예를 들어, 데이터베이스는 Master-Slave 구조로 복제(Replication)하거나, 분산 파일 시스템을 사용하여 고가용성을 높일 수 있다.

고려해야 할 요소

고가용성을 추구할 때는 프로젝트의 규모와 필요성을 잘 판단하는 것이 중요하다. 모든 시스템에서 고가용성을 최대로 추구할 필요는 없기 때문이다.

프로젝트의 중요성

• 만약 서비스의 장애로 인한 금전적 손실이나 사용자 이탈이 심각한 경우 고가용성은 매우 중요하다. 예를 들어, 금융 서비스나 대규모 전자상거래 사이트는 몇 분의 다운타임도 큰 손실로 이어질 수 있다. ‘다운 타임으로 발생하는 비용이 고가용성을 추구하는데 드는 비용보다 큰가?’ 를 잘 따져봐야 할 것.
• 반대로 개발 환경이나 내부 시스템에서는 잠깐의 다운타임이 큰 문제가 되지 않기 때문에 고가용성을 위한 추가 비용과 노력을 들일 필요가 없다.

규모에 따른 고려

• 작은 프로젝트나 스타트업 단계에서는 모든 시스템을 고가용성으로 구축하는 것이 오버스펙이 될 수 있다. 초기에는 싱글 서버나 단순한 클라우드 인프라만으로도 충분히 운영 가능하다. 이런 상황에서 고가용성을 과도하게 추구하면 불필요한 비용과 시간이 소모된다.
• 반면 규모가 커지면서 서비스의 트래픽이 증가하거나 사용자가 많아지는 시점에서는 고가용성을 점진적으로 도입하는 것이 바람직하다. 이때 로드밸런서, 이중화된 서버, 분산 스토리지 등의 도입을 고려해야 한다.

내가 구축하려는 시스템은 포트폴리오와 지극히 개인적으로 사용할 웹 서비스이다보니 이 부분에 대한 고민이 많아졌다. 고려 지점을 토대로 추구 정도를 결정하게 됐다.

고가용성 추구 정도

고가용성을 구축할 때는 당연히 추가적인 시간과 비용이 들어간다. 내가 진행하는 프로젝트의 규모에 따라 시간과 비용을 어느정도까지 소모 할 것인지 잘 따져봐야 한다.

복잡한 인프라

• 고가용성을 위해 시스템을 이중화하거나 다중화하면, 인프라 관리가 더 복잡해진다. Failover 설정, 데이터 복제, 네트워크 구성 등 다양한 부분을 신경 써야 하기 때문에, 시스템 운영 비용이 증가한다.
• 특히 다중 노드, 클러스터, 로드밸런서를 관리하려면 전문 지식이 필요하고 인프라 설정의 복잡성이 커진다.

비용 증가

• 고가용성 시스템을 구축하려면 추가적인 하드웨어, 클라우드 리소스, 소프트웨어 라이선스가 필요하다. 예를 들어 여러 대의 서버, 이중화된 네트워크 장비, 스토리지 공간 등을 확보해야 하기 때문에 비용이 크게 증가할 수 있다.
• 클라우드 환경에서는 자동 스케일링, 로드밸런서, 데이터 복제 서비스 등이 추가 비용을 발생시킨다. 규모가 클수록 비용 부담이 커진다.

개발 및 배포 속도 저하

• 고가용성 시스템을 유지하면서 새로운 기능을 개발하고 배포하려면 무중단 배포를 해야 하고, 이를 위해서는 별도의 배포 전략과 테스트 절차가 필요하다. 이는 개발 속도에 영향을 미치고, 배포 주기가 길어질 수 있다.
• 또한 시스템 변경 사항을 테스트하기 위해 고가용성 환경에서 테스트 인프라를 추가적으로 구성해야 할 수도 있다. (결국 또 돈)

결론

개인적으로 고민 됐던 것은 이후 노드를 늘리게 되면 다중 마스터노드 구성을 해야할 것 같은데, 처음부터 구성하고 시작할까? 그렇다면 앞단에 로드밸런서가 필요한데? 로드밸런서를 노드 중 1대에 할당한다면 결국 그 노드가 단일 장애 지점(Single Point of Failure, SPOF)이 아닌가? 나중에 추가하려면 일이 더 피곤해지는데? 클라우드에 로드밸런서를 이용할까? 돈 아까운데? 같은 고민의 연속이었다.
다녔던 회사에선 비용보단 고가용성에 큰 비중을 뒀기 때문에 너무 큰 비용과 시간 손실이 나지 않는다면 고가용성을 추구했으며 이에 대해 논의 할 사람들이 있었지만 지금은 혼자 모든 결정을 하기 때문에 더 답을 내리기 어려운 것 같다.

결국 내가 내린 결론은 고가용성은 시스템의 안정성과 신뢰성을 보장하지만, 모든 프로젝트에 적용할 필요는 없다. 작은 규모의 프로젝트에서는 고가용성을 과도하게 추구하면 시간과 비용적인 손해가 클 수 있으며, 필요 이상으로 복잡해진 인프라를 관리하는 데 어려움이 발생할 수 있다. 따라서 단일 마스터 노드로 구성하고 나중에 생각하는 것으로 결론을 내렸다.

The post 고가용성 (High Availability, HA) appeared first on .