다음을 통해 공유

실패를 견딜 수 있도록 디자인(Azure를 사용하여 Real-World Cloud Apps 빌드)

  • 아티클

작성자 : Rick Anderson, Tom Dykstra

수정 프로젝트 다운로드 또는 전자책 다운로드

Azure 전자책 을 사용하여 Real World Cloud Apps 빌드 는 Scott Guthrie가 개발한 프레젠테이션을 기반으로 합니다. 클라우드용 웹앱을 성공적으로 개발하는 데 도움이 될 수 있는 13개의 패턴과 사례를 설명합니다. 전자책에 대한 자세한 내용은 첫 번째 챕터를 참조하세요.

모든 유형의 애플리케이션을 빌드할 때 고려해야 할 사항 중 하나이지만, 특히 많은 사람들이 사용하는 클라우드에서 실행되는 애플리케이션은 오류를 정상적으로 처리하고 가능한 한 많은 가치를 계속 제공할 수 있도록 앱을 디자인하는 방법입니다. 충분한 시간이 주어지면 모든 환경이나 소프트웨어 시스템에서 문제가 발생할 수 있습니다. 앱이 이러한 상황을 처리하는 방법은 고객이 얼마나 화가 났는지, 그리고 문제를 분석하고 해결하는 데 얼마나 많은 시간을 소비해야 하는지를 결정합니다.

오류 유형

다르게 처리하려는 두 가지 기본 오류 범주가 있습니다.

  • 일시적인 네트워크 연결 문제와 같은 일시적인 자가 복구 오류입니다.
  • 개입이 필요한 지속적인 실패.

일시적인 오류의 경우 재시도 정책을 구현하여 앱이 빠르고 자동으로 복구되는 대부분의 시간을 보장할 수 있습니다. 고객은 응답 시간이 약간 더 길어질 수 있지만, 그렇지 않으면 영향을 받지 않습니다. 일시적인 오류 처리 챕터에서 이러한 오류를 처리하는 몇 가지 방법을 보여 드리겠습니다.

지속적인 오류의 경우 문제가 발생할 때 즉시 알리고 근본 원인 분석을 용이하게 하는 모니터링 및 로깅 기능을 구현할 수 있습니다. 모니터링 및 원격 분석 챕터에서 이러한 종류의 오류를 파악하는 데 도움이 되는 몇 가지 방법을 살펴보겠습니다.

오류 scope

또한 단일 머신이 영향을 받는지, SQL Database 또는 Storage와 같은 전체 서비스 또는 전체 지역인지와 같은 오류 scope 고려해야 합니다.

오류 scope

컴퓨터 오류

Azure에서 실패한 서버는 자동으로 새 서버로 대체되고 잘 설계된 클라우드 앱은 이러한 종류의 오류에서 자동으로 신속하게 복구됩니다. 앞서 상태 비저장 웹 계층의 확장성 이점과 실패한 서버에서의 복구 용이성은 상태 비저장의 또 다른 이점이라고 강조했습니다. 복구 용이성도 SQL Database 및 Azure App Service Web Apps 같은 PaaS(Platform-as-a-Service) 기능의 이점 중 하나입니다. 하드웨어 오류는 드물지만 이러한 서비스가 발생할 때 자동으로 처리합니다. 이러한 서비스 중 하나를 사용할 때 컴퓨터 오류를 처리하는 코드를 작성할 필요가 없습니다.

서비스 오류

클라우드 앱은 일반적으로 여러 서비스를 사용합니다. 예를 들어 수정 앱은 SQL Database 서비스, Storage 서비스를 사용하고 웹앱은 Azure App Service 배포됩니다. 의존하는 서비스 중 하나가 실패하면 앱은 어떻게 합니까? 일부 서비스 오류의 경우 "죄송합니다. 나중에 다시 시도하세요" 메시지가 가장 좋습니다. 그러나 많은 시나리오에서 더 잘 할 수 있습니다. 예를 들어 백 엔드 데이터 저장소가 다운되면 사용자 입력을 수락하고 "요청이 수신되었습니다"를 표시하고 다른 곳에 일시적으로 입력을 저장할 수 있습니다. 필요한 서비스가 다시 작동하면 입력을 검색하고 처리할 수 있습니다.

큐 중심 작업 패턴 챕터에서는 이 시나리오를 처리하는 한 가지 방법을 보여 줍니다. 수정 앱은 SQL Database 작업을 저장하지만 SQL Database 중단된 경우 작업을 종료할 필요가 없습니다. 이 챕터에서는 큐에 작업에 대한 사용자 입력을 저장하고 작업자 프로세스를 사용하여 큐를 읽고 작업을 업데이트하는 방법을 살펴보겠습니다. SQL이 다운된 경우 수정 작업을 만드는 기능은 영향을 받지 않습니다. 작업자 프로세스는 SQL Database 사용할 수 있을 때 새 작업을 대기하고 처리할 수 있습니다.

지역 오류

전체 지역이 실패할 수 있습니다. 자연 재해는 데이터 센터를 파괴 할 수 있습니다, 그것은 유성에 의해 평면 얻을 수 있습니다, 데이터 센터에 트렁크 라인은 백호로 소를 묻어 농부에 의해 절단 될 수있다, 등. 앱이 피해 데이터 센터에서 호스트되는 경우 어떻게 해야 합니까? 여러 지역에서 동시에 실행되도록 Azure에서 앱을 설정하여 재해가 발생한 경우 다른 지역에서 계속 실행할 수 있습니다. 이러한 오류는 극히 드물며, 대부분의 앱은 이러한 종류의 오류를 통해 중단 없는 서비스를 보장하는 데 필요한 후프를 통과하지 않습니다. 지역 오류를 통해서도 앱을 계속 사용할 수 있도록 유지하는 방법에 대한 자세한 내용은 장 끝에 있는 리소스 섹션을 참조하세요.

Azure의 목표는 이러한 모든 종류의 오류를 훨씬 더 쉽게 처리하는 것이며, 다음 챕터에서 이러한 작업을 수행하는 방법에 대한 몇 가지 예를 확인할 수 있습니다.

SLA

사람 클라우드 환경의 SLA(서비스 수준 계약)에 대해 자주 듣습니다. 기본적으로 이들은 기업이 자신의 서비스가 얼마나 신뢰할 수 있는지에 대해 만드는 약속입니다. 99.9% SLA는 서비스가 99.9%의 시간 동안 올바르게 작동할 것으로 예상해야 하다는 것을 의미합니다. 이는 SLA에 대한 매우 일반적인 값이며 매우 높은 숫자처럼 들리지만 가동 중지 시간 .1%가 실제로 얼마나 많은지 깨닫지 못할 수도 있습니다. 다음은 다양한 SLA 백분율이 1년, 1개월 및 1주일에 얼마나 많은 가동 중지 시간을 나타내는 표입니다.

SLA 테이블

따라서 99.9% SLA는 서비스가 1년 8.76시간 또는 한 달에 43.2분 감소할 수 있음을 의미합니다. 이는 대부분의 사람들이 깨닫는 것보다 더 많은 가동 중지 시간입니다. 따라서 개발자는 일정량의 가동 중지 시간이 가능하다는 것을 알고 정상적인 방식으로 처리하려고 합니다. 어떤 시점에서 누군가가 앱을 사용하려고 하고 서비스가 중단될 것이며 고객에게 미치는 부정적인 영향을 최소화하려고 합니다.

SLA에 대해 알아야 할 한 가지는 시계가 어떤 시간 프레임을 참조하는지입니다. 시계가 매주, 매월 또는 매년 다시 설정됩니까? Azure에서는 매년 SLA가 일련의 양월로 상쇄하여 나쁜 달을 숨길 수 있으므로 매년 SLA보다 더 나은 매달 시계를 다시 설정합니다.

물론 우리는 항상 SLA보다 더 잘하기를 열망합니다. 일반적으로 당신은 그보다 훨씬 적게 내려갈 것입니다. 약속은 우리가 이제까지 최대 가동 중지 시간 보다 더 이상 아래로 있다면 당신은 다시 돈을 요청할 수 있습니다. 당신이 다시 얻을 돈의 양은 아마 완전히 초과 가동 중지 시간의 비즈니스 영향에 대한 보상하지 않을 것입니다, 하지만 SLA의 측면은 집행 정책 역할을하고 우리가 매우 심각하게 그것을 할 것을 알 수 있습니다.

복합 SLA

SLA를 볼 때 고려해야 할 중요한 사항은 각 서비스에 별도의 SLA가 있는 앱에서 여러 서비스를 사용할 때의 영향입니다. 예를 들어 Fix It 앱은 Azure App Service Web Apps, Azure Storage 및 SQL Database 사용합니다. 이 전자책이 2013년 12월에 작성된 날짜를 기준으로 SLA 번호는 다음과 같습니다.

SLA 웹 사이트, 스토리지, SQL Database

이러한 서비스 SLA를 기반으로 앱에 대해 예상되는 최대 가동 중지 시간은 얼마인가요? 가동 중지 시간이 최악의 SLA 백분율 또는 이 경우 99.9%와 같다고 생각할 수 있습니다. 세 가지 서비스가 모두 동시에 실패하는 경우에도 마찬가지이지만 실제로 실제로 발생하는 것은 아닙니다. 각 서비스는 서로 다른 시간에 독립적으로 실패할 수 있으므로 개별 SLA 번호를 곱하여 복합 SLA를 계산해야 합니다.

복합 SLA

따라서 앱은 한 달에 43.2분이 아니라 해당 금액의 3배, 한 달에 108분까지 다운될 수 있으며 여전히 Azure SLA 제한 내에 있을 수 있습니다.

이 문제는 Azure에서 고유하지 않습니다. Microsoft는 실제로 사용 가능한 모든 클라우드 서비스의 최상의 클라우드 SLA를 제공하며, 공급업체의 클라우드 서비스를 사용하는 경우 비슷한 문제를 처리할 수 있습니다. 이는 고객 또는 사용자에게 영향을 미칠 만큼 자주 발생할 수 있으므로 불가피한 서비스 오류를 정상적으로 처리하도록 앱을 디자인하는 방법에 대해 생각하는 것이 중요합니다.

엔터프라이즈 가동 중지 시간 환경에 비해 클라우드 SLA

사람 때때로 "내 엔터프라이즈 앱에서 나는 이런 문제가 없다"고 말합니다. 한 달에 얼마나 많은 가동 중지 시간을 가지고 있는지 묻는다면, 그들은 일반적으로 "글쎄, 때때로 일어난다"고 말합니다. 그리고 얼마나 자주 묻는다면, 그들은 "때때로 우리는 새 서버를 백업하거나 설치하거나 소프트웨어를 업데이트해야 합니다"라고 인정합니다. 물론 가동 중지 시간으로 계산됩니다. 특히 중요 업무용 앱이 아닌 대부분의 엔터프라이즈 앱은 실제로 서비스 SLA에서 허용하는 시간보다 더 많이 다운됩니다. 그러나 서버와 인프라를 담당하고 이를 제어할 때 가동 중지 시간에 대한 분노를 덜 느끼는 경향이 있습니다. 클라우드 환경에서는 다른 사람에게 의존하고 있으며 무슨 일이 일어나고 있는지 모르기 때문에 더 걱정하는 경향이 있을 수 있습니다.

엔터프라이즈가 클라우드 SLA에서 얻는 것보다 더 큰 업타임 비율을 달성하면 하드웨어에 더 많은 돈을 지출하여 이를 수행합니다. 클라우드 서비스는 그렇게 할 수 있지만 서비스에 대해 훨씬 더 많은 요금을 부과해야 합니다. 대신 비용 효율적인 서비스를 활용하고 소프트웨어를 설계하여 불가피한 오류로 인해 고객에게 최소한의 중단이 발생하도록 합니다. 클라우드 앱 디자이너로서의 업무는 실패를 피하기 위한 것이 아니며 하드웨어가 아닌 소프트웨어에 집중하여 이 작업을 수행합니다. 엔터프라이즈 앱은 오류 사이의 평균 시간을 최대화하기 위해 노력하는 반면 클라우드 앱은 평균 복구 시간을 최소화하기 위해 노력합니다.

모든 클라우드 서비스에 SLA가 있는 것은 아닙니다.

또한 모든 클라우드 서비스에 SLA가 있는 것은 아닙니다. 앱이 가동 시간 보장 없이 서비스에 종속된 경우 예상보다 훨씬 더 오래 다운될 수 있습니다. 예를 들어 Facebook 또는 Twitter와 같은 소셜 공급자를 사용하여 사이트에 로그인을 사용하도록 설정하는 경우 서비스 공급자와 검사 SLA가 있는지 확인하고 SLA가 없는지 확인할 수 있습니다. 그러나 인증 서비스가 중단되거나 요청하는 양을 지원할 수 없는 경우 고객은 앱에서 잠깁니다. 며칠 이상 다운 될 수 있습니다. 한 새로운 앱의 제작자는 수억 개의 다운로드를 기대하고 Facebook 인증에 의존했지만 라이브로 전환하기 전에 Facebook과 이야기하지 않았고 해당 서비스에 대한 SLA가 없다는 것을 너무 늦게 발견했습니다.

모든 가동 중지 시간이 SLA에 계산되는 것은 아닙니다.

일부 클라우드 서비스는 앱에서 과도하게 사용하는 경우 서비스를 의도적으로 거부할 수 있습니다. 이를 제한이라고 합니다. 서비스에 SLA가 있는 경우 제한될 수 있는 조건을 명시해야 하며, 앱 디자인은 이러한 조건을 방지하고 제한에 적절하게 대응해야 합니다. 예를 들어 초당 특정 수를 초과할 때 서비스에 대한 요청이 실패하기 시작하면 자동 재시도가 너무 빨리 수행되지 않아 제한이 계속되도록 해야 합니다. 일시적인 오류 처리 챕터에서 제한에 대해 자세히 살펴보겠습니다.

요약

이 챕터는 실제 클라우드 앱이 오류를 정상적으로 유지하도록 설계되어야 하는 이유를 파악하는 데 도움을 주기 위해 노력했습니다. 다음 챕터부터 이 시리즈의 나머지 패턴은 이를 수행하는 데 사용할 수 있는 몇 가지 전략에 대해 자세히 설명합니다.

  • 적절한 모니터링 및 원격 분석을 통해 개입이 필요한 오류에 대해 신속하게 파악하고 이를 resolve 충분한 정보를 확인할 수 있습니다.
  • 지능형 재시도 논리를 구현하여 일시적인 오류를 처리하므로 가능하면 앱이 자동으로 복구되고, 복구할 수 없을 때 회로 차단기 논리로 돌아갑니다.
  • 분산 캐싱을 사용하여 데이터베이스 액세스와 관련된 처리량, 대기 시간 및 연결 문제를 최소화합니다.
  • 큐 중심 작업 패턴을 통해 느슨한 결합을 구현하여 백 엔드가 다운된 경우 앱 프런트 엔드가 계속 작동할 수 있도록 합니다.

리소스

자세한 내용은 이 전자책의 이후 장 및 다음 리소스를 참조하세요.

설명서:

비디오:

  • FailSafe: 확장 가능하고 복원력 있는 Cloud Services 빌드합니다. 울리히 호만, 마크 머큐리, 마크 심스의 9부작 시리즈. 실제 고객과의 MICROSOFT CAT(고객 자문 팀) 경험에서 가져온 스토리와 함께 매우 액세스 가능하고 흥미로운 방식으로 높은 수준의 개념과 아키텍처 원칙을 제시합니다. 에피소드 1과 8은 실패에서 살아남기 위해 클라우드 앱을 디자인하는 이유를 자세히 설명합니다. 49:57부터 시작되는 에피소드 2의 제한에 대한 후속 토론, 56:05부터 시작되는 에피소드 2의 실패 지점 및 실패 모드에 대한 논의, 40:55부터 시작되는 에피소드 3의 회로 차단기에 대한 논의를 참조하세요.
  • 큰 빌드: Azure 고객으로부터 배운 교훈 - 2부. Mark Simms는 실패를 위한 설계 및 모든 것을 계측하는 방법에 대해 이야기합니다. Failsafe 시리즈와 비슷하지만 자세한 방법 세부 정보로 이동합니다.

이전다음