Failsafe: 복원력 있는 클라우드 아키텍처에 대한 지침

업데이트 날짜: 2014년 6월

저자: Marc Mercuri, Ulrich Homann, Mark Simms, Jason Wescott, Andrew Townhill

검토자: Michael Thomassy, Curt Peterson, Stuart Ozer, Fran Dougherty, Tim O’Brien, Hatay Tuna, Patrick Butler Monterde, Mark Kottke, Lewis Curtis, William Bellamy

게시 날짜: 2014년 6월

FailSafe(비상 안전 장치) 명사. 메커니즘, 시스템 등의 고장을 방지하기 위해 자동으로 작동하거나 기능하도록 디자인된 것입니다.

직원, 시민, 소비자 등 개인은 응용 프로그램, 계산 및 데이터 서비스에 대한 즉각적인 액세스를 요구합니다. 연결된 사람과 이러한 서비스에 연결하는 데 사용하는 장치가 계속 증가하고 있는 항상 작동하는 서비스의 세계에서 서비스를 지원하는 시스템은 가용성과 복원력을 둘 다 갖추도록 디자인되어야 합니다.

이러한 서비스는 미리 정의된 구성의 상품으로 채워진 클라우드 환경에 배포됩니다. 이전에는 수직 확장하기 위해 고급 하드웨어를 구입했을 것입니다. 그러나 클라우드 환경에서는 대신 수평 확장해야 합니다. 상용 하드웨어를 사용하여 이러한 클라우드 환경의 비용을 낮게 유지합니다. 상용 하드웨어에는 오류가 발생하기 마련이므로 클라우드에는 실제로 오류를 받아들이는 아키텍처가 필요합니다. 이전에는 오류를 방지하고 “평균 오류 간격”을 최적화하는 데 초점을 뒀을 것입니다. 이 새로운 환경에서는 초점이 “최소의 영향으로 복원하는 평균 시간” 중 하나로 이동합니다.

개발하는 서비스는 필시 복합적일 것입니다. 서비스는 하나 이상의 자사 또는 타사 플랫폼과 타사 공급자 서비스로 구성됩니다. 이러한 서비스는 오류가 발생할 클라우드 인프라에 빌드됩니다. 또한 아키텍처는 아키텍처에 사용되는 서비스에도 오류가 발생할 것이라고 가정해야 합니다. 인프라 아키텍처와 마찬가지로 응용 프로그램 아키텍처 설계는 오류를 받아들여야 합니다.

Microsoft의 FailSafe 이니셔티브는 복원력이 있는 클라우드 아키텍처를 구축하기 위한 일반적인 지침, 이러한 아키텍처를 Microsoft 기술을 기반으로 구현하기 위한 지침 및 특정 시나리오를 대상으로 이러한 아키텍처를 구현하는 방법을 제공하는 것을 목적으로 합니다. 이 문서의 저자들은 Microsoft의 클라우드 + 엔터프라이즈 사업부, 신뢰할 수 있는 컴퓨팅 및 Microsoft Consulting Services의 멤버입니다.

이 문서에서는 확장성과 복원력이 있는 시스템을 디자인하기 위한 아키텍처 고려 사항을 중점적으로 다룹니다.

이 문서는 다음 섹션으로 구성되어 있습니다.

  • 작업에 따라 응용 프로그램 분해: 작업 중심 방법을 정의하면 비용을 좀 더 효과적으로 제어할 수 있고 작업에 가장 적합한 기술을 선택하는 데 있어서 유연성이 커지며 가용성과 복원력에 대한 보다 세부적으로 조정된 접근법이 가능합니다.

  • 수명 주기 모델 설정: 응용 프로그램 수명 주기 모델을 설정하면 프로덕션에서 응용 프로그램의 예상 동작을 정의하는 데 유용하며 전체적인 아키텍처를 파악하고 요구 사항을 발견할 수 있습니다.

  • 가용성 모델 및 계획 설정: 가용성 모델은 작업에 예상되는 가용성 수준을 식별합니다. 가용성 모델은 서비스를 설정할 때 내릴 결정 중 상당수를 알려주므로 매우 중요합니다.

  • 오류 지점, 오류 모드 및 오류 영향 식별: 복원력 있는 아키텍처를 만들려면 오류 지점과 오류 모드를 이해하고 식별해야 합니다. 특히 가동 중단을 일으킬 수 있는 문제를 이해하고 문서화하기 위해 사전에 노력하면 분석과 계획에 사용할 수 있는 윤곽이 잡힙니다.

  • 복원력 패턴 및 고려 사항: 이 섹션은 문서의 대부분을 차지하며 계산, 저장소 및 플랫폼 서비스 전반의 주요 고려 사항을 포함하고 있습니다. 이러한 고려 사항은 계산, 저장소 및 플랫폼 서비스 전반의 주요 고려 사항에서 정상적인 응용 프로그램을 제공하기 위한 증명된 방법에 초점을 맞춥니다.

  • 운영을 위한 디자인: 서비스가 "항상 작동"할 것으로 기대하는 세계에서 서비스는 운영을 위해 디자인되어야 합니다. 이 섹션에서는 상태 모델 설정에서 원격 분석 구현과 운영자 및 개발자를 위한 원격 분석 정보 시각화에 이르는 수명 주기에 걸쳐 있는 운영을 위한 디자인에 대한 증명된 방법을 살펴봅니다.

응용 프로그램은 일반적으로 여러 작업으로 구성되어 있습니다.

작업마다 서로 다른 요구 사항과 서로 다른 수준의 비즈니스 중요도 및 재정적 고려 사항이 있을 수 있으며 그러한 경우는 흔합니다. 조직은 응용 프로그램을 작업으로 분해하여 중요한 유연성을 얻습니다. 작업 중심 방법은 비용에 대한 보다 효과적인 제어, 작업에 가장 적합한 기술 선택 시 향상된 유연성, 가용성과 보안에 대한 작업 관련 접근법, 새 기능 추가 및 배포 시 유연성과 민첩성 등을 제공합니다.

복원력에 대해 고려할 때 시나리오의 맥락에서 살펴보는 것이 도움이 되기도 합니다. 다음은 일반적인 시나리오의 예입니다.

  • 스포츠 데이터 서비스

    고객이 스포츠 정보를 제공하는 데이터 서비스를 제공합니다. 이 서비스에는 두 가지 주요 작업이 있습니다. 첫 번째 작업은 선수와 팀에 대한 통계를 제공하고, 두 번째 작업은 현재 진행 중인 게임에 대한 점수와 해설을 제공합니다.

  • 전자 상거래 웹 사이트

    온라인 소매점이 잘 설정된 모델의 웹 사이트를 통해 상품을 판매합니다. 응용 프로그램에는 가장 자주 사용되는 "검색 및 찾아보기"와 "결제"를 비롯한 많은 작업이 있습니다.

  • 소셜 사이트

    잘 알려진 소셜 사이트에서는 커뮤니티의 회원이 포럼, 사용자 생성 콘텐츠 및 가벼운 게임을 통해 서로 경험을 공유할 수 있습니다. 응용 프로그램에는 등록, 검색 및 찾아보기, 사회적 교류, 게임, 전자 메일 등의 많은 작업이 있습니다.



  • 조직은 웹 사이트를 통해 고객에게 체험 환경을 제공하고자 합니다. 응용 프로그램은 PC 기반 브라우저뿐만 아니라 인기 있는 모바일 장치 유형(휴대폰, 태블릿)에서 체험 환경을 제공해야 합니다. 응용 프로그램에는 등록, 검색 및 찾아보기, 콘텐츠 게시, 비평, 사회, 게임 등의 많은 작업이 있습니다.

위의 시나리오 중 하나를 좀 더 자세히 살펴보고 하위 작업으로 분해해 보겠습니다. 전자 상거래 웹 사이트에는 찾아보기 및 검색, 결제 및 관리, 사용자 등록, 사용자 생성 콘텐츠(리뷰 및 평가), 개인 설정 등의 많은 작업이 있을 수 있습니다.

이 시나리오의 두 가지 핵심 작업은 다음과 같이 정의할 수 있습니다.

  • 찾아보기 및 검색은 고객이 제품 카탈로그를 탐색하고 특정 품목을 검색하고 장바구니나 관심 상품 목록을 관리할 수 있도록 합니다. 이 작업에는 익명 사용자 액세스, 1초 미만의 응답 시간 및 캐싱과 같은 특성이 있을 수 있습니다. 예기치 않은 사용자 부하 또는 제품 재고를 새로 고치기 위한 응용 프로그램 허용 중단을 통해 응답 시간이 증가하는 형태로 성능 저하가 발생할 수 있습니다. 이러한 경우 응용 프로그램은 캐시에서 정보를 계속 제공하도록 선택할 수 있습니다.

  • 결제 및 관리는 고객이 주문을 실행, 추적 및 취소하고 배송 방법과 지불 옵션을 선택하고 프로필을 관리하는 데 도움이 됩니다. 이 작업에는 보안 액세스, 큐에 대기되는 처리, 타사 지불 게이트웨이에 대한 액세스 및 백 엔드 온-프레미스 시스템 연결과 같은 특성이 있을 수 있습니다. 응용 프로그램이 증가한 응답 시간을 허용할 수는 있지만 주문 손실은 허용할 수 없습니다. 따라서 응용 프로그램은 지불을 처리할 수 있든 배송을 준비할 수 있든 간에 고객 주문이 항상 허용되고 캡처되는 것을 보장하도록 디자인됩니다.

응용 프로그램 수명 주기 모델은 운영 시 응용 프로그램의 예상 동작을 정의합니다. 단계와 시간에 따라 응용 프로그램은 기능 수준에서든 전체적인 수준에서든 간에 시스템에 각기 다른 요구를 하며, 수명 주기 모델은 이를 반영합니다.

작업은 적용 가능한 모든 관련 시나리오에 대한 수명 주기 모델을 적절한 세분성 수준에서 정의해 놓아야 합니다. 서비스에는 모델링될 때 시간에 따른 특정 용량, 가용성, 성능 및 확장성 요구 사항을 식별하는 시간별, 일별, 주별 또는 계절별 수명 주기 차이가 있을 수 있습니다.

Failsafe_03

그림 1. 다양한 산업 및 시나리오의 수명 주기 예

일반적으로 다음과 같은 고유한 수명 주기가 있는 기간이 있습니다.

  • 휴가 기간 동안의 최대 수요 관련 급증

  • 기한 직전의 납세 신고서 작성 증가

  • 오전 및 오후 통근 시간대

  • 연말의 직원 성과 검토서 작성

많은 조직에서는 이러한 유형의 시나리오와 관련 시나리오별 수명 주기를 파악하고 있습니다.

분해를 사용하면 작업 수준에 다양한 내부 SLA(서비스 수준 계약)가 있을 수 있습니다. 이러한 예로는 목표 SLA가 99.99%인 스포츠 데이터 API를 들 수 있습니다. 그러나 해당 API를 두 개의 작업 즉, “실시간 점수 + 해설” 및 “팀, 선수 및 리그 통계”로 분할할 수 있습니다.

“실시간 점수 + 해설” 작업의 경우 수명 주기에 “불규칙한” 패턴이 있습니다. 그러나 “팀, 선수 및 리그 통계”의 가용성은 변함없습니다. 작업별 분해를 사용하면 복합 서비스의 집계된 작업 가용성 요구에 맞는 SLA를 보유할 수 있습니다.

Failsafe_12

그림 2

수명 주기 모델이 파악되면 다음 단계는 가용성 모델 및 계획을 설정하는 것입니다. 응용 프로그램의 가용성 모델은 작업에 예상되는 가용성 수준을 식별합니다. 가용성 모델은 서비스를 설정할 때 내릴 결정 중 상당수를 알려주므로 매우 중요합니다.

여러 가지 고려할 사항이 있으며 취할 수 있는 잠재적인 조치도 다양합니다.

가용성 계획을 개발할 때 응용 프로그램에 대한 원하는 가용성, 응용 프로램 내 작업 및 해당 작업 제공 시 사용되는 서비스를 파악하는 것이 중요합니다.

작업의 수명 주기를 이해하면 제공하려는 SLA를 선택하는 데 도움이 됩니다. SLA는 서비스에 대해 공개적으로 제공되지 않을 수 있습니다. 그러나 아키텍처는 충족하고자 하는 가용성 기준을 대상으로 해야 합니다.

빌드하는 솔루션 유형에 따라 고가용성을 제공하기 위한 다양한 고려 사항과 옵션이 있습니다. 상용 서비스 공급자는 100% 수준의 SLA를 제공하기 위한 복잡성과 비용이 가능하지 않거나 채산이 맞지 않으므로 이러한 수준의 SLA를 제공하지 않습니다. 응용 프로그램을 작업 수준으로 분해하면 가용성에 대한 접근법을 구현하고 의사 결정을 내릴 수 있습니다. 전체 응용 프로그램에 대해 99.99% 가동 시간을 제공하는 것은 불가능할 수 있지만, 한 응용 프로그램의 한 가지 작업에 대해서라면 가능할 수 있습니다.

작업 수준에서도 모든 옵션을 구현하도록 선택하지는 않을 것입니다. 구현하도록 선택하는 옵션은 요구 사항에 따라 결정됩니다. 선택하는 옵션에 관계없이 모든 옵션을 신중하게 고려한 후 합리적인 선택을 해야 합니다.

자치란 독립과 관련이 있으며 서비스를 전체적으로 구성하는 부분 간의 종속성을 줄이는 것입니다. 관련 기능을 서비스 내의 자치 단위로 작성할 계획으로 서비스를 디자인하는 경우 구성 요소, 데이터 및 외부 엔터티에 대한 종속성을 검사해야 합니다. 이렇게 하면 개별 자치 단위의 버전을 신속하게 업데이트하고 자치 단위의 확장을 보다 세부적으로 제어하는 등의 이점이 있습니다.

작업 아키텍처는 흔히 수동 개입에 의존하지 않는 자치 구성 요소로 구성되며 자치 구성 요소가 종속되어 있는 엔터티를 사용할 수 없는 경우 오류가 발생하지 않습니다. 자치 부분으로 구성된 응용 프로그램의 특징은 다음과 같습니다.

  • 사용 가능하고 작동합니다.

  • 복원력이 있고 오류에서 쉽게 복구 가능합니다.

  • 정상적이 아닌 오류 상태에 대한 위험이 적습니다.

  • 복제를 통해 쉽게 확장됩니다.

  • 수동 개입이 필요할 가능성이 적습니다.

이러한 자치 단위는 비동기 통신, 끌어오기 기반 데이터 처리 및 지속적인 서비스를 보장하기 위한 자동화를 활용하는 경우가 많습니다.

향후 시장은 종적인 시나리오와 횡적인 시나리오에 해당하는 특정 유형의 기능에 대한 표준화된 인터페이스가 있는 수준까지 발전할 것입니다. 이러한 향후 비전이 실현되면 서비스 공급자가 자치 단위의 지정된 작업을 해결하는 잠재적으로 다른 구현 및 다른 공급자와 작업할 수 있을 것입니다. 지속적인 서비스를 위해 이 작업은 자치적으로 수행되며 정책을 기반으로 합니다.

자치를 원하는 만큼 대부분의 서비스는 호스팅만을 위해서라도 타사 서비스에 종속될 것입니다. 이러한 종속 서비스의 SLA를 이해하고 가용성 계획에 통합하는 것이 필수적입니다.

이 섹션에서는 서비스와 관련될 수 있는 다양한 유형의 SLA를 식별합니다. 이러한 서비스 유형 각각에는 주요 고려 사항 및 접근법뿐만 아니라 물어야 하는 질문이 있습니다.

공용 클라우드 플랫폼 서비스

상용 클라우드 계산 플랫폼에서 제공하는 서비스(예: 계산 또는 저장소)에는 상당한 규모의 많은 고객을 수용하도록 디자인된 서비스 수준 계약이 있습니다. 이러한 서비스의 SLA는 협상이 가능하지 않습니다. 공급자는 각기 다른 SLA가 있는 계층 수준의 서비스를 제공할 수 있지만 이러한 계층은 협상이 가능하지 않습니다. 서비스 공급자는 예측 가능한 서비스 품질을 제공하기 위해 계층화된 서비스 수준과 다양한 SLA를 사용합니다.

이 유형의 서비스에 대해 고려할 질문:

  • 이 서비스에서 서비스 API에 대한 호출을 특정 횟수만큼만 허용합니까?

  • 이 서비스에서 서비스 API에 대한 호출 주기에 제한을 둡니까?

  • 이 서비스에서 서비스 API를 호출할 수 있는 서버의 수를 제한합니까?

  • 서비스에서 가용성 약속을 실현하는 방법에 대해 공개된 정보는 무엇입니까?

  • 이 서비스가 자신의 상태를 어떻게 전달합니까?

  • 명시된 SLA(서비스 수준 계약)는 무엇입니까?

  • 다른 타사에서 제공하는 동등한 플랫폼 서비스는 무엇입니까?

타사 "무료" 서비스

"무료" 서비스를 커뮤니티에 제공하는 타사가 많습니다. 민간 부문 조직의 경우 대부분 자신의 핵심 제품이나 서비스 주위에 응용 프로그램 에코시스템을 생성하기 위해 무료 서비스를 제공합니다. 공공 부문의 경우에는 세금을 통한 정부의 자금 제공을 통해 외견상으로는 수집한 데이터에 대해 지불한 시민과 기업에 데이터를 제공하기 위해 무료 서비스를 제공합니다.

대부분의 이러한 서비스에는 서비스 수준 계약이 제공되지 않으므로 가용성이 보장되지 않습니다. SLA가 제공되는 경우에는 일반적으로 응용 프로그램 소비에 대한 제한과 이러한 제한을 적용하는 데 사용될 메커니즘에 초점이 맞춰집니다. 제한의 예로는 특정 횟수의 서비스 호출을 초과하거나, 지정된 기간 동안 특정 횟수의 호출(분당 x)을 초과하거나, 서비스를 호출하는 허용 가능한 서버의 수를 초과하는 경우 해당 솔루션을 제한하거나 차단 목록에 포함하는 것이 포함될 수 있습니다.

이 유형의 서비스에 대해 고려할 질문:

  • 이 서비스에서 서비스 API에 대한 호출을 특정 횟수만큼만 허용합니까?

  • 이 서비스에서 서비스 API에 대한 호출 주기에 제한을 둡니까?

  • 이 서비스에서 서비스 API를 호출할 수 있는 서버의 수를 제한합니까?

  • 서비스에서 가용성 약속을 실현하는 방법에 대해 공개된 정보는 무엇입니까?

  • 이 서비스가 자신의 상태를 어떻게 전달합니까?

  • 명시된 SLA(서비스 수준 계약)는 무엇입니까?

  • 이 서비스는 필요한 기능 및/또는 데이터를 여러 서비스 공급자로부터 사용 가능한 상용 서비스입니까?

  • 상용 서비스인 경우 다른 서비스 공급자와 인터페이스가 상호 운용됩니까(직접 또는 사용 가능한 추상 계층을 통해)?

  • 다른 타사에서 제공하는 동등한 플랫폼 서비스는 무엇입니까?

타사 상용 서비스

타사에서 제공하는 상용 서비스에는 지불 고객의 요구를 수용하도록 디자인된 서비스 수준 계약이 있습니다. 공급자는 각기 다른 수준의 가용성을 가진 계층 수준의 SLA를 제공할 수 있지만 이러한 SLA는 협상이 가능하지 않습니다.

이 유형의 서비스에 대해 고려할 질문:

  • 이 서비스에서 서비스 API에 대한 호출을 특정 횟수만큼만 허용합니까?

  • 이 서비스에서 서비스 API에 대한 호출 주기에 제한을 둡니까?

  • 이 서비스에서 서비스 API를 호출할 수 있는 서버의 수를 제한합니까?

  • 서비스에서 가용성 약속을 실현하는 방법에 대해 공개된 정보는 무엇입니까?

  • 이 서비스가 자신의 상태를 어떻게 전달합니까?

  • 명시된 SLA(서비스 수준 계약)는 무엇입니까?

  • 이 서비스는 필요한 기능 및/또는 데이터를 여러 서비스 공급자로부터 사용 가능한 상용 서비스입니까?

  • 상용 서비스인 경우 다른 서비스 공급자와 인터페이스가 상호 운용됩니까(직접 또는 사용 가능한 추상 계층을 통해)?

  • 다른 타사에서 제공하는 동등한 플랫폼 서비스는 무엇입니까?

커뮤니티 클라우드 서비스

공급망과 같은 조직의 커뮤니티는 구성원 조직이 서비스를 사용할 수 있게 만들 수 있습니다.

이 유형의 서비스에 대해 고려할 질문:

  • 이 서비스에서 서비스 API에 대한 호출을 특정 횟수만큼만 허용합니까?

  • 이 서비스에서 서비스 API에 대한 호출 주기에 제한을 둡니까?

  • 이 서비스에서 서비스 API를 호출할 수 있는 서버의 수를 제한합니까?

  • 서비스에서 가용성 약속을 실현하는 방법에 대해 공개된 정보는 무엇입니까?

  • 이 서비스가 자신의 상태를 어떻게 전달합니까?

  • 명시된 SLA(서비스 수준 계약)는 무엇입니까?

  • 커뮤니티의 구성원으로서 다른 SLA를 협상할 가능성이 있습니까?

  • 이 서비스는 필요한 기능 및/또는 데이터를 여러 서비스 공급자로부터 사용 가능한 상용 서비스입니까?

  • 상용 서비스인 경우 다른 서비스 공급자와 인터페이스가 상호 운용됩니까(직접 또는 사용 가능한 추상 계층을 통해)?

  • 다른 타사에서 제공하는 동등한 플랫폼 서비스는 무엇입니까?

자사 내부 엔터프라이즈 수준 클라우드 서비스

기업은 주가 데이터 또는 제품 메타데이터와 같은 핵심 서비스를 부문과 부서에서 사용할 수 있게 만들 수 있습니다.

이 유형의 서비스에 대해 고려할 질문:

  • 이 서비스에서 서비스 API에 대한 호출을 특정 횟수만큼만 허용합니까?

  • 이 서비스에서 서비스 API에 대한 호출 주기에 제한을 둡니까?

  • 이 서비스에서 서비스 API를 호출할 수 있는 서버의 수를 제한합니까?

  • 서비스에서 가용성 약속을 실현하는 방법에 대해 공개된 정보는 무엇입니까?

  • 이 서비스가 자신의 상태를 어떻게 전달합니까?

  • 명시된 SLA(서비스 수준 계약)는 무엇입니까?

  • 조직의 구성원으로서 다른 SLA를 협상할 가능성이 있습니까?

  • 이 서비스는 필요한 기능 및/또는 데이터를 여러 서비스 공급자로부터 사용 가능한 상용 서비스입니까?

  • 상용 서비스인 경우 다른 서비스 공급자와 인터페이스가 상호 운용됩니까(직접 또는 사용 가능한 추상 계층을 통해)?

  • 다른 타사에서 제공하는 동등한 플랫폼 서비스는 무엇입니까?

자사 내부 부문 또는 부서 클라우드 서비스

기업의 부문 또는 부서에서는 직속 조직의 다른 구성원이 서비스를 사용할 수 있게 만들 수 있습니다.

이 유형의 서비스에 대해 고려할 질문:

  • 이 서비스에서 서비스 API에 대한 호출을 특정 횟수만큼만 허용합니까?

  • 이 서비스에서 서비스 API에 대한 호출 주기에 제한을 둡니까?

  • 이 서비스에서 서비스 API를 호출할 수 있는 서버의 수를 제한합니까?

  • 서비스에서 가용성 약속을 실현하는 방법에 대해 공개된 정보는 무엇입니까?

  • 이 서비스가 자신의 상태를 어떻게 전달합니까?

  • 명시된 SLA(서비스 수준 계약)는 무엇입니까?

  • 부문의 구성원으로서 다른 SLA를 협상할 가능성이 있습니까?

  • 이 서비스는 필요한 기능 및/또는 데이터를 여러 서비스 공급자로부터 사용 가능한 상용 서비스입니까?

  • 상용 서비스인 경우 다른 서비스 공급자와 인터페이스가 상호 운용됩니까(직접 또는 사용 가능한 추상 계층을 통해)?

  • 다른 타사에서 제공하는 동등한 플랫폼 서비스는 무엇입니까?

복합 서비스 가용성의 진정한 "9"의 개수

기존 서비스를 활용하면 조직이나 상용 판매를 위해 솔루션을 제공할 때 상당한 민첩성을 얻을 수 있습니다. 이러한 이점이 있긴 하지만 이러한 종속성이 작업의 전체적인 SLA에 미치는 영향을 정확하게 이해하는 것이 중요합니다.

가용성은 일반적으로 해당 연도의 가동률로 표현됩니다. 이렇게 표현된 가용률은 “9”의 개수로 지칭됩니다. 예를 들어 99.9는 "3개의 9"를 가진 서비스를 나타내고 99.999는 "5개의 9"를 가진 서비스를 나타냅니다.

 

가용률

연간 가동 중지 시간

월간 가동 중지 시간

주간 가동 중지 시간

90%("1개의 9")

36.5일

72시간

16.8시간

95%

18.25일

36시간

8.4시간

97%

10.96일

21.6시간

5.04시간

98%

7.30일

14.4시간

3.36시간

99%("2개의 9")

3.65일

7.20시간

1.68시간

99.5%

1.83일

3.60시간

50.4분

99.8%

17.52시간

86.23분

20.16분

99.9%("3개의 9")

8.76시간

43.2분

10.1분

99.95%

4.38시간

21.56분

5.04분

99.99%("4개의 9")

52.56분

4.32분

1.01분

99.999%("5개의 9")

5.26분

25.9초

6.05초

99.9999%("6개의 9")

31.5초

2.59초

0.605초

99.99999%("7개의 9")

3.15초

0.259초

0.0605초

한 가지 일반적인 오해는 복합 서비스가 제공하는 "9"의 개수와 관련되어 있습니다. 특히, 주어진 서비스가 5개의 서비스로 구성되어 있고 각 서비스가 SLA에서 99.99%의 가동 시간을 약속한 경우 생성된 복합 서비스의 가용성도 99.99%라고 흔히 간주됩니다. 하지만 이는 실제와 다릅니다.

Failsafe_13

그림 3: 보다 일반적인 개수의 "9"와 관련된 가동 중지 시간

복합 SLA는 실제로 연간 가동 중지 시간을 고려하는 계산입니다. SLA에 "4개의 9"(99.99%)가 명시된 서비스는 최대 52.56분까지 오프라인 상태일 수 있습니다.

서비스 5개를 99.99% SLA와 통합하면 262.8분 또는 4.38시간의 SLA 위험이 식별됩니다. 이로 인해 가용성은 단 한 줄의 코드도 작성하기 전에 99.95%로 낮아집니다.

일반적으로 타사 서비스의 가용성은 변경할 수 없다는 말은 사실입니다. 그러나 코드를 작성할 때 이 문서에 설명된 방법과 같은 방법을 사용하여 응용 프로그램의 전체 가용성을 높일 수 있습니다.

note참고
일부 서비스에서는 비즈니스 파트너 관계를 기반으로 또는 다양한 가격에 대해 다양한 계층의 서비스를 제공할 수 있습니다.

앞에서 언급한 스포츠 데이터 API를 고려하세요. 사용자는 특정일의 특정 시간 동안만 게임을 합니다. 이러한 기간 동안 SLA는 100%입니다. 예정된 게임이 없을 때 이 작업은 SLA가 0%입니다. “팀, 선수, 리그 통계” 작업은 보다 일관된 수명 주기 패턴을 가집니다. 또한 해당 작업에 대해서는 항상 SLA가 99%여야 한다는 요구 사항이 있습니다.

Failsafe_14

그림 4

외부 서비스를 활용할 때는 SLA를 개별적으로 이해하는 것과 복합 서비스에 대한 SLA의 영향을 이해하는 것의 중요성을 충분히 강조할 수 없습니다.

복원력 있는 아키텍처를 만들려면 먼저 그러한 아키텍처를 이해해야 합니다. 특히 가동 중단을 일으킬 수 있는 문제를 이해하고 문서화하기 위해 사전에 노력해야 합니다.

응용 프로그램과 관련 작업 서비스에 대한 오류 지점과 오류 모드를 이해하면 복원력 및 가용성 전략에 대해 목적에 부합하는 합리적인 결정을 내릴 수 있습니다.

오류 지점은 오류로 인해 서비스 중단이 발생할 수 있는 위치입니다. 중요한 초점은 외부 변경에 종속되는 디자인 요소에 맞춰집니다.

오류 지점의 예는 다음과 같습니다.

  • 데이터베이스 연결

  • 웹 사이트 연결

  • 구성 파일

  • 레지스트리 키

일반적인 오류 지점의 범주는 다음과 같습니다.

  • ACL

  • 데이터베이스 액세스

  • 외부 웹 사이트/서비스 액세스

  • 트랜잭션

  • 구성

  • Capacity

  • 네트워크

오류 지점이 가동 중단을 발생시킬 수 있는 영역을 정의하는 반면, 오류 모드는 오류가 발생할 수 있는 구체적인 방식을 식별합니다.

오류 모드의 예는 다음과 같습니다.

  • 누락된 구성 파일

  • 리소스 용량을 초과하는 상당한 트래픽

  • 최대 용량에 도달한 데이터베이스

오류 영향은 기능에 대한 오류의 결과입니다. 오류의 영향과 이러한 유형의 오류가 발생할 수 있는 빈도를 살펴보세요. 이렇게 하면 응용 프로그램 또는 서비스의 오류 지점 및 오류 모드를 처리하는 시기와 방법의 우선 순위를 지정할 수 있습니다.

이 문서에서는 계산, 저장소 및 플랫폼 서비스에 대한 주요 고려 사항을 살펴봅니다. 이러한 항목을 다루기 전에 흔히 잘못 이해되거나 구현되지 않는 몇 가지 기본적인 복원력 영향 항목을 요약해 보겠습니다.

앞에서 설명했듯이 복원력 있는 아키텍처는 자치를 위해 최적화되어야 합니다. 자치를 달성하는 방법 중 하나는 통신을 비동기로 만드는 것입니다. 복원력 있는 아키텍처는 기본적으로 비동기 상호 작용으로 설정되어야 하고 동기 상호 작용은 예외의 결과로만 발생해야 합니다.

상태 비저장 웹 계층 또는 분산 캐시가 있는 웹 계층은 솔루션의 프런트 엔드에서 이를 제공할 수 있습니다. 큐는 작업 서비스 간의 상호 작용 또는 작업 서비스 내 서비스의 통신을 위해 이 기능을 제공할 수 있습니다.

후자의 경우 메시지가 큐에 배치될 수 있으며 보조 서비스가 해당 메시지를 검색할 수 있습니다. 이 작업은 논리, 시간 또는 볼륨 고려 논리를 기반으로 수행될 수 있습니다. 프로세스를 비동기로 설정하는 것 외에도 필요에 따라 큐에서 "밀어넣기" 또는 "끌어오기" 계층을 확장할 수도 있습니다.

임시 오류는 아키텍처가 서비스나 데이터베이스와 같은 리소스에 연결하는 경우에 일반적으로 발생합니다. 이러한 서비스를 사용할 때는 시간 제한 개념을 도입하는 논리를 구현하는 것이 일반적인 방법입니다. 이 논리는 응답이 예상되는 허용 가능한 기간을 식별하고 이 기간을 초과할 때 식별 가능한 오류를 생성합니다. 표시되는 시간 제한 오류에 따라 적절한 단계가 오류가 발생하는 컨텍스트를 기반으로 수행됩니다. 컨텍스트에는 해당 오류가 발생한 횟수, 사용할 수 없는 리소스의 잠재적인 영향, 주어진 고객에 대한 현재 기간의 SLA 보증 등이 포함될 수 있습니다.

작업을 제공할 서비스를 디자인할 때 오류가 발생할 것임을 받아들이고 오류를 처리하기 위해 적절한 단계를 수행해야 합니다.

처리할 일반적인 영역 중 하나는 일시적인 오류입니다. 가동 시간이 100%인 서비스는 없으므로 작업이 종속된 서비스에 연결하지 못할 수도 있다고 예상하는 것이 현실적입니다. 해당 서비스 중 하나에 연결할 수 없거나 오류가 표시되는 기간이 일시적(1초 미만) 또는 영구적(공급자가 종료함)일 수 있습니다.

정상적 저하

작업 서비스는 이러한 일시적인 오류를 정상적으로 처리하려고 해야 합니다. 예를 들어 Netflix는 클라우드 공급자에서 작동이 중단되는 동안 기본 데이터 저장소를 사용할 수 없었을 때 고객을 위해 이전 비디오 큐를 사용했습니다. 또 다른 예로 지불 게이트웨이를 사용할 수 없는 경우 계속해서 주문을 받는 전자 상거래 사이트를 들 수 있습니다. 이 경우에는 지불 게이트웨이를 다시 사용할 수 있게 되거나 보조 지불 게이트웨이로 장애 조치한 후 주문을 처리할 수 있는 기능을 제공합니다.

정상적인 저하에 대한 개괄적인 고려 사항

정상적으로 저하시키는 방법에 대해 생각할 때 핵심 고려 사항은 다음과 같습니다.

  • 요청의 전체 컨텍스트를 포함하지 않는 구성 요소는 오류가 발생하고 예외 메시지를 전달해야 합니다. 이 문제를 해결하려면 이 문서의 뒷부분에 설명되어 있는 회로 차단기를 구현하여, 오류 수 임계값에 도달할 경우 빠른 오류가 발생하도록 합니다.

  • 본질적으로 일시적일 수 있는 오류는 일반적입니다. 이 문서의 뒷부분에 설명되어 있는 재시도 패턴을 사용하여 이러한 오류를 처리합니다.

  • 호출자가 다른 매개 변수 또는 다른 경로를 사용하여 요청을 다시 시도함으로써 실패한 요청을 수정할 수도 있습니다.

  • 요청의 성공이 시나리오에 중요하지 않은 경우 간단한 생략을 사용하여 오류를 처리합니다.

  • 성공 메시지를 반환하고 나중에 리소스가 정상 상태로 돌아가면 처리하기 위해 실패한 요청을 큐에 넣어 오류를 처리할 수 있습니다.

  • 이전에 올발랐던 항목, 예를 들어 캐시된 자격 증명, 캐시의 오래된 데이터 등을 반환할 수 있습니다.

  • 거의 올바른 환경, 예를 들어 임시 액세스, 근사치로 계산된 값, 추측, noscript 등을 제공하여 일부 오류를 처리할 수 있습니다.

  • 오류를 throw하는 대신 다른 대안, 예를 들어 임의 값, 익명 권한, 기본 이미지 등을 제공할 수 있습니다.

일시적인 오류 처리 고려 사항

일시적인 오류 처리의 구현을 위한 몇 가지 주요 고려 사항이 있으며 이에 대해서는 다음 섹션에서 설명합니다.

  • 재시도 논리

    일시적인 오류 처리의 가장 간단한 형태는 실패한 작업을 다시 시도하는 것입니다. 상용 타사 서비스를 사용하는 경우 "재시도 논리"를 구현하면 이 문제가 흔히 해결됩니다.

    논리가 재시도되는 횟수를 디자인 단계에서 일반적으로 제한해야 한다는 것을 명심해야 합니다. 논리에서는 일반적으로 작업을 특정 횟수만큼 실행하려고 시도하고 오류가 계속되는 경우 오류를 등록하거나 보조 서비스 또는 워크플로를 활용합니다.

  • 지수 백오프

    일시적인 오류의 결과가 과부하로 인한 서비스의 제한 때문인 경우 서비스를 호출하려고 반복적으로 시도하면 제한이 연장되고 전체적인 가용성에 영향을 미치기만 합니다.

    제한을 방지하거나 줄이기 위해 서비스 호출량을 줄이는 것이 바람직한 경우가 많습니다. 일반적으로 이 작업은 결국 성공하거나 응용 프로그램에 정의된 오류 임계값에 도달할 때까지 첫 번째 오류 후 즉시 재시도하고 두 번째 오류 후 1초 기다렸다가 재시도하고 세 번째 오류 후 5초 기다렸다가 재시도하는 식으로 알고리즘 방식으로 수행됩니다.

    이 방법을 "지수 백오프"라고 합니다.

  • 멱등원

    연결된 서비스에 대한 핵심 가정은 연결된 서비스의 가용성이 100%일 수는 없으며 재시도 논리를 사용한 일시적인 오류 처리가 핵심 구현 방법이라는 것입니다. 재시도 논리가 구현되는 경우 동일한 메시지가 두 번 이상 전송되거나 메시지가 순서에 맞지 않게 전송될 가능성이 있습니다.

    동일한 메시지를 여러 번 보내도 데이터 저장소가 예기치 않은 상태가 되거나 오염되지 않도록 작업을 멱등원이 되도록 디자인해야 합니다.

    예를 들어 모든 요청에서 데이터를 삽입하면 서비스 작업이 여러 번 호출되는 경우 여러 레코드가 추가될 수 있습니다. 다른 방법은 지능형 'upsert'로 코드를 구현하는 것입니다. 타임스탬프 또는 전역 식별자를 사용하여 새 메시지와 이전에 처리된 메시지를 식별하여 새 메시지만 데이터베이스에 삽입하고 메시지가 이전에 받은 것보다 최신인 경우 기존 레코드를 업데이트할 수 있습니다.

  • 보정 동작

    멱등원뿐만 아니라 고려할 또 다른 영역은 보정 동작이라는 개념입니다. 연결된 시스템이 계속 증가하고 복합 서비스가 등장하는 세계에서 보정 동작을 처리하는 방법을 이해하는 것은 매우 중요합니다.

    기간 업무(LOB) 응용 프로그램의 많은 개발자에게 트랜잭션 개념은 새로운 것이 아니지만 로컬 데이터 기술 및 관련 코드 라이브러리가 노출하는 트랜잭션 기능에 한정된 경우가 많습니다. 클라우드 측면에서 트랜잭션 개념을 살펴볼 때는 분산 서비스의 오케스트레이션과 관련된 새로운 고려를 해야 합니다.

    서비스 오케스트레이션은 여러 분산 시스템에 걸쳐 있을 수 있으며 오래 실행되고 상태 저장일 수 있습니다. 오케스트레이션 자체는 거의 동기가 아니며 여러 시스템에 걸쳐 있을 수 있고 비즈니스 시나리오에 따라 몇 초에서 몇 년에 이를 수 있습니다.

    공급망 시나리오에서는 25개 조직을 동일한 작업 활동에 함께 결합할 수 있습니다. 예를 들어 하나 이상의 서비스 오케스트레이션에서 상호 연결된 25개 이상의 시스템 집합이 있을 수 있습니다.

    성공이 발생하면 활동이 성공했음을 25개 시스템이 인식해야 합니다. 활동의 각 연결 지점에 대해 참가자 시스템은 다른 시스템에서 받는 메시지에 대한 상관 관계 ID를 제공할 수 있습니다. 활동의 유형에 따라 해당 상관 관계 ID를 수신한 당사자는 트랜잭션이 개념적으로 완료되었음을 받아들일 수 있습니다. 다른 경우에는 모든 25개 당사자의 상호 작용이 완료될 때 확인 메시지가 모든 당사자에게 전송될 수 있습니다(단일 서비스에서 직접 또는 각 시스템의 특정 오케스트레이션 상호 작용 지점을 통해).

    복합 및/또는 분산 활동에서 오류를 처리하기 위해 각 서비스는 고유 식별자에 따라 지정된 트랜잭션을 취소하는 요청을 받기 위해 서비스 인터페이스 및 작업을 노출합니다. 서비스 외관 뒤에서 이 활동의 취소를 보정하기 위한 워크플로가 설정됩니다. 이상적으로 이러한 워크플로는 자동화된 절차이지만 수동으로 해결하도록 조직의 담당자에게 라우팅하는 것처럼 간단할 수도 있습니다.

회로 차단기는 전류가 현재 한도를 초과하는 경우 전류의 흐름을 자동으로 중단하는 스위치입니다. 회로 차단기는 회로를 통한 과도한 전류가 위험할 수 있는 경우 안전 조치로 가장 흔히 사용됩니다. 퓨즈와 달리 회로 차단기는 재설정하고 다시 사용할 수 있습니다.

동일한 패턴을 소프트웨어 디자인에 적용할 수 있으며 특히 가용성과 복원력이 주요 고려 사항인 서비스에 적용 가능합니다.

리소스를 사용할 수 없는 경우 소프트웨어 회로 차단기를 구현하면 적절한 작업으로 대응할 수 있습니다.

회로 차단기의 상태는 닫힘, 열림 및 반 열림 이렇게 3가지입니다.

닫힘 상태는 응용 프로그램 또는 서비스의 정상적인 상태입니다. 닫힘 상태일 때 요청은 표준 경로를 통해 라우팅됩니다. 카운터는 실패율을 추적하고 임계값에 대해 평가합니다. 실패율이 임계값을 벗어나면 회로 차단기가 열림 상태로 변경됩니다. 데이터베이스 리소스에 대한 호출이 연결을 연속해서 100번 시도한 후 실패한 경우 데이터베이스 호출을 계속할 가치가 거의 없습니다. 회로 차단기는 이 임계값에서 트리거될 수 있으며 적절한 작업이 수행될 수 있습니다.

열림 상태일 때 회로 차단기는 요청을 완화 경로로 라우팅합니다. 이는 빠른 오류이거나 다른 형태의 정상적인 저하일 수 있습니다. 열림 상태로 전환될 때 회로 차단기는 타이머도 시작합니다. 타이머가 만료되면 회로 차단기가 반 열림 상태로 전환됩니다.

반 열림 상태에서는 정상 경로를 통해 제한된 수의 요청을 라우팅하기 시작합니다. 이러한 작업에 성공하면 회로 차단기가 닫힘 상태로 전환됩니다. 이 제한된 수의 요청이 실패하면 회로 차단기가 열림 상태로 돌아갑니다.

아키텍처에 회로 차단기 패턴을 포함할 때 다음을 고려하세요.

  • 회로 차단기는 열림 상태일 때 작업에서 throw된 예외 유형에 따라 다양한 완화 또는 다양한 시간을 호출할 수 있습니다.

  • 회로 차단기는 모든 전환 상태를 기록해야 합니다. 그러면 운영자가 전환 동작을 모니터링하고 타이머를 미세 조정하여 열림 상태가 길어지는 것 또는 열림 상태와 반 열림 상태 간의 빈번한 변동을 방지할 수 있습니다.

  • 타이머를 사용하여 열림 상태에서 반 열림 상태로 전환하는 대신 회로 차단기는 주기적으로 표준 경로를 테스트하여 표준 경로가 다시 정상 상태가 되었는지 확인할 수 있습니다.

  • 여러 분할로 이어지는 작업을 처리할 때는 회로 차단기 사용에 주의하세요. 여기서 문제는 상태가 분할 수준에 있을 수 있어 다음과 같은 바람직하지 않은 두 가지 시나리오가 발생할 수 있다는 것입니다.

    • 하나의 분할만 실패할 때 열림 상태로 이동합니다.

    • 하나 이상의 분할이 정상 상태일 때 실수로 닫힘 상태로 이동합니다.

이 패턴의 일반적인 구현은 데이터베이스 또는 데이터 서비스의 액세스와 관련되어 있습니다. 활동의 설정된 유형 및 수준에서 오류가 발생하면 회로 차단기가 반응합니다. 데이터가 관련된 경우 이는 일반적으로 데이터베이스 또는 해당 데이터베이스 앞의 데이터 서비스에 연결하지 못하기 때문에 발생합니다.

데이터베이스 리소스에 대한 호출이 연결을 연속해서 100번 시도한 후 실패한 경우 데이터베이스 호출을 계속할 가치가 거의 없습니다. 회로 차단기는 이 임계값에서 트리거될 수 있으며 적절한 작업이 수행될 수 있습니다.

특히 데이터 서비스에 연결할 때와 같은 경우에는 지정된 기간 내에 허용되는 호출의 횟수를 초과하는 클라이언트에 따른 제한의 결과로 회로 차단기가 트리거될 수도 있습니다. 회로 차단기는 연결이 성공적으로 설정되고 허용 수준을 충족할 때까지 호출 간에 지연을 삽입할 수 있습니다.

다른 경우에는 데이터 저장소를 사용하지 못할 수 있습니다. 데이터의 중복 복사본을 사용할 수 있는 경우 시스템은 해당 복제본으로 장애 조치될 수 있습니다. 실제 복제본을 사용할 수 없거나 데이터베이스 서비스가 공급자 내의 모든 데이터 센터에서 광범위하게 작동하지 않는 경우 보조 방법을 사용할 수 있습니다. 여기에는 대체 데이터 서비스 공급자를 통해 요청된 데이터의 버전을 데이터의 원본으로 사용하는 것이 포함될 수 있습니다. 이 대체 원본은 캐시, 현재 클라우드 공급자의 대체 영구 데이터 저장소 유형, 별도의 클라우드 공급자 또는 온-프레미스 데이터 센터에서 제공될 수 있습니다. 이러한 대체 원본을 사용할 수 없는 경우 클라이언트가 적절하게 처리할 수 있는 인식 가능한 오류를 서비스에서 반환할 수도 있습니다.

회로 차단기 예: Netflix

미디어 스트리밍 회사인 Netflix는 복원력 있는 아키텍처의 훌륭한 예로 흔히 제시됩니다. Netflix에서 회로 차단 패턴을 논할 때 Netflix 팀은 Netflix Tech Blog에서 회로 차단기에 포함된 몇 가지 조건을 요구합니다. 이러한 조건은 다음과 같습니다.

  1. 원격 서비스 요청 시간이 제한됩니다.

  2. 서비스 종속성과 상호 작용하는 데 사용되는 스레드 풀과 바인딩된 작업 큐의 용량을 100% 사용할 수 있습니다.

  3. 서비스 종속성과 상호 작용하는 데 사용되는 클라이언트 라이브러리가 예외를 throw합니다.

이러한 조건 모두 전체적인 오류율에 기여합니다. 오류율이 정의된 임계값을 초과하면 회로 차단기가 "시동"되고 해당 서비스의 회로가 원격 서비스에 연결하려고 시도하지도 않고 대체를 즉시 수행합니다.

같은 블로그 항목에서 Netflix 팀은 각 서비스의 회로 차단기가 다음 세 방법 중 하나를 사용하여 대체를 구현한다고 밝힙니다.

  1. 사용자 지정 대체 - 서비스 클라이언트 라이브러리가 호출 가능한 대체 메서드를 제공하거나 API 서버에서 로컬로 사용할 수 있는 데이터(예: 쿠키 또는 로컬 캐시)가 대체 응답을 생성하는 데 사용됩니다.

  2. 자동 실패 - 메서드가 요청하는 클라이언트에 null 값을 반환합니다. 요청되는 데이터가 선택 항목인 경우 클라이언트는 잘 작동합니다.

  3. 빠른 오류 - 데이터가 필요하거나 효과적인 대체를 사용할 수 없는 경우 5xx 응답이 클라이언트에 반환됩니다. 이 방법은 API 서버의 상태를 정상으로 유지하고 영향을 받는 서비스가 온라인 상태로 돌아올 때 신속한 복구를 가능하게 하는 데 중점을 두지만 클라이언트 UX에 부정적인 영향을 미치는 단점이 있습니다.

SLA를 적용하기 위해 조직은 데이터 서비스에서 두 가지 범주의 이상값인 신뢰할 수 있는 당사자와 믿지 못할 자를 다루는 방법을 처리해야 합니다.

신뢰할 수 있는 당사자 및 허용 목록 작성

신뢰할 수 있는 당사자는 해당 조직이 특별한 합의를 할 수 있는 조직이며 표준 SLA에 대한 특정 예외를 만들 수 있는 대상입니다.

  • 사용자 지정 계약을 맺은 타사

    특별한 가격 조건 또는 정책을 협상하고자 하는 서비스의 사용자가 있을 수 있습니다. 데이터 서비스에 대한 대량 호출이 특별한 가격을 보증할 수 있는 경우도 있고, 주어진 데이터 서비스에 대한 수요가 표준 사용 계층에 지정된 양을 초과할 수 있는 경우도 있습니다. 이러한 고객은 믿지 못할 자로 잘못 지정되는 것을 방지하기 위해 신뢰할 수 있는 당사자로 정의되어야 합니다.

  • 허용 목록 작성

    신뢰할 수 있는 당사자를 처리하는 일반적인 방법은 허용 목록을 설정하는 것입니다. 신뢰할 수 있는 당사자의 목록을 식별하는 허용 목록은 고객 사용을 처리할 때 적용할 비즈니스 규칙을 결정할 때 서비스에서 사용됩니다. 허용 목록 작성은 일반적으로 IP 주소 범위 또는 API 키의 권한을 부여하여 수행됩니다.

    소비 정책을 설정할 때 조직은 허용 목록 작성이 지원되는지 여부, 고객이 허용 목록에 포함되도록 지원하는 방법, 고객을 허용 목록에 추가하는 방법 및 고객이 허용 목록에서 제거되는 조건을 확인해야 합니다.

  • 믿지 못할 자 처리

    신뢰할 수 있는 당사자가 고객 스펙트럼의 한쪽 끝을 나타낸다고 할 때 반대쪽 끝에 있는 그룹을 "믿지 못할 자"라고 합니다. 믿지 못할 자는 일반적으로 "과도한 소비"를 시도하여 서비스에 부담을 줍니다. 이러한 잘못된 동작이 순전히 우발적으로 발생하는 경우도 있지만, 의도적인 경우도 있으며 몇몇 상황에서는 악의적인 경우도 있습니다. 이러한 자에게는 "믿지 못함"이라는 꼬리표가 붙는데 그의 행동이 의도적이든 그렇지 않든 간에 하나 이상의 서비스에 대한 가용성에 영향을 미칠 수 있기 때문입니다.

    믿지 못할 자에 대한 부담으로 인해 데이터 서비스 공급자는 불필요한 비용을 떠안을 수 있으며, 사용 조건을 충실히 따르고 SLA에 명시된 대로 서비스에 대한 합리적인 기대를 하고 있는 소비자는 액세스 시 어려움을 겪을 수 있습니다. 따라서 믿지 못할 자는 미리 정해진 일관된 방식으로 처리되어야 합니다. 믿지 못할 자에 대한 일반적인 반응은 제한과 차단 목록 작성입니다.

  • 조정

    조직은 데이터 서비스 소비자의 사용 급증을 처리하기 위한 전략을 정의해야 합니다. 소비자의 트래픽이 크게 급증하면 데이터 서비스에 예기치 않은 부하가 발생할 수 있습니다. 이러한 급증이 발생하면 조직은 특정 기간 동안 해당 소비자의 액세스를 제한하려고 할 수 있습니다. 이 경우 서비스는 1분, 5분, 10분 등의 특정 기간 동안 해당 소비자의 모든 요청을 거부합니다. 이 기간 동안 대상 소비자가 서비스 요청을 하면 과도한 사용으로 인해 제한되고 있음을 알리는 오류 메시지가 표시됩니다.

    요청을 하는 대상 소비자는 그의 행동을 변경하는 등, 적절하게 대응할 수 있습니다.

    조직은 제한을 구현하고 관련된 비즈니스 규칙을 설정할지 여부를 결정해야 합니다. 소비자가 제한될 수 있다고 결정하는 경우 조직은 제한 응답을 트리거할 동작도 결정해야 합니다.

  • 차단 목록 작성

    제한으로 믿지 못할 자의 동작이 처리되어야 하지만 항상 성공하지는 못할 수도 있습니다. 성공하지 못하는 경우 조직은 소비자를 추방하려고 할 수 있습니다. 허용 목록과 상반되는 차단 목록은 서비스에 대한 액세스가 금지되는 소비자를 식별합니다. 서비스는 차단 목록에 포함된 고객의 액세스 요청에 데이터 서비스 리소스의 사용을 최소화하는 방식으로 적절하게 응답합니다.

    차단 목록 작성은 허용 목록 작성과 마찬가지로 API 키 또는 IP 주소 범위를 사용하여 일반적으로 수행됩니다.

    소비 정책을 설정할 때 조직은 차단 목록에 소비자를 포함할 동작, 차단 목록 작성에 이의를 제기하는 방법 및 소비자가 차단 목록에서 제거되는 방법을 지정해야 합니다.

사람은 실수를 하기 마련입니다. 예기치 않은 결과를 발생시킬 수 있는 코드 변경을 하는 개발자이든, 데이터베이스의 테이블을 실수로 삭제하는 DBA이든, 변경만 하고 문서화하지 않는 운영자이든 간에 사람이 실수로 서비스의 복원력을 저하시킬 수 있는 기회는 다양하게 존재합니다.

사람의 오류를 줄이기 위한 논리적인 접근법은 프로세스에서 사람이 차지하는 부분을 줄이는 것입니다. 자동화의 도입을 통해 서비스를 위태롭게 하는, 예상된 동작에서 벗어난 우연한 임시 델타의 능력을 제한할 수 있습니다.

DevOps 커뮤니티에는 “모든 것을 자동화하라!”고 말하는 만화 캐릭터가 문화적 요소로 등장합니다. 클라우드에서 대부분의 서비스는 API를 통해 노출됩니다. 개발 도구에서 가상 인프라, 플랫폼 서비스, SaaS(Software as a Service)로 제공되는 솔루션에 이르기까지 대부분의 것은 스크립팅할 수 있습니다.

스크립팅은 매우 권장되는 방법입니다. 스크립팅은 배포와 관리를 일관성 있고 예측 가능하게 만들고 투자에 상당한 이익을 제공합니다.

배포 자동화

자동화의 핵심 영역 중 하나는 솔루션의 구축 및 배포입니다. 자동화를 통해 개발자 팀은 손쉽게 테스트하고 여러 환경에 배포할 수 있습니다. 개발, 테스트, 준비, 베타 및 프로덕션은 모두 자동화된 빌드를 통해 손쉽고 일관성 있게 배포될 수 있습니다. 여러 환경에 일관성 있게 배포하는 능력은 프로덕션에 있는 것이 테스트된 것을 나타내도록 하는 데 도움이 됩니다.

배포 관련 스크립트, 구성 파일 및 메타데이터를 "코드"로 간주합니다. 또한 코드에는 소스 제어에서 다음을 위한 이러한 아티팩트의 관리도 포함됩니다.

  • 변경 내용 문서화

  • 버전 관리 허용

  • 역할 기반 액세스 제어 제공

  • 콘텐츠 백업 보장

  • SSOT(Single Source of Truth) 제공

테스트 도구 설정 및 자동화

테스트는 자동화할 수 있는 또 다른 영역입니다. 자동화된 배포와 마찬가지로, 자동화된 테스트 설정은 시스템이 복원력을 갖추고 시간이 흐름에 따라 복원력을 유지하도록 하는 데 중요합니다. 서비스의 코드와 사용이 발전함에 따라 기능적으로뿐만 아니라 전체적인 차원에서도 모든 적절한 테스트가 수행되도록 유지하는 것이 중요합니다.

데이터 보관 및 제거 자동화

주의를 끌지 못하는 영역 중 하나가 데이터 보관 및 제거입니다. 데이터 볼륨은 커지고 있고 이전 어느 때보다도 다양한 형태로 계속해서 커지고 있습니다. 데이터베이스 기술과 필요한 쿼리 유형에 따라 불필요한 데이터는 시스템의 응답 시간을 줄이고 비용을 불필요하게 증가시킬 수 있습니다. 데이터 저장소의 복제본을 하나 이상 포함하는 복원력 계획의 경우 필요한 데이터를 제외하고 모두 제거하면 데이터 백업 및 복원과 같은 관리 활동이 촉진될 수 있습니다.

핵심 기능에 필요한 데이터, 규정 준수를 위해 필요하지만 보관될 수 있는 데이터 및 더 이상 필요하지 않으며 제거될 수 있는 데이터와 관련된 솔루션에 대한 요구 사항을 식별해야 합니다.

관련 제품 및 서비스에서 사용할 수 있는 API를 활용하여 이러한 요구 사항의 구현을 자동화할 수 있습니다.

복원력 있는 아키텍처를 구축하는 경우 오류 도메인과 업그레이드 도메인의 개념도 이해해야 합니다.

오류 도메인

오류 도메인은 알려진 하드웨어 경계와 특정 유형의 중단이 컴퓨터 집합에 영향을 미칠 가능성에 따라 서비스의 배치를 제한합니다. 오류 도메인은 동시에 오류가 발생할 수 있으며 대개 물리적 속성으로 정의되는 일련의 컴퓨터(컴퓨터의 특정 랙, 동일한 전원을 공유하는 일련의 컴퓨터 등)로 정의됩니다.

업그레이드 도메인

업그레이드 도메인은 오류 도메인과 유사합니다. 업그레이드 도메인은 시스템에서 동시에 업데이트되는 서비스의 물리적 집합을 정의합니다. 클라우드 공급자에 있는 부하 분산 장치는 특정 도메인이 업데이트되고 있는 경우 전체 시스템이 부하가 분산된 상태로 유지되고 서비스를 계속 사용할 수 있도록 하기 위해 업그레이드 도메인을 인식해야 합니다.

업그레이드는 다음에서 발생할 수 있습니다.

  • 하이퍼바이저 수준(“호스트 OS 업그레이드”)

  • 운영 체제 수준(“게스트 OS 업그레이드”)

  • 환경에 응용 프로그램 또는 서비스 업그레이드를 배포한 결과

클라우드 공급자와 사용되는 플랫폼 서비스에 따라 오류 도메인과 업그레이드 도메인은 자동으로 제공될 수 있거나, API를 통해 서비스에서 옵트인(opt in)할 수 있는 것이거나, 자사 또는 타사 솔루션을 필요로 할 수 있습니다.

업그레이드 중 장애 도메인 오류에서의 복원력

장애 도메인과 업그레이드 도메인은 서로 다르지만 두 도메인이 교차하는 시나리오가 있습니다. 이 시나리오에서 하드웨어 장애는 가상 컴퓨터를 오프라인 상태로 만들지만 업그레이드는 동시에 다른 VM 인스턴스에서 이루어집니다. 이 경우 두 대의 VM이 오프라인 상태가 됩니다. 서비스 배포에 가상 컴퓨터가 두 대만 포함된 경우 서비스가 오프라인 상태가 됩니다. 원하는 SLA를 제공해야 하는 인스턴스 수를 평가할 때 이러한 사실을 고려하세요.

클라우드 플랫폼은 흔히 리소스 그룹에 대한 선호도 수준을 식별하는 기능을 제공합니다. 이러한 리소스를 “선호도 그룹” 또는 “선호도 집합”이라고 합니다. 선호도 그룹은 기본 플랫폼이 관련 리소스를 함께 배치하고 장애 도메인 및 업그레이드 도메인 전체에 인스턴스를 할당하는 데 도움이 됩니다.

온-프레미스 솔루션은 가용성과 확장성의 이점을 얻기 위해 중복에 흔히 의존하고 있습니다. 가용성 관점에서 중복 데이터 센터는 특정 데이터 센터나 데이터 센터의 일부분에서 인프라 오류가 발생할 때 비즈니스 연속성의 가능성을 높일 수 있도록 합니다.

소비자가 지리적으로 분산되어 있는 응용 프로그램의 경우 트래픽 관리와 중복 구현을 통해 흔히 지연 시간이 단축되어 사용자가 로컬 리소스로 라우팅됩니다.

note참고
중복을 포함하는 데이터 복원력은 데이터 복원력 접근법 설정이라는 섹션에서 별도의 항목으로 다룹니다.

중복 및 클라우드

지금까지 온-프레미스 중복은 하드웨어, 소프트웨어 및 네트워킹의 중복 집합을 통해 달성되었습니다. 때때로 온-프레미스 중복은 단일 위치 또는 여러 데이터 센터에 분산된 클러스터에 구현됩니다.

클라우드에 대한 전략을 고안할 때 세 가지 방향에서 중복이 필요한 근거를 확보해야 합니다. 이러한 방향에는 클라우드 공급자 환경 내의 배포된 코드, 공급자 자체의 중복, 클라우드 및 온-프레미스 간의 중복이 포함됩니다.

배포 중복

조직이 클라우드 공급자를 선택했으면 해당 공급자 내의 배포에 대한 중복 전략을 설정해야 합니다.

PaaS(Platform as a Service)로 배포하는 경우 이 작업의 상당 부분이 기본 플랫폼에서 처리될 수 있지만 IaaS(Infrastructure as a Service) 모델에서는 그렇지 않습니다.

  • 데이터 센터에 n개의 역할 배포

    가장 간단한 형태의 중복은 솔루션을 단일 클라우드 공급자 내의 여러 인스턴스에 배포하는 것입니다. 여러 인스턴스에 배포하여 솔루션은 단일 노드를 배치한 경우 발생하는 가동 중지 시간을 제한할 수 있습니다.

    많은 PaaS(Platform as a Service) 환경에서 코드를 호스팅하는 가상 컴퓨터의 상태가 모니터링되고 비정상 상태인 것으로 감지된 가상 컴퓨터가 자동으로 정상 노드로 대체될 수 있습니다.

  • 여러 데이터 센터에 배포

    단일 데이터 센터에 여러 노드를 배포하면 혜택을 얻을 수 있지만 전체 데이터 센터를 잠재적으로 사용하지 못할 수도 있음을 아키텍처에서 고려해야 합니다. 일반적인 경우는 아니지만 자연 재해, 전쟁 등으로 인해 특정 지리적 위치에서 서비스 중단이 발생할 수 있습니다.

    SLA를 충족하기 위해 선택한 클라우드 공급자의 여러 데이터 센터에 솔루션을 배포하는 것이 적합할 수 있습니다. 이를 위한 몇 가지 방법이 아래에 나와 있습니다.

    1. 여러 데이터 센터의 완전한 중복 배포

      첫 번째 옵션은 트래픽 관리 공급자와 함께 수행되는 여러 데이터 센터의 완전한 중복 솔루션입니다. 이 방법에 대한 주요 고려 사항은 이러한 유형의 중복에 대한 계산 관련 비용에 영향을 미칩니다. 이 비용은 추가 데이터 센터 배포마다 100%씩 증가합니다.

    2. 장애 조치를 위한 보조 데이터 센터의 부분 배포

      또 다른 방법은 규모가 축소된 보조 데이터 센터에 부분 배포를 수행하는 것입니다. 예를 들어 표준 구성에서 12개의 계산 인스턴스를 사용한 경우 보조 데이터 센터는 6개의 계산 인스턴스가 포함된 하나의 배포를 포함하게 됩니다.

      트래픽 관리와 함께 수행되는 이 방법은 기본 센터에만 영향을 미친 사건 후 저하된 서비스로 비즈니스 연속성을 허용합니다.

      데이터 센터가 전체적으로 오프라인 상태가 되는 횟수가 제한되어 있으므로 이는 계산에 대한 비용 효과적인 방법으로 간주되며, 조직이 보조 데이터 센터에 새 인스턴스를 손쉽게 탑재할 수 있도록 하는 플랫폼의 경우에는 특히 그렇습니다.

    3. 백업 노드를 사용하는 여러 데이터 센터에 분할된 배포

      특히 금융 서비스 부문의 작업을 비롯한 특정 작업의 경우 고정된 짧은 기간 내에 처리되어야 하는 상당한 양의 데이터가 있습니다. 이러한 상황에서 작업은 단기간의 급증 형태로 수행되며 중복 비용은 해당 기간 내에 결과를 제공하기 위해 정당화됩니다.

      이러한 경우에 코드는 여러 데이터 센터에 배포됩니다. 작업은 분할되고 처리를 위해 여러 노드에 분산됩니다. 데이터 센터를 사용할 수 없게 되는 경우에 해당 노드를 대상으로 하는 작업이 백업 노드로 전달되고 백업 노드에서 작업을 완료하게 됩니다.

    4. 데이터 센터별로 지역에 적절한 규모의 여러 데이터 센터 배포

      이 방법에서는 여러 데이터 센터에 있지만 지역과 관련된 대상의 규모에 따라 적절하게 크기가 지정된 중복 배포를 사용합니다.

공급자 중복

데이터 센터 중심 중복이 유용하지만 SLA는 데이터 센터 수준에 적용되는 것이 아니라 서비스 수준에 적용되는 것입니다. 현재 많은 상용 서비스에서는 새 버전을 프로덕션 환경의 한 “조각”에 배포하여 프로덕션 환경에서 코드의 유효성을 검사합니다. 그러나 공급자가 제공하는 서비스가 여러 데이터 센터 또는 모든 데이터 센터에서 사용할 수 없게 될 가능성도 있습니다.

솔루션에 대한 SLA에 따라 공급자 중복도 통합하는 것이 바람직할 수 있습니다. 이를 실현하려면 여러 클라우드 플랫폼에서 작동할 클라우드 배포 가능 제품이나 클라우드 서비스가 파악되어야 합니다. 예를 들어 Microsoft SQL Server는 대부분의 공급업체에서 서비스 제품으로 인프라 내의 가상 컴퓨터에 배포할 수 있습니다.

클라우드 제공 서비스의 경우 계산, 저장소, 큐 등과 같은 핵심 서비스의 경우에도 표준 인터페이스가 설정되어 있지 않기 때문에 이 작업이 좀 더 어렵습니다. 공급자 중복이 이러한 서비스에 바람직한 경우 대개 추상 계층을 통해서만 구현할 수 있습니다. 추상 계층이 솔루션에 충분한 기능을 제공할 수는 있지만 기본 서비스만큼 빠르게 혁신이 이루어지는 것은 아니며 공급자가 제공하는 새로운 기능을 조직에서 즉시 채택하는 데 장애가 될 수 있습니다.

중복 공급자 서비스가 정당화될 수 있는 경우 전체 응용 프로그램, 작업 또는 작업의 한 측면과 같은 몇 가지 수준 중 하나에서 정당화될 수 있습니다. 적절한 수준에서 계산, 데이터 및 플랫폼 서비스에 대한 수요를 평가하고 실제로 중복되어야 하는 것과 정상적인 저하를 제공하는 방법을 통해 처리될 수 있는 것을 결정해야 합니다.

온-프레미스 중복

클라우드 공급자에 의존하는 경우 경제적으로 도움이 될 수 있지만 규정 준수 및/또는 비즈니스 연속성을 위해 온-프레미스 중복이 필요한 특정 비즈니스 고려 사항이 있을 수 있습니다.

솔루션에 대한 SLA에 따라 온-프레미스 중복도 통합하는 것이 바람직할 수 있습니다. 이를 실현하려면 여러 클라우드 유형에서 작동할 사설 클라우드 배포 가능 제품이나 클라우드 서비스가 파악되어야 합니다. 공급자 중복의 경우와 마찬가지로 Microsoft SQL Server는 온-프레미스로 배포되거나 IaaS 서비스로 배포될 수 있는 제품의 훌륭한 예입니다.

클라우드 제공 서비스의 경우 인터페이스 및 대칭 기능에 해당하는 온-프레미스 항목이 대개 없으므로 이 작업은 좀 더 어렵습니다.

중복 공급자 서비스가 온-프레미스에 필요한 경우 전체 응용 프로그램, 작업 또는 작업의 한 측면과 같은 몇 가지 수준 중 하나에서 필요할 수 있습니다. 적절한 수준에서 계산, 데이터 및 플랫폼 서비스에 대한 수요를 평가하고 실제로 중복되어야 하는 것과 정상적인 저하를 제공하는 방법을 통해 처리될 수 있는 것을 결정해야 합니다.

중복 구성 방법

중복 구성 방법을 파악할 때 클라우드 이전에 존재한 분류도 적용됩니다. 솔루션에서 사용되는 서비스의 유형에 따라 이 중 일부는 기본 플랫폼에서 자동으로 처리될 수 있으며, Windows Fabric과 같은 기술을 통해 처리되는 경우도 있습니다.

  1. 활성/활성 — 실패한 노드를 대상으로 하는 트래픽이 기존 노드로 전달되거나 나머지 노드로 부하가 분산됩니다. 이 방법은 일반적으로 노드에서 유형이 같은 소프트웨어 구성을 사용하는 경우에만 가능합니다.

  2. 활성/수동 — 각 노드의 완전히 중복된 인스턴스를 제공합니다. 이 인스턴스는 연결된 기본 노드가 실패한 경우에만 온라인 상태가 됩니다. 일반적으로 이 구성에는 가장 많은 추가 하드웨어가 필요합니다.

  3. N+1 — 실패한 노드의 역할을 수행하기 위해 온라인 상태로 전환되는 추가 노드를 하나만 제공합니다. 각 기본 노드에 있는 소프트웨어 구성의 유형이 다른 경우 추가 노드는 담당하는 기본 노드의 모든 역할을 일반적으로 수행할 수 있어야 합니다. 이는 여러 서비스가 동시에 실행되고 있는 클러스터를 일반적으로 나타냅니다. 단일 서비스의 경우 이 구성은 활성/수동이 됩니다.

  4. N+M — 단일 클러스터가 여러 서비스를 관리하고 있는 경우 전용 장애 조치 노드가 하나만 있으면 충분한 중복이 제공되지 않을 수 있습니다. 이러한 경우 둘 이상(M)의 대기 서버가 포함되고 사용 가능합니다. 대기 서버의 수는 비용과 안정성 요구 사항을 절충하여 정됩니다.

  5. N 대 1 — 원래 노드가 복원되거나 다시 온라인 상태가 될 때까지 장애 조치 대기 노드가 일시적으로 활성 노드가 될 수 있도록 합니다. 이때 서비스나 인스턴스가 고가용성을 복원하기 위해 이 노드로 장애 복구되어야 합니다.

  6. N 대 N — 활성/활성과 N+M의 조합인 N 대 N은 실패한 노드의 서비스, 인스턴스 또는 연결을 나머지 활성 노드로 다시 분산시키므로 활성/활성의 경우와 마찬가지로 '대기' 노드는 필요하지 않지만 모든 활성 노드에서 추가 용량이 필요합니다.

트래픽이 비즈니스 연속성 시나리오를 충족시키기 위해 항상 지리적으로 분산되든 다른 데이터 센터로 라우팅되든 간에 트래픽 관리 기능은 솔루션에 대한 요청이 적절한 인스턴스로 라우팅되도록 하는 데 중요합니다.

트래픽 관리 서비스에 의존하는 경우 단일 실패 지점이 생성되는 것에 유의해야 합니다. 응용 프로그램의 기본 트래픽 관리 서비스에 대한 SLA를 검토하고 대체 트래픽 관리 기능이 요구 사항으로 보증되는지 확인해야 합니다.

확장성이 높은 많은 클라우드 응용 프로그램이 웹 계층 분할은 훌륭하게 수행했지만 클라우드에서 데이터 계층을 확장하는 데는 그리 성공적이지 못합니다. 연결된 장치의 다양성이 계속 증가하는 상황에서 생성되고 쿼리되는 데이터의 수준은 지금까지 볼 수 없었던 수준으로 증가하고 있습니다. 예를 들어 매일 500,000명의 새로운 사용자를 지원할 수 있어야 하는 필요성이 지금은 적당한 것으로 간주됩니다.

분할 전략을 수립하는 것은 해당 데이터의 저장, 쿼리 또는 유지 관리를 비롯한 여러 차원에서 매우 중요합니다.

분해 및 분할

여러 가지 기술의 장점과 단점 때문에 주어진 작업에 가장 최적인 기술을 활용하는 것이 일반적입니다.

작업에 따라 솔루션을 분해하면 주어진 작업에 최적인 데이터 기술을 선택할 수 있습니다. 예를 들어 웹 사이트에서는 개인의 콘텐츠용으로 테이블 저장소를 사용할 수 있으며 응답 경험을 위해 사용자 수준에서 파티션을 사용할 수 있습니다. 이러한 테이블 행은 보고와 분석을 위해 주기적으로 관계형 데이터베이스로 집계될 수 있습니다.

분할 전략은 선택한 기술에 따라 달라질 수 있으며 그렇게 되는 경우가 많습니다.

전략을 정의할 때는 수정된 전략이나 병렬 전략이 필요할 수 있는 이상값을 식별하는 것도 중요합니다. 예를 들어 소셜 네트워킹 사이트를 개발 중인 경우 일반적인 사용자의 연결 수는 500개 정도지만 유명인의 연결 수는 5백 만개에 달할 수 있습니다.

사이트에서 1억 명의 사용자를 예상하고 유명인은 5만 명 미만이 될 것으로 예상하는 경우 핵심 분할 전략은 일반적인 사용자에 대해 최적화됩니다. 유명인은 다르게 관리할 것입니다. 즉, 다수의 사용자를 단일 분할로 그룹화하고 유명인은 고유한 분할에 할당할 수 있습니다.

3 V 이해

조직에서 분할 전략을 적절하게 수립하려면 먼저 이해해야 합니다.

Gartner에 의해 널리 알려진 3 V는 데이터의 세 가지 측면을 살펴봅니다. 3 V가 데이터와 어떻게 관련되는지를 이해하면 분할 전략에 대한 합리적인 결정을 내리는 데 도움이 됩니다.

  • 볼륨

    볼륨은 데이터의 크기를 의미합니다. 볼륨은 분할 전략에 매우 실제적인 영향을 미칩니다. 특정 데이터 기술에 대한 볼륨 제한은 크기 제한, 볼륨에서의 쿼리 속도 등 때문에 강제로 분할을 적용할 수 있습니다.

  • 속도(Velocity)

    속도는 데이터가 증가하는 속도를 의미합니다. 느리게 증가하는 데이터 저장소와 매일 500,000명의 새로운 사용자를 수용해야 하는 데이터 저장소에 대해 서로 다른 분할 전략을 수립하려고 할 것입니다.

  • 다양성(Variety)

    다양성은 작업과 관련된 여러 가지 유형의 데이터를 의미합니다. 데이터가 관계형 데이터, 키-값 쌍, 소셜 미디어 프로필, 이미지, 오디오 파일 또는 비디오를 비롯한 어떤 유형이든 간에 데이터를 이해하는 것이 중요합니다. 이는 적절한 데이터 기술을 선택하고 분할 전략에 대한 합리적인 결정을 내리기 위해서입니다.

수평 분할

가장 널리 알려진 데이터 분할 방법은 수평으로 분할하는 방법일 것입니다. 수평으로 분할할 때 데이터 저장소를 여러 분할된 데이터베이스로 분할하는 기준에 대한 결정이 이루어집니다. 각 분할된 데이터베이스에는 적절한 분할된 데이터베이스에 데이터를 배치하는 기준과 함께 전체 스키마가 포함되어 있습니다.

데이터 유형과 데이터 사용에 따라 이 작업은 다른 방식으로 수행될 수 있습니다. 예를 들어 조직이 고객 이름을 기준으로 데이터를 분할하도록 선택할 수도 있습니다. 다른 경우에는 분할이 날짜 중심일 수 있으며 시, 일, 주 또는 월의 관련 간격에 분할될 수 있습니다.

행 분할 다이어그램

그림 5: 이름 기준 수평 분할의 예

수직 분할

또 다른 방법은 수직 분할합니다. 이 방법은 흔히 다양한 데이터에 연결되어 있는 여러 저장소에 데이터를 배치하는 작업을 최적화합니다. 그림 5에서는 고객에 대한 메타데이터가 한 저장소에 배치되고 축소판 이미지와 사진은 각기 다른 저장소에 배치되는 예를 보여 줍니다.

수직 분할은 데이터의 저장 및 배달을 최적화할 수 있습니다. 예를 들어 그림 5에서 사진이 고객을 위해 거의 표시되지 않는 경우 레코드당 3MB를 반환하면 사용량 기준 과금 방식의 모델에서 불필요한 비용이 추가될 수 있습니다.

수직 분할 다이어그램

그림 6: 수직 분할의 예

혼합 분할

대부분의 경우 혼합 분할 전략을 설정하는 것이 적절합니다. 이 방법은 단일 솔루션에서 수평 분할과 수직 분할의 효율성을 제공합니다.

그림 6에서는 혼합 분할의 예를 보여 줍니다. 여기에서 이전에 표시된 수직 분할은 이제 고객 메타데이터의 수평 분할을 이용하도록 확대되었습니다.

행 분할 다이어그램

그림 7: 혼합 분할의 예

클라우드 컴퓨팅의 핵심에는 네트워크가 있습니다. 네트워크는 장치가 서비스에 연결하고 서비스가 다른 서비스에 연결하기 위한 패브릭이나 백본을 제공하므로 매우 중요합니다. 모든 FailSafe 응용 프로그램에서 고려할 세 가지 네트워크 경계가 있습니다.

이러한 네트워크 경계에 대한 설명이 맥락을 제공하기 위한 예로 Azure를 사용하여 아래에 나와 있습니다.

  1. 역할 경계는 일반적으로 계층이라고 합니다. 일반적인 예는 웹 계층 또는 비즈니스 논리 계층입니다. Azure를 예로 살펴보자면, Azure는 최신 분산 응용 프로그램의 다중 계층 특성에 대한 인프라 지원을 제공하기 위해 핵심 디자인의 일부로 공식적으로 역할을 도입했습니다. Azure는 동일한 서비스에 속하는 역할 인스턴스가 단일 네트워크 환경의 범위 내에 호스트되고 단일 패브릭 컨트롤러에 의해 관리되도록 보장합니다.

  2. 서비스 경계는 다른 서비스에서 제공하는 기능에 대한 종속성을 나타냅니다. 일반적인 예는 관계형 데이터베이스 액세스를 위한 SQL 환경과 게시/구독 메시징 지원을 위한 Service Bus입니다. 예를 들어 Azure 내에서 서비스 경계는 네트워크를 통해 적용됩니다. 서비스 종속성이 동일한 네트워크 또는 패브릭 컨트롤러 환경의 일부라는 보장은 제공되지 않습니다. 그러한 경우도 있을 수 있지만 모든 담당 응용 프로그램에 대한 디자인 가정은 서비스 종속성이 각기 다른 패브릭 컨트롤러가 관리하는 서로 다른 네트워크에 있다는 것이어야 합니다.

    클라우드 서비스 역할 인스턴스 다이어그램
    그림 8

  3. 끝점 경계는 클라우드의 외부에 있습니다. 끝점 경계에는 일반적으로 서비스를 소비하기 위해 클라우드에 연결된 장치로 간주되는 소비하는 끝점이 포함됩니다. 네트워크의 가변적이고 신뢰할 수 없는 특성 때문에 디자인의 이 부분에서는 특별한 고려를 해야 합니다. 역할 경계와 서비스 경계는 클라우드 환경의 경계 내에 있고 특정 수준의 안정성과 대역폭을 가정할 수 있습니다. 외부 종속성의 경우 이러한 가정을 할 수 없으며 장치가 서비스(데이터 및 상호 작용)를 소비할 수 있으려면 추가 지원이 제공되어야 합니다.

    네트워크는 그 특성상 정보를 네트워크의 한 지점에서 다른 지점으로 전달할 때 대기 시간을 경험합니다. 사용자뿐만 아니라 종속 서비스 또는 역할에도 훌륭한 환경을 제공하기 위해 응용 프로그램 아키텍처 및 디자인에서는 가능한 한 대기 시간을 줄이고 피할 수 없는 대기 시간을 명시적으로 관리는 방법을 찾아야 합니다. 대기 시간을 줄이는 가장 일반적인 방법 중 하나는 네트워크와 관련된 서비스 호출을 피하는 것입니다. 데이터와 서비스에 대한 로컬 액세스는 대기 시간을 줄이고 응답 속도를 높이는 주요 방법입니다. 로컬 데이터 및 서비스를 사용하면 오류 보안의 또 다른 계층도 제공됩니다. 사용자나 응용 프로그램의 요청을 로컬 환경에서 처리할 수 있는 한 른 역할이나 서비스와 상호 작용할 필요가 없으므로 종속 구성 요소를 사용할 수 없는 것이 오류 지점이 될 가능성이 제거됩니다.

캐싱

캐싱은 데이터를 로컬로 저장할 수 없는 경우 데이터 액세스 속도를 높이는 데 사용할 수 있는 기법입니다. 캐싱은 오늘날 대규모로 운영되는 대부분의 클라우드 서비스에서 매우 효과적으로 활용됩니다. Wikipedia에서 제공하는 정의에 나와 있듯이 캐시는 응용 프로그램이 반복적으로 요청하는 데이터에 대한 로컬 액세스를 제공합니다. 캐싱은 다음 두 가지에 의존합니다.

  • 사용자와 종속 응용 프로그램에 의한 데이터의 사용 패턴이 주로 읽기 전용입니다. 전자 상거래 웹 사이트와 같은 특정 시나리오에서 읽기 전용 액세스(검색이라고도 함)의 비율은 사이트에서 이루어지는 모든 사용자 활동의 최대 95%를 차지합니다.

  • 응용 프로그램의 정보 모델은 캐싱에 최적인 안정적인 단일 데이터의 식별을 지원하는 의미 체계 정보의 추가 계층을 제공합니다.

장치 캐싱

FailSafe 이니셔티브의 초점은 아니지만 장치 캐싱은 모든 장치 + 서비스 응용 프로그램의 유용성과 견고성을 높이는 가장 효과적인 방법 중 하나입니다. 모든 표준 브라우저에서 구현된 네이티브 캐싱 기능을 제공하는 HTML5 사양에서 SQL Server Compact Edition과 같은 로컬 데이터베이스 인스턴스에 이르는 다양한 방법이 장치 또는 클라이언트 계층에서 캐싱 서비스를 제공하기 위해 존재합니다.

분산 캐싱

분산 캐싱은 강력한 기능 집합이지만 그 목적은 관계형 데이터베이스나 다른 영구 저장소를 대체하는 것이 아니라 특성상 네트워크 중심이므로 대기 시간에 민감한 분산 응용 프로그램의 응답 속도를 높이는 것입니다. 캐싱을 도입하는 경우의 부수적인 혜택은 영구 데이터 저장소에 대한 트래픽을 줄여 데이터 서비스와의 상호 작용을 최소화하는 것입니다.

  • 캐싱에 최적화된 정보 모델

    note참고
    이 섹션의 많은 내용이 Pat Helland가 서비스 지향 아키텍처 세계의 데이터에 대해 연구하던 때 작성한 훌륭한 문서를 기반으로 합니다. Microsoft Developer Network에서 전체 문서를 읽을 수 있습니다.

    캐시된 데이터는 그 특성상 안정적인 데이터입니다. 즉, 더 이상 최신일 필요가 없는 데이터입니다. 캐시된 데이터의 훌륭한 예는 매우 다른 도메인에서 제공되는 것이기는 하지만 수천 가구에 전송되는 제품 카탈로그입니다. 제품 카탈로그를 생성하는 데 사용된 데이터는 카탈로그가 만들어졌을 때는 최신 상태입니다. 하지만 인쇄가 진행되면 카탈로그 생산 과정 중에 경과되는 시간의 특성상 데이터는 유효하지 않게 됩니다. 캐시된 데이터가 유효하지 않게 되기 때문에 안정성과 특이성 측면에서 데이터의 특성은 캐싱 디자인에 매우 중요합니다.

    • 안정성 - 공간과 시간 차원에서 명확한 해석을 가진 데이터입니다. 일반적으로 변경되지 않는 데이터 값을 의미합니다. 예를 들어 대부분의 기업은 고객 ID 또는 SKU 번호를 절대로 재활용하지 않습니다. 안정적인 데이터를 만드는 또 다른 방법은 기존 데이터에 만료일을 추가하는 것입니다. 위의 인쇄된 제품 카탈로그가 훌륭한 예입니다. 일반적으로 2회의 게시 기간 동안 소매점은 주어진 카탈로그에서 주문을 받습니다. 1년에 4번 카탈로그를 게시하는 경우 제품 카탈로그 데이터는 6개월 동안 안정적이며 주문 및 주문 이행과 같은 정보 처리에 사용될 수 있습니다.

      안정적인 데이터를 흔히 마스터 데이터 또는 참조 데이터라고 합니다. FailSafe 이니셔티브에서는 참조 데이터라는 용어가 마스터 데이터라는 용어보다 의미적으로 포괄적이므로 참조 데이터를 사용합니다. 많은 기업에서 마스터 데이터는 매우 구체적인 의미를 갖고 있고 참조 데이터보다 제한적입니다.

    • 특이성 - 동시 업데이트를 하지 않거나 적게 하면서 고유하게 식별 가능한 인스턴스와의 연결을 통해 분리될 수 있는 데이터입니다. 장바구니를 예로 들어 보겠습니다. 장바구니가 분명히 업데이트되지만 업데이트는 비교적 드물게 발생하며 처리 관점에서뿐만 아니라 저장소에서도 완전히 분리될 수 있습니다.

      위에서 설명한 분리 가능한 데이터를 작업 데이터 또는 세션 데이터라고 합니다.

      이러한 두 가지 특성을 염두에 두고 다음과 같은 스키마가 등장합니다.

      데이터 형식 다이어그램
      그림 9

  • 정보 모델링

    많은 응용 프로그램 설계자 또는 개발자가 정보 모델링에 대해 생각할 때 개체 또는 엔터티 모델을 대상으로 합니다. 개체 또는 엔터티 모델은 정보 모델링의 학술적인 부분에 속하지만, 더 많은 부분은 FailSafe 응용 프로그램의 정보 모델에 속합니다. 

    오늘날의 분산된 세계에 필요한 사고 프로세스에 대한 첫 관점에서는 안정성과 특이성에 초점을 맞췄습니다. 또 다른 핵심 요소는 사용자/장치와의 상호 작용에서나 구현될 비즈니스 프로세스의 일환으로 데이터가 사용되는 방식을 이해하는 것입니다. 개체 지향 모델링은 다양한 방법으로 정보 디자인의 일부가 되어야 합니다.

    • 정보 숨기기 - 사용자 또는 비즈니스 프로세스에 유용하지 않은 정보에 대한 액세스를 숨기거나 제공하지 않는 것이 관계형 데이터베이스에서 저장되고 관리되는 공유 데이터 또는 리소스와의 충돌을 방지하는 최선의 방법 중 하나입니다.

      정보 숨기기가 동시성을 개선하기 위해 매우 효과적으로 활용되는 방법에 대한 훌륭한 예는 일반적인 ERP 시스템과 Amazon.com에서 대부분의 재고 시나리오를 관리하는 방식의 차이입니다. ERP 시스템의 일반적인 구현에서 재고 테이블은 가장 정체되거나 많이 사용되는 테이블 중 하나입니다(관계형 데이터베이스 구현을 가정하는 경우). 일반적으로 ERP 응용 프로그램은 비즈니스 트랜잭션이 시작될 때 응용 프로그램에 정확한 재고 수를 제공하기 위해 사용자가 트랜잭션을 마칠 때까지 재고를 잠그려고 시도합니다. SAP와 같은 일부 시스템은 데이터베이스 잠금을 사용하지 않지만 큐 삽입 시스템에서 응용 프로그램 잠금을 얻습니다. 낙관적 동시성 제어, 더티 읽기 등 데이터베이스 계층의 수많은 기법이 이러한 정체에 도움을 주기 위해 개발되었습니다. 그러나 실제로 문제 없이 작동하는 것은 없으며 모두 부작용이 있습니다. 특정 시나리오에서는 테이블을 잠그려고 하지만 이러한 경우는 드물어야 합니다.

      Amazon.com은 이 문제를 훨씬 간단한 방식으로 해결했습니다. Amazon.com은 사용자에게 옵트인(opt in)하고 허용하거나 거부할 수 있는 SLO(서비스 수준 목표)를 제공했습니다. SLO는 주로 "N시간 동안 대개 사용할 수 있음"으로 표현되었습니다. 사용자는 사용 가능한 도서나 다른 품목의 실제 개수를 확인하지 못했지만 그럼에도 불구하고 가용성에 대한 정보가 제공되었습니다. 데이터베이스 잠금이 필요하지 않았으며, 사실 데이터베이스 연결이 전혀 필요하지 않았습니다. 시스템이 SLO를 충족할 수 없는 경우에는 구매자에게 사과를 전하고(대개 전자 메일을 통해) 업데이트된 SLO를 제공합니다.

    • 대체 가능 리소스:사전의 정의에 따르면 대체 가능은 '특정한 특성이나 종류의 물건을 비슷한 특성이나 종류의 다른 물건으로 전체적으로나 부분적으로 자유롭게 교환 가능한 것'입니다. 공유 데이터 액세스의 충돌을 줄이는 것을 목표로 하는 이 개념의 핵심은 정보 모델링을 사용하여 사용자가 특정 인스턴스 대신 데이터의 대체 가능 인스턴스와 상호 작용하도록 하는 방법을 제공하는 것입니다. 호텔 객실 예약이 좋은 예입니다. 객실 번호 '123'을 언급하지 않고 침대 수, 바다 전망, 흡연/금연 등의 많은 구체적 정보를 표현할 수 있습니다. 이와 같은 모델링을 사용하면 대체 가능 데이터의 풀에 대한 정보를 캐시하고, 이 풀에 대해 비즈니스 프로세스를 실행하고, 체크인 프로세스의 종료 후에만 이 풀에서 특정 객실을 할당하는 것이 전적으로 가능합니다. 체크인 프로세스가 시작되면 풀에서 특정 객실을 제거하는 혼합 모델도 전적으로 가능합니다.

  • 캐시 관리

    적절한 시기에 적절한 정보를 캐시하는 것이 성공적인 캐싱 전략의 핵심 부분입니다. 캐시를 로드하는 다양한 기법이 있습니다. 이에 대해서는 “분산 환경의 캐싱”에 간략하게 설명되어 있습니다. 또한 아래의 섹션에서는 분산 캐싱에 종속된 FailSafe 응용 프로그램 디자인에 대한 몇 가지 고려 사항을 간단히 살펴봅니다.

    • 참조 데이터 - 호스팅 환경(패브릭 컨트롤러 또는 데이터 센터)에서 재해가 발생하는 경우 응용 프로그램이 다른 환경으로 이동됩니다. 응용 프로그램의 활성 인스턴스가 이미 활성인 경우(활성-활성 디자인) 캐시에 이미 많은 관련 정보(특히 참조 데이터)가 들어 있을 가능성이 높습니다. 응용 프로그램의 새 인스턴스가 생성되는 경우 캐시 노드에 정보가 없습니다. 캐시 누락 시 원하는 데이터를 자동으로 로드하도록 응용 프로그램을 디자인해야 합니다. 새 인스턴스의 경우 참조 데이터를 캐시에 대량으로 로드하는 시작 루틴을 사용할 수 있습니다. 응용 프로그램이 클라우드 인프라에서 처리되는 즉시 사용자가 활성화될 수 있으므로 두 방법을 결합하는 것이 바람직합니다.

    • 작업 데이터 - 참조 데이터에 대해 설명된 기본 방법이 작업 데이터에도 적용됩니다. 그러나 작업 데이터에는 특이한 점이 있습니다. 참조 데이터는 응용 프로그램의 영구 저장소에서 사용할 수 있는 것으로 간주됩니다. 참조 데이터가 자주 변경되지는 않으므로 동기화가 고려되어야 하긴 하지만 문제가 되지는 않습니다. 그러나 작업 데이터는 격리된 곳에서 가끔 업데이트됨에도 불구하고 참조 데이터보다 일시적입니다. 이상적으로 분산된 캐시는 작업 데이터를 빈번하게 유지하며 응용 프로그램의 다양한 인스턴스 간에 작업 데이터를 복제합니다. 지속성 및 동기화 간격이 경합을 방지할 정도로 멀리 떨어져 있지만 가능한 데이터 손실을 최소한으로 유지할 정도로 가깝게 있도록 해야 합니다.

관계, 특히 플랫폼과 응용 프로그램 간의 책임의 영역에 대한 일반적인 오해가 있습니다. 이것이 가장 문제가 되는 영역 중 하나는 데이터와 관련되어 있습니다.

Azure와 같은 플랫폼이 데이터의 여러 복사본을 저장하는 약속을 이행하지만(일부 서비스에서는 지역 간 중복을 제공하기까지 함) 저장되는 데이터는 응용 프로그램, 작업 및 구성 요소 서비스에 의해 제어됩니다. 응용 프로그램이 응용 프로그램 데이터를 손상시키는 작업을 수행하는 경우 플랫폼은 해당 데이터의 복사본을 여러 개 저장합니다.

오류 모드와 오류 지점을 설정할 때 잠재적으로 데이터 손상을 일으킬 수 있는 응용 프로그램의 영역을 식별해야 합니다. 오류 발생 지점은 잘못된 코드나 서비스에 대한 포이즌 메시지 등 다양할 수 있지만 관련된 오류 모드와 오류 지점을 식별하는 것이 중요합니다.

응용 프로그램 수준 수정

  • 멱등원

    연결된 서비스에 대한 핵심 가정은 연결된 서비스의 가용성이 100%일 수는 없으며 재시도 논리를 사용한 일시적인 오류 처리가 핵심 구현 방법이라는 것입니다. 재시도 논리가 구현되는 경우 동일한 메시지가 두 번 이상 전송되거나 메시지가 순서에 맞지 않게 전송될 가능성이 있습니다.

    동일한 메시지를 여러 번 보내도 데이터 저장소가 예기치 않은 상태가 되거나 오염되지 않도록 작업을 멱등원이 되도록 디자인해야 합니다.

    예를 들어 모든 요청에서 데이터를 삽입하면 서비스 작업이 여러 번 호출되는 경우 여러 레코드가 추가될 수 있습니다. 다른 방법은 레코드가 있으면 업데이트를 수행하고 없으면 삽입을 수행하는 지능형 "upsert"로 코드를 구현하는 것입니다. 타임스탬프 또는 전역 식별자를 사용하여 새 메시지와 이전에 처리된 메시지를 식별하여 새 메시지만 데이터베이스에 삽입하고 메시지가 이전에 받은 것보다 최신인 경우 기존 레코드를 업데이트할 수 있습니다.

  • 작업 활동 및 보정 동작

    멱등원뿐만 아니라 고려할 또 다른 영역은 보정 동작이라는 개념입니다.

    보정 동작의 실제 예는 신용 카드로 지불된 제품을 반품할 때 확인할 수 있습니다. 이 시나리오에서 소비자는 소매점을 방문하고 신용 카드를 제공하며, 청구 금액은 소비자의 신용 카드 계정에 적용됩니다. 소비자가 소매점에 제품을 반품하는 경우 정책이 평가되고 반품이 정책을 따르는 경우 소매점은 구입 금액을 소비자의 신용 카드 계정에 발급합니다.

    연결된 시스템이 계속 증가하고 복합 서비스가 등장하는 세계에서 보정 동작을 처리하는 방법을 이해하는 것은 매우 중요합니다.

    기간 업무(LOB) 응용 프로그램의 많은 개발자에게 트랜잭션 개념은 새로운 것이 아니지만 로컬 데이터 기술 및 관련 코드 라이브러리가 노출하는 트랜잭션 기능에 한정된 경우가 많습니다. 클라우드 측면에서 트랜잭션 개념을 살펴볼 때는 분산 서비스의 오케스트레이션과 관련된 새로운 고려를 해야 합니다.

    서비스 오케스트레이션은 여러 분산 시스템에 걸쳐 있을 수 있으며 오래 실행되고 상태 저장일 수 있습니다. 오케스트레이션 자체는 거의 동기가 아니며 비즈니스 시나리오에 따라 몇 초에서 몇 년에 이를 수 있습니다.

    공급망 시나리오에서는 25개 조직을 동일한 작업 활동에 함께 결합할 수 있습니다. 예를 들어 하나 이상의 서비스 오케스트레이션에서 상호 연결된 25개 이상의 시스템 집합이 있을 수 있습니다.

    성공이 발생하면 활동이 성공했음을 25개 시스템이 인식해야 합니다. 활동의 각 연결 지점에 대해 참가자 시스템은 다른 시스템에서 받는 메시지에 대한 상관 관계 ID를 제공할 수 있습니다. 활동의 유형에 따라 해당 상관 관계 ID를 수신한 당사자는 트랜잭션이 개념적으로 완료되었음을 받아들일 수 있습니다. 다른 경우에는 모든 25개 당사자의 상호 작용이 완료될 때 확인 메시지가 모든 당사자에게 전송될 수 있습니다(단일 서비스에서 직접 또는 각 시스템의 특정 오케스트레이션 상호 작용 지점을 통해).

    복합 및/또는 분산 활동에서 오류를 처리하기 위해 각 서비스는 고유 식별자에 따라 지정된 트랜잭션을 취소하는 요청을 받기 위해 서비스 인터페이스 및 작업을 노출합니다. 서비스 외관 뒤에서 이 활동의 취소를 보정하기 위한 워크플로가 설정됩니다. 이상적으로 이러한 워크플로는 자동화된 절차이지만 수동으로 해결하도록 조직의 담당자에게 라우팅하는 것처럼 간단할 수도 있습니다.

백업

데이터 손상을 방지하기 위한 응용 프로그램 수준 수정뿐만 아니라 응용 프로그램 수정이 성공적이 아닌 경우 옵션을 제공하기 위해 설정되어 있는 수정도 있습니다.

데이터 저장소의 백업 복사본을 만들고 복원하기 위한 프로세스가 복원력 계획에 속해야 합니다. 데이터 백업 및 복원 개념이 새로운 것은 아니지만 클라우드에서는 새로운 특이점이 있습니다.

백업 전략은 데이터 복원에 대한 비즈니스 요구 사항을 분명히 이해하여 정의되어야 합니다. 데이터 저장소가 재해 시 손상되거나 오프라인 상태가 되는 경우 복원해야 하는 데이터의 유형, 복원해야 하는 볼륨 및 비즈니스에 필요한 복원 속도를 알아야 합니다. 이는 전체적인 가용성 계획에 영향을 미치며 백업 및 복원 계획을 이끌어야 합니다.

  • 관계형 데이터베이스

    관계형 데이터베이스를 백업하는 것은 새로운 것이 아닙니다. 많은 조직에는 재해 복구 또는 규정 준수 요구를 충족하기 위해 데이터를 백업하기 위한 도구, 방법 및 프로세스가 마련되어 있습니다. 많은 경우 전통적인 백업 도구, 방법 및 프로세스는 수정을 거의 하지 않거나 수정 없이 작동할 수 있습니다. 또한 데이터를 백업하고 클라우드 기반 Blob 저장소에 복사본을 저장하는 등의 새로운 대안이나 변형된 대안을 고려할 수 있습니다.

    기존 프로세스와 도구를 평가할 때 클라우드 기반 솔루션에 적합한 방법을 평가해야 합니다. 대부분의 경우 아래에 나열된 방법 중 하나 이상이 여러 가지 오류 모드를 수정하는 데 적용됩니다.

    1. 전체 백업 - 데이터 저장소 전체를 백업하는 것입니다. 전체 백업은 데이터 볼륨 및 속도를 기준으로 지정된 일정에 따라 발생해야 합니다. 전체 백업은 서비스에 대한 서비스 수준 계약을 이행하는 데 필요한 전체 데이터 집합입니다. 이러한 유형의 백업 메커니즘은 데이터베이스/데이터베이스 서비스 공급자 또는 해당 공급업체 에코시스템에서 일반적으로 제공합니다.

    2. 지정 시간 - 지정 시간 백업은 실재하는 데이터베이스에서 주어진 지정 시간을 반영하는 백업입니다. 예를 들어 데이터 저장소를 손상시킨 오류가 오후에 발생한 경우 정오에 수행된 지정 시간 백업을 복원하여 비즈니스 영향을 최소화할 수 있습니다.

      개인의 연결 수준이 계속해서 증가하는 상황에서 하루 중 언제든지 서비스를 이용하려는 기대 때문에 최신 지정 시간으로 빠르게 복원하는 기능이 필요하게 되었습니다.

    3. 동기화 - 전통적인 백업 이외의 또 다른 옵션은 데이터의 동기화입니다. 데이터는 여러 데이터 센터에 저장될 수 있으며 한 데이터 센터에서 다른 데이터 센터로 데이터를 주기적으로 동기화할 수 있습니다. 일반적인 가용성 계획의 일부로 트래픽 관리를 활용하는 솔루션에서 동기화된 데이터를 제공하는 것 외에도 비즈니스 연속성 문제가 있는 경우 제2의 데이터 센터로 장애 조치하는 데 동기화를 사용할 수도 있습니다.

      서비스를 소비하는 개인이 상시 연결되어 있으므로 가동 중지 시간은 많은 시나리오에서 점점 더 받아들일 수 없게 되고 있으며, 이러한 상황에서 동기화는 바람직한 방법일 수 있습니다.

      동기화 패턴에는 다음이 포함될 수 있습니다.

      - 주어진 클라우드 공급자의 데이터 센터 간 동기화

      - 여러 클라우드 공급자의 데이터 센터 간 동기화

      - 온-프레미스에서 주어진 클라우드 공급자로 데이터 센터 간 동기화

      - 소비자 관련 데이터 조각에 대한 데이터 센터와 장치 간 동기화

  • 분할된 관계형 데이터베이스

    많은 경우 클라우드로의 이동은 모바일 또는 소셜 응용 프로그램과 관련된 시나리오와 같이 사용자가 대규모이고 트래픽이 많은 시나리오를 촉진해야 하는 필요성에 의해 이루어집니다. 이러한 시나리오에서 응용 프로그램 패턴은 일반적으로 단일 데이터베이스 모델에서 전체 데이터 집합의 일부를 포함하고 대규모 사용에 최적화된 많은 분할된 데이터베이스로 이동하는 것을 수반합니다. Azure를 기반으로 구축된 최근의 한 소셜 네트워킹 프로젝트는 총 400개의 분할된 데이터베이스로 시작되었습니다.

    각각의 분할된 데이터베이스는 독립 실행형 데이터베이스이며, 아키텍처와 관리에서는 개별 분할된 데이터베이스와 모든 분할된 데이터베이스가 포함된 전체 데이터 집합의 전체 백업, 지정 시간 백업 및 백업 복원을 촉진해야 합니다.

  • NoSQL 데이터 저장소

    관계형 데이터 저장소뿐만 아니라 NoSQL(Not only SQL) 데이터 저장소에 대한 백업 정책도 고려해야 합니다. 주요 클라우드 공급자가 제공하는 NoSQL 데이터베이스의 가장 널리 사용되는 형태는 흔히 테이블 저장소라고 하는 고가용성 키-값 쌍 저장소의 형태입니다.

    NoSQL 저장소는 가용성이 높을 수 있습니다. 경우에 따라 NoSQL 저장소는 지리적으로 중복되어 특정 데이터 센터의 치명적 오류 시 손실을 방지하는 데 도움이 될 수 있습니다. 이러한 저장소는 일반적으로 실수로 콘텐츠를 덮어쓰거나 삭제하는 응용 프로그램으로부터 보호하는 기능을 제공하지 않습니다. 응용 프로그램 또는 사용자 오류는 Blob 저장소와 같은 플랫폼 서비스에서 자동으로 처리되지 않으며 백업 전략이 평가되어야 합니다.

    일반적으로 관계형 데이터베이스에는 백업을 수행하기 위한 기존의 잘 설정된 도구가 있지만 많은 NoSQL 저장소는 이러한 도구가 없습니다. 널리 사용되는 아키텍처 차원의 방법은 복제 NoSQL 저장소에 데이터의 중복 복사본을 만들고 조회 테이블을 사용하여 복제 저장소에 배치된 원본 저장소의 행을 식별하는 것입니다. 데이터를 복원하려면 이 동일한 테이블을 사용하며, 이 테이블에서 읽어서 복원될 수 있는 복제 저장소의 콘텐츠를 식별합니다.

    비즈니스 연속성 문제에 따라 이 복제본의 배치는 동일한 클라우드 공급자를 사용하여 동일한 데이터 센터 및/또는 동일한 NoSQL 데이터 저장소에 호스팅될 수 있습니다. 또한 다른 데이터 센터, 다른 클라우드 공급자 및/또는 다른 변형된 NoSQL 데이터 저장소에 있을 수도 있습니다. 배치의 동인은 작업 서비스의 원하는 SLA와 관련 규정 준수 고려 사항에 따라 크게 영향을 받습니다.

    이 결정을 내릴 때 고려할 요소는 특히 데이터 유입 및 유출과 관련이 있으므로 비용입니다. 클라우드 공급자는 자체 데이터 센터 내의 무료 이동을 제공할 수 있으며 자체 환경으로 데이터를 무료로 전달하도록 허용할 수 있습니다. 클라우드 공급자는 무료 데이터 유출을 제공하지 않으며 보조 클라우드 플랫폼 공급자로 데이터를 이동하는 비용은 규모가 큰 경우 상당히 높을 수 있습니다.

    note참고
    조회 테이블은 잠재적인 오류 지점이 되며 조회 테이블의 복제본은 복원력 계획의 일부로 고려되어야 합니다.

  • Blob 저장소

    관계형 및 NoSQL 데이터 저장소와 마찬가지로, Blob 저장소 서비스에 대해 구현된 가용성 기능 덕분에 백업 정책의 구현을 고려할 필요가 없다는 일반적인 오해가 있습니다.

    Blob 저장소도 지리적으로 중복될 수 있지만, 앞에서 설명했듯이 이러한 중복이 응용 프로그램 오류에 대한 보호 기능을 제공하지는 못합니다. 응용 프로그램 또는 사용자 오류는 Blob 저장소와 같은 플랫폼 서비스에서 자동으로 처리되지 않으며 백업 전략이 평가되어야 합니다.

    백업 전략은 NoSQL 저장소에 사용되는 백업 전략과 매우 유사할 수 있습니다. Blob의 크기가 잠재적으로 크기 때문에 데이터를 이동하는 비용과 시간은 백업 및 복원 전략의 중요한 부분입니다.

  • 백업 복원

    백업 정책을 설정하고 성실하게 따랐지만 데이터 복원은 테스트하지 않은 조직에 대한 이야기를 대부분 들어 봤을 것입니다. 재해가 발생한 중대한 날에 데이터베이스 백업을 복원하려고 하지만 결국 백업을 잘못 구성했고 수년 동안 오프사이트로 보내고 있는 테이프에 필요한 정보가 없다는 사실만 발견하게 됩니다.

    설정된 백업 프로세스가 무엇이든 간에 데이터를 올바르게 복원할 수 있음을 확인하고 비즈니스에 최소한의 영향을 주면서 복원이 시기 적절하게 발생하는지 확인하는 테스트를 설정해야 합니다.

CDN(콘텐츠 배달 네트워크)은 자주 요청된 파일에 대한 가용성 및 향상된 사용자 환경을 제공하는 데 널리 사용되는 방법입니다. CDN의 콘텐츠는 처음 사용할 때 로컬 노드에 복사된 다음 이후 요청 시 해당 로컬 노드에서 제공됩니다. 콘텐츠는 지정된 기간 후 만료됩니다. 만료 후 다음 요청 시 콘텐츠가 로컬 노드에 다시 복사되어야 합니다.

CDN을 활용하면 다양한 이점이 있지만 종속성도 추가됩니다. 다른 종속성의 경우와 마찬가지로 서비스 오류의 수정을 적극적으로 검토해야 합니다.

CDN의 적절한 사용

CDN이 모든 규모에 대한 대책이라는 일반적인 오해가 있습니다. 한 시나리오에서 고객은 CDN이 온라인 전자책 상점에 대한 적절한 솔루션이라고 확신합니다. 하지만 그렇지 않습니다. 그 이유는 무엇일까요? 수백만 권의 책에 대한 카탈로그에서 자주 요청되는 책("적중")은 작은 부분만 차지하고 다른 수많은 책은 예측을 거의 할 수 없게 요청됩니다. 자주 요청되는 책은 첫 요청 시 로컬 노드에 복사되어 비용 효율적인 로컬 규모와 쾌적한 사용자 환경을 제공합니다. 그밖의 거의 모든 요청은 두 번 복사됩니다. 한 번은 로컬 노드에 복사되고 그 다음 번에는 고객에게 복사됩니다. 드문 요청으로 콘텐츠가 정기적으로 만료되기 때문입니다. 이는 CDN이 원하는 효과와 상반되게 솔루션의 속도를 저하시키고 비용을 높인다는 증거입니다.

대부분의 경우 솔루션의 운영은 수명 주기가 상당히 진행될 때까지 계획되지 않을 수 있습니다. 진정으로 복원력 있는 응용 프로그램을 구축하려면 운영을 위해 응용 프로그램을 디자인해야 합니다. 일반적으로 운영을 위한 디자인에는 상태 모델 설정, 원격 분석 정보 캡처, 상태 모니터링 서비스 및 워크플로 통합, 운영자 및 개발자에 의해 동작 가능하게 해당 데이터 설정 등의 주요 작업이 포함됩니다.

개발 팀은 응용 프로그램 “상태”를 흔히 간과하고 때때로 완전히 무시하기도 합니다. 이에 따라 서비스가 두 가지 알려진 상태인 가동 또는 중단으로 프로덕션에 들어가는 일이 많습니다. 복원력 있는 서비스의 디자이너는 응용 프로그램 상태 조건, 상태 저하, 오류 및 상태 종속성을 정의하는 상태 모델을 개발해야 합니다.

상태 모델을 미리 개발하면 오류 모드 및 지점이 드러나고 개발자가 응용 프로그램 디자인 단계에서 가상(what-if) 시나리오를 식별하고 연구하게 됩니다. 상태 모델을 운용할 수 있으려면 서비스가 자신의 상태를 전달할 수 있어야 합니다. 서비스는 이러한 정보를 프로그래밍 방식으로 브로드캐스트하는 기능을 갖추고 해당 상태를 대화형으로 쿼리하기 위한 인터페이스를 제공해야 하며, 관리자가 응용 프로그램 상태를 실시간으로 모니터링할 수 있는 메커니즘을 제공하고(또는 기존 메커니즘에 연결하고) 필요한 경우 관리자가 응용 프로그램을 정상 상태로 되돌리기 위해 교정 "치료제"를 제공할 수 있는 메커니즘을 설정해야 합니다.

특성 정의

주어진 서비스 또는 응용 프로그램에 대해 최소한 세 가지 범주의 상태(정상, 상태 저하 및 비정상)를 나타내는 데이터 요소 및 값 범위를 식별하기 위해 진단을 수행해야 합니다. 이 정보를 활용하여 서비스의 자동 복구를 자동화할 수 있습니다.

인터페이스 정의

상태가 정의된 경우 서비스는 상태 관련 인터페이스를 노출해야 합니다. 이러한 인터페이스는 다음과 같은 범주의 작업을 제공합니다.

  • 구독된 파트너 서비스에 상태 내보내기

    서비스는 구독된 파트너 서비스에 상태 정보를 내보내야 합니다. 이 상태는 간결해야 하고 상위 수준 상태 및 기본 진단을 갖추어야 합니다.

    서비스는 파트너 서비스가 상태 메시지를 구독할 수 있는 기능을 제공해야 합니다. 상태 메시지의 배달은 솔루션에 적절한 경로를 통해 이루어질 수 있습니다. 한 경로에서 서비스는 구독자가 검색할 수 있는 큐에 상태 업데이트를 배치할 수도 있습니다.

    다른 방법은 알려진 상태 보고 인터페이스가 노출되는 끝점을 구독자가 제공할 수 있도록 허용하는 것입니다. 상태 정보가 변경되면 제공된 끝점에서 구독자에게 정보를 내보낼 수 있습니다.

  • 원격 분석 데이터를 제공하기 위한 인터페이스 노출

    원격 분석은 여러 수준에서 응용 프로그램 및/또는 서비스의 현재 상태를 식별하는 데 도움이 되므로 운영에 매우 유용합니다. 또한 환경에서 이례적인 상황이 발생할 때 신속하게 식별하는 데도 도움이 될 수 있습니다. 원격 분석은 서비스에 대해 상당히 세분화된 뷰를 제공하고 서비스 공급자의 대시보드, 서비스 및 운영자에게 노출됩니다.

    운영의 경우 원격 분석 메트릭에는 여러 역할, 서비스 및 서비스에 구축된 복합 응용 프로그램에 대한 평균 CPU 사용률, 오류, 연결, 큐 등이 포함될 수 있습니다.

    응용 프로그램 관련 원격 분석은 일반적으로 자동으로 활성화되지 않으며 플랫폼 자체에서 직접 모니터링되지 않으므로 서비스와 응용 프로그램에서 원격 분석을 활성화해야 합니다.

  • 서비스에 추가 상태 진단 정보를 질의하는 인터페이스 노출

    서비스는 추가 상태 진단 정보를 질의하는 인터페이스도 제공해야 합니다. 구독자 서비스는 상태에서 받은 상위 수준 정보에 따라, 상태 정보를 제공하는 서비스와의 관계에서 이후의 과정을 결정하기 위해 추가 정보를 요청할 수 있습니다.

    특히 서비스의 상태가 좋지 못한 경우 소비하는 서비스는 추가 정보를 통해 해당 서비스를 계속 사용할지 아니면 대체 공급자로 장애 조치할지를 결정할 수 있습니다.

  • 서비스 및 응용 프로그램 수준에서 서비스 상태를 수정하는 인터페이스 노출

    상태 정보의 소비자가 내부 서비스나 관련 서비스인 경우 알려진 문제를 서비스에서 자체적으로 수정할 수 있도록 할 수 있습니다. 의약품과 마찬가지로, 서비스 상태에 대한 이해도 점점 발전하고 있으며 상태 데이터는 다양한 치료 과정으로 이끌 수 있습니다.

    서비스는 그 치료를 제공할 수 있도록 인터페이스를 노출해야 합니다. 가장 간단한 형태에서 이러한 치료책은 서비스의 재부팅이나 재이미징을 트리거하는 것에서 다른 내부 데이터 또는 서비스 공급자로 장애 조치하는 것에 이릅니다.

    서비스의 상태를 이해하면 서비스 공급자가 비정상인 서비스 상태를 신속하게 식별할 수 있습니다. 자동화된 운영은 알려진 문제에 대한 신속하고 일관성 있는 규정된 수정을 제공하고 서비스가 자동으로 복구되게 합니다. 이 섹션에서는 상태의 다양한 측면을 좀 더 자세하게 검토합니다.

원격 분석은 “특수 장비를 사용하여 무엇인가를 측정(예: 압력, 속도 또는 온도)한 후 무선으로 다른 곳에 보내는 프로세스”입니다.

서비스에서 원격 분석 데이터를 수직하는 것은 중요합니다. 흔히 원격 분석은 사용자, 비즈니스, 응용 프로그램 및 인프라의 4가지 유형 중 하나로 범주화됩니다.

사용자 원격 분석은 대상인 개별 사용자의 동작을 대상으로 합니다. 사용자 원격 분석은 사용자의 동작을 파악할 수 있게 해주고, 그 결과 개인화된 환경을 쉽게 제공할 수 있게 해줍니다.

비즈니스 원격 분석에는 비즈니스 활동 관련 데이터와 비즈니스의 KPI(핵심 성과 지표)가 포함됩니다. 비즈니스 원격 분석의 예로는 사이트의 고유 활성 사용자 수, 시청한 비디오 수 등이 있습니다.

응용 프로그램 원격 분석에는 응용 프로그램 계층 및 해당 종속 서비스의 상태, 성능 및 활동에 대한 세부 정보가 포함됩니다. 응용 프로그램 원격 분석에는 데이터 클라이언트 호출 및 로그인, 예외, API 호출, 세션 등에 대한 세부 정보가 포함됩니다.

인프라 원격 분석에는 기본 시스템 인프라의 상태에 대한 세부 정보가 포함됩니다. 인프라 원격 분석에는 CPU, 메모리, 네트워크, 사용 가능한 용량 등과 같은 리소스에 대한 데이터가 포함될 수 있습니다.

수집할 데이터와 데이터의 수집 방법을 식별할 때는 데이터와 이 데이터를 사용할 용도를 이해하는 것이 중요합니다.

먼저, 수집할 데이터의 용도가 정보를 제공하기 위한 것인지 아니면 작업을 시작하기 위한 것인지를 결정합니다. 물어볼 질문은 “얼마나 빨리 반응해야 하는가?”입니다. 잠재적으로 작업을 시작하기 위해 데이터를 근 실시간으로 사용할 것입니까? 또는 데이터를 전월대비 추세 보고서에 사용할 것입니까? 이러한 질문에 대한 대답은 원격 분석 접근법과 아키텍처에 사용되는 기술에 정보를 제공합니다.

다음으로, 수집할 원격 분석 데이터에 적용할 질문의 유형을 식별합니다. 알려진 질문에 대답하기 위해 원격 분석을 사용할 것입니까? 아니면 탐색을 위해 원격 분석을 사용할 것입니까? 예를 들어 비즈니스의 경우 KPI가 알려진 질문에 대한 대답입니다. 그러나 장애가 발생한 패턴의 장치 데이터를 탐색하려는 제조업체는 미지의 세계에 발을 들여놓을 것입니다. 제조업체의 경우 장애는 시스템 내 하나 이상의 항목에서 유래된 것입니다. 제조업체는 탐색을 하고 추가 데이터를 필요로 할 것입니다.

원격 분석을 사용하여 이해하려고 할 때는 이러한 이해를 얻는 데 필요한 시간을 고려해야 합니다. 일부 경우 원격 분석을 사용하여 몇 초 또는 몇 분 동안 발생한 장치 센서 판독값의 급증을 탐지합니다. 또 다른 경우 원격 분석을 사용하여 훨씬 긴 기간 동안 웹 사이트의 전주대비 사용자 증가를 식별할 수 있습니다.

마지막으로, 이해하기 위해 이 기간 내에 신호 소스에서 수집할 수 있는 데이터의 양을 고려합니다. 필요한 소스 신호의 양을 알아야 합니다. 그런 다음 해당 신호를 분할하고 로컬 계산과 전역 계산의 적절한 혼합을 설정하기 위한 최선의 방법을 결정할 수 있습니다.

원격 분석에서 이벤트의 시퀀스를 어떻게 기록할 것인지도 고려해야 합니다. 많은 조직에서는 기본적으로 타임스탬프를 사용합니다. 그러나 서버 시간이 데이터 센터 내에서와 데이터 센터 전체에서 일관되지 않으므로 타임스탬프는 적용하기 어려울 수 있습니다. 시간을 주기적으로 동기화할 수 있지만 서버 시간이 드리프트(천천히 점점 더 부정확해짐)하는 문서화된 증거가 있습니다. 이 드리프트는 효과적인 분석을 저하시킬 수 있는 변화를 초래합니다. 정밀도가 필요한 시나리오의 경우 벡터 시간 구현을 활용하는 등 다른 솔루션을 고려하세요.

원격 분석 접근법을 식별한 후에는 신호 특성화를 진행합니다.

신호를 연속 또는 이산으로 분류할 수 있습니다. 연속 신호의 예로는 실시간 이벤트 데이터가 있습니다. 로그 파일 항목은 이산 신호에 속합니다.

접근법의 요구 사항을 만족하려면 신호에 포함된 데이터의 양을 식별해야 합니다. 정보가 연속인 경우 샘플링 속도를 설정해야 합니다. 정보가 이산인 경우 유지하거나 필터링할 레코드를 식별해야 합니다.

또한 액세스 유형을 식별해야 합니다. 일부 경우 원격 분석 데이터를 밀어넣는 것이 적절합니다. 또 다른 경우에는 끌어오기를 해 원격 분석 데이터를 검색합니다.

보다 발전된 시스템에서는 밀어넣은 기존 원격 분석에서 얻은 이해 내용에서 더 나아가 추가 정보를 얻기 위해 끌어오기 방법을 사용할 수 있다는 사실을 알 수 있습니다. 예를 들어 밀어넣은 원격 분석에 불충분 상태가 표시되면 끌어오기를 통해 추가 진단 데이터를 검색할 수 있습니다.

수집된 모든 데이터가 특정 상황에서 관련될 수는 있지만, 모든 원격 분석 데이터를 항상 전송해야 하는 것은 아닙니다. 원격 분석 유형 및 이해를 얻는 데 필요한 데이터의 양에 따라 보다 작은 양의 데이터를 검색할 수도 있습니다. 로컬 계산을 사용하여 집계, 샘플링 또는 하위 집합을 생성하고 해당 데이터를 서비스에 보낼 수 있습니다. 예를 들어 표준 원격 분석에서 검색한 데이터에 불충분 상태가 표시되면 서비스에서 추가 데이터를 요청할 수 있습니다.

원격 분석 전략을 개발할 때는 적절한 정책을 고려하세요. 원격 분석에는 사용 가능한 연결이 필요하며, 해당 연결을 통해 데이터를 보내는 데는 비용이 듭니다. 컨텍스트, 연결 및 비용을 고려하는 정책을 만들고 원격 분석을 적절하게 조정합니다.

정책은 현재 상태의 컨텍스트를 고려하여 지금 보내는 데 적절한 원격 분석을 결정해야 합니다. 이전에 수신한 원격 분석에서 얻은 이해 내용과 관련된 비즈니스 요구 사항을 통해 컨텍스트를 알 수 있습니다. 이 컨텍스트는 원격 분석 수집을 지시하고 그 우선 순위를 지정하는 데 도움이 됩니다.

이러한 장치의 연결 유형은 다양할 수 있으며(WiFi, LTE, 4G, 3G 등), 해당 연결은 변할 수 있습니다. 지금 장치의 연결이 전송되어야 하는 데이터를 결정하는 데 관련됩니다. 연결을 신뢰할 수 없거나 연결 속도가 느린 경우 정책에서는 전송되는 원격 분석에 우선 순위를 지정할 수 있습니다.

일반적으로 연결은 유료로 제공됩니다. 정책에서는 현재 연결이 데이터 통신 연결인지 아니면 데이터 통신이 아닌 연결인지 고려합니다. 데이터 통신 연결인 경우 정책에서는 연결된 비용을 식별하고, 가능한 경우 사용 캡도 식별합니다. 많은 장치에서는 하루 동안 다양한 유형의 연결을 사용합니다. 특정 원격 분석을 제공하는 데 드는 비용에 따라 해당 원격 분석에 우선 순위를 지정하거나 우선 순위를 해제할 수 있습니다.

일반적으로 다양한 사용자가 원격 분석 데이터를 수집하고 시각화합니다. 시각화가 중요한 두 사용자로는 운영자 및 개발자가 있습니다. 그러나 아래에 간략하게 설명한 것처럼 각 사용자의 요구 사항에서 필요로 하는 세분성 수준은 서로 다릅니다.

운영자에게는 개괄적인 작업 상태 및 하위 수준 원격 분석 데이터를 시각화하는 것이 중요합니다. 원격 분석 데이터에 따라 자동화된 알림이 설정되어 있을 수 있습니다. 그러나 운영자에게는 현재 및 이전 서비스 성능의 시각화에 유용한 대시보드가 필요합니다.

대규모 응용 프로그램의 경우 이 정보는 현재 문제를 신속하게 식별하거나 미래의 문제를 예측하는 데 도움이 될 수 있습니다. 또한 이 정보는 운영자가 잠재적 영향과 근본 원인을 식별하는 데 도움이 될 수 있습니다.

성능 대시보드 다이어그램

그림 10

대규모 소셜 사이트에 대한 위의 다이어그램에는 API 역할 평균 CPU%, API 오류, 온라인 사용자, 웹 활성 연결, 웹 역할 CPU%, 웹 오류, 웹 하드 연결, 웹 풀링된 연결, 웹 응용 프로그램 큐, 웹 소프트 연결이 나와 있습니다.

위에 표시된 원격 분석 및 보고 유형은 운영자가 서비스 자체의 코드를 수정하지 않고 오류를 수정할 수 있는 경우에 특히 유용합니다. 운영자가 수행할 수 있는 작업의 예에는 역할 및 재활용 인스턴스를 더 배포하는 것이 포함될 수 있습니다.

이전 및 실시간 원격 분석 데이터의 시각화를 다음에 활용할 수 있습니다.

  • 문제 해결

  • 라이브 사이트 문제에 대해 수행된 사후 평가

  • 새 운영자 교육

운영자뿐만 아니라 소프트웨어 개발자도 원격 분석 데이터의 중요한 소비자입니다. 오류는 운영 환경과 관련되지 않고 기본 응용 프로그램 코드와 관련될 수도 있습니다. 개발자를 위한 원격 분석 대시보드를 갖추면 개발자가 규정된 조치를 취할 수 있습니다.

다음은 이러한 목적으로 만든 샘플 유틸리티의 두 가지 스크린샷입니다. 대시보드는 오류 수, 오류가 속한 범주 및 각 범주와 관련된 특정 데이터에 대한 정보를 제공합니다. 여기에는 총 오류 수, 오류가 발생한 역할 인스턴스의 총 수 및 오류가 있는 데이터베이스의 총 수가 들어 있는 검사 데이터가 포함되어 있습니다.

대시보드 다이어그램

그림 11

대시보드 다이어그램

그림 12

수백만 명의 사용자가 참여하는 대규모 사이트의 경우 오류 보고가 더 많이 발생하며 완전히 허용 가능할 수 있습니다. 원격 분석을 해석하는 개발자 중심 대시보드가 있으면 실제로 문제가 있는지 여부, 관여하기에 적합한 문제인지 여부 및 문제가 발생한 코드의 위치를 파악하는 데 도움이 될 수 있습니다.

참고 항목

표시: