1단계: 목표 설정

필요한 복원력 수준과 이를 측정하는 방법을 이해하는 것이 목표 설정 단계의 기반입니다. 목표가 없고 측정할 수 없는 경우 무언가를 개선하기가 어렵습니다.

모든 애플리케이션에 동일한 수준의 복원력이 필요한 것은 아닙니다. 목표를 설정할 때 올바른 투자와 장단점을 위해 필요한 수준을 고려하세요. 이에 대한 좋은 비유는 자동차입니다. 4개의 타이어가 있지만 스페어 타이어는 하나만 가지고 있습니다. 승차 중에 여러 플랫 타이어가 발생할 가능성은 낮으며, 추가 예비 부품을 보유하면 화물 공간 또는 연료 효율성과 같은 다른 기능에서 벗어날 수 있으므로 이는 합리적인 절충입니다.

목표를 정의한 후 이후 단계(2단계: 설계 및 구현, 4단계: 운영)에서 관찰성 제어를 구현하여 목표가 충족되고 있는지 파악합니다.

중요한 애플리케이션 매핑

복원력 목표를 정의하는 것이 기술적인 대화만 되어서는 안 됩니다. 대신 비즈니스 중심의 중점 사항부터 시작하여 애플리케이션이 제공해야 하는 사항과 장애의 결과를 이해합니다. 그런 다음 비즈니스 목표에 대한 이러한 이해는 아키텍처, 엔지니어링 및 운영과 같은 영역으로 전달됩니다. 정의한 복원력 목표는 모든 애플리케이션에 적용될 수 있지만, 목표 측정 방식은 애플리케이션의 함수에 따라 달라지는 경우가 많습니다. 비즈니스에 중요한 애플리케이션을 실행하고 있을 수 있으며,이 애플리케이션이 손상되면 조직이 상당한 수익을 잃거나 평판에 해를 끼칠 수 있습니다. 또는 중요하지 않고 조직의 비즈니스 수행 능력에 부정적인 영향을 미치지 않으면서 가동 중지 시간을 허용할 수 있는 다른 애플리케이션이 있을 수 있습니다.

예를 들어 소매 회사의 주문 관리 애플리케이션을 생각해 보세요. 주문 관리 애플리케이션의 구성 요소가 손상되어 제대로 실행되지 않으면 새 판매가 이루어지지 않습니다. 또한이 소매 회사에는 건물 중 하나에 있는 직원을 위한 커피숍이 있습니다. 커피숍에는 직원이 정적 웹 페이지에서 액세스할 수 있는 온라인 메뉴가 있습니다. 이 웹 페이지를 사용할 수 없게 되면 일부 직원이 불평할 수 있지만 회사에 반드시 재정적 피해를 입히는 것은 아닙니다. 이 예제를 기반으로 기업은 주문 관리 애플리케이션에 대해 더 공격적인 복원력 목표를 선택하지만 웹 애플리케이션의 복원력을 보장하기 위해 상당한 투자를 하지는 않을 것입니다.

가장 중요한 애플리케이션, 가장 많은 노력을 기울일 부분, 절충을 할 부분을 파악하는 것은 프로덕션 환경에서 애플리케이션의 복원력을 측정할 수 있는 것만큼 중요합니다. 장애의 영향을 더 잘 이해하기 위해 비즈니스 영향 분석(BIA)을 수행할 수 있습니다. BIA는 중요한 비즈니스 애플리케이션을 식별하고 우선 순위를 지정하며, 잠재적 위험과 영향을 평가하고, 지원되는 종속성을 식별하는 체계적이고 체계적인 접근 방식을 제공합니다. BIA는 조직의 가장 중요한 애플리케이션의 가동 중지 비용을 정량화하는 데 도움이 됩니다. 이 지표는 특정 애플리케이션이 손상되어 기능을 완료할 수 없는 경우 비용이 얼마나 드는지 간략하게 설명하는 데 도움이 됩니다. 이전 예제에서 주문 관리 애플리케이션이 손상된 경우 소매 비즈니스는 상당한 수익을 잃을 수 있습니다.

사용자 스토리 매핑

BIA 프로세스 중에 애플리케이션이 둘 이상의 비즈니스 기능을 담당하거나 비즈니스 기능에 여러 애플리케이션이 필요하다는 것을 발견할 수 있습니다. 이전 소매 회사 예제를 사용하면 주문 관리 함수에 체크아웃, 프로모션 및 요금에 대한 별도의 애플리케이션이 필요할 수 있습니다. 한 애플리케이션이 실패하면 비즈니스와 회사와 상호 작용하는 사용자가 영향을 느낄 수 있습니다. 예를 들어 회사는 새 주문을 추가하거나, 프로모션 및 할인에 대한 액세스 권한을 제공하거나, 제품 가격을 업데이트하지 못할 수 있습니다. 주문 관리 함수에 필요한 이러한 다양한 함수는 여러 애플리케이션에 의존할 수 있습니다. 또한 이러한 함수에는 여러 외부 종속성이 있을 수 있으므로 구성 요소 중심 복원력을 달성하는 프로세스가 너무 복잡합니다. 이 시나리오를 처리하는 더 나은 방법은 사용자가 하나의 애플리케이션 또는 일련의 애플리케이션과 상호 작용할 때 기대하는 경험을 설명하는 사용자 스토리에 초점을 맞추는 것입니다.

사용자 스토리에 집중하면 고객 경험의 어떤 부분이 가장 중요한지 이해하는 데 도움이 되므로 특정 위협으로부터 보호하는 메커니즘을 구축할 수 있습니다. 이전 예제에서 한 가지 사용자 스토리는 체크아웃일 수 있으며, 체크아웃 애플리케이션에 관련되고 요금 애플리케이션에 의존합니다. 또 다른 사용자 스토리는 프로모션 애플리케이션이 포함된 프로모션을 보는 것일 수 있습니다. 가장 중요한 애플리케이션과 해당 사용자 스토리를 매핑한 후 이러한 사용자 스토리의 복원력을 측정하는 데 사용할 지표를 정의할 수 있습니다. 이러한 지표는 전체 포트폴리오 또는 개별 사용자 스토리에 적용할 수 있습니다.

측정값 정의

복구 시점 목표(RPOs), 복구 시간 목표(RTOs) 및 서비스 수준 목표(SLOs)는 특정 시스템의 복원력을 평가하는 데 사용되는 표준 산업 측정치입니다. RPO는 장애 발생 시 비즈니스가 감당할 수 있는 데이터 손실의 양을 가리키는 반면, RTO는 중단 후 애플리케이션을 다시 사용할 수 있어야 하는 속도의 측정치입니다. 이 두 지표는 초, 분, 시간이라는 시간 단위로 측정됩니다. 또한 애플리케이션이 제대로 작동하는 시간, 즉 애플리케이션이 설계된 대로 기능을 수행하고 사용자가 액세스할 수 있는 시간을 측정할 수 있습니다. 이러한 SLOs는 고객이 받게 될 예상 서비스 수준을 자세히 설명하며, 응답 시간 1초 이내에 오류 없이 서비스되는 요청의 백분율(%)과 같은 지표로 측정됩니다(예: 요청의 99.99%가 매월 응답을 받습니다).   RPO 및 RTO는 백업 복원부터 사용자 트래픽 리디렉션에 이르기까지 애플리케이션 운영 및 복구 프로세스가 중단될 것이라고 가정할 때 재해 복구 전략과 관련이 있습니다. SLOs는 애플리케이션의 가동 중지 시간을 줄이는 경향이 있는 고가용성 제어를 구현하여 해결합니다.

SLO 지표는 일반적으로 서비스 공급자와 최종 사용자 간의 계약인 서비스 수준 계약(SLAs)의 정의에 사용됩니다. SLAs는 일반적으로 재정적 약정과 함께 제공되며 이러한 계약이 충족되지 않는 경우 공급자가 지불해야 하는 벌금을 간략하게 설명합니다. 그러나 SLA는 복원력 태세를 측정하는 것이 아니며, SLA를 늘리면 애플리케이션이 더 복원력이 높아지지 않습니다.

SLOs, RPOs 및 RTOs. 복원력 목표를 정의하고 RPO 및 RTO 목표를 명확하게 이해한 후 AWS Resilience Hub를 사용하여 아키텍처 평가를 실행하여 잠재적인 복원력 관련 약점을 파악할 수 있습니다. AWS Resilience Hub 는 AWS Well-Architected Framework 모범 사례를 기준으로 애플리케이션 아키텍처를 평가하고 정의된 RTO 및 RPO 목표를 충족하기 위해 특별히 개선해야 하는 사항의 맥락에서 문제 해결 지침을 공유합니다.

추가 측정 생성

RPO, RTO 및 SLOs는 복원력의 좋은 지표이지만 비즈니스 관점에서 목표에 대해 생각하고 애플리케이션 함수에 대한 목표를 정의할 수도 있습니다. 예를 들어 목표는 다음과 같습니다. 프런트엔드와 백엔드 간의 지연 시간이 40% 증가할 경우 분당 주문 성공률은 98%를 초과할 수 있습니다. 또는: 초당 시작된 스트림은 특정 구성 요소가 손실되더라도 평균에서 표준 편차 이내로 유지됩니다. 또한 목표를 생성하여 알려진 장애 유형에서 평균 복구 시간(MTTR)을 줄일 수 있습니다. 예를 들어, 이러한 알려진 문제가 발생할 경우 복구 시간이 x% 단축됩니다. 비즈니스 요구 사항에 맞는 목표를 생성하면 애플리케이션이 허용해야 하는 장애 유형을 예측하는 데 도움이 됩니다. 또한 애플리케이션 장애 가능성을 줄이기 위한 접근 방식을 식별하는 데도 도움이 됩니다.

애플리케이션에 전원을 공급하는 인스턴스의 5%를 잃어버린 경우 계속 작동하려는 목표에 대해 생각하면 애플리케이션을 사전 조정하거나 해당 이벤트 중에 발생하는 추가 트래픽을 지원할 수 있을 만큼 빠르게 확장할 수 있는 기능을 갖추어야 한다고 판단할 수 있습니다. 또는 2단계: 설계 및 구현 섹션에 설명된 대로 다양한 아키텍처 패턴을 활용해야 한다고 결정할 수 있습니다.

또한 특정 비즈니스 목표에 대한 관찰성 조치를 구현해야 합니다. 예를 들어 평균 주문률, 평균 주문 가격, 평균 구독 수 또는 애플리케이션의 동작에 따라 비즈니스 상태에 대한 인사이트를 제공할 수 있는 기타 지표를 추적할 수 있습니다. 애플리케이션에 관찰성 기능을 구현하면 경보를 생성하고 이러한 지표가 정의된 경계를 초과하는 경우 조치를 취할 수 있습니다. 관찰성은 4단계: 작업 섹션에서 자세히 다룹니다.