기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
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단계: 운영 섹션에서 더 자세히 다룹니다.
