높은 가용성을 달성하기 위해 답해야 할 두 가지 질문

소비자와 직원이 디지털 경험으로 갑작스럽게 이동함에 따라 운영에 가장 큰 영향을 미치는 요소는 가용성일 것입니다. 확실히, 직원들이 사무실에서 집으로 이동하면서 상당수의 조직이 원격 접근에 어려움을 겪었습니다 . 하지만 일부 근로자만 재택근무를 하게 되었고, 전체 인구가 갑자기 일상생활을 디지털 기기에 의존하게 되었습니다. 

Nokia의 조사 결과를 살펴보세요. Nokia는 "2020년 3월의 업스트림 트래픽(미국 내 일부 네트워크)"에서 "팬데믹 이전 수준보다 업스트림 트래픽이 30% 증가했다"고 보고했습니다. 또는 4월 둘째 주에 거래량이 72% 증가했고(페이지 뷰는 29% 증가) 있다는 데이터를 보세요.  

디지털 경험에 대한 수요가 증가하고 있습니다. 그리고 앱이나 웹사이트가 로드되지 않는 것보다 사용자를 더 짜증나게 하는 일은 거의 없습니다. 솔직히 말해서 앱이나 웹사이트가 로드되지 않는 것보다 운영자 에게 더 짜증나는 일은 거의 없습니다.

높은 가용성을 달성하는 것은 단순히 데이터 경로에 로드 밸런서를 삽입하는 문제가 아닙니다. 이것도 방정식의 일부이긴 하지만, 앱이나 웹사이트를 계속 사용할 수 있도록 하는 데 필요한 단계 중 하나일 뿐입니다.

가장 먼저 해야 할 일은 간단하지 않은 두 가지 질문에 답하는 것입니다.

• 고가용성을 위해 서버 간의 트래픽을 어떻게 분산하시나요?
• 서버 가용성을 적절하게 검증하려면 어느 수준의 상태 검사가 필요합니까?

언뜻 보면 실제보다 간단해 보입니다. 이러한 질문에 대답하려면 앱과 해당 인프라에 대해 많은 것을 알아야 하기 때문입니다.

시작해볼까요?

고가용성을 위해 서버 간의 트래픽을 어떻게 분산하시나요?

이 질문은 실제로 올바른 부하 분산 알고리즘을 사용하는 방법을 파헤치는 것입니다. 알고리즘은 트래픽(요청)을 리소스(서버)에 어떻게 분산시킬지 결정하기 때문입니다. 이에 대한 답변은 여러 가지 요소에 따라 달라지지만 앱 아키텍처와 사용 패턴부터 시작됩니다. 

아시다시피, 기존 앱(모놀리스, 클라이언트-서버, 3계층 웹)의 가용성을 높이려면 완전히 다른 관점에서 사용 패턴을 이해해야 합니다.

이는 하나의 백엔드 "서버"가 모든 비즈니스 로직을 실행하는 역할을 하기 때문입니다. 로그인을 시도하시나요? 제품을 주문하시나요? 카탈로그를 살펴보시나요? 모두 같은 "서버"입니다. 그러면 라운드 로빈 같은 간단한 알고리즘을 사용하여 트래픽을 분산할 수 있다고 생각할 수도 있습니다. 오히려 그렇지요, 친구여. 각 비즈니스 기능에는 서로 다른 컴퓨팅, 메모리, 네트워크 및 데이터 요구 사항이 있습니다. 즉, 각 비즈니스 기능은 "서버"에 다른 부하를 줍니다. 단일 "서버" 인스턴스는 리소스가 많이 필요한 요청을 너무 많이 전달하기만 해도 금방 과부하가 걸릴 수 있습니다.

기존 앱의 가용성을 보장하기 위해 요청 분산을 최적화하는 가장 좋은 방법은 최소 연결 기반 알고리즘을 사용하는 것입니다. 이렇게 하면 현재 열려 있는 연결 수에 따라 "서버" 인스턴스에 부하가 분산됩니다. 이 방법이 효과적인 이유는 리소스가 많이 필요한 요청은 처리하는 데 시간이 더 오래 걸려 연결이 활성 상태로 유지되기 때문입니다. 연결이 적은 "서버"에 요청을 전달함으로써 모든 연결을 사용할 수 있는 가능성이 더 높아집니다.  

최신(마이크로서비스 기반) 앱의 경우 이 질문에 대한 답이 더 쉽습니다. 그 이유는 최신 앱이 이미 개별적으로 확장 가능한 비즈니스 기능으로 분해되어 있기 때문입니다. 동일한 기능에 대한 일부 요청이 다른 요청보다 더 많은 리소스를 소모할 수 있으므로 최소 연결 기반 알고리즘을 사용하는 것이 여전히 좋은 생각입니다. 하지만 최신 앱 아키텍처에서는 트래픽이 자연스럽게 균형을 이루므로 거의 모든 알고리즘을 사용하면 모든 "서버"를 사용 가능한 상태로 유지할 수 있습니다.

가용성에 관해 (적어도 저에게는) 흥미로운 점은 요청을 분산하는 방법을 아는 것이 전투의 절반일 뿐이라는 것입니다. 다른 하나는 안타깝게도 빨간색과 파란색 레이저가 아니라 애플리케이션의 상태에 대한 가시성에 의존합니다.

서버 가용성을 적절하게 검증하려면 어느 수준의 상태 검사가 필요합니까?

여기에 관찰 가능성에 대한 제 논문을 삽입해야 할 곳이지만, 간결함과 여러분의 정신 건강을 위해 다음과 같이 요약하겠습니다. 

"애플리케이션 가용성" 이외의 다른 방법을 사용하여 앱 상태를 확인하는 경우 고가용성이 위험에 처하게 됩니다. 그 이유는 다른 관찰 가능한 측정 항목 중 어느 것도 앱에 대해 아무것도 알려주지 않기 때문입니다. 네트워크와 전송 및 플랫폼 가용성이 필요하지만 앱이 요청을 수신할 준비가 되었는지 확신할 때까지 트래픽을 보내면 문제가 발생합니다.

관찰성의 네 가지 구성요소는 모두 중요합니다. 결국 네트워크 연결이 끊어지면 나머지는 아무 의미가 없습니다. 그러므로 네 가지 측정 항목을 모두 주시하고, 모두 확인해야 합니다. 앱 아키텍처가 무엇인지는 중요하지 않습니다. 모든 앱은 네트워크, 전송, 플랫폼 계층에 따라 달라집니다. 아키텍처가 차이를 만드는 것은 앱 계층입니다. 아키텍처는 앱이 작동하는지 여부를 판단하는 방식을 제한할 수 있기 때문입니다.

개발 중에는 항상 앱의 "상태를 점검"할 수 있는 방법을 물어보세요. API 또는 HTTP 요청을 통해 전담 "상태 점검"이 제공되므로 개발자와 운영자는 앱이 올바르게 작동하는지 쉽게 확인할 수 있습니다. 여기에는 데이터나 파트너 API와 같은 외부 리소스에 대한 연결을 확인하는 기능이 포함될 수 있습니다. 이러한 구성 요소 중 하나라도 실패하면 앱을 사용할 수 없거나 소비자에게 응답하지 않는 것처럼 보일 수 있으므로 모든 필수 구성 요소의 가용성을 확인하는 것이 중요합니다.

고가용성은 생각보다 어렵습니다

마케팅 자료를 보면 고가용성은 서버를 복제하고 그 앞에 로드 밸런서를 넣는 것만큼 간단하다고 생각하는 경우가 많습니다. 하지만 실제로 앱의 고가용성을 보장하려면 심각한 고려 사항, 측정 및 준비가 필요합니다. 인스턴스를 사용 가능하게 하는 것만이 문제가 아닙니다. 모든 종속 앱을 사용 가능하게 하고 어떤 인스턴스에도 과부하가 걸리지 않는 방식으로 요청을 분산하는 것입니다.

앱의 고가용성을 보장하기 위해 투입한 모든 추가 작업의 이점은 긍정적인 고객 경험과 앱이 다운되었다는 밤늦은 긴급 전화가 줄어든다는 것입니다.

_{* 사실 저는 관찰가능성에 관한 논문을 쓴 적이 없습니다. 하지만 내가 그랬다면 여기에 삽입했을 겁니다.}