안녕하세요, 저는 Linode의 솔루션 엔지니어 마이크 (Mike)입니다. 고 가용성에 대해 궁금한 경우 이 게시물이 문제를 해결하는 데 도움이 될 것입니다. 즐거운 시간 보내십시오!
오늘날의 초연결 세계에서 소비자는 언제 어디서나 서비스에 즉시 액세스할 수 있기를 기대합니다. 또한 주의 지속 시간에 대해서도 생각해야 합니다. 소비자가 떠나가기 전에 소비자의 주의를 끄는 데는 약 30초만이 주어진다는 사실을 알고 있습니까? 이러한 이유로 애플리케이션에 고 가용성 (HA)을 구현하는 것이 중요합니다. 이 블로그 게시물에서는 HA를 정의하고 기본 HA 아키텍처에 들어가는 다양한 구성 요소를 설명하며 웹 애플리케이션을 위한 간단한 HA 인프라를 구축하는 방법을 살펴 봅니다.
고 가용성이란 무엇입니까?
먼저 가용성을 정의해 보겠습니다. 컴퓨터 시스템이 정상적인 사용을 위해 액세스할 수 있는 총 시간의 비율입니다. 즉, 가용성은 시스템이 온라인 상태이고 액세스할 수 있는 정도를 나타냅니다. 최적의 가용성이 100%라고 가정할 수도 있겠지만, 이는 불가능합니다.
여기가 바로 고 가용성이 필요한 곳입니다. HA 시스템은 온라인 가용성이 99.9~99.999%인 시스템입니다 (표 1 참조). 이상적인 HA는 99.999% —”five nines”—로 연간 약 5분의 다운 타임을 구성합니다.
숫자별 고가용성
시스템 설계자는 가능한 가장 높은 HA를 달성하려고 합니다. 내결함성을 통해 HA를 늘릴 수 있습니다. 여기에는 시스템 장애 발생 시 지속적인 작동을 가능하게 하는 다양한 시스템 기능 구축이 포함됩니다. 내결함성 기능의 예로는 이중화 및 복제가 있습니다. 이에 대해서는 다음에 설명합니다.
고 가용성은 어떻게 작동합니까?
이상적인 HA 시스템을 구축하는 데 사용할 수 있는 많은 기능이 있습니다. 이러한 구성 요소는 함께 통합되고 지속해서 모니터링되며 신속한 복구가 가능해야 합니다. 여기에는 다음이 포함됩니다:
- 인스턴스 중복,
- 로드 밸런싱,
- 서로 다른 구성 요소에 대한 하드웨어 및 소프트웨어 장애 조치,
- 데이터 복제 및
- 자동화된 확장.
이러한 기능은 아래 다이어그램에 자세히 설명되어 있습니다:
시스템의 가용성을 평가하는 방법
클라우드 인프라의 가용성을 확인하고 싶으십니까? 세 가지 기준을 기반으로 합니다.
- 크기와 범위
- 하드웨어 구성 요소 포함
- 향후 수요를 맞추기 위한 예상 확장
평가 후 인프라 수정을 결정할 수 있습니다. 먼저 각 기준을 개별적으로 수정한 다음 일괄적으로 수정하는 것이 좋습니다. 아키텍처 수정에는 다음과 같은 가상 도구가 포함될 수 있습니다:
- 새로운 보조 서버 및 추가 기능
- HA 지원 소프트웨어 유틸리티
- 보조 하드웨어
부하 분산이 HA에 어떤 영향을 줍니까?
부하 분산은 수신 트래픽을 하나 이상의 서버에 지능적으로 분산합니다. Linode의 NodeBalancer와 같은 이러한 도구는 "설정되고 잊혀지도록" 설계되었습니다. 이를 통해 최종 사용자가 다운 타임을 겪지 않고 백엔드 서버를 원활하게 추가하거나 제거할 수 있습니다.
일반적인 로드 밸런서는 수신 요청에 대한 IP 주소를 모니터링하고 과부하 또는 실패를 스캔합니다. 감지되면 구성된 규칙 (할당 된 IP 장애 조치 포함)을 따라 트래픽을보다 쉽게 사용할 수 있는 노드로 보냅니다. 이렇게 하면 트래픽이 균등하게 분산되고 최종 사용자가 서비스 중단을 겪지 않습니다.
거의 모든 애플리케이션이로드 밸런싱의 이점을 누릴 수 있습니다. 중복성을 달성하는 동시에 사용자를 확장하기 위한 핵심 구성 요소입니다.
페일 오버란 정확히 무엇입니까?
페일 오버는 HA 시스템의 초석입니다. 페일 오버를 사용하면 계획된 또는 우발적 인 다운 타임이 발생하는 경우 작업이 자동으로 보조 또는 세 번째 서버로 다시 라우팅됩니다.
페일 오버는 미러링된 데이터베이스 서버를 클러스터에 추가하거나 트래픽을 가장 사용 가능한 서버로 라우팅하도록 IP 주소를 구성하는 등의 하드웨어 및 소프트웨어 솔루션으로 구성됩니다.
파일 시스템 복제는 어떻게 작동합니까?
HA 클러스터에서 각 서버 (예 : 앱, 데이터베이스, 파일 시스템)는 다른 서버를 미러링하도록 구성되며 저장된 데이터는 아키텍처의 다른 모든 서버간에 자동으로 복제됩니다. 들어오는 요청은 어떤 서버에 있든 상관없이 데이터에 액세스할 수 있습니다. 이는 최종 사용자에게 원활한 경험을 제공합니다.
GlusterFS, LizardFS 및 HDFS와 같은 NFS (Network File System) 소프트웨어는 다양한 서버 유형을 하나의 병렬 네트워크 파일 시스템으로 통합할 수 있습니다. 한 서버에 장애가 발생하면 NFS 소프트웨어는 해당 파일과 데이터가 미러링되고 동기화된 온라인 서버로 요청을 자동으로 다시 라우팅합니다.
데이터베이스는 어떻습니까?
여기서 목표는 동기식 복제를 달성하는 것입니다. 데이터는 한 데이터베이스 서버에서 다른 데이터베이스 서버로 지속적으로 복사됩니다. 그 결과 중단없이 최종 사용자에게 균일한 데이터 배포가 가능합니다. 다음과 같은 소프트웨어 플랫폼을 조합하여이를 달성할 수 있습니다.
Seamless Scaling은 어디에 적합합니까?
시스템이 성장하여 최종 사용자에게 대응하게끔 해야 합니다. 모든 시스템이 다르기 때문에 HA를 유지하면서 시스템을 확장할 수 있는 하나의 단일 플랫폼이 없습니다. 적합한 분산 배포 플랫폼을 선택해야 합니다. 몇 가지 예는 다음과 같습니다:
- SaltStack: 이벤트 기반 클라우드 자동화를 위한 확장 가능하고 유연한 구성 관리 플랫폼
- Chef: Erlang 또는 Ruby로 시스템 구성 레시피를 작성하는 소프트웨어
- Puppet: Unix 계열 및 Microsoft Windows 시스템의 구성을 관리하는 소프트웨어
예를 살펴 보겠습니다.
상황을 파악하는 데 도움이 되도록 HA를 달성하기 위해 취할 수 있는 단계 목록을 작성했습니다. 여기에는 단일로드 밸런서, 3 개의 웹/애플리케이션 서버 및 3 개의 데이터베이스 서버가 있는 시스템 설계가 포함됩니다. 참고: HA 아키텍처 내에서 데이터 쿼럼을 설정하려면 최소 3개의 DB 서버가 필요합니다.
- 클러스터가 조립되면 선택한 NFS를 사용하여 사이트 데이터를 복제하도록 웹/앱 서버를 구성합니다.
- 이렇게 하면 로드 밸런서가 활성화되고 3 개의 웹/앱 노드간에 트래픽이 할당되어 실패한 모든 노드가 자동으로 제거됩니다.
- 다음을 사용하여 MySQL 마스터-마스터 구성 만들기 Percona XtraDB.
- Keepalived에서 관리하는 유동 사설 IP를 장애 조치로 작동하도록 지정합니다.
- 모든 웹/앱 서버를 유동 사설 IP로 지정하여 DB 서버가 다운되는 경우 자동으로 온라인 데이터베이스 노드로 이동합니다.
짜잔! 이는 실패 지점에도 불구하고 서버 액세스를 계속 사용할 수 있기 때문에 최종 사용자의 업무 중단을 최소화합니다.
결론
그래서 HA 시스템을 구축하시겠습니까?
이를 위해서는 신중한 계획이 필요하다는 것을 아는 것이 중요합니다. 먼저, 다운 타임의 실제 비용을 계산해야 합니다. 이는 조직에 따라 다르며 주어진 연도에 허용 가능한 가동 중지 시간을 결정하는 데 중요한 역할을 합니다. 이 정보는 하드웨어 구성, 소프트웨어 도구 및 시스템 유지 관리의 올바른 조합을 결정하는 데 중요합니다.
시스템에 하드웨어 구성 요소를 추가하면 HA가 지연될 수 있습니다. 클러스터에 서버를 연결하면 궁극적으로 실패 위험이 증가하므로 올바르게 수행해야 합니다.
사실입니다. 단순화된 시스템 아키텍처가 더 간단합니다. 그러나 타협할 사항이 없는 것은 아닙니다. 이러한 종류의 시스템은 각각의 모든 패치 또는 OS 업그레이드에 대해 오프라인으로 전환되어야 합니다. 이 산발적인 중단은 시스템의 가용성을 약화합니다. 소프트웨어도 마찬가지입니다. 어리석은 오타 또는 잘못된 설치와 같은 단일 오류는 HA를 손상합니다.
99.999% 이상 온라인 상태를 유지하는 이상적인 HA 시스템은 중복성, 페일 오버 및 모니터링을 통합하는 동시에 하드웨어, 네트워크, 운영 체제, 미들웨어 및 애플리케이션 패치를 조정하고 온라인으로 엔드-사용자 중단없이 실시간으로 업그레이드합니다.
댓글 (7)
What about geographic redundancy? Node balancers no yet supports nodes in other data centers. How I can achieve this?
You’re right, Javier: our NodeBalancers offer redundancy for Linodes within the same data center. For geographic redundancy, we’d recommend using a CDN service, such as Cloudflare, Fastly, Limelight, or similar. You could set this up yourself by using a service such as HAProxy. There’s a great Community Questions post that covers this in further detail: https://www.linode.com/community/questions/17647/can-i-use-nodebalancers-across-data-centers
Otherwise, we’ve added this as a feature request for future NodeBalancer development to our internal tracker. If we make any changes, we’ll be sure to post about them here on our blog.
What about geographic redundancy?
Hi there! I just responded to a similar comment above. In short, we recommend a CDN for geographic redundancy, though you could use HAProxy if you’d like to set this up yourself.
Thanks for writing the awesome article. I really loved the stuff. You see, I have been using Linode server from past 2 years and it’s been working pretty awesome for me. Although, it’s not the conventional hosting server. Instead it’s the managed hosting instance which is being managed by Cloudways.
I hardly remember any downtime. So, am I consistently experiencing the high availability? or Cloudways is playing it’s role.
Thanks for the compliment, Marilu! There are a few things that can cause uptime, such as the dependability of the hosts or the host’s software. In your case, it could be both. In regards to Cloudways’ service, I suggest reaching out to their support as they would be in a better position to answer that question.
Yeah sure! I regularly talk to the Cloudways support team. This time I will ask them the secret behind their service.