1단계: 목표 설정
필요한 복원력 수준과 이를 측정하는 방법을 이해하는 것이 목표 설정 단계의 기반입니다. 목표가 없고 측정할 수 없다면 무언가를 개선하기 어렵습니다.
애플리케이션에 필요한 복원력 수준은 서로 다를 수 있습니다. 목표를 설정할 경우 올바른 투자와 장단점을 파악하려면 필요한 수준을 고려합니다. 자동차를 비유로 들어 설명할 수 있습니다. 타이어는 4개이지만 예비 타이어는 1개뿐입니다. 주행 중에 타이어에 고장이 날 가능성은 낮으며, 화물 공간 또는 연료 효율성과 같은 다른 기능에서 추가 예비 부품을 치울 수 있으므로 이는 합리적인 절충입니다.
목표를 정의한 후 이후 단계(2단계: 설계 및 구현, 4단계: 운영)에서 관찰성 제어를 구현하여 목표가 충족되고 있는지 파악합니다.
중요한 애플리케이션 매핑
복원력 목표를 정의할 때 기술적 대화로만 국한되어서는 안 됩니다. 대신 비즈니스 중심의 초점에서 시작하여 애플리케이션이 전달해야 하는 사항과 장애의 결과를 이해합니다. 그런 다음 비즈니스 목표에 대한 이러한 이해는 아키텍처, 엔지니어링 및 운영과 같은 영역으로 점차 확대됩니다. 사용자가 정의한 복원력 목표는 모든 애플리케이션에 적용될 수도 있지만, 목표 측정 방법은 애플리케이션의 기능에 따라 달라지는 경우가 많습니다. 비즈니스에 중요한 애플리케이션을 실행 중일 수 있으며,이 애플리케이션이 손상되면 조직이 상당한 수익을 잃거나 평판에 해를 끼칠 수 있습니다. 또는 중요하지 않고 조직의 비즈니스 수행 능력에 부정적인 영향을 주지 않으면서 가동 중지 시간을 허용할 수 있는 다른 애플리케이션이 있을 수 있습니다.
예를 들어 소매 회사의 주문 관리 애플리케이션을 생각해 보세요. 주문 관리 애플리케이션의 구성 요소가 손상되어 제대로 실행되지 않으면 새 판매가 진행되지 않습니다. 이 소매 회사에는 건물 중 하나에 직원을 위한 커피숍도 있습니다. 커피숍에는 직원이 정적 웹 페이지에서 액세스할 수 있는 온라인 메뉴가 있습니다. 이 웹 페이지가 사용 불가능해지면 일부 직원이 불만 제기를 할 수 있지만 반드시 회사에 재정적 손해를 끼치는 것은 아닙니다. 이 예제를 기반으로 비즈니스는 주문 관리 애플리케이션에 대해 보다 적극적인 복원력 목표를 설정하기로 선택했지만 웹 애플리케이션의 복원력을 보장하기 위해 상당한 투자는 하지 않을 것입니다.
가장 중요한 애플리케이션, 가장 많은 노력을 기울일 부분, 절충할 부분을 파악하는 것은 프로덕션 환경에서 애플리케이션의 복원력을 측정할 수 있는 것만큼 중요합니다. 장애의 영향을 더 잘 이해하기 위해 비즈니스 영향 분석(BIA)을 수행할 수 있습니다. BIA는 중요한 비즈니스 애플리케이션을 식별 및 우선순위 지정하고, 잠재적 위험과 영향을 평가하며, 지원 종속성을 식별하는 체계적이고 체계적인 접근 방식을 제공합니다. BIA는 조직의 가장 중요한 애플리케이션에 대한 가동 중지 시간의 비용을 정량화하는 데 도움이 됩니다. 이 지표는 특정 애플리케이션에 장애가 발생하여 기능을 완료할 수 없는 경우 비용이 얼마나 드는지 설명하는 데 도움이 됩니다. 이전 예제에서 주문 관리 애플리케이션에 장애가 발생한 경우 리테일 비즈니스는 상당한 수익을 잃을 수 있습니다.
사용자 스토리 매핑
BIA 프로세스 중에 애플리케이션이 둘 이상의 비즈니스 기능을 담당하거나 비즈니스 기능에 여러 애플리케이션이 필요함을 발견할 수 있습니다. 이전 리테일 회사 예제를 사용하면 주문 관리 기능에 결제, 프로모션 및 요금을 위한 별도의 애플리케이션이 필요할 수 있습니다. 하나의 애플리케이션에서 장애가 발생하면 비즈니스 및 이 회사와 상호 작용하는 사용자가 영향을 받을 수 있습니다. 예를 들어 회사에서는 새 주문 추가, 프로모션 및 할인에 대한 액세스 제공 또는 제품 가격 업데이트와 같은 작업을 수행하지 못할 수 있습니다. 주문 관리 기능에 필요한 이러한 다양한 기능은 여러 애플리케이션에 의존할 수 있습니다. 이러한 기능에는 여러 외부 종속성이 있을 수 있으므로 순전히 구성 요소 중심의 복원력만 달성하려는 프로세스는 너무 복잡해질 수 있습니다. 이 시나리오를 처리하는 더 나은 방법은 사용자가 하나의 애플리케이션 또는 일련의 애플리케이션과 상호 작용할 때 기대하는 경험을 설명하는 사용자 스토리
사용자 스토리에 집중하면 고객 경험의 어떤 부분이 가장 중요한지 이해하는 데 도움이 되므로 특정 위협으로부터 보호하는 메커니즘을 빌드할 수 있습니다. 이전 예제에서 한 가지 사용자 스토리는 체크아웃일 수 있으며, 이는 체크아웃 애플리케이션과 관련이 있고 요금 애플리케이션에 종속되어 있습니다. 또 다른 사용자 스토리로, 홍보 애플리케이션과 관련된 홍보 표시가 있습니다. 가장 중요한 애플리케이션과 사용자 스토리를 매핑한 후 이러한 사용자 스토리의 복원력을 측정하는 데 사용할 지표를 정의할 수 있습니다. 이러한 지표는 전체 포트폴리오 또는 개별 사용자 스토리에 적용할 수 있습니다.
측정 정의
목표 복구 시점(RPO), 목표 복구 시간(RTO) 및 서비스 수준 목표(SLO)는 특정 시스템의 복원력을 평가하는 데 사용되는 표준 업계 측정입니다. RPO는 장애 발생 시 비즈니스에서 허용할 수 있는 데이터 손실의 양을 나타내는 반면, RTO는 중단 후 애플리케이션을 다시 사용할 수 있어야 하는 속도를 측정한 것입니다. 이 두 지표는 초, 분, 시간의 단위로 측정됩니다. 또한 애플리케이션이 제대로 작동하는 시간을 측정할 수 있습니다. 즉, 애플리케이션이 설계된 대로 기능을 수행하고 해당 사용자에게 액세스할 수 있습니다. 이러한 SLO는 고객이 받게 될 예상 서비스 수준을 자세히 설명하고 1초 미만의 응답 시간 내에 오류 없이 지원되는 요청의 백분율(%)과 같은 지표로 측정됩니다(예: 요청의 99.99%가 매월 응답을 수신함). RPO 및 RTO는 백업 복원부터 사용자 트래픽 리디렉션에 이르기까지 애플리케이션 운영 및 복구 프로세스가 중단될 것이라고 가정할 때 재해 복구 전략과 관련이 있습니다. SLO는 고가용성 제어를 구현하여 처리됩니다. 이는 애플리케이션의 가동 중지 시간을 줄이는 경향이 있습니다.
SLO 지표는 일반적으로 서비스 공급자와 최종 사용자 간의 계약인 서비스 수준 계약(SLA)의 정의에 사용됩니다. SLA는 일반적으로 재무 약정과 함께 제공되며 이러한 계약이 충족되지 않는 경우 제공업체에서 지불해야 하는 벌금을 간략하게 설명합니다. 그러나 SLA는 복원력 태세를 측정하는 것이 아니며, SLA를 늘리더라도 애플리케이션의 복원력이 향상되지 않습니다.
처음에 SLO, RPO 및 RTO를 기반으로 목표를 설정할 수 있습니다. 복원력 목표를 정의하고 RPO 및 RTO 목표를 명확하게 이해한 후 AWS Resilience Hub
추가 측정 생성
RPO, RTO 및 SLO는 복원력의 좋은 지표이지만 비즈니스 관점에서 목표에 대해 생각하고 애플리케이션 기능에 대한 목표를 정의할 수도 있습니다. 예를 들어 목표는 다음과 같습니다. 프론트엔드와 백엔드 간의 지연 시간이 40% 증가하면 분당 성공적인 주문은 98% 이상으로 유지됩니다. 또는: 특정 구성 요소가 손실되더라도 초당 시작된 스트림은 평균에서 표준 편차 이내로 유지됩니다. 또한 목표를 생성하여 알려진 장애 유형에서 평균 복구 시간(MTTR)을 줄일 수 있습니다. 예를 들어 이러한 알려진 문제가 발생하면 복구 시간이 x% 단축됩니다. 비즈니스 요구 사항에 맞는 목표를 생성하면 애플리케이션이 허용해야 하는 장애 유형을 예측하는 데 도움이 됩니다. 또한 애플리케이션 장애 가능성을 줄이기 위한 접근 방식을 식별하는 데도 도움이 됩니다.
애플리케이션에 전원을 공급하는 인스턴스의 5%를 손실한 경우 계속 운영하는 것이 목표라고 생각하면 애플리케이션을 사전 확장해야 하거나 해당 이벤트 중에 발생하는 추가 트래픽을 지원할 수 있을 만큼 빠르게 확장할 수 있어야 한다고 판단할 수 있습니다. 또는 2단계: 설계 및 구현 섹션에 설명된 대로 여러 아키텍처 패턴을 활용해야 한다고 결정할 수 있습니다.
또한 특정 비즈니스 목표에 대한 관찰성 측정을 구현해야 합니다. 예를 들어 평균 주문률, 평균 주문 가격, 평균 구독 수 또는 애플리케이션의 동작에 따라 비즈니스 상태에 대한 인사이트를 제공할 수 있는 기타 지표를 추적할 수 있습니다. 애플리케이션에 대한 관찰성 기능을 구현하면 이러한 지표가 정의된 경계를 초과하는 경우 경보를 생성하고 조치를 취할 수 있습니다. 관찰성은 4단계: 운영 섹션에서 자세히 다룹니다.
